The Barry Silbert segwit2x agreement with >80% miner support.

[ComputerGenie]

...the core devs are in a decentralized, open source github project, which you yourself are welcome to join and that far more of them are volunteers, not working for any company...

I'm not sure if it's sad  or cute  that you (and your ilk) actually believe that. 
Perhaps one day you'll even learn the difference between a "developer" (dev) and a "contributor"  ; if that day ever comes, perhaps you'll be able to be a proactive part of this conversation. 


(emoticons for requested effect)

[1714755506]

1714755506

[1714755506]

1714755506

[1714755506]

1714755506

[Haladay]

I really don't understand something. Will only miners take the most important decissions about bitcoin and its future? This is purely stupid. I think miners are seeing themselves as the ruler of blockchain, this is terrible.

[ComputerGenie]

...I think miners are seeing themselves as the ruler of blockchain, this is terrible.

I'm sure someone will slam me for "semantics"; however, you do realize that, since Bitcoin is a POW system, there is no "blockchain" without "blocks"*, right?  




*you know, "those things that are only produced by miners"

[ComputerGenie]

...So if I listen to YOUR ilk, I'd think that a minimum of 45 or more different core devs work for Blockstream.....paid to be a journalist here in 2012.

So, when you write your paid writings, do you use any journalistic integrity or do you just make stuff up like you do in this thread? Since you're a "journalist", I'd like for you to cite a single source where I've ever mentioned a singular relation between "Blockstream" and "core devs"....Or are you actually so misinformed that you think that Blockstream is the only source of financial backing into Core and conflate the idea of "income" and "Blockstream" into one word?  

[BTCLuke]

I noticed that you had nothing to say about most every rebuttle I made except one that you found a tiny hole in. I'll take that as near-total victory.

Since you're a "journalist", I'd like for you to cite a single source where I've ever mentioned a singular relation between "Blockstream" and "core devs"

You haven't paid me so I don't see why I'd be inclined to do that research.

However, I'll concede that you didn't make the direct link in this thread if you can concede that this is the common link people make. I'll give you the benefit of the doubt that you feel the problem is more widespread than one company. Hopefully you can see that so, too, are the core devs.

I speak to several of them on a daily basis and keep up with the linuxfoundation devlists. In doing so, I see more infighting between them than I do agreement by far. If they were financially incentivized to do something for their bosses, you'd expect to see more agreement on the attack against decentralization/freedom. That is actually pretty rare and I only tend to find argument about how decentralization can best be acheived.

Edit: I don't see any other teams around here even fighting towards that goal so why would anyone consider any team but the core devs?

[JayJuanGee]

I am only glad that finally someone is doing something and "we" are not just talking until the world ends

Segwit Implementation sometime before August 1st seems like a done deal so the UASF is basically moot.

Then if hashrate keeps supporting the 2 MB hard fork this will also happen.

And yes: now the bad bad miners are activating SegWit and not good core, but well .... Core just couldn't do it, so get over it

I don't see any purpose in describing the situation as some kind of competition.

If in the end, some variation of segwit is implemented first because we achieve a higher consensus with that, then why would core be against that, unless there is some fault with the variation of seg wit that is going to be implemented.  Sounds like something that they were agreeable to  in the first place, and sounds like some of the miners are coming around , maybe due to threat of UASF and also some of the ridiculous Jihan Wu (bitmain) bullshit that was being proposed.

[CoinCube]

How ridiculous the face saving code has become is nicely summarised by Samson Mow.

Letter to signal intent to use "NYA" coinbase signal to signal using bit4 to signal bit1 to signal BIP141 activation.

Instead of just signalling BIP141... One day history will look back upon our blockchain and facepalm. Heck I think it already is.

Meanwhile support just hit 64% over the last 24 hours.

For those non-developer non-miner folks like me who found the the bit signaling thing to be confusing here is a nice write-up that explains it pretty well.
https://bitcoinmagazine.com/articles/bip91-segwit-activation-kludge-should-keep-bitcoin-whole/

[Last of the V8s]

What's also amusing is the corresponding drop in transactions back to normal basal levels again now that all those pools are in agreement about what to do next. This adds circumstantial evidence that someone was injecting all that shit into the transaction biosphere to make it look like there was a transaction volume crisis there that didn't exist.

I pointed out the drop in mempool spam a few weeks ago and nobody commented. What's interesting is fees haven't gone down, probably because the blocks are still full and people have their fees cranked up to avoid stuck transactions. Since the blocks are full, I'm guessing that fake volume with a lot of inputs was clogging the mempool. I also saw last month 1000s of transactions that were invalid, that slowed the network down, indicating an actor with high technical knowledge.

I'm hoping somebody who is more technically knowledgeable than me can figure out who was/is spamming. I know it's not that easy to attribute the transactions. Chances are we could at least get a source IP address, and then work from there...

