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

[ComputerGenie]

@JayJuanGee
You're right, there's nothing left for you and I to discuss (especially since you seem to keep wanting to go on about things that you don't want to educate yourself about and, based on that, you confuse facts with "unnecessary negative accusations").  




P.S. - it's not an "unnecessary negative accusation" to assert the fact that Core's main obligation is to Core and the collective beliefs of Core.  

[1714904929]

1714904929

[1714904929]

1714904929

[1714904929]

1714904929

[1714904929]

1714904929

[1714904929]

1714904929

[JayJuanGee]

@JayJuanGee
You're right, there's nothing left for you and I to discuss (especially since you seem to keep wanting to go on about things that you don't want to educate yourself about and, based on that, you confuse facts with "unnecessary negative accusations").  

It's like arguing that I have failed to read encyclopedia brittanica because all the answers are in there somewhere, and without specifying where or what I am supposed to look for.

I think that I am sufficiently educated about whatever we had been talking about.  You are the one making vague accusations that are not really backed up.. I am supposed to educate myself about your vague accusations and you don't even tell me what I am supposed to look for, besides core members being a bunch of tyrants?

P.S. - it's not an "unnecessary negative accusation" to assert the fact that Core's main obligation is to Core and the collective beliefs of Core.  

Yeah, but you did not back up any of that with any kind of evidence, so it is really not helpful and it seems to have slid mostly into non-relevance because you cannot even show how it is even remotely relevant (except for the point conceded by everyone, including myself that an overwhelming majority of Core devs wanted to have seg wit implemented), when it appears that we are going to get segwit consensus from 95% or more of the hashing power, and not all of those miners and various community supporters who are facilitating the achievement of 95% consensus are not core, are they?

[ComputerGenie]

...It's like arguing that I have failed to read encyclopedia brittanica because all the answers are in there somewhere, and without specifying where or what I am supposed to look for....

No, it's like you saying:

I don't have to read the Encyclopedia Britannica volumes to know that the Encyclopedia Britannica doesn't support your conclusions and that you're making 'unnecessary negative accusations' about the Encyclopedia Britannica, because I've already made up my mind that the Encyclopedia Britannica doesn't support your conclusions and that you're making 'unnecessary negative accusations' about the Encyclopedia Britannica (even though I haven't read a single volume of the Encyclopedia Britannica). Also, I don't have to read the Encyclopedia Britannica volumes to know that the Encyclopedia Britannica doesn't contain evidence of the contents of the Encyclopedia Britannica.

I'm too tired for your silliness .... I concede; you're 100% right, I'm 100% wrong.... Take the "win" and go on about your merry little way.  

[JayJuanGee]

...It's like arguing that I have failed to read encyclopedia brittanica because all the answers are in there somewhere, and without specifying where or what I am supposed to look for....

No, it's like you saying:

I don't have to read the Encyclopedia Britannica volumes to know that the Encyclopedia Britannica doesn't support your conclusions and that you're making 'unnecessary negative accusations' about the Encyclopedia Britannica, because I've already made up my mind that the Encyclopedia Britannica doesn't support your conclusions and that you're making 'unnecessary negative accusations' about the Encyclopedia Britannica (even though I haven't read a single volume of the Encyclopedia Britannica).

I'm too tired for your silliness .... I concede; you're 100% right, I'm 100% wrong.... Take the "win" and go on about your merry little way.  

I'm not competing with you... just attempting to have a communication and to attempt to clarify various assertions... and I suppose we have accomplished enough clarification for the time being.

[Variogam]

Oh... I almost forgot that it was going to get released today. How many days it will take to find the bugs, if there are any? Honestly, I hope that no major bugs will be found. But considering the fact that this was rushed through, I am worried.

The code is already tested for two weeks on testnet, and 2-3 more weeks available before real signaling begins.

SegWit2x Calendar:
https://segwit2x.github.io/

July 14 - Agreement Participants Install and Test Milestone
July 21 - Nodes Running & Signaling begins

[Searing]

So just imho to review what this all means

1) using the segwi2x agreement....segregated witness is implemented.

2) the 2mb part of the above is still up in the air, due to bitcoin core making no comment on adoption

Result:  We get to do this all over again with the 2mb hard-fork controversy in 3 months or so.

Does that about sum it up?

[mindrust]

So just imho to review what this all means

1) using the segwi2x agreement....segregated witness is implemented.

2) the 2mb part of the above is still up in the air, due to bitcoin core making no comment on adoption

Result:  We get to do this all over again with the 2mb hard-fork controversy in 3 months or so.

Does that about sum it up?

Pretty much this.

Everybody's playing the Mr. Nice Guy till we get segwit, when it comes to 2mb fork, cancer cells will get dumped to the trash can and we'll move on.

[mike4001]

Why is F2Pool not signaling anymore ??

Has anyone information about this?

[DooMAD]

More professional than Barry Silbert and his unethical closed door agreement. ... and also pretty spot on,  segwit2x and the process used to create it isn't just bad, but absurdly so...  as highlighted by jtimon's recent post: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014661.html

While it would certainly be better to have everything out in the open, the simple fact is, Core could be producing this code themselves.  It's merely that you choose not to because it conflicts with your preferred vision of development.  It's easy to sit there and complain about the manner in which they're going about it, but we could avoid all of that if you offered everyone a choice in the code they choose to run.  If you were to release another version of Core which supports both SegWit and a 2mb base, then you can have a say on the process used to create it.  Plus it would be far more constructive than sniping.

What you are arguing seems to make little sense, or possibly I do not sufficiently understand your point?

Core is not some kind of centralized entity, but if consensus within that group is to push for segwit without a 2mb increase because as individuals each of them believes that there is no fucking justification for actually adding either a 2mb upgrade or especially attempting to accomplish such in terms of a hardfork, so why would any specific one of them (of course any one of them is free to do what he wants) just concede and write some stupid ass technically unnecessary code?

I'm just pointing out the futility of complaining about the quality of any work that you aren't willing to do yourself.  It doesn't achieve anything.  In effect, you forfeit the right to moan about how you would have done it better if you clearly have no intention of doing it to begin with.  If anyone would like to see SegWit2x completed to a higher standard, "put up or shut up", basically.  I'm not saying it would or should be in Core's interest to actually go ahead and do it, just that there's no point in pretending their input is of any consequence if they willingly remove themselves from the equation.  By all means critique the intended goal of the code if you have justification, but if you aren't part of the creation process, all you can do is express a meaningless preference on what that creation process should be.  That's the extent of your influence on the matter.

Core are free to churn out whatever code they like, however they like, via any process they like.  If anyone else disagrees with how Core go about their business, they're free to express a meaningless preference or try to create something better.  The same applies to Barry Silbert's group.  If you think you can do SegWit2x better, by all means go for it.  But beyond that, it's just posturing.

[Iranus]

More professional than Barry Silbert and his unethical closed door agreement. ... and also pretty spot on,  segwit2x and the process used to create it isn't just bad, but absurdly so...  as highlighted by jtimon's recent post: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014661.html

While it would certainly be better to have everything out in the open, the simple fact is, Core could be producing this code themselves.  It's merely that you choose not to because it conflicts with your preferred vision of development.  It's easy to sit there and complain about the manner in which they're going about it, but we could avoid all of that if you offered everyone a choice in the code they choose to run.  If you were to release another version of Core which supports both SegWit and a 2mb base, then you can have a say on the process used to create it.  Plus it would be far more constructive than sniping.

What you are arguing seems to make little sense, or possibly I do not sufficiently understand your point?

Core is not some kind of centralized entity, but if consensus within that group is to push for segwit without a 2mb increase because as individuals each of them believes that there is no fucking justification for actually adding either a 2mb upgrade or especially attempting to accomplish such in terms of a hardfork, so why would any specific one of them (of course any one of them is free to do what he wants) just concede and write some stupid ass technically unnecessary code?

I'm just pointing out the futility of complaining about the quality of any work that you aren't willing to do yourself.  It doesn't achieve anything.

If you hire a collection of people to build your house, you're going to moan if they start trying to build an extension you didn't want.  You'd say, "why didn't you just build the extension I showed you?"

Sure, you wouldn't be capable of building it yourself, but you know what you want. 

Another example:  you have a representative democracy.  You're not capable of doing everything related to running the country, but you still advocate certain policies and oppose others, which is how people get elected and how they get somewhat influenced by the views of the public.

  In effect, you forfeit the right to moan about how you would have done it better if you clearly have no intention of doing it to begin with.  If anyone would like to see SegWit2x completed to a higher standard, "put up or shut up", basically.

It's not like there are no devs willing to work on Bitcoin or something... it's just saying "you should do x instead of y", and even if one specific group won't do it, it's possible that another will if it has enough public support.

If public opinions are regarded as futile, then no one would know what they actually want in the first place.

[Variogam]

1) using the segwi2x agreement....segregated witness is implemented.

