Gold collapsing. Bitcoin UP.

[_mr_e]

He's clearly admitted that these issues are a people problem. Any decentralised system we design will have these same political issues, is he denouncing decentralization completely? Why can't he understand that the free market can sort these things out and that this issue is nothing more then the symptoms of a very young system going through growing pains?

I don't actually believe that he's sold all his coins...

 

[cypherdoc]

huh, i've never seen this post by Satoshi to Mike. at least that i can remember. he made it so clear that Bitcoin can scale:

http://bitcoinfoundation.org/forum/index.php?/topic/54-my-first-message-to-satoshi/#entry533

 

[cypherdoc]

Classic doesn't look to include RBF of any kind. that's good. BU shouldn't as well.

 

[Roger_Murdock]

Peter Todd is totally jumping the shark here, because nobody except btcd and libbitcoin is actually re-implementing anything consensus-related. XT/BU/Classic/etc. all make fairly trivial consensus code changes merely to blocksize, and btcd being a true re-implementation is developed by some serious pros who really appear to know their stuff (as opposed to being experts on social media pontification) and have contributed immensely to finding edge cases. I don't know much about libbitcoin, but it appears that it's really only prominently used for the (now largely abandoned?) Darkwallet and Airbitz's servers, so the systemic risk of consensus failure is pretty contained.

Yeah, unless I'm missing something, alternative "implementations" (in the context of that quote) referred to two code bases attempting to produce identical behavior whereas a "fork" is attempting to change the network's behavior. It's absurd to use Satoshi's quote with respect to the former to suggest that he was somehow against the latter. A Bitcoin that couldn't be forked wouldn't be decentralized which would, you know, sort of defeat its entire purpose.

Someone on reddit brought this other Satoshi quote to my attention which seems a tad more on point:

Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.

 

[Zangelbert Bingledack]

Mike Hearn likes to turn up the heat with a little sensationalism. Interesting timing, though, with the tide turning as it is. What we are NOT seeing is complaints from users about backlog plastering the subreddits. That will happen if things continue without progress, but it is premature to conclude that people won't move to avoid the oncoming train. I think he just wants to strike fear into people's hearts, instigate a price drop, and drive Core out.
[doublepost=1452817245][/doublepost]@cypherdoc

Yes I think user config of blocksize limit is inconsistent with the original "take blocksize out of the consensus layer and put it back in the transport layer" idea. This can be seen as a way of saying BU sees the blocksize limit as unnecessary but does not consider it the developers' place to try to tether decisions on controversial issues to the implementation. It's a stance that recommends ignoring blocksize but makes no pretense toward central planning.
[doublepost=1452817312][/doublepost]And yes, Bitcoin bucks exceedingly hard. Now I don't want to hear any fool in 2017 tell the Bitcoin new rich that they didn't earn their money.

 

[cypherdoc]

@Zangelbert Bingledack

thanks for answering.

but then, shouldn't blocksize limits then also be taken out of the hands of everyone? why should full node operators be given preference to set limits? mind you, i agree that BU w/o a limit at_all isn't likely to get accepted at this day and age. i think it's an idea too far ahead of it's time, despite it being in the WP, as @Peter R said yesterday. that said, i do want to nail down the theory of maybe not using the user config within an implementation such as BU. another way of saying this is that maybe the market wants users/full node (non mining) operators to express their blocksize limit preferences by choosing the implementation that coincides with their beliefs instead of having the freedom to directly set a limit in their individual clients within an implementation. reason being, i'm noticing that miners and devs being hesitant to participate in BU. yesterday's announcement by Gavin to help with BU is the first time i actually heard him say that. but he's it. i personally asked Jeff to help out or run for an office. clearly, he's not interested. he did sign up to help with Classic though along with Gavin. what i think it is gonna have to happen is that we accept less of what we consider as ideal at this stage of the game and swallow Classic simply to get the ball moving. getting core dev out of the equation is a big enough incentive to me. the Classic Team seems to have the longer picture in mind as well. which then brings me to adaptive block sizes per Bitpay. i really like that idea b/c it puts a mathematical limit in place that gets recalculated every 2 wks. that could equate to exponential growth if need be. it also seals off the single exablock attack quite nicely. my only concern about BU allowing everyone to set their own limits has to do with multiple small forks. maybe i don't understand it as well as some of you b/c i was never for it but it seems there could be quite alot of hashing wasted on these multiple smallish forks. how messy does it get? my sense is that miners won't like this b/c it introduces quite a bit of uncertainty into their equations if their blocks aren't getting relayed b/c BU has allowed ill-defined limits to get back into the consensus layer. the adaptive limit of 2MB initially is a well defined target miners can hang their hats on at least psychologically while being confident their blocks will be relayed.

 