aliens https://bitcointalk.org/index.php?action=trust;u=197593

[ComputerGenie]

I noticed that you had nothing to say about most every rebuttle I made except one that you found a tiny hole in. I'll take that as near-total victory.

Since you're a "journalist", I'd like for you to cite a single source where I've ever mentioned a singular relation between "Blockstream" and "core devs"

You haven't paid me so I don't see why I'd be inclined to do that research.

However, I'll concede that you didn't make the direct link in this thread if you can concede that this is the common link people make. I'll give you the benefit of the doubt that you feel the problem is more widespread than one company. Hopefully you can see that so, too, are the core devs.

I speak to several of them on a daily basis and keep up with the linuxfoundation devlists. In doing so, I see more infighting between them than I do agreement by far. If they were financially incentivized to do something for their bosses, you'd expect to see more agreement on the attack against decentralization/freedom. That is actually pretty rare and I only tend to find argument about how decentralization can best be acheived.

Edit: I don't see any other teams around here even fighting towards that goal so why would anyone consider any team but the core devs?

You're almost to the point where you're no longer putting words in my mouth.  
I never said, or implied, that Core devs are beholden to "bosses" or some "centralized" anything.
Core devs (and by this I mean the ones that "matter", hold the most "control" over what Core is/does, and derive a "living wage" from it) are beholden to Core (and the "living wage" they get from it).
The more wallet choices that exist is the less relevant any one wallet is.
Core (and the devs that derive a "living wage" from it) must maintain the historical relevance as well as the relevance of Core in the future.
If Core (and the devs that derive a "living wage" from it) do not maintain future relevance, Core's "power" in/over Bitcoin will become something of only historical value (and the devs that derive a "living wage" from it will no longer do so).
Core (and the devs that derive a "living wage" from it) must maintain the perception of "innovation" (even in the absence of any).
Core (and the devs that derive a "living wage" from it) cannot survive the future, intact, if Core ever looses the foothold control of being "the" maintainer(s) of the protocol.
Core (and the devs that derive a "living wage" from it) must look out for Core (and the devs that derive a "living wage" from it) first, and foremost.
Core (and the devs that derive a "living wage" from it) must maintain the status of Core and "if that happens to be good for Bitcoin as a whole, great; if not, meh"....

[Variogam]

I really don't understand something. Will only miners take the most important decissions about bitcoin and its future? This is purely stupid. I think miners are seeing themselves as the ruler of blockchain, this is terrible.

No, the initiative to SegWit2x come from Bitcoin business, miners and individuals:
https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77

Miners would not activate SegWit2x if there was not clear support/acceptance for it from Bitcoin business, including exchanges.

[-ck]

Up to 78.5% over the last rolling 24 hours now.

[Variogam]

How ridiculous the face saving code has become is nicely summarised by Samson Mow.

Letter to signal intent to use "NYA" coinbase signal to signal using bit4 to signal bit1 to signal BIP141 activation.

Instead of just signalling BIP141... One day history will look back upon our blockchain and facepalm. Heck I think it already is.

Except NYA coinbase signal means both BIP141 and 2MB base blocksize. The point of the SegWit2x is prevent the possible Aug 1 Bitcoin split and the code is similar to what was expected from early 2016 HK roundtable meeting between Core representatives and miners. If Core was any good, we would already have SegWit activated 6 months ago and the 2MB base blocksize later this year as well. But whatever, it works without Core as well, which is positive signal to me.

Up to 78.5% over the last rolling 24 hours now.

Why the excitement about the NYA coinbase? SegWit2x code not fully tested yet, so expect true activation next month. Still the hard part comes when 2MB base blocksize becomes active in few months - time for bit more drama probably.

[-ck]

Except NYA coinbase signal means both BIP141 and 2MB base blocksize. The point of the SegWit2x is prevent the possible Aug 1 Bitcoin split and the code is similar to what was expected from early 2016 HK roundtable meeting between Core representatives and miners. If Core was any good, we would already have SegWit activated 6 months ago and the 2MB base blocksize later this year as well. But whatever, it works without Core as well, which is positive signal to me.

It does mean both indeed and it is just a vote not a signal at this stage, however it does mean there is enough commitment for segwit to get activated. I don't really understand the sentiment of "If core was any good" when segwit not getting activated by the original mechanism was for social reasons, not technological, and ultimately miners will be activating core's designed and implemented segwit technology through this, just through their own signalling mechanism which was a disastrous incompatible design originally and James Hilliard made it compatible through the multiple bit communication mechanism.

Once segwit activates through the convoluted bit mechanism, all the user nodes out there will still be accepting and activating segwit through the original BIP141. If the users don't move off core nodes, that's when the real battle comes indeed because without core code supporting the 2MB hard fork we'll be really facing a split. Let's worry about that hurdle when we come to it.

As I've said before, I'm not personally against a 2MB base blocksize increase either, I just believe that any split can only be bad for bitcoin. Having to force someone's hand to adopt a position is again purely for social reasons and it would be nice if people just agreed but that's fairytale thinking now. The stakes are so high and everyone doesn't want to relinquish what control they (think they) have.

[JayJuanGee]

Except NYA coinbase signal means both BIP141 and 2MB base blocksize. The point of the SegWit2x is prevent the possible Aug 1 Bitcoin split and the code is similar to what was expected from early 2016 HK roundtable meeting between Core representatives and miners. If Core was any good, we would already have SegWit activated 6 months ago and the 2MB base blocksize later this year as well. But whatever, it works without Core as well, which is positive signal to me.

It does mean both indeed and it is just a vote not a signal at this stage, however it does mean there is enough commitment for segwit to get activated. I don't really understand the sentiment of "If core was any good" when segwit not getting activated by the original mechanism was for social reasons, not technological, and ultimately miners will be activating core's designed and implemented segwit technology through this, just through their own signalling mechanism which was a disastrous incompatible design originally and James Hilliard made it compatible through the multiple bit communication mechanism.

Once segwit activates through the convoluted bit mechanism, all the user nodes out there will still be accepting and activating segwit through the original BIP141. If the users don't move off core nodes, that's when the real battle comes indeed because without core code supporting the 2MB hard fork we'll be really facing a split. Let's worry about that hurdle when we come to it.

As I've said before, I'm not personally against a 2MB base blocksize increase either, I just believe that any split can only be bad for bitcoin. Having to force someone's hand to adopt a position is again purely for social reasons and it would be nice if people just agreed but that's fairytale thinking now. The stakes are so high and everyone doesn't want to relinquish what control they (think they) have.

I'm not sure if I understand the full implications what you are saying -ck.  

This is like an ambiguous compound question, and not really a package deal, right?

I think that I agree with you that there is a less controversial part of the compound question (which seems to be a kind of softfork implementation of segwit) and a more controversial part (which seems to involve both 2mb upgrade and the idea of a hardfork that might be attempted to employ with less than 95% consensus).


Now if the less controversial part of segwit goes through and begins to be used by anywhere between 80% and even more than 95% of the network, at some point, that usage would become a kind of permanency, no? , especially if the hashrate goes over 95% and is sustained over 95%?  

So yeah, we are already seeing that folks seem to be jumping onboard to the concept of getting segwit activation, but surely some of those who are currently jumping on board might feel that they are being misled if they think that either the 2mb upgrade or the concept of an actual hardfork would be automatically implemented, merely because the segwit portion was implemented - because even the language of implementation requires that the 2mb aspect be tested first and the 2mb aspect reach consensus (I am unclear if 80% would be sufficient or probably 95% would be sufficient, no?).  

I really don't think that 80% is going to be enough for either a hardfork or 2mb upgrade, but maybe I have an incorrect understanding about what is going on and how these implementation matters are triggered and at which points hashing power might be pulled out of the project after we thought that we had a permanent resolution (or at least a partial resolution - and that is the segwit part of the implementation).

So, there seems to be two fairly obvious ways that the 2mb part of the implementation can fail.  1) fail to pass tests and 2) fail to achieve consensus ...

so we already got a lot of folks out there screaming that segwit2x is a kind of package, when the first part of segwit seems to be agreed upon; however, the second part of the deal (the 2mb aspect) seems to have contingencies.  So, if it ends up that the second part does not go through, then then a large number of folks will be whining that Core broke the agreement, blah blah blah.. and the 2mb aspect was supposed to be "guaranteed", just like (and maybe even worse) they were mischaracterizing and whining about the Hong Kong agreement. 

Where am I going wrong in my thinking, here?

[Paashaas]

Will the other miners who signal Bip141 join the party?

[cryptonia]

Is there a blog or a link that summarises the current state of play in an easily understandable  way?

Thank you

[Auxi]

Is there a blog or a link that summarises the current state of play in an easily understandable  way?

Thank you

I need it too, i found: https://bitcoinmagazine.com/articles/bip91-segwit-activation-kludge-should-keep-bitcoin-whole/

[Viper1]

Except NYA coinbase signal means both BIP141 and 2MB base blocksize. The point of the SegWit2x is prevent the possible Aug 1 Bitcoin split and the code is similar to what was expected from early 2016 HK roundtable meeting between Core representatives and miners. If Core was any good, we would already have SegWit activated 6 months ago and the 2MB base blocksize later this year as well. But whatever, it works without Core as well, which is positive signal to me.

