diff options
| author | Alex Morcos <morcos@gmail.com> | 2015-10-15 09:47:33 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-10-15 13:47:34 +0000 |
| commit | c5c48917a85ee63c8837d496918ba351b36da9de (patch) | |
| tree | ee8be75a539152311e9e057b5e0e85ffeeda1173 | |
| parent | 7cd8303a0a21978369eaaad04551cc18b82f7d53 (diff) | |
| download | pi-bitcoindev-c5c48917a85ee63c8837d496918ba351b36da9de.tar.gz pi-bitcoindev-c5c48917a85ee63c8837d496918ba351b36da9de.zip | |
Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
| -rw-r--r-- | 2e/f79a436bc19e555d3798d8b7bda5c1d1902291 | 207 |
1 files changed, 207 insertions, 0 deletions
diff --git a/2e/f79a436bc19e555d3798d8b7bda5c1d1902291 b/2e/f79a436bc19e555d3798d8b7bda5c1d1902291 new file mode 100644 index 000000000..22c276ff6 --- /dev/null +++ b/2e/f79a436bc19e555d3798d8b7bda5c1d1902291 @@ -0,0 +1,207 @@ +Return-Path: <morcos@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id F3B0E282 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 15 Oct 2015 13:47:34 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com + [209.85.213.170]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F3968144 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 15 Oct 2015 13:47:33 +0000 (UTC) +Received: by igbni9 with SMTP id ni9so14340037igb.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 15 Oct 2015 06:47:33 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:in-reply-to:references:date:message-id:subject:from:to + :cc:content-type; + bh=d4iMrFPWTzr1bv+eEXwLM/FcyFyqWj6Ykvcs86+4m64=; + b=kUfOpTNm3xyg0niz5cg87NWkcXRAwFtxmgUCunSeINtmRmwkRW2LltjhhqVVP+nnCj + AbzchpLsweLK7GuqDQI/zzJTBNRH/MiClu8Q0pRM88xiZ9WnaT/jamVdFS545XS786qJ + KzweQ8wg8o7qv02X1LA62auN4uV7T8t5o/kcVRwIwzzzFRYYCdqXQFAENDXI0b3DBbPP + NpCwc/DthtbYQZH4YCDIvjnOWv+scQLv0cAKpAkhEaioBVFWCzX+bNBLHK9/Tm1qZVhf + yBipb66mh9MBl8Jh9g+XDYn6bJQNZOwxVtNHH0pRghPLipTe5stSvFJTYTWimTwAzmbA + CFtg== +MIME-Version: 1.0 +X-Received: by 10.50.111.83 with SMTP id ig19mr10140328igb.82.1444916853425; + Thu, 15 Oct 2015 06:47:33 -0700 (PDT) +Received: by 10.64.25.80 with HTTP; Thu, 15 Oct 2015 06:47:33 -0700 (PDT) +In-Reply-To: <87pp0okeip.fsf@rustcorp.com.au> +References: <20151003143056.GA27942@muck> <87lhbgn4fa.fsf@rustcorp.com.au> + <20151008174120.GA9291@muck> <87pp0okeip.fsf@rustcorp.com.au> +Date: Thu, 15 Oct 2015 09:47:33 -0400 +Message-ID: <CAPWm=eUR1fo4iVX=-J7mO34LvT6akRy5=Cxjn7j64PBn+A_oGQ@mail.gmail.com> +From: Alex Morcos <morcos@gmail.com> +To: Rusty Russell <rusty@rustcorp.com.au> +Content-Type: multipart/alternative; boundary=089e013d0bf2c74a90052224eb9c +X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW + autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to + motivate the change +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Thu, 15 Oct 2015 13:47:35 -0000 + +--089e013d0bf2c74a90052224eb9c +Content-Type: text/plain; charset=UTF-8 + +Mark, + +You seemed interested in changing BIP 68 to use 16 bits for sequence number +in both the block and time versions, making time based sequence numbers +have a resolution of 512 seconds. + +I'm in favor of this approach because it leaves aside 14 bits for further +soft forks within the semantics of BIP 68. + +It would be nice to know if you're planning this change, and perhaps people +can hold off on review until things are finalized. + +I'd cast my "vote" against BIP 68 without this change, but am also open to +being convinced otherwise. + +What are other peoples opinions on this? + +On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> Peter Todd <pete@petertodd.org> writes: +> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote: +> >> Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> +> >> writes: +> >> > However I don't think we've done a good job showing why we need to +> >> > implement this feature via nSequence. +> >> +> >> It could be implemented in other ways, but nSequence is the neatest and +> >> most straightforward I've seen. +> >> +> >> - I'm not aware of any other (even vague) proposal for its use? +> Enlighten? +> > +> > There's three that immediately come to mind: +> > +> > Gregory Maxwell has proposed it as a way of discouraging miners from +> > reorging chains, by including some of the low-order bits of a previous +> > block header in nSequence. +> > +> > A few people have proposed implementing proof-of-stake blocksize voting +> > with nSequence. +> +> Excellent, thanks! It's good to have such ideas as a compass. PoS +> voting seems like it won't be a problem in 5 bits. +> +> The "prevbits" idea would want more bits; naively 64 would be good, but +> I think there are some tricks we can use to make 32 work OK. We would +> have to then split between nLocktime (if available) and multiple +> nSequence fields, and it would weaken it for some txs. +> +> There is one easy solution: change the BIP wording from: +> +> -For transactions with an nVersion of 2 or greater, +> +For transactions with an nVersion of 2, +> +> And on every tx bump, we decide whether to keep this scheme (mempool +> would enforce it always). +> +> Cheers, +> Rusty. +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--089e013d0bf2c74a90052224eb9c +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Mark,=C2=A0<div><br><div>You seemed interested in changing= + BIP 68 to use 16 bits for sequence number in both the block and time versi= +ons, making time based sequence numbers have a resolution of 512 seconds.</= +div></div><div><br></div><div>I'm in favor of this approach because it = +leaves aside 14 bits for further soft forks within the semantics of BIP 68.= + =C2=A0</div><div><br></div><div>It would be nice to know if you're pla= +nning this change, and perhaps people can hold off on review until things a= +re finalized.</div><div><br></div><div>I'd cast my "vote" aga= +inst BIP 68 without this change, but am also open to being convinced otherw= +ise.</div><div><br></div><div>What are other peoples opinions on this?</div= +></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Oc= +t 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev <span dir=3D"ltr"><<= +a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b= +itcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote c= +lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;= +padding-left:1ex"><span class=3D"">Peter Todd <<a href=3D"mailto:pete@pe= +tertodd.org">pete@petertodd.org</a>> writes:<br> +> On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:<br> +>> Peter Todd via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists= +.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>><br> +>> writes:<br> +>> > However I don't think we've done a good job showing w= +hy we need to<br> +>> > implement this feature via nSequence.<br> +>><br> +>> It could be implemented in other ways, but nSequence is the neates= +t and<br> +>> most straightforward I've seen.<br> +>><br> +>> - I'm not aware of any other (even vague) proposal for its use= +?=C2=A0 Enlighten?<br> +><br> +> There's three that immediately come to mind:<br> +><br> +> Gregory Maxwell has proposed it as a way of discouraging miners from<b= +r> +> reorging chains, by including some of the low-order bits of a previous= +<br> +> block header in nSequence.<br> +><br> +> A few people have proposed implementing proof-of-stake blocksize votin= +g<br> +> with nSequence.<br> +<br> +</span>Excellent, thanks!=C2=A0 It's good to have such ideas as a compa= +ss.=C2=A0 PoS<br> +voting seems like it won't be a problem in 5 bits.<br> +<br> +The "prevbits" idea would want more bits; naively 64 would be goo= +d, but<br> +I think there are some tricks we can use to make 32 work OK.=C2=A0 We would= +<br> +have to then split between nLocktime (if available) and multiple<br> +nSequence fields, and it would weaken it for some txs.<br> +<br> +There is one easy solution: change the BIP wording from:<br> +<br> +-For transactions with an nVersion of 2 or greater,<br> ++For transactions with an nVersion of 2,<br> +<br> +And on every tx bump, we decide whether to keep this scheme (mempool<br> +would enforce it always).<br> +<div class=3D"HOEnZb"><div class=3D"h5"><br> +Cheers,<br> +Rusty.<br> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= +linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</div></div></blockquote></div><br></div> + +--089e013d0bf2c74a90052224eb9c-- + |