Gold collapsing. Bitcoin UP.

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
The cracks are showing. He's directly accusing users of being paid shills.
But didn't he do that before? Can't remember.

The other shoe is finally dropping, and Maxwell is openly explaining what a large proportion of the Bitcoin community have known all along but have been relentlessly attacked and abused for pointing out.

Segwit is not some mundane softfork, it's the opening move in an agenda to incrementally move Bitcoin toward central technocratic capacity control.
Indeed. The poison part of the pill. In that sense, it is terrifying that even 25% of the network chose to support this.
 

Inca

Moderator
Staff member
Aug 28, 2015
517
1,679
Not posted for a while. But the tide is turning. Hashing power moving to BU. The game is nearly up.

Bitcoin looks like it will break through this governance attack. A huge rally is brewing in the bitcoin space. Probably going to be timed with the ETF. I thought this would have all happened a lot sooner than it probably will but as long as it goes ahead thats fine.

Excellent! :)

ps. Maxwell will go down as a villain over the longer term history of bitcoin. He has made contributions but the negatives outweigh the positives considerably now.
 

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
So regarding my proposal, I must have overlooked this and I have to admit I am out of the loop regarding the current state of the code due to too much reddit. But @theZerg, it looks like getexcessiveblock and setexcessiveblock are already in the RPC interface, so basically there is everything in place to write a 'blocksize governor'?

That kind of makes my plan for a BUIP regarding RPC calls moot :D
 

Inca

Moderator
Staff member
Aug 28, 2015
517
1,679
It has just occurred to me that when we sign as ourselves in the BU proposals (or for anything online) we expose the public keys to our bitcoin addresses which could easily be farmed now and vulnerable in the far future.

Therefore I suggest no one uses their cold storage address to sign anything, ever. If you have, consider moving your funds as a precaution to a new address.
 

satoshis_sockpuppet

Active Member
Feb 22, 2016
776
3,312
@Inca
I see no reason to use an active address with more than a few dollars as a public key for signing.
Even more if you try to stay halfway anonymous.

once my node is all synced up and such, will i be receiving new blocks via thin blocks?

i kinda feel like Banning all the 0.13.1 peers off my node, do you see any problem with this?
I don't think it's a good idea and there is no reason to do that atm imho.
These nodes are fully validating nodes working with the same set of rules your node does.
If we have more than 50% of BU+Classic hashpower there would be a good reason to ban these nodes as they probably won't accept your blocks in the future.
 

Richy_T

Well-Known Member
Dec 27, 2015
1,085
2,741
So you know when one of your friends is being enthusiastic and trying to be helpful but you wish they'd just calm down a little bit...

So, my recollection is that we had a bit of a thing going on with BU, starting to gain a little ground but we got dissed by Gavin then there was Classic and whilst I was as hopeful that that would succeed as anyone, we had to wait for that to clearly fail before we could start turning attention back to the superior solution encapsulated by BU.

So now BU is starting to see some solid gains and adoption and its mechanisms are being explored, understood and internalized and finally accepted by many. And now Thomas Zander is stirring things up again with another new consensus discovery method.

I'm trying to be careful here because I don't want to be seen as attacking friends but I'd like to suggest that this is not exactly a great time to be introducing this and it would be good to see some consolidation of the adoption we've seen before we start with new mechanisms. We've made serious progress on presenting a clean and consistent vision and throwing in turbulence at this stage is more likely to turn people away than draw them in.

Not that we shouldn't be able to discuss such things. I just think there are more and less appropriate forums to do so.
 

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
@Richy_T : Unless I see good reason to do otherwise, I tend to BUIP0041 as a minor and sufficient adjustment to the EB/AD scheme to deal with @dgenr8's attack scenario.

I think @Tom Zander is still in brainstorming mode regarding a blocksize solution. And I think his solution would indeed be simpler. And I think that is great. But I also think BU (somewhat unfortunately (ossification due to political pressure), somewhat fortunately (it is gaining user-share)) is not :)

But I also fully agree that we should stick to what we have now, people like EB/AD, and I don't want to start confusion around this concept, potentially alienating a lot of users. Just because *I* like his solution doesn't mean that people running BU do. And I think customers/users are important.

Furthermore, it looks like his solution can be implemented using RPC calls and an external 'blocksize governor' program.
 

adamstgbit

Well-Known Member
Mar 13, 2016
1,206
2,650
@Richy_T : Unless I see good reason to do otherwise, I tend to BUIP0041 as a minor and sufficient adjustment to the EB/AD scheme to deal with @dgenr8's attack scenario.

I think @Tom Zander is still in brainstorming mode regarding a blocksize solution. And I think his solution would indeed be simpler. And I think that is great. But I also think BU (somewhat unfortunately (ossification due to political pressure), somewhat fortunately (it is gaining user-share)) is not :)

