There's a pull req to core already for part of it: https://github.com/bitcoin/bitcoin/pull/10444
On Tue, Jun 27, 2017 at 12:31 PM, Jorge Timón via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > First the implementation, then the technical design (BIP)... will the > analysis come after that? > Will there be any kind of simulations of tje proposed size or will thag > come only after activation on mainnet? > I assume the very last step will be activation on testnet 3 ? > > > On 27 Jun 2017 8:44 am, "Sergio Demian Lerner via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Currently the only implementation that fulfills the requirements of the > NYA agreement is the segwit2x/btc1 implementation, which is being finalized > this week. > > Segwit2mb does not fulfill the NYA agreement. > > I'm asking now the segwit2x development team when a BIP will be ready so > that Core has the opportunity to evaluate the technical proposal. > > > > > On Wed, Jun 21, 2017 at 1:05 AM, Jacob Eliosoff via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Well, this Saturday's "Chinese roundtable" statement from a bunch of >> miners (https://pastebin.com/b3St9VCF) says they intend "NYA" in the >> coinbase as support for "the New York consensus SegWit2x program btc1 ( >> https://github.com/btc1)", whose code includes the (accelerated >> 336-block) BIP 91 change. So, other facts or interpretations could come to >> light, but until they do we should probably assume that's what the "NYA" >> (which just broke 80% over the last 24h) means. >> >> >> On Tue, Jun 20, 2017 at 10:11 PM, Mark Friedenbach <m...@friedenbach.org> >> wrote: >> >>> 80% have set "NYA" in their coinbase string. We have no idea what that >>> means. People are equating it to BIP 91 -- but BIP 91 did not exist at >>> the time of the New York agreement, and differs from the actual text >>> of the NYA in substantive ways. The "Segwit2MB" that existed at the >>> time of the NYA, and which was explicitly referenced by the text is >>> the proposal by Sergio Demian Lerner that was made to this mailing >>> list on 31 March. The text of the NYA grants no authority for >>> upgrading this proposal while remaining compliant with the agreement. >>> This is without even considering the fact that in the days after the >>> NYA there was disagreement among those who signed it as to what it >>> meant. >>> >>> I feel it is a very dangerous and unwarranted assumption people are >>> making that what we are seeing now is either 80% support for BIP-91 or >>> for the code in the btc1 repo. >>> >>> On Tue, Jun 20, 2017 at 6:36 PM, Erik Aronesty <e...@q32.com> wrote: >>> > # Jacob Eliosoff: >>> > >>> >> will start orphaning non-bit-1 blocks before Aug 1, and we avoid a >>> split. >>> > >>> > Correct. There are 2 short activation periods in BIP91 either of which >>> > would avoid a split. >>> > >>> > # Gregory Maxwell: >>> > >>> >> unclear to me _exactly_ what it would need to implement to be >>> consistent. >>> > >>> > This is the relevant pull req to core: >>> > >>> > https://github.com/bitcoin/bitcoin/pull/10444 >>> > >>> > Seems OK. It's technically running now on testnet5. I think it (or a >>> > -bip148 option) should be merged as soon as feasible. >>> > >>> >> previously debunked "XT" and "Classic" hysteria. >>> > >>> > apples vs oranges, imo. segwit is not a contentious feature. the >>> > "bundling" in segwit2x is, but that's not the issue here. the issue >>> is we >>> > are indirectly requiring miners that strongly support segwit to install >>> > consensus protocol changes outside of bitcoin's standard reference. >>> 80% of >>> > them have signaled they will do so. these are uncharted waters. >>> > >>> > >>> > On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff via bitcoin-dev >>> > <bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >> >>> >> I could be wrong, but the latest BIP91 implementation (also included >>> in >>> >> Segwit2x) cuts the activation period to 336 blocks (2.33 days). >>> (This has >>> >> been updated at >>> >> https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki.) So >>> if 80% >>> >> of hashpower is actually running that code and signaling on bit 4 by >>> July 25 >>> >> or so, then those 80+% will start orphaning non-bit-1 blocks before >>> Aug 1, >>> >> and we avoid a split. >>> >> >>> >> There may still be a few non-bit-1 blocks that get orphaned after Aug >>> 1, >>> >> because they're mined by old BIP141 nodes. But it seems like very few >>> >> miners won't be signaling either Segwit2x *or* BIP141 by then... >>> >> >>> >> Make sense? >>> >> >>> >> >>> >> On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach < >>> m...@friedenbach.org> >>> >> wrote: >>> >>> >>> >>> Why do you say activation by August 1st is likely? That would >>> require an >>> >>> entire difficulty adjustment period with >=95% bit1 signaling. That >>> seems a >>> >>> tall order to organize in the scant few weeks remaining. >>> >>> >>> >>> On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev >>> >>> <bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>> >>> >>> If segwit is activated before Aug 1, as now seems likely, there will >>> be >>> >>> no split that day. But if activation is via Segwit2x (also likely), >>> and at >>> >>> least some nodes do & some don't follow through with the HF 3mo later >>> >>> (again, likely), agreed w/ Greg that *then* we'll see a split - >>> probably in >>> >>> Sep/Oct. How those two chains will match up and how the split will >>> play out >>> >>> is anyone's guess... >>> >>> >>> >>> >>> >>> >>> >>> On Jun 20, 2017 6:16 PM, "Hampus Sjöberg via bitcoin-dev" >>> >>> <bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>> >>> >>> > 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. >>> >>> >>> >>> >>> >>> > As far as prevent a chain split goes, all those things >>> >>> > (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- >>> so I >>> >>> > don't think that holds. >>> >>> >>> >>> Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x >>> (or >>> >>> BIP148) node, because they wouldn't have the new consensus rule of >>> requiring >>> >>> all blocks to signal for segwit. >>> >>> I don't believe there would be any long lasting chainsplit though >>> >>> (because of the ~80% hashrate support on segwit2x), perhaps 2-3 >>> blocks if we >>> >>> get unlucky. >>> >>> >>> >>> Hampus >>> >>> >>> >>> 2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev >>> >>> <bitcoin-dev@lists.linuxfoundation.org>: >>> >>>> >>> >>>> On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev >>> >>>> <bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>>> > Because a large percentage of miners are indifferent, right now >>> miners >>> >>>> > have >>> >>>> > to choose between BIP148 and Segwit2x if they want to activate >>> Segwit. >>> >>>> >>> >>>> Miners can simply continuing signaling segwit, which will leave them >>> >>>> at least soft-fork compatible with BIP148 and BIP91 (and god knows >>> >>>> what "segwit2x" is since they keep changing the actual definition >>> and >>> >>>> do not have a specification; but last I saw the near-term behavior >>> the >>> >>>> same as BIP91 but with a radically reduced activation window, so the >>> >>>> story would be the same there in the near term). >>> >>>> >>> >>>> 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. >>> >>>> >>> >>>> I don't think the rejection of segwit2x from Bitcoin's developers >>> >>>> could be any more resolute than what we've already seen: >>> >>>> https://en.bitcoin.it/wiki/Segwit_support >>> >>>> >>> >>>> On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev >>> >>>> <bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>>> > I think it is very naïve to assume that any shift would be >>> temporary. >>> >>>> > We have a hard enough time getting miners to proactively upgrade >>> to >>> >>>> > recent versions of the reference bitcoin daemon. If miners >>> interpret >>> >>>> > the situation as being forced to run non-reference software in >>> order >>> >>>> > to prevent a chain split because a lack of support from Bitcoin >>> Core, >>> >>>> > that could be a one-way street. >>> >>>> >>> >>>> I think this is somewhat naive and sounds a lot like the repeat of >>> the >>> >>>> previously debunked "XT" and "Classic" hysteria. >>> >>>> >>> >>>> There is a reason that segwit2x is pretty much unanimously rejected >>> by >>> >>>> the technical community. And just like with XT/Classic/Unlimited >>> >>>> you'll continue to see a strong correlation with people who are >>> >>>> unwilling and unable to keep updating the software at an acceptable >>> >>>> level of quality-- esp. because the very founding on their fork is >>> >>>> predicated on discarding those properties. >>> >>>> >>> >>>> If miners want to go off and create an altcoin-- welp, thats >>> something >>> >>>> they can always do, and nothing about that will force anyone to go >>> >>>> along with it. >>> >>>> >>> >>>> As far as prevent a chain split goes, all those things >>> >>>> (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- >>> so I >>> >>>> don't think that holds. >>> >>>> _______________________________________________ >>> >>>> bitcoin-dev mailing list >>> >>>> bitcoin-dev@lists.linuxfoundation.org >>> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> bitcoin-dev mailing list >>> >>> bitcoin-dev@lists.linuxfoundation.org >>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> bitcoin-dev mailing list >>> >>> bitcoin-dev@lists.linuxfoundation.org >>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> bitcoin-dev mailing list >>> >> bitcoin-dev@lists.linuxfoundation.org >>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >> >>> > >>> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev