diff options
| author | Btc Drak <btcdrak@gmail.com> | 2015-10-15 17:27:43 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-10-15 16:28:05 +0000 |
| commit | 6bd0385ac6f001b012cb96f905b316f57caf26b8 (patch) | |
| tree | e1ccf96c34d029945c5546f8c092a56eac5a6040 | |
| parent | d5f7a7ea84d88fb9a9b64eab4855758a12df0696 (diff) | |
| download | pi-bitcoindev-6bd0385ac6f001b012cb96f905b316f57caf26b8.tar.gz pi-bitcoindev-6bd0385ac6f001b012cb96f905b316f57caf26b8.zip | |
Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
| -rw-r--r-- | 65/b0528e86c021f98ffefd744323d2a39232281b | 297 |
1 files changed, 297 insertions, 0 deletions
diff --git a/65/b0528e86c021f98ffefd744323d2a39232281b b/65/b0528e86c021f98ffefd744323d2a39232281b new file mode 100644 index 000000000..33e6415e1 --- /dev/null +++ b/65/b0528e86c021f98ffefd744323d2a39232281b @@ -0,0 +1,297 @@ +Return-Path: <btcdrak@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 58E9989E + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 15 Oct 2015 16:28:05 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-qk0-f178.google.com (mail-qk0-f178.google.com + [209.85.220.178]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 31F3312D + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 15 Oct 2015 16:28:04 +0000 (UTC) +Received: by qkap81 with SMTP id p81so41971715qka.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 15 Oct 2015 09:28:03 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:in-reply-to:references:from:date:message-id:subject:to + :cc:content-type; + bh=+6WEUNyi5b9B7WnEIpNnXEFrJq7ogFJtXATRxitHIcQ=; + b=zeLDJyHeTJuug5HhlatZEDy7bUnfaCVMzKzUngNRs6i/Yawb74xr8M+bncZpvKELw1 + ld43n0IcaRSAb+Nx+7DpCxw8NO2fYSbobrtSBkJ78UYA42EYRkbm09NYCPHWK5xIwOqq + Ga8To5/aNmjl907fEf3R42ZOvnM9Zoi5r14MCh1KJRLoMY+4P1b6A+dD5iOM5asfYhVl + fr1yYlp2zukNUIEQc0EbAA9rDCkfsLuOw0iLRL4KTpTo+G7xpumw/kzq/I4I1Rp2ht7T + 5ZT7hkuLRDH7IyzeM1aaRcie5v8NyqxxuGYDNulbSquPK8HQ8T6lWQ1ha0ad7nsEdCy5 + s3Rw== +X-Received: by 10.55.22.162 with SMTP id 34mr13613356qkw.3.1444926483255; Thu, + 15 Oct 2015 09:28:03 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.55.130.7 with HTTP; Thu, 15 Oct 2015 09:27:43 -0700 (PDT) +In-Reply-To: <CAPWm=eUR1fo4iVX=-J7mO34LvT6akRy5=Cxjn7j64PBn+A_oGQ@mail.gmail.com> +References: <20151003143056.GA27942@muck> <87lhbgn4fa.fsf@rustcorp.com.au> + <20151008174120.GA9291@muck> <87pp0okeip.fsf@rustcorp.com.au> + <CAPWm=eUR1fo4iVX=-J7mO34LvT6akRy5=Cxjn7j64PBn+A_oGQ@mail.gmail.com> +From: Btc Drak <btcdrak@gmail.com> +Date: Thu, 15 Oct 2015 17:27:43 +0100 +Message-ID: <CADJgMzsvdG2iE=FhYrgKve_JxtMjFVOS4Gx-0Q8GnqDYF_-qOw@mail.gmail.com> +To: Alex Morcos <morcos@gmail.com> +Content-Type: multipart/alternative; boundary=001a11493914c2d78e0522272933 +X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, + HK_RANDOM_FROM, + HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=no 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 16:28:05 -0000 + +--001a11493914c2d78e0522272933 +Content-Type: text/plain; charset=UTF-8 + +Alex, + +I am sorry for not communicating more clearly. Mark and I discussed your +concerns from the last meeting and he made the change. The BIP text still +needs to be updated, but the discussed change was added to the PR, albeit +squashed making it more non-obvious. BIP68 now explicitly uses 16 bits with +a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK +and SEQUENCE_LOCKTIME_GRANULARITY in the PR +https://github.com/bitcoin/bitcoin/pull/6312. + + /* If CTxIn::nSequence encodes a relative lock-time, this mask is + * applied to extract that lock-time from the sequence field. */ + static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff; + + /* In order to use the same number of bits to encode roughly the + * same wall-clock duration, and because blocks are naturally + * limited to occur every 600s on average, the minimum granularity + * for time-based relative lock-time is fixed at 512 seconds. + * Converting from CTxIn::nSequence to seconds is performed by + * multiplying by 512 = 2^9, or equivalently shifting up by + * 9 bits. */ + static const int SEQUENCE_LOCKTIME_GRANULARITY = 9; + +I am also much happier with this last tightening up of the specification +because it removes ambiguity. 512s granularity makes sense within the +context of the 10 minute block target. + +Thank you for spending so much time carefully considering this BIP and +reference implementation and please let me know if there there are any +remaining nits so we can get those addressed. + + + + + +On Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> 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 +>> +> +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> +> + +--001a11493914c2d78e0522272933 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Alex,<div><br></div><div>I am sorry for not communicating = +more clearly. Mark and I discussed your concerns from the last meeting and = +he made the change. The BIP text still needs to be updated, but the discuss= +ed change was added to the PR, albeit squashed making it more non-obvious. = +BIP68 now explicitly uses 16 bits with a bitmask. Please see the use of SEQ= +UENCE_LOCKTIME_MASK and=C2=A0SEQUENCE_LOCKTIME_GRANULARITY in the PR=C2=A0<= +a href=3D"https://github.com/bitcoin/bitcoin/pull/6312">https://github.com/= +bitcoin/bitcoin/pull/6312</a>.</div><div><br></div><div><div>=C2=A0 =C2=A0 = +/* If CTxIn::nSequence encodes a relative lock-time, this mask is</div><div= +>=C2=A0 =C2=A0 =C2=A0* applied to extract that lock-time from the sequence = +field. */</div><div>=C2=A0 =C2=A0 static const uint32_t SEQUENCE_LOCKTIME_M= +ASK =3D 0x0000ffff;</div><div><br></div><div>=C2=A0 =C2=A0 /* In order to u= +se the same number of bits to encode roughly the</div><div>=C2=A0 =C2=A0 = +=C2=A0* same wall-clock duration, and because blocks are naturally</div><di= +v>=C2=A0 =C2=A0 =C2=A0* limited to occur every 600s on average, the minimum= + granularity</div><div>=C2=A0 =C2=A0 =C2=A0* for time-based relative lock-t= +ime is fixed at 512 seconds.</div><div>=C2=A0 =C2=A0 =C2=A0* Converting fro= +m CTxIn::nSequence to seconds is performed by</div><div>=C2=A0 =C2=A0 =C2= +=A0* multiplying by 512 =3D 2^9, or equivalently shifting up by</div><div>= +=C2=A0 =C2=A0 =C2=A0* 9 bits. */</div><div>=C2=A0 =C2=A0 static const int S= +EQUENCE_LOCKTIME_GRANULARITY =3D 9;</div></div><div><br></div><div>I am als= +o much happier with this last tightening up of the specification because it= + removes ambiguity. 512s granularity makes sense within the context of the = +10 minute block target.</div><div><br></div><div>Thank you for spending so = +much time carefully considering this BIP and reference implementation and p= +lease let me know if there there are any remaining nits so we can get those= + addressed.=C2=A0</div><div><br></div><div><br></div><div><br></div><div><b= +r></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On = +Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev <span dir=3D"ltr"= +><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= +ank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockq= +uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = +solid;padding-left:1ex"><div dir=3D"ltr">Mark,=C2=A0<div><br><div>You seeme= +d 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 reso= +lution of 512 seconds.</div></div><div><br></div><div>I'm in favor of t= +his 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 t= +o know if you're planning this change, and perhaps people can hold off = +on review until things are finalized.</div><div><br></div><div>I'd cast= + my "vote" against BIP 68 without this change, but am also open t= +o being convinced otherwise.</div><div><br></div><div>What are other people= +s opinions on this?</div></div><div class=3D"HOEnZb"><div class=3D"h5"><div= + class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Oct 8, 2015 a= +t 9:38 PM, Rusty Russell via bitcoin-dev <span dir=3D"ltr"><<a href=3D"m= +ailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@= +lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class=3D"gma= +il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef= +t:1ex"><span>Peter Todd <<a href=3D"mailto:pete@petertodd.org" target=3D= +"_blank">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" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.o= +rg</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><div><br> +Cheers,<br> +Rusty.<br> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +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> +</div></div><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> +<br></blockquote></div><br></div> + +--001a11493914c2d78e0522272933-- + |