Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from <mark@friedenbach.org>) id 1YzoND-0001aZ-5R for bitcoin-development@lists.sourceforge.net; Tue, 02 Jun 2015 15:45:03 +0000 X-ACL-Warn: Received: from mail-ie0-f181.google.com ([209.85.223.181]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YzoN8-0003pe-Kt for bitcoin-development@lists.sourceforge.net; Tue, 02 Jun 2015 15:45:03 +0000 Received: by ieczm2 with SMTP id zm2so136153683iec.1 for <bitcoin-development@lists.sourceforge.net>; Tue, 02 Jun 2015 08:44:53 -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:date :message-id:subject:from:to:cc:content-type; bh=KKQK17RFVj8Ps/vz9dFGSczlqIVvYtfBwc8KTiGsHiE=; b=Qd5emifusVQkWWiojfW+qtg8DnE8qWcu1kbxUrzGinVV3Ua6QER28C4/1rty0/cXIb YoqriW0wae2mxgvvhlJiCA3JqS6lgHn3vBnIJWgibkVKBbXiyxTwQSpualENLQyHCaty l9M0Gvfdh8ZnasnSWuE9lpi+0A7xO4yGE0RiO72+gzrzMHKT5mvRnzEURMwdRhNVvy/d DpqnsyvnKVTAbhyqm8A5fFxFvtHrerqIpArFi7yEjZFFWm6Br6X9+QqAhRdjajqR3AE/ mxSH63vcU7Q52lBwCWd1y07JHjQFxmVKV2NN2xh1zm32LRYgKSUQdjOo6fiqQ/3z06Ry tf0w== X-Gm-Message-State: ALoCoQmRdgYpBcrTEVXKgNagWMqMC+LKTxKshOzsIc0JM5MAovXgPV2FaA31Od2z1lu/rjDIVAdC MIME-Version: 1.0 X-Received: by 10.107.3.210 with SMTP id e79mr34570336ioi.50.1433259893178; Tue, 02 Jun 2015 08:44:53 -0700 (PDT) Received: by 10.107.10.197 with HTTP; Tue, 2 Jun 2015 08:44:52 -0700 (PDT) X-Originating-IP: [172.56.17.138] Received: by 10.107.10.197 with HTTP; Tue, 2 Jun 2015 08:44:52 -0700 (PDT) In-Reply-To: <CALqxMTFkWOfWXOnVAnZESkVWHtbZLc=T_sQDoTofr66mcb6_gQ@mail.gmail.com> References: <CAOG=w-uufDPkQSEi1K_L82j4OXObGmESnfYyxi1z99fcBCotcg@mail.gmail.com> <CABHVRKQD4YPt0NA8VnXW4VYx0fmCgSHUYq-73F2esHZqX-FUxw@mail.gmail.com> <CAOG=w-tDdJTkkqGaEEpDZ6pX0kXT7f2wvoN_cEpd6+MVnu1CdQ@mail.gmail.com> <E67A3D18-EFB0-4156-98B7-082793D2D871@gmail.com> <CALqxMTFkWOfWXOnVAnZESkVWHtbZLc=T_sQDoTofr66mcb6_gQ@mail.gmail.com> Date: Tue, 2 Jun 2015 08:44:53 -0700 Message-ID: <CAOG=w-v-twsRcfT=nOQA0y5MYQ7bN+W_NVXYkuWSb0kyh4rnvg@mail.gmail.com> From: Mark Friedenbach <mark@friedenbach.org> To: Adam Back <adam@cypherspace.org> Content-Type: multipart/alternative; boundary=001a113f8ef0ce101e05178ad2d0 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: 1YzoN8-0003pe-Kt Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net> 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: Tue, 02 Jun 2015 15:45:03 -0000 --001a113f8ef0ce101e05178ad2d0 Content-Type: text/plain; charset=UTF-8 Oh it is far worse than that. There is nothing preventing those coins from being spent somewhere else, so actually an expiry would enable coin theft in a reorg -- you make your spends expire right after they hit the chain the first time, and then if there is a reorg the spend and subsequent transactions are invalidated. This is an exploitable means of theft. For this reason it is very important to male sure that once a transaction makes it on the chain, it cannot be invalidated by means of a reorg. On Jun 2, 2015 6:11 AM, "Adam Back" <adam@cypherspace.org> wrote: > That would also introduce the anomaly of a script that was once valid > becoming later invalid, when nothing varies other than time. That is > not super compatible with the current model of reprocessing > transactions in later blocks if the block they were first in gets > reorged. > > (Not a huge flexibility loss as you can implement "not after" by > making it the previous holders responsibility to spend a "not before" > back to themselves.) > > Adam > > On 2 June 2015 at 13:52, Stephen <stephencalebmorse@gmail.com> wrote: > > Do you think it would be useful to have an inverted version of both CSV > and > > CLTV? To verify if an output is spent before a specific time. CLTV and > CSV > > could be implemented by taking two stack arguments, an integer for the > > comparison and TRUE/FALSE. > > > > Now that I think about this more, the problem is that, for example, just > > having a lock time of less than some value doesn't actually mean it has > to > > be spent before that script value, so this might not work. Likely any > > implementations of such a feature would have to provide the script > execution > > environment with access to information that it doesn't have now, which is > > what we are trying to avoid. > > > > Best, > > Stephen > > > > > > > > On Jun 2, 2015, at 12:16 AM, Mark Friedenbach <mark@friedenbach.org> > wrote: > > > > You are correct! I am maintaining a 'checksequenceverify' branch in my > git > > repository as well, an OP_RCLTV using sequence numbers: > > > > https://github.com/maaku/bitcoin/tree/checksequenceverify > > > > Most of the interesting use cases for relative lock-time require an RCLTV > > opcode. What is interesting about this architecture is that it possible > to > > cleanly separate the relative lock-time (sequence numbers) from the RCLTV > > opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation. > Like > > CLTV, the CSV opcode only checks transaction data and requires no > contextual > > knowledge about block headers, a weakness of the other RCLTV proposals > that > > violate the clean separation between libscript and libconsensus. In a > > similar way, this BIP proposal only touches the transaction validation > logic > > without any impact to script. > > > > I would like to propose an additional BIP covering the > CHECKSEQUENCEVERIFY > > opcode and its enabling applications. But, well, one thing at a time. > > > > On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse < > stephencalebmorse@gmail.com> > > wrote: > >> > >> Hi Mark, > >> > >> Overall, I like this idea in every way except for one: unless I am > missing > >> something, we may still need an OP_RCLTV even with this being > implemented. > >> > >> In use cases such as micropayment channels where the funds are locked up > >> by multiple parties, the enforcement of the relative locktime can be > done by > >> the first-signing party. So, while your solution would probably work in > >> cases like this, where multiple signing parties are involved, there may > be > >> other, seen or unforeseen, use cases that require putting the relative > >> locktime right into the spending contract (the scriptPubKey itself). > When > >> there is only one signer, there's nothing that enforces using an > nSequence > >> and nVersion=2 that would prevent spending the output until a certain > time. > >> > >> I hope this is received as constructive criticism, I do think this is an > >> innovative idea. In my view, though, it seems to be less fully-featured > than > >> just repurposing an OP_NOP to create OP_RCLTV. The benefits are > obviously > >> that it saves transaction space by repurposing unused space, and would > >> likely work for most cases where an OP_RCLTV would be needed. > >> > >> Best, > >> Stephen > >> > >> On Mon, Jun 1, 2015 at 9: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 > >>> > >>> > >>> > ------------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> Bitcoin-development mailing list > >>> Bitcoin-development@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >>> > >> > > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > --001a113f8ef0ce101e05178ad2d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p dir=3D"ltr">Oh it is far worse than that. There is nothing preventing th= ose coins from being spent somewhere else, so actually an expiry would enab= le coin theft in a reorg -- you make your spends expire right after they hi= t the chain the first time, and then if there is a reorg the spend and subs= equent transactions are invalidated. This is an exploitable means of theft.= </p> <p dir=3D"ltr">For this reason it is very important to male sure that once = a transaction makes it on the chain, it cannot be invalidated by means of a= reorg.</p> <div class=3D"gmail_quote">On Jun 2, 2015 6:11 AM, "Adam Back" &l= t;<a href=3D"mailto:adam@cypherspace.org">adam@cypherspace.org</a>> wrot= e:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That would also i= ntroduce the anomaly of a script that was once valid<br> becoming later invalid, when nothing varies other than time.=C2=A0 That is<= br> not super compatible with the current model of reprocessing<br> transactions in later blocks if the block they were first in gets<br> reorged.<br> <br> (Not a huge flexibility loss as you can implement "not after" by<= br> making it the previous holders responsibility to spend a "not before&q= uot;<br> back to themselves.)<br> <br> Adam<br> <br> On 2 June 2015 at 13:52, Stephen <<a href=3D"mailto:stephencalebmorse@gm= ail.com">stephencalebmorse@gmail.com</a>> wrote:<br> > Do you think it would be useful to have an inverted version of both CS= V and<br> > CLTV? To verify if an output is spent before a specific time. CLTV and= CSV<br> > could be implemented by taking two stack arguments, an integer for the= <br> > comparison and TRUE/FALSE.<br> ><br> > Now that I think about this more, the problem is that, for example, ju= st<br> > having a lock time of less than some value doesn't actually mean i= t has to<br> > be spent before that script value, so this might not work. Likely any<= br> > implementations of such a feature would have to provide the script exe= cution<br> > environment with access to information that it doesn't have now, w= hich is<br> > what we are trying to avoid.<br> ><br> > Best,<br> > Stephen<br> ><br> ><br> ><br> > On Jun 2, 2015, at 12:16 AM, Mark Friedenbach <<a href=3D"mailto:ma= rk@friedenbach.org">mark@friedenbach.org</a>> wrote:<br> ><br> > You are correct! I am maintaining a 'checksequenceverify' bran= ch in my git<br> > repository as well, an OP_RCLTV using sequence numbers:<br> ><br> > <a href=3D"https://github.com/maaku/bitcoin/tree/checksequenceverify" = target=3D"_blank">https://github.com/maaku/bitcoin/tree/checksequenceverify= </a><br> ><br> > Most of the interesting use cases for relative lock-time require an RC= LTV<br> > opcode. What is interesting about this architecture is that it possibl= e to<br> > cleanly separate the relative lock-time (sequence numbers) from the RC= LTV<br> > opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation.= Like<br> > CLTV, the CSV opcode only checks transaction data and requires no cont= extual<br> > knowledge about block headers, a weakness of the other RCLTV proposals= that<br> > violate the clean separation between libscript and libconsensus. In a<= br> > similar way, this BIP proposal only touches the transaction validation= logic<br> > without any impact to script.<br> ><br> > I would like to propose an additional BIP covering the CHECKSEQUENCEVE= RIFY<br> > opcode and its enabling applications. But, well, one thing at a time.<= br> ><br> > On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse <<a href=3D"mailto:st= ephencalebmorse@gmail.com">stephencalebmorse@gmail.com</a>><br> > wrote:<br> >><br> >> Hi Mark,<br> >><br> >> Overall, I like this idea in every way except for one: unless I am= missing<br> >> something, we may still need an OP_RCLTV even with this being impl= emented.<br> >><br> >> In use cases such as micropayment channels where the funds are loc= ked up<br> >> by multiple parties, the enforcement of the relative locktime can = be done by<br> >> the first-signing party. So, while your solution would probably wo= rk in<br> >> cases like this, where multiple signing parties are involved, ther= e may be<br> >> other, seen or unforeseen, use cases that require putting the rela= tive<br> >> locktime right into the spending contract (the scriptPubKey itself= ). When<br> >> there is only one signer, there's nothing that enforces using = an nSequence<br> >> and nVersion=3D2 that would prevent spending the output until a ce= rtain time.<br> >><br> >> I hope this is received as constructive criticism, I do think this= is an<br> >> innovative idea. In my view, though, it seems to be less fully-fea= tured than<br> >> just repurposing an OP_NOP to create OP_RCLTV. The benefits are ob= viously<br> >> that it saves transaction space by repurposing unused space, and w= ould<br> >> likely work for most cases where an OP_RCLTV would be needed.<br> >><br> >> Best,<br> >> Stephen<br> >><br> >> On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach <<a href=3D"ma= ilto:mark@friedenbach.org">mark@friedenbach.org</a>><br> >> wrote:<br> >>><br> >>> I have written a reference implementation and BIP draft for a = soft-fork<br> >>> change to the consensus-enforced behaviour of sequence numbers= for the<br> >>> purpose of supporting transaction replacement via per-input re= lative<br> >>> lock-times. This proposal was previously discussed on the mail= ing list in<br> >>> the following thread:<br> >>><br> >>> <a href=3D"http://sourceforge.net/p/bitcoin/mailman/message/34= 146752/" target=3D"_blank">http://sourceforge.net/p/bitcoin/mailman/message= /34146752/</a><br> >>><br> >>> In short summary, this proposal seeks to enable safe transacti= on<br> >>> replacement by re-purposing the nSequence field of a transacti= on input to be<br> >>> a consensus-enforced relative lock-time.<br> >>><br> >>> The advantages of this approach is that it makes use of the fu= ll range of<br> >>> the 32-bit sequence number which until now has rarely been use= d for anything<br> >>> other than a boolean control over absolute nLockTime, and it d= oes so in a<br> >>> way that is semantically compatible with the originally envisi= oned use of<br> >>> sequence numbers for fast mempool transaction replacement.<br> >>><br> >>> The disadvantages are that external constraints often prevent = the full<br> >>> range of sequence numbers from being used when interpreted as = a relative<br> >>> lock-time, and re-purposing nSequence as a relative lock-time = precludes its<br> >>> use in other contexts. The latter point has been partially add= ressed by<br> >>> having the relative lock-time semantics be enforced only if th= e<br> >>> most-significant bit of nSequence is set. This preserves 31 bi= ts for<br> >>> alternative use when relative lock-times are not required.<br> >>><br> >>> The BIP draft can be found at the following gist:<br> >>><br> >>> <a href=3D"https://gist.github.com/maaku/be15629fe64618b14f5a"= target=3D"_blank">https://gist.github.com/maaku/be15629fe64618b14f5a</a><b= r> >>><br> >>> The reference implementation is available at the following git= <br> >>> repository:<br> >>><br> >>> <a href=3D"https://github.com/maaku/bitcoin/tree/sequencenumbe= rs" target=3D"_blank">https://github.com/maaku/bitcoin/tree/sequencenumbers= </a><br> >>><br> >>> I request that the BIP editor please assign a BIP number for t= his work.<br> >>><br> >>> Sincerely,<br> >>> Mark Friedenbach<br> >>><br> >>><br> >>> --------------------------------------------------------------= ----------------<br> >>><br> >>> _______________________________________________<br> >>> Bitcoin-development mailing list<br> >>> <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">B= itcoin-development@lists.sourceforge.net</a><br> >>> <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoi= n-development" target=3D"_blank">https://lists.sourceforge.net/lists/listin= fo/bitcoin-development</a><br> >>><br> >><br> ><br> ><br> > ----------------------------------------------------------------------= --------<br> ><br> > _______________________________________________<br> > Bitcoin-development mailing list<br> > <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d= evelopment@lists.sourceforge.net</a><br> > <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo= pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco= in-development</a><br> ><br> </blockquote></div> --001a113f8ef0ce101e05178ad2d0--