[Melbustus]

Sheesh. Mike obviously makes quite a few good points, but man he has a flair for the over-dramatic.

While I agree that blocksize and the governance issues it exposes are the biggest threats bitcoin has faced, I'm tentatively starting to feel like we're on our way to a better path....finally. Shame that Mike bails *now*, but I can understand the frustration, especially being so viciously attacked all day every day by bitcoin's many 14 year olds (at heart or literally).

Anyways, I agree with @rocks' post upthread - the fact that Coinbase et al *must* make a move to survive, and that Bitcoin Unlimited is getting traction, and that Bitcoin Classic now has both Gavin & Jeff onboard, makes me think that we *will* get a hard-fork blocksize increase in 2016. While it may not be the long-term solution that it should be, even a successful 2MB hard-fork dramatically reduces the importance of the devs who work for Blockstream to the overall governance of the Bitcoin protocol, and therefore does quite a bit to restore my faith in Bitcoin's ability to remain what its users want it to be.

 

[bucktotal]

i honestly couldnt read the whole thing. skimmed it. i'd hate to see him miss out on this ride of a lifetime, but maybe he needs a break. i can understand that. i would be surprised if he actually sold his coins. that'd just be nuts.

 

[theZerg]

But BU doesn't have a limit. When the excessive block 8s exceeded it simply refuses to relay and does not update the gui in the hopes we don't orphan. So the display and transport is affected not consensus.

How are guys who have been with BU this whole time talking limit again?

 

[cypherdoc]

But BU doesn't have a limit. When the excessive block 8s exceeded it simply refuses to relay and does not update the gui in the hopes we don't orphan. So the display and transport is affected not consensus.

How are guys who have been with BU this whole time talking limit again?

the refusal to relay is what i'm talking about. the self selected limit won't relay valid blocks exceeding it. that, by itself, is a threat to miner adoption since the network wide true limit is unknown and is back to a form of consensus layer decision making b/c it's possible not to relay valid blocks.
[doublepost=1452826125,1452825510][/doublepost]@theZerg

maybe the solution is to remove the language from the Articles about moving blocksize to the transport layer? at least we will then be consistent altho i think willingness to adopt by miners and devs still suffers.

 

[Peter R]

Like ZB said, XT cracked the Core, Unlimited blew it apart, and now Classic is drinking its sweet nectar.

To keep the momentum going, I think we need to make it clear that the primary goal is to get that first 1.1 MB block into the Blockchain and decentralize away from Core. How we achieve this goal is secondary.

1. We need to break people out of the "one-implementation-to-rule-them-all" mindset. Implementations can be made compatible (and in fact symbiotic). For example, running Unlimited helps Classic and running Classic helps Unlimited. If people really understand this, then hopefully they migrate away from Core to more than one implementation, in order to split the power and help avoid another developer centralization crisis like the one that occurred with Blockstream.

2. The community needs to understand that there is no way to be 100% sure that the first block > 1 MB will be accepted by the network other than by mining one and seeing if it sticks. This problem is fundamental and would apply even if all the nodes were still running Core. Because of this, online forums should be open and censorship free, nodes should signal their preferences in the user-agent string, and businesses and thought leaders should make clear statements.

Regarding Bitcoin Unlimited development in particular, I think the most important task right now is implementing BUIP005 (block size limit signalling in the user-agent string). I think the community will be intrigued to watch this data as more and more nodes start to signal their preferences. Many people still seem confused about what "Bitcoin Unlimited" is all about, but I think they'll start to "get it" when they see graphs and tables that summarize the preferences of a bunch of nodes.

 

