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 ) 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 ; 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: References: Date: Tue, 2 Jun 2015 08:44:53 -0700 Message-ID: From: Mark Friedenbach To: Adam Back 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" 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 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 > 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 > >> 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

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.=

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" &l= t;adam@cypherspace.org> wrot= e:
That would also i= ntroduce the anomaly of a script that was once valid
becoming later invalid, when nothing varies other than time.=C2=A0 That is<= br> 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<= br> making it the previous holders responsibility to spend a "not before&q= uot;
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 CS= V 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, ju= st
> having a lock time of less than some value doesn't actually mean i= t has to
> 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
> environment with access to information that it doesn't have now, w= hich 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' bran= ch 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 RC= LTV
> opcode. What is interesting about this architecture is that it possibl= e to
> cleanly separate the relative lock-time (sequence numbers) from the RC= LTV
> opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation.= Like
> CLTV, the CSV opcode only checks transaction data and requires no cont= extual
> knowledge about block headers, a weakness of the other RCLTV proposals= that
> violate the clean separation between libscript and libconsensus. In a<= br> > 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 CHECKSEQUENCEVE= RIFY
> opcode and its enabling applications. But, well, one thing at a time.<= br> >
> 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 impl= emented.
>>
>> In use cases such as micropayment channels where the funds are loc= ked up
>> by multiple parties, the enforcement of the relative locktime can = be done by
>> the first-signing party. So, while your solution would probably wo= rk in
>> cases like this, where multiple signing parties are involved, ther= e may be
>> other, seen or unforeseen, use cases that require putting the rela= tive
>> 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=3D2 that would prevent spending the output until a ce= rtain 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-fea= tured than
>> just repurposing an OP_NOP to create OP_RCLTV. The benefits are ob= viously
>> that it saves transaction space by repurposing unused space, and w= ould
>> 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 re= lative
>>> lock-times. This proposal was previously discussed on the mail= ing list in
>>> the following thread:
>>>
>>> http://sourceforge.net/p/bitcoin/mailman/message= /34146752/
>>>
>>> In short summary, this proposal seeks to enable safe transacti= on
>>> replacement by re-purposing the nSequence field of a transacti= on input to be
>>> a consensus-enforced relative lock-time.
>>>
>>> The advantages of this approach is that it makes use of the fu= ll range of
>>> the 32-bit sequence number which until now has rarely been use= d for anything
>>> other than a boolean control over absolute nLockTime, and it d= oes so in a
>>> way that is semantically compatible with the originally envisi= oned 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 add= ressed by
>>> having the relative lock-time semantics be enforced only if th= e
>>> most-significant bit of nSequence is set. This preserves 31 bi= ts 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 t= his work.
>>>
>>> Sincerely,
>>> Mark Friedenbach
>>>
>>>
>>> --------------------------------------------------------------= ----------------
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> B= itcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listin= fo/bitcoin-development
>>>
>>
>
>
> ----------------------------------------------------------------------= --------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-d= evelopment@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitco= in-development
>
--001a113f8ef0ce101e05178ad2d0--