But I also fully agree that we should stick to what we have now, people like EB/AD, and I don't want to start confusion around this concept, potentially alienating a lot of users. Just because *I* like his solution doesn't mean that people running BU do. And I think customers/users are important.

Furthermore, it looks like his solution can be implemented using RPC calls and an external 'blocksize governor' program.
I agree BUIP0041 is the way to go, IMO it makes perfect sense that AD would grow proportional to the size of the EB violation. AD is a sort of AI which allows my node to pick the right chain while i'm away, BUIP0041 only makes the node smarter, if a block is only slightly bigger then my EB i'll want to converge on that new chain faster than if the block is 4X > my EB...

a quick read of @Tom Zander proposal, makes me think his solution is pretty much the same thing as BUIP0041, he says "The more a block goes over our limit, the higher the punishment." which sounds a lot like BUIP0041 from a high level point of view.

i think all this talk is sorta moot because minner wont actually attempt a bigger block then >51% is already willing to accept , but if they do, its nice to know the node will be smart and resist appropriately.
 
Last edited:

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
a quick read of @Tom Zander proposal, makes me think his solution is pretty much the same thing as BUIP0041, he says "The more a block goes over our limit, the higher the punishment." which sounds a lot like BUIP0041 from a high level point of view.
Yes, but he's proposing to make it softer, more analogue so that the penalty for blocks just over the limit is small and they are easier to slip through.

But that is different to EB/AD and I am very reluctant to change a promise to our users mid-flight.

What should happen (if I can find the time and agreement here :D) is to make a contrib/bsl-governors directory with a bunch of scripts implementing other optional blocksize proposals - such as his one. That would make BU the extremely compatible implementation (though in a sense it is already).
 

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
@Mengerian, @deadalnix: A couple thoughts while watching this:

- Yes, subchains would make it easier for miners to allow instant confirmation transactions. I wonder whether this is not also something that we should explicitly 'sell' to the miners as an alternative to off-chain stuff? I mean, one off-chain case is the instant confirmation, and with Subchains we can get there for small value stuff (and I think fast confirmation is of interest mainly there). Instead of fee-avoiding payment channels ...

- I like the distinction between the different nodes, for example UTXO serving nodes for SPV clients.

- Regarding the UTXO block and 'necessity of validating since the genesis block'. I have heard that argument from various people that this is the only way to stay trustless, but I disagree there on the trustlessness. Because there is (in theory, and this whole 'validating since genesis' idea is purely due to theoretical concerns!) no reason at all that I am not interacting with a made up world where a man-in-the middle handed me the wrong Genesis block. There is no trustlessness. Everyone is trusting the Genesis block. The difference with UTXO commitments and TXN data for a year would be that no-one invented another blockchain within that year and got all that piled-up hashpower as visible in the blockheaders. So they'd also need to do that in secret and then suddenly convince everyone around the planet that they are the good guys. So I think that scenario of running from UTXO-commitments plus partial history is like today's full node security minus an arbitrarily small epsilon (with the epsilon depending on your willingness to validate old history).

- I am still not convinced that we're going to have or want sharding (not only specialization on function, but also on data), but I am willing to entertain the idea. And your talk at least made the picture a lot more clear to me what you imagine sharding will be. I think it would help here (for the next talk or so) to draw a nice picture with nodes and so forth and who's going to hold and/or validate what data.
 

lunar

Well-Known Member
Aug 28, 2015
1,001
4,290
We just touched $795 US and $808 in China.

It's by no means linear, but since September last year, 15 months ago, bitcoin has risen on average ~ $1.25 a day.

Considering the utter shitstorm of controversy, and what can only really be described as bitcoins stubborn argumentative Adolescent period. This is quite a remarkable achievement.
 

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
krugman doubles down on bitcoin :ROFLMAO:
Well, I bet he has strong ties to others of TPTB (cough, Bilderberg, cough, AXA, ...), so maybe we should be worried?

What gives me hope is that Russia as well as China have a comparatively quite low amount of public debt, and so a successful Bitcoin presents a nice lever for those countries to screw with the West.

A lever that might create problems (for the government) further down the road in their own country, but a lever nonetheless.

And I do not believe in a 'one world government' conspiracy.

That said, it would be tragically ironic if the west starts to build another great internet firewall against Bitcoin to shield against this effect.

I also sometimes wonder whether that kind of war in the shadows between Russia, China and the U.S. isn't what is underpinning the current blocksize 'debate' in the end.
 

albin

Active Member
Nov 8, 2015
931
4,008
Krugman is running a very unique and noteworthy scam. His work that the general public is actually aware of is just run-of-the-mill political talking-head punditry that has essentially zero direct basis in any actual rigorous academic work, but establishment left-wingers get to point at his credentials to fraudulently sell toxic lay political just-some-guy-isms as the stuff of Nobel Laureatehood.

Despite his handwavy objections to Bitcoin (which entirely comprise regurgitating Keynes's handwavy argument about gold), he's ironically the perfect role-model for the political machinations of Core devs.
 
Last edited: