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 com
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, "Serg
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 o
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.
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
# 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
(That is: "...because they're mined by old non-Segwit2x nodes that *aren't
signaling bit 1 support*", ie, that support neither Segwit2x nor old segwit)
On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff
wrote:
> I could be wrong, but the latest BIP91 implementation (also included in
> Segwit2x) cu
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
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
> wrote:
>
> If segwit i
> I think it would be useful for there to exist a useful and trivial
> patch against current (0.14.2) software to engage in the BIP91-like
> orphaning, like people have provided for BIP148-- but right now I
> don't see any specification of the behavior so it's unclear to me
> _exactly_ what it woul
On Tue, Jun 20, 2017 at 10:15 PM, Hampus Sjöberg
wrote:
> 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.
All versions of Bitcoin Core since 0.13.1 signal segw
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/O
> 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 kin
I concur with Mark's reply. Just to underscore this: Miners arent going to
bother to signaling or changing a setting unless they have to. Anything that
requires time--especially if requiring a restart/any time not mining or risks a
crash---reduces income. So why would they change any settings un
On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
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 leas
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 spli
I don't think it's a huge deal if the miners need to run a non-Core node
once the BIP91 deployment of Segwit2x happens. The shift will most likely
be temporary.
I agree that the "-bip148"-option should be merged, though.
2017-06-20 17:44 GMT+02:00 Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists
Are we going to merge BIP91 or a -BIP148 option to core for inclusion in
the next release or so?
Because a large percentage of miners are indifferent, right now miners have
to choose between BIP148 and Segwit2x if they want to activate Segwit.
Should we be forcing miners to choose to run non-core
18 matches
Mail list logo