It does mean both indeed and it is just a vote not a signal at this stage, however it does mean there is enough commitment for segwit to get activated. I don't really understand the sentiment of "If core was any good" when segwit not getting activated by the original mechanism was for social reasons, not technological, and ultimately miners will be activating core's designed and implemented segwit technology through this, just through their own signalling mechanism which was a disastrous incompatible design originally and James Hilliard made it compatible through the multiple bit communication mechanism.

Once segwit activates through the convoluted bit mechanism, all the user nodes out there will still be accepting and activating segwit through the original BIP141. If the users don't move off core nodes, that's when the real battle comes indeed because without core code supporting the 2MB hard fork we'll be really facing a split. Let's worry about that hurdle when we come to it.

As I've said before, I'm not personally against a 2MB base blocksize increase either, I just believe that any split can only be bad for bitcoin. Having to force someone's hand to adopt a position is again purely for social reasons and it would be nice if people just agreed but that's fairytale thinking now. The stakes are so high and everyone doesn't want to relinquish what control they (think they) have.

I think for people saying things like "if core was any good", they actually mean if core listened to what the community wanted.

In terms of the potential for a split afterwards, if core believes that the community are the ones that "vote" on what code is bitcoin, then why would they continue with "their" code that was rejected.

I'm really confused by your "forcing someone's hand" comment. It just looks to me like the community is doing what they need to since core didn't seem to want to listen to them but instead wanted to build their own vision of bitcoin. Is that the way it's supposed to be? IF (and I think it's a big if at this point), the 2M hard fork actually happens, it will be very interesting to see what many of the core devs end up doing as that will let lots of people know what they really believe in.

[CoinCube]

so we already got a lot of folks out there screaming that segwit2x is a kind of package, when the first part of segwit seems to be agreed upon; however, the second part of the deal (the 2mb aspect) seems to have contingencies.  So, if it ends up that the second part does not go through, then then a large number of folks will be whining that Core broke the agreement, blah blah blah.. and the 2mb aspect was supposed to be "guaranteed", just like (and maybe even worse) they were mischaracterizing and whining about the Hong Kong agreement. 

Where am I going wrong in my thinking, here?

It's a package deal SegWit first followed by 2MB later. Those signalling are agreeing to activate SegWit and also support a later hard fork to increase the block size.

Now it is true that major players could lie and later retract their support for 2MB sort of a "ha ha I got mine" approach to negotiation but this would be utterly destructive to trust and kill any chance for future upgrades to the protocol for the foreseeable future.

You can't build a consensus on falsehood. Once commitments are made they should be honored. Otherwise it is very bad news for all of us as the consensus system will become nonfunctional.

[-ck]

So, there seems to be two fairly obvious ways that the 2mb part of the implementation can fail.  1) fail to pass tests and 2) fail to achieve consensus ...

so we already got a lot of folks out there screaming that segwit2x is a kind of package, when the first part of segwit seems to be agreed upon; however, the second part of the deal (the 2mb aspect) seems to have contingencies.  So, if it ends up that the second part does not go through, then then a large number of folks will be whining that Core broke the agreement, blah blah blah.. and the 2mb aspect was supposed to be "guaranteed", just like (and maybe even worse) they were mischaracterising and whining about the Hong Kong agreement.  

Well assuming the segwit2x code is ready before mid July and the 80+% that are advertising NYA go ahead and adopt the code, then they will be actively dropping any blocks not signalling segwit at that time, and those running BIP141 nodes will automatically end up on the longest chain regardless since it will be >80% of the hashrate. Since all of the blocks on that branch must advertise segwit, it is guaranteed that segwit will activate after the two diff periods - one lock in period and then the one to activate it - since it will be 100% segwit signalling and >95% required by BIP141.

As for what happens after that, as you have correctly surmised, if core never adopts the 2MB hard fork code from segwit2x, then the bulk of the users using core's client will end up on a very low hashrate fork of bitcoin if the miners go ahead with their fork regardless. Claiming that "core broke the agreement" is likely on their part, but then - core never agreed to segwit2x in the first place! It is the segwit2x miners that agreed indirectly to activate segwit, not the other way around. Once segwit activates, there is also nothing preventing miners from going back to the core client as well and maintain the status quo, though the signed agreement is a contract of sorts.

What is likely to happen is after segwit gets activated, the pressure on transactions will no longer seem present; especially since there doesn't appear to truly be a transaction crisis at all since transaction spam suddenly and magically disappeared after the segwit2x agreement. If we reach a new deadlock there (and there's a good chance we will) then I suspect the transaction spam will magically appear again, larger than ever, and there will be cries that we desperately need the 2MB expansion as well. As I've said before, most of core has said they'd support a block size increase but at a less frantic pace. I suspect the miners will maintain their pressure of their own hard fork claiming that core will backpedal on their agreement if they don't (as you said they claimed about the HK agreement - none of which actually happened.)