From: Matt Corallo <lf-lists@mattcorallo•com>
To: Jacob Eliosoff <jacob.eliosoff@gmail•com>,
bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Barry Silbert segwit agreement
Date: Fri, 26 May 2017 20:02:41 +0000 [thread overview]
Message-ID: <9e2e7009-7bec-845a-bc9f-3ee03d4b4e7f@mattcorallo.com> (raw)
In-Reply-To: <CAAUaCyiHUOQ-rhN5XiGyMc6ocfsNBuH_tzK_QWu7sg1=Qd-o=Q@mail.gmail.com>
Your proposal seems to be simply BIP 91 tied to the
as-yet-entirely-undefined hard fork Barry et al proposed.
Using James' BIP 91 instead of the Barry-bit-4/5/whatever proposal, as
you propose, would make the deployment on the incredibly short timeline
Barry et al proposed slightly more realistic, though I would expect to
see hard fork code readily available and well-tested at this point in
order to meet that timeline.
Ultimately, due to their aggressive timeline, the Barry et al proposal
is incredibly unlikely to meet the requirements of a
multi-billion-dollar system, and continued research into meeting the
spirit, not the text, of their agreement seems warranted.
Matt
On 05/26/17 17:47, Jacob Eliosoff via bitcoin-dev wrote:
> Forgive me if this is a dumb question. Suppose that rather than
> directly activating segwit, the Silbert/NYC Segwit2MB proposal's lock-in
> just triggered BIP141 signaling (plus later HF). Would that avoid
> incompatibility with existing BIP141 nodes, and get segwit activated
> sooner? Eg:
>
> - Bit 4 (or bit 5 or whatever, now that BIP91 uses 4) signals support
> for "segwit now, HF (TBD) at scheduled date (Nov 23?)"
> - If bit 4 support reaches 80%, it locks in two things: the scheduled HF
> (conditional on segwit), and *immediately* turning on bit 1 (BIP141 support)
>
> I realize this would still leave problems like the aggressive HF
> schedule, possible chain split at the HF date between Segwit2MB nodes
> and any remaining BIP141 nodes, etc. My focus here is how
> incompatibility with existing nodes could be minimized.
>
> (BIP91 could also be used if BIP141 support still fell short of 95%.
> But if Segwit2MB support reaches 80%, it seems likely that an additional
> 15% will support BIP141-without-HF.)
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
next prev parent reply other threads:[~2017-05-26 20:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-26 17:47 Jacob Eliosoff
2017-05-26 18:48 ` Tom Zander
2017-05-26 20:02 ` Matt Corallo [this message]
2017-05-26 20:10 ` Jacob Eliosoff
2017-05-26 21:30 ` James Hilliard
2017-05-26 22:12 ` Tom Zander
[not found] ` <CADvTj4qdr2yGYFEWA7oVmL-KkrchYb5aQBRY9w0OK4ZVopSTSA@mail.gmail.com>
2017-05-28 20:51 ` Tom Zander
2017-05-28 23:28 ` James Hilliard
2017-05-26 22:44 ` Matt Corallo
-- strict thread matches above, loose matches on Subject: below --
2017-05-22 12:29 Daniele Pinna
2017-05-22 6:12 shaolinfry
2017-05-22 6:27 ` Peter Todd
2017-05-22 9:23 ` Hampus Sjöberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9e2e7009-7bec-845a-bc9f-3ee03d4b4e7f@mattcorallo.com \
--to=lf-lists@mattcorallo$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jacob.eliosoff@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox