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

[ComputerGenie]

... He doesn't want to hear that Segwit might not get done...If and when Segwit does activate...

Perhaps that's because he hasn't time for delusional comments?  
There is no "if" about it in the real world.  

There are 2 near certainties in Bitcoin Core:

• Even if the Core devs were the only people in the world to support segwit, it would still be in every version of Core from now until the end of time (and they will make every effort to activate it).
• Even though BDB 4.8 is antiquated by every standard in the world, it will still be the "compatible" db in every version of Core from now until the end of time (and they will make no effort to remove it).

[1714025840]

1714025840

[1714025840]

1714025840

[hv_]

I m not a lawyer but this looks strong

http://www.coindesk.com/the-risks-of-bitcoins-segregated-witness-problems-under-us-contract-law/

Any comments ?

[Last of the V8s]

I m not a lawyer but this looks strong

http://www.coindesk.com/the-risks-of-bitcoins-segregated-witness-problems-under-us-contract-law/

Any comments ?

https://twitter.com/alansilbert/status/879699425421135875
 Alan Silbert‏ @alansilbert 5h5 hours ago

Alan Silbert Retweeted CoinDesk

Translation: Craig Wright fabricating FUD before launching competing product. Shame on you @coindesk Title should lead with OpEd

[JayJuanGee]

I m not a lawyer but this looks strong

http://www.coindesk.com/the-risks-of-bitcoins-segregated-witness-problems-under-us-contract-law/

Any comments ?

https://twitter.com/alansilbert/status/879699425421135875
 Alan Silbert‏ @alansilbert 5h5 hours ago

Alan Silbert Retweeted CoinDesk

Translation: Craig Wright fabricating FUD before launching competing product. Shame on you @coindesk Title should lead with OpEd

Frequently, I am confused by supposed legal implications of a decentralized system.  Who are they going to prosecute?  Bitcoin?

[franky1]

coindesk owned by barry silbert, brother of alan silbert.

alan and barry have at each'satoshi round table' event(which they sponsored/paid for) for last couple years, drummed up some empty craig wright drama to distract the sheep from deeper issues involving other things happening behind the scnes unrelated to CW and related to the roadmap.

inshort if ever there is something CW related.. something else is happening elsewhere they dont want people gossiping about

seems if we ignore this latest CW drama event they want to create. we might find the real story they are trying to avoid being talked about

my theory is if segwit does have legal issues its more about it breaks asicboosts patent and thats why Gmax and crew have been crying that the softfork method of implementing it would ultimately fail. hense all these other bip methods popping up to try getting it activated.

though the real thing alan wants to distract people away from may not even be about segwit legal issues.
either way nothing to concern ourselves with in regards to CW, thats just drama

[JayJuanGee]

This may be a dumb question - or an area that has already been covered, but do we have a date in which the segwit2x software will be available for miners to actually run, to change their smoke from "intention" to actual "signaling" that counts towards locking in segwit? 

Accordingly, since BIP141 is already at about 42%, then the segwit2x portion would only need about 53% in order to add up to 95% and then to lock in segwit, right?

Seems like there is enough support.. but an ongoing problem is that there is a difference between actually running software and merely asserting intention.. .. and I know that there is some locking in, as well.. with BIP148 and also with BIP91 that requires them to actually signal segwit which will bring the segwit number close to 100%. 

Somewhere I heard that the miners would have to start running the segwit2x software by July 7 in order to have enough time to lock it in before August 1 and to make BIP148 irrelevant.

Am I on the right track?

[Sithara007]

This may be a dumb question - or an area that has already been covered, but do we have a date in which the segwit2x software will be available for miners to actually run, to change their smoke from "intention" to actual "signaling" that counts towards locking in segwit? 

Accordingly, since BIP141 is already at about 42%, then the segwit2x portion would only need about 53% in order to add up to 95% and then to lock in segwit, right?

Seems like there is enough support.. but an ongoing problem is that there is a difference between actually running software and merely asserting intention.. .. and I know that there is some locking in, as well.. with BIP148 and also with BIP91 that requires them to actually signal segwit which will bring the segwit number close to 100%. 

Somewhere I heard that the miners would have to start running the segwit2x software by July 7 in order to have enough time to lock it in before August 1 and to make BIP148 irrelevant.

Am I on the right track?

Can someone confirm this? How much support is needed for locking the SegWit? Is it 80% or 95%? I heard that support levels of more than 80% for three days will be enough to lock the SegWit. Also, are they planning to run it from July 7?

[-ck]

Can someone confirm this? How much support is needed for locking the SegWit? Is it 80% or 95%? I heard that support levels of more than 80% for three days will be enough to lock the SegWit. Also, are they planning to run it from July 7?

80% support with segwit2x for 2 days will mean those miners will then orphan any blocks that are not signalling segwit. That means the chain is then guaranteed to reach 100% within the next 2 weeks (since the chain will only have segwit signalling blocks) which makes it above the 95% threshold to activate regular segwit. Anyone mining on core nodes signalling segwit, or users running core nodes will select the longest compatible chain which is the one with 100% segwit signalled blocks as well.

They're planning to run it on July 14 though they have until July 21 to deploy it.

6 months after the 80% activation threshold is the 2MB hard fork. At that stage anyone running core nodes that are incompatible will end up forked on a separate smaller chain (from that fork point onwards) unless core creates something compatible or the mining consortium no longer agrees to participate in the rest of the segwit2x agreement...

[Netnox]

Can someone confirm this? How much support is needed for locking the SegWit? Is it 80% or 95%? I heard that support levels of more than 80% for three days will be enough to lock the SegWit. Also, are they planning to run it from July 7?

80% support with segwit2x for 2 days will mean those miners will then orphan any blocks that are not signalling segwit. That means the chain is then guaranteed to reach 100% within the next 2 weeks (since the chain will only have segwit signalling blocks) which makes it above the 95% threshold to activate regular segwit. Anyone mining on core nodes signalling segwit, or users running core nodes will select the longest compatible chain which is the one with 100% segwit signalled blocks as well.

They're planning to run it on July 14 though they have until July 21 to deploy it.

6 months after the 80% activation threshold is the 2MB hard fork. At that stage anyone running core nodes that are incompatible will end up forked on a separate smaller chain (from that fork point onwards) unless core creates something compatible or the mining consortium no longer agrees to participate in the rest of the segwit2x agreement...

Very informative post. Thanks a lot for spending so much time to explain these things to everyone. So right now, I'd say that SegWit2X is almost a 100% probbaility. Those miners who are opposing it will fall in line, when they realize that they are about to wage a losing battle. Chances of a split are also quite low. 

[BrianH]

Can someone confirm this? How much support is needed for locking the SegWit? Is it 80% or 95%? I heard that support levels of more than 80% for three days will be enough to lock the SegWit. Also, are they planning to run it from July 7?

80% support with segwit2x for 2 days will mean those miners will then orphan any blocks that are not signalling segwit. That means the chain is then guaranteed to reach 100% within the next 2 weeks (since the chain will only have segwit signalling blocks) which makes it above the 95% threshold to activate regular segwit. Anyone mining on core nodes signalling segwit, or users running core nodes will select the longest compatible chain which is the one with 100% segwit signalled blocks as well.

They're planning to run it on July 14 though they have until July 21 to deploy it.

6 months after the 80% activation threshold is the 2MB hard fork. At that stage anyone running core nodes that are incompatible will end up forked on a separate smaller chain (from that fork point onwards) unless core creates something compatible or the mining consortium no longer agrees to participate in the rest of the segwit2x agreement...

Very informative post. Thanks a lot for spending so much time to explain these things to everyone. So right now, I'd say that SegWit2X is almost a 100% probbaility. Those miners who are opposing it will fall in line, when they realize that they are about to wage a losing battle. Chances of a split are also quite low. 

Segwit is a near certainty, but whether there is a split is much less certain... The 2MB block size is the real obstacle.

[gmaxwell]

unless core creates something compatible

https://en.bitcoin.it/wiki/Segwit_support

[-ck]

unless core creates something compatible

https://en.bitcoin.it/wiki/Segwit_support

Eh? I was talking about the 2MB hard fork component.

EDIT: Oh I see you're saying they won't. Well that's obviously their position for now; I was speaking only hypothetically.

[ComputerGenie]

Love the professionalism of:

LOL

[gmaxwell]

Love the professionalism of:

LOL

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

[JayJuanGee]

Love the professionalism of:

LOL

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

I don't claim to understand all these various technical variations, but it seems to me that even if segwit2x is fucked up and ambiguous, it seems to be serving as a pretty decent vehicle to on board  a large number of folks into segregated witness, which is seeming to make segregated witness more likely to happen, and also on a bit quicker of a timeline. 

So, even if segwit2x is a bunch of nonsense, likely we would not gotten to the likely activation and locking in of segwit?  Sure segwit is not a done deal, yet, and there are a variety of influential factors - but doesn't segwit2x deserve some credit for adding to the likelihood and speed of the real deal seg wit activation and lock in?

[ComputerGenie]

Love the professionalism of:

LOL

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

Perhaps if Core pulled the cobs out of their collective asses, let uses drive the protocol, stopped playing the centralized Gods of Bitcoin, and modernized Core (in general), then people wouldn't feel the need to "go around" Core? 

[JayJuanGee]

I think that this article is in sync with what is being said here regarding time line.

http://www.coindesk.com/bitcoin-scaling-project-segwit2x-release-new-code-tomorrow/

Segwit2x tested for two weeks, and then maybe go live at that point, and then the real test is regarding how many miners are actually running it, rather than merely stating an intention to run it?

At that point, would it be fair to add up those running segwit2x and those running BIP141 in order to achieve 80% under BIP91?  and then once BIP91 80% requirements are met, then it becomes a requirement to signal segwit or otherwise become orphaned... which would cause more than 95% and then the activation of BIP 141.   

There seems to be a kind of loophole here, because BIP141 is currently at above 44%,  but if that percentage is added together with whoever is going to run segwit2x, then only 36% would be needed in order to trigger BIP91 - which would pretty much make segwit certain thereafter?   

[classicsucks]

From gmax's listserv post:

Code:

 > Ironically, it looks like most of the segwit2x signaling miners are
 > faking it (because they're not signaling segwit which it requires).
 > It'll be unfortunate if some aren't faking it and start orphaning
 > their own blocks because they are failing to signal segwit.

Well, they're doing some kind of "pre-signaling" in the coinbase at
the moment because the segwit2x project is still in alpha-phase
according to the timeline. They're just showing commitment.
I'm sure they will begin signaling on version bit 4/BIP91 as well as
actually running a segwit2x node when the time comes.

Exactly what I was saying about signalling - very different from actually running code and actually orphaning blocks in as a little as 2 weeks...

And the code just officially dropped today? This is highly suspect. I still don't see Segwit activating.

Perhaps one or two key Core devs are feeding the Segwit2x code to a third party who is "not Core", so Core doesn't have to bear the brunt when nobody hard forks in 3 months? 

[DooMAD]

Love the professionalism of:

LOL

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.

[JayJuanGee]

Love the professionalism of:

LOL

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?

Furthermore, it seems that this segwit2x, as flawed as it may be, may well end up being a vehicle that catalyses the activation, implementation and locking in of segwit - without the dumbass 2mb or the hardforking parts. 

So fine and dandy, we are going to get a bunch of whiners down the road, who are trying to argue that the 2x part was already agreed to because of NY agreement and because segwit2x code, but why would core jump in and concede on that 2x part (or the hardforking part), when it is not agreed to and is not technically necessary, at least at this point and even more once segwit is actually locked in? 

Furthermore, why would core agree to concede to any kind of change in governance to allow for 80% consensus when it seems to appear that there are vehicles already in place, including BIP148 and BIP91 that seem to have considerable incentives to cause a movement from 80% in order to achieve the necessary 95% consensus which they had outlined in BIP9.  O.k. maybe down the road there will be some BIP vehicles that allow for other kinds of changes in governance - at least in terms of how to reach consensus, and what kind of thresholds might be sufficient - but at this point it is looking like 95% plus is going to be a pretty safe accomplishment and it looks pretty probable to be achieved in the near term, at least with the segwit portion, no?