[cypherdoc]

@Peter R

i'd like your opinion on whether BU is being consistent in claiming it has moved blocksizes to the transport layer while at the same time allowing users to configure their nodes to relay only blocksizes they choose regardless of their validity of construction.

 

[Peter R]

@cypherdoc

I think it is consistent--with BU there's no longer a hard-coded limit. Each node instead enforces a sort of "soft limit" from which emerges an effective limit for the network.

I also don't share your concern regarding miners being spooked to produce bigger blocks if a significant fraction of the network is running Unlimited. I think in practice, the effective "limit" imposed by the nodes will be significantly higher than the limits the miners agree to adhere to anyways. For example, I would leave my node's limit set to the 16 MB default (and be quick to increase it if blocks got close to that, so long as I was confident the network could support it) but I don't suspect miners would produce anything over 2 MB for a while.

The only time I think that miners would be spooked to produce larger blocks is if they genuinely were making jumbo blocks that the majority of the network thought were filled with spam. In such a case, the nodes might revolt by signalling lower limits! But this would be a good thing in my opinion. This "check" on the miners is also why I like the idea of miners running different software than the nodes (perhaps miners eventually agree to something like BitPay's algorithm while nodes run BU).

 

[Zangelbert Bingledack]

@cypherdoc

Communication is paramount, but I don't see why it has to be tied to implementation. My idea is that the blocksize will be just as solidly known as it is now, because Schelling points are what really decide the limit and there is overwhelming incentive to converge on a Schelling point. @theZerg places more emphasis on the acceptance depth, whereas I see it as more of a theoretical failsafe for miners and a practical one for nodes.

You seem to imply that blocksize should be tied to the implementation because that will attract devs (correct me if this isn't your view), but that seems to attract devs who want to be central planners or be able to dictate consensus parameters to users, or at least use their clout/fanbase to push them toward that. As a practical matter you may be right, but if you want to talk theory and endgame I don't see it.

 

[JVWVU]

So let's say this is true, can we pick one guy every day over the next 3 weeks to do this and have a sell off like we are seeing, maybe all the 1MBers would get hedged out.

 

[Roger_Murdock]

If Brian Armstrong's theory is true, I'd find that disappointing as it indicates that Mike Hearn is being disingenuous. I don't like FUD even when it's friendly FUD.

 

[cypherdoc]

actually, i was disappointed Brian would even think such a thing of Mike.

 

[Mengerian]

That's really sad that Mike sold his coins.

While I agree that blocksize and the governance issues it exposes are the biggest threats bitcoin has faced, I'm tentatively starting to feel like we're on our way to a better path....finally.

Yes, I agree with this. Bitcoin is facing its biggest existential challenge yet. But if it can survive this, can you imagine how much more confidence we can have in its future resilience? Sometimes I almost feel like it is necessary for Bitcoin's growth to be painful. So yeah, its a scary time, but if we can get through this and come out stronger, Bitcoin will seem almost unstoppable.

If Bitcoin is to succeed, it must confront and overcome everything that could possibly destroy it

 

[Zangelbert Bingledack]

It *is* necessary for Bitcoin's growth to be painful. We know exactly how many people would be using this forum if the Theymos forums had stayed perfectly neutral and censorship-free. Zero. Theymos's power would have grown and grown until either it finally corrupted him or someone got to him. Better it happened now than later. Same story with Core.

 

[awemany]

So let's say this is true, can we pick one guy every day over the next 3 weeks to do this and have a sell off like we are seeing, maybe all the 1MBers would get hedged out.

Dangerous game. It might well be that the 1MBers like his departure and are buying. Of course, as there are (still) fewer of them than disillusioned bigblockers, it still results in a net price drop.

I hope for Mike he didn't sell all his coins - it would be a pity if he as an early adopter and driver of progress loses out because Core is finally being worked around.

I could see that either explanation is true: Mike's motivating with inverse psychology, but also that he's simply burned out by the coropaths. And as someone else said, from his perspective, XT looks like a failure.