diff options
| author | Mark Friedenbach <mark@friedenbach.org> | 2015-06-16 18:00:45 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-17 01:01:13 +0000 |
| commit | a2a721fb05abf68830e5f567ef3458ac89fe643e (patch) | |
| tree | e23a51687417c9d410f226ae12b7fa9eb60f9549 | |
| parent | 31f2ef876320eb98bb4da618d95af2727b5f3bf3 (diff) | |
| download | pi-bitcoindev-a2a721fb05abf68830e5f567ef3458ac89fe643e.tar.gz pi-bitcoindev-a2a721fb05abf68830e5f567ef3458ac89fe643e.zip | |
Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers
| -rw-r--r-- | 18/6303585e9c38aa386cfeef35a0b654fca169c4 | 164 |
1 files changed, 164 insertions, 0 deletions
diff --git a/18/6303585e9c38aa386cfeef35a0b654fca169c4 b/18/6303585e9c38aa386cfeef35a0b654fca169c4 new file mode 100644 index 000000000..d3b9e7fde --- /dev/null +++ b/18/6303585e9c38aa386cfeef35a0b654fca169c4 @@ -0,0 +1,164 @@ +Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] + helo=mx.sourceforge.net) + by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <mark@friedenbach.org>) id 1Z51j7-0005wj-SD + for bitcoin-development@lists.sourceforge.net; + Wed, 17 Jun 2015 01:01:13 +0000 +X-ACL-Warn: +Received: from mail-ig0-f171.google.com ([209.85.213.171]) + by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1Z51j4-0007LF-SS + for bitcoin-development@lists.sourceforge.net; + Wed, 17 Jun 2015 01:01:13 +0000 +Received: by igbiq7 with SMTP id iq7so55994338igb.1 + for <bitcoin-development@lists.sourceforge.net>; + Tue, 16 Jun 2015 18:01:05 -0700 (PDT) +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:mime-version:in-reply-to:references:from:date + :message-id:subject:to:content-type; + bh=mqTzfyTCK9hpOL65oNGxtU58KFX+9NLnQHc3ctn0zNM=; + b=Eau2PWybS6j1ggq2ZORo1Fz02QpoDq+kajfq0DoKZIWt1EjvmNeHy0kfyZqv+6pk63 + 6q57TzqWKfXaY27Nl+bXjQ/sBwWyPcxDGY+aK5HObTi2LirMMYiN3KNsR7c6OPLak8GN + sWQiQN9Q21gTCsgV2sDsS5MPzBij8vcpaQf+qyU0bY9NZirP5dohmHg4fFnB0MHIP3vD + P8zX3nlZI/NkRoLDpBAMY8SypIvQ6N75hCuqDMy2FV1FE9NCkRHuynkj/yIcQRNT7ohe + I0JBaBi4RE+qiJ2R/SrFiMdFhamb53ZZSoZDixTB4jb0FSpbrwysZZSrPqTQfPXjH2aH + XF7g== +X-Gm-Message-State: ALoCoQlAJHB/6sP2YYiBkxBJjVh3miI6VS1Xo/a2pm1E5LWAveHwFjG5uIQ+CW23wv/nMljO5heU +X-Received: by 10.43.40.130 with SMTP id tq2mr6014105icb.46.1434502865427; + Tue, 16 Jun 2015 18:01:05 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.107.149.20 with HTTP; Tue, 16 Jun 2015 18:00:45 -0700 (PDT) +X-Originating-IP: [173.228.107.141] +In-Reply-To: <CAOG=w-uufDPkQSEi1K_L82j4OXObGmESnfYyxi1z99fcBCotcg@mail.gmail.com> +References: <CAOG=w-uufDPkQSEi1K_L82j4OXObGmESnfYyxi1z99fcBCotcg@mail.gmail.com> +From: Mark Friedenbach <mark@friedenbach.org> +Date: Tue, 16 Jun 2015 18:00:45 -0700 +Message-ID: <CAOG=w-s5D2eaF0biPEEeFgLKLNpA3ho1Sk4mCPQNpVOeNBgr-A@mail.gmail.com> +To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>, + Gregory Maxwell <gmaxwell@gmail.com> +Content-Type: multipart/alternative; boundary=bcaec51dd849b957010518ac3949 +X-Spam-Score: 1.0 (+) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + 1.0 HTML_MESSAGE BODY: HTML included in message +X-Headers-End: 1Z51j4-0007LF-SS +Subject: Re: [Bitcoin-development] [BIP draft] Consensus-enforced + transaction replacement signalled via sequence numbers +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Wed, 17 Jun 2015 01:01:13 -0000 + +--bcaec51dd849b957010518ac3949 +Content-Type: text/plain; charset=UTF-8 + +Given that we have had more than two weeks of public discussion, code is +available and reviewed, and several community identified issues resolved, I +would like to formally request a BIP number be assigned for this work. Will +the BIP editor be so kind as to do so to allow the BIP consensus process to +proceed? + +Thank you, +Mark Friedenbach + +On Mon, Jun 1, 2015 at 6:49 PM, Mark Friedenbach <mark@friedenbach.org> +wrote: + +> I have written a reference implementation and BIP draft for a soft-fork +> change to the consensus-enforced behaviour of sequence numbers for the +> purpose of supporting transaction replacement via per-input relative +> lock-times. This proposal was previously discussed on the mailing list in +> the following thread: +> +> http://sourceforge.net/p/bitcoin/mailman/message/34146752/ +> +> In short summary, this proposal seeks to enable safe transaction +> replacement by re-purposing the nSequence field of a transaction input to +> be a consensus-enforced relative lock-time. +> +> The advantages of this approach is that it makes use of the full range of +> the 32-bit sequence number which until now has rarely been used for +> anything other than a boolean control over absolute nLockTime, and it does +> so in a way that is semantically compatible with the originally envisioned +> use of sequence numbers for fast mempool transaction replacement. +> +> The disadvantages are that external constraints often prevent the full +> range of sequence numbers from being used when interpreted as a relative +> lock-time, and re-purposing nSequence as a relative lock-time precludes its +> use in other contexts. The latter point has been partially addressed by +> having the relative lock-time semantics be enforced only if the +> most-significant bit of nSequence is set. This preserves 31 bits for +> alternative use when relative lock-times are not required. +> +> The BIP draft can be found at the following gist: +> +> https://gist.github.com/maaku/be15629fe64618b14f5a +> +> The reference implementation is available at the following git repository: +> +> https://github.com/maaku/bitcoin/tree/sequencenumbers +> +> I request that the BIP editor please assign a BIP number for this work. +> +> Sincerely, +> Mark Friedenbach +> + +--bcaec51dd849b957010518ac3949 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div><div>Given that we have had more than two weeks of pu= +blic discussion, code is available and reviewed, and several community iden= +tified issues resolved, I would like to formally request a BIP number be as= +signed for this work. Will the BIP editor be so kind as to do so to allow t= +he BIP consensus process to proceed?<br><br></div>Thank you,<br></div>Mark = +Friedenbach<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= +te">On Mon, Jun 1, 2015 at 6:49 PM, Mark Friedenbach <span dir=3D"ltr"><= +<a href=3D"mailto:mark@friedenbach.org" target=3D"_blank">mark@friedenbach.= +org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar= +gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr= +"><div>I have written a reference implementation and BIP draft for a soft-f= +ork change to the consensus-enforced behaviour of sequence numbers for the = +purpose of supporting transaction replacement via per-input relative lock-t= +imes. This proposal was previously discussed on the mailing list in the fol= +lowing thread:<br><br><a href=3D"http://sourceforge.net/p/bitcoin/mailman/m= +essage/34146752/" target=3D"_blank">http://sourceforge.net/p/bitcoin/mailma= +n/message/34146752/</a><br><br></div><div>In short summary, this proposal s= +eeks to enable safe transaction replacement by re-purposing the nSequence f= +ield of a transaction input to be a consensus-enforced relative lock-time.<= +br><br>The advantages of this approach is that it makes use of the full ran= +ge of the 32-bit sequence number which until now has rarely been used for a= +nything other than a boolean control over absolute nLockTime, and it does s= +o in a way that is semantically compatible with the originally envisioned u= +se of sequence numbers for fast mempool transaction replacement.<br><br></d= +iv><div>The disadvantages are that external constraints often prevent the f= +ull range of sequence numbers from being used when interpreted as a relativ= +e lock-time, and re-purposing nSequence as a relative lock-time precludes i= +ts use in other contexts. The latter point has been partially addressed by = +having the relative lock-time semantics be enforced only if the most-signif= +icant bit of nSequence is set. This preserves 31 bits for alternative use w= +hen relative lock-times are not required.<br></div><div><br></div><div>The = +BIP draft can be found at the following gist:<br><br><a href=3D"https://gis= +t.github.com/maaku/be15629fe64618b14f5a" target=3D"_blank">https://gist.git= +hub.com/maaku/be15629fe64618b14f5a</a><br><br></div><div>The reference impl= +ementation is available at the following git repository:<br></div><div><br>= +<a href=3D"https://github.com/maaku/bitcoin/tree/sequencenumbers" target=3D= +"_blank">https://github.com/maaku/bitcoin/tree/sequencenumbers</a><br><br><= +/div><div>I request that the BIP editor please assign a BIP number for this= + work.<br><br></div><div>Sincerely,<br></div><div>Mark Friedenbach<br></div= +></div> +</blockquote></div><br></div> + +--bcaec51dd849b957010518ac3949-- + + |