2) the 2mb part of the above is still up in the air, due to bitcoin core making no comment on adoption

Its misunderstanding to think SegWit and 2M are separate things. These have to come together, its the only reasonable way how SegWit could get 95% and some base blocksize increase implemented. SegWit2x is acceptable compromise for many, and the 2M part going to happen as well. The only question is whether there going to be significant split of Bitcoin economy ignoring the change, which I doubt.

[tristan1960]

1) using the segwi2x agreement....segregated witness is implemented.

2) the 2mb part of the above is still up in the air, due to bitcoin core making no comment on adoption

Its misunderstanding to think SegWit and 2M are separate things. These have to come together, its the only reasonable way how SegWit could get 95% and some base blocksize increase implemented. SegWit2x is acceptable compromise for many, and the 2M part going to happen as well. The only question is whether there going to be significant split of Bitcoin economy ignoring the change, which I doubt.

I also thought 2 megabyte improvement and segwit are the same offers. If they're separete, how can they be implemented into blockchain evenly?

[DooMAD]

I see what you're getting at, but neither example seems to fit the scenario we're in.  

I'm just pointing out the futility of complaining about the quality of any work that you aren't willing to do yourself.  It doesn't achieve anything.

If you hire a collection of people to build your house, you're going to moan if they start trying to build an extension you didn't want.  You'd say, "why didn't you just build the extension I showed you?"

If you walked into a random construction site for a building that isn't yours and you've made it abundantly clear you wouldn't willingly choose to live in it given the option, but still thought you'd chime in and tell the builders how to do their job, that would be analogous to what's happening here.  Silbert's group can build whatever they please, just as Core can.  Neither gets to tell the other what they can't or can't build, or how to build it.

Another example:  you have a representative democracy.  You're not capable of doing everything related to running the country, but you still advocate certain policies and oppose others, which is how people get elected and how they get somewhat influenced by the views of the public.

And for representative democracy, again, Core have every right to dictate what their own manifesto should entail, but they don't get to dictate how the other candidates run their party or what policies they can or can't campaign on.  It just doesn't work like that.

[JayJuanGee]

1) using the segwi2x agreement....segregated witness is implemented.

2) the 2mb part of the above is still up in the air, due to bitcoin core making no comment on adoption

Its misunderstanding to think SegWit and 2M are separate things. These have to come together, its the only reasonable way how SegWit could get 95% and some base blocksize increase implemented. SegWit2x is acceptable compromise for many, and the 2M part going to happen as well. The only question is whether there going to be significant split of Bitcoin economy ignoring the change, which I doubt.

I also thought 2 megabyte improvement and segwit are the same offers. If they're separete, how can they be implemented into blockchain evenly?

It seems to me that the way that segwit would be implemented would allow for mechanisms that achieve the 95% consensus levels of segwit (bip 141 and bip 9) through bip 91 reconciliation, but that reconciliation does not have the same kind of 95% level to achieve for either the 2mb limit increase or the hardfork. 

So in that regard, there seems to be some tension regarding whether either of those 2mb increase or hardfork are going to achieve 95% consensus..   Of course if those two do not receive 95% consensus then they cannot be hardforked as a non-contentious kind of thing that is within the already existing framework that is requiring 95%, of course unless that threshold gets lowered below 95%. 

Currently, the hardforking threshold for the contending group seems to be at changing the consensus to 80%.. so maybe if the consensus were somewhere between 80% and 95% then there could be a hardfork because it is not sufficiently over the 95% in order to achieve current required consensus.   And, then at that point there would be two bitcoin forks and a need to chose which one to support

 If businesses, miners are willing to hardfork off and to continue to follow the hardfork based on 80% consensus, then that would be a change in the governance rules under the new hardfork and maybe the new bitcoin would then begin to have 80% consensus?   And, maybe thereafter consensus would be achieved at 80% rather than 95%, which would make bitcoin relatively easy to change rather than hard to change.

It seems that there are theories that making bitcoin easier to change would take away disputes about bitcoin, but probably, making bitcoin easier to change would cause more disputes rather than fewer, until bitcoin's value is diminished down to make it no longer distinguishable as an immutable secure and decentralized value storage system?

I have my doubts about whether the following would continue to be that strong and even sustainable up to 80% regarding the idea of a 2mb increase and hardforking, especially once segtwit is locked in... .. So this is likely going to continue to be contentious with continued plays to hardfork, unless the support for that 2mb and hardforking position dies down to very low levels (like way below 30%), which remains uncertain at this point.

[classicsucks]

The code is already tested for two weeks on testnet, and 2-3 more weeks available before real signaling begins.

SegWit2x Calendar:

July 14 - Agreement Participants Install and Test Milestone
July 21 - Nodes Running & Signaling begins

More shite code that is destined for the rubbish bin. Do people really think the miners are dumb enough to trust this "Segwit, then hard fork in 3 months agreement with no Core support"?

The miners will signal for Segwit2x until UASF loses all of its steam, then they'll go back to status quo 0.12.1 or whatever. Or maybe BU or a new 2MB hard fork proposal...

The more people f*ck with the miners and try to steamroll them into Segwit, the more likely they'll ALL band together and fork to something that will stanch bitcoin's continuing loss of market share (the elephant in the room).  

The facts that people are compiling and running a non-Core release and that Core doesn't even have a seat at the negotiating table shows just how much their influence has waned.

And just lol at the "decentralized" rhetoric floating around. At this point it's obvious that the word decentralized has lost all meaning other than good/Core and the word centralized only means bad/miners in this echo chamber. Supreme irony given the centralization of Lightning and the draconian tactics Core/Blockstream is using to ram it down our throats.

[Variogam]

95% consensus levels

SegWit alone does not have such support, not even close. The same can be told about blocksize increase. Only because these two are bundled, it is acceptable solution, but even this cannot get 95% levels. Thats why it was decreased to 80% when activating both, SegWit and 2M. While 95% levels would be preffered, it is unrealistical here. Not only about 85% miner support is guaranteed to activate SegWit2x, but also acceptance from the majority of Bitcoin economy, including exchanges.

[franky1]

95% consensus levels

SegWit alone does not have such support, not even close. The same can be told about blocksize increase. Only because these two are bundled, it is acceptable solution, but even this cannot get 95% levels. Thats why it was decreased to 80% when activating both, SegWit and 2M. While 95% levels would be preffered, it is unrealistical here. Not only about 85% miner support is guaranteed to activate SegWit2x, but also acceptance from the majority of Bitcoin economy, including exchanges.

segwit2x is a false flag of 80% to then start orphaning off the other 20% to then get above the 95% to activate the bip9 from the pools prospective
(afterall the code is not even released yet the flagging has already started (facepalm))

the part about the 2mb involves usernodes actually running code to accept >1mb blocks. which we have yet to see the node count actually get established to be ready to accept >1mb blocks

so all that is 'possibly' guaranteed is the segwit tier network aspect and not so much the >1mb block aspect

[d5000]

Do people really think the miners are dumb enough to trust this "Segwit, then hard fork in 3 months agreement with no Core support"?

The miners will signal for Segwit2x until UASF loses all of its steam, then they'll go back to status quo 0.12.1 or whatever. Or maybe BU or a new 2MB hard fork proposal...

I've thought about this kind of outcome. But I now consider it unlikely.

I think the main goal of the miners is that users accept them to have influence over the development of the reference client. As they have identified the Core team as hostile to them, their desire would be an own implementation - what now begun as Segwit2x - to slowly become the reference software.

A "turning back" just before the Segwit activation would be counter-productive to this goal. In this case, they would give Core and the surrounding "small blocker" fraction the opportunity to accuse them to behave in an unstable and untrustworthy way, breaking their own agreement. In this case they would never have chances to convince enough users to download and use their implementation.

Instead, if they move forward with Segwit2x, they can present themselves as "the guys that ended the scaling war and the blockchain congestion" and offer an implementation (the 2MB hard fork) that assures that there won't be congestion again for a couple of years.

[Lauda]

segwit2x is a false flag of 80% to then start orphaning off the other 20% to then get above the 95% to activate the bip9 from the pools prospective

Correct.

(afterall the code is not even released yet the flagging has already started (facepalm))

They are just signalling their intent to support it.

the part about the 2mb involves usernodes actually running code to accept >1mb blocks. which we have yet to see the node count actually get established to be ready to accept >1mb blocks

so all that is 'possibly' guaranteed is the segwit tier network aspect and not so much the >1mb block aspect

They haven't properly considered how consensus works. Right now, there are 0 users running 0 nodes with that code. I don't expect this to drastically change even after the code gets released (unless someone creates a lot of fake nodes). They somehow seem to think that the users must fall in line and accept their fork.

[Last of the V8s]

https://medium.com/@lukedashjr/the-segwit-2x-beta-review-and-thoughts-ca480694a8c7
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013923.html