From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yzlgq-00029F-CH for bitcoin-development@lists.sourceforge.net; Tue, 02 Jun 2015 12:53:08 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.51 as permitted sender) client-ip=209.85.216.51; envelope-from=stephencalebmorse@gmail.com; helo=mail-vn0-f51.google.com; Received: from mail-vn0-f51.google.com ([209.85.216.51]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yzlgn-00072v-Q4 for bitcoin-development@lists.sourceforge.net; Tue, 02 Jun 2015 12:53:08 +0000 Received: by vnbg129 with SMTP id g129so20270159vnb.11 for ; Tue, 02 Jun 2015 05:53:00 -0700 (PDT) X-Received: by 10.52.249.4 with SMTP id yq4mr9066940vdc.61.1433249580344; Tue, 02 Jun 2015 05:53:00 -0700 (PDT) Received: from [10.0.0.7] (c-24-218-184-40.hsd1.nh.comcast.net. [24.218.184.40]) by mx.google.com with ESMTPSA id ql13sm26879547vdb.2.2015.06.02.05.52.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Jun 2015 05:52:59 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-53F44E09-CEB9-4E68-B2E0-F81F95D556FF Mime-Version: 1.0 (1.0) From: Stephen X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Tue, 2 Jun 2015 08:52:58 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: To: Mark Friedenbach X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stephencalebmorse[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Yzlgn-00072v-Q4 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 12:53:08 -0000 --Apple-Mail-53F44E09-CEB9-4E68-B2E0-F81F95D556FF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Do you think it would be useful to have an inverted version of both CSV and C= LTV? To verify if an output is spent before a specific time. CLTV and CSV co= uld be implemented by taking two stack arguments, an integer for the compari= son and TRUE/FALSE.=20 Now that I think about this more, the problem is that, for example, just hav= ing a lock time of less than some value doesn't actually mean it has to be s= pent before that script value, so this might not work. Likely any implementa= tions of such a feature would have to provide the script execution environme= nt with access to information that it doesn't have now, which is what we are= trying to avoid.=20 Best, Stephen > On Jun 2, 2015, at 12:16 AM, Mark Friedenbach wrote= : >=20 > You are correct! I am maintaining a 'checksequenceverify' branch in my git= repository as well, an OP_RCLTV using sequence numbers: >=20 > https://github.com/maaku/bitcoin/tree/checksequenceverify >=20 > Most of the interesting use cases for relative lock-time require an RCLTV o= pcode. What is interesting about this architecture is that it possible to cl= eanly separate the relative lock-time (sequence numbers) from the RCLTV opco= de (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation. Like CLTV= , the CSV opcode only checks transaction data and requires no contextual kno= wledge about block headers, a weakness of the other RCLTV proposals that vio= late the clean separation between libscript and libconsensus. In a similar w= ay, this BIP proposal only touches the transaction validation logic without a= ny impact to script. >=20 > I would like to propose an additional BIP covering the CHECKSEQUENCEVERIFY= opcode and its enabling applications. But, well, one thing at a time. >=20 >> On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse wrote: >> Hi Mark, >>=20 >> Overall, I like this idea in every way except for one: unless I am missin= g something, we may still need an OP_RCLTV even with this being implemented.= =20 >>=20 >> In use cases such as micropayment channels where the funds are locked up b= y multiple parties, the enforcement of the relative locktime can be done by t= he 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 ri= ght into the spending contract (the scriptPubKey itself). When there is only= one signer, there's nothing that enforces using an nSequence and nVersion=3D= 2 that would prevent spending the output until a certain time.=20 >>=20 >> I hope this is received as constructive criticism, I do think this is an i= nnovative idea. In my view, though, it seems to be less fully-featured than j= ust repurposing an OP_NOP to create OP_RCLTV. The benefits are obviously tha= t it saves transaction space by repurposing unused space, and would likely w= ork for most cases where an OP_RCLTV would be needed. >>=20 >> Best, >> Stephen >>=20 >>> On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach w= rote: >>> I have written a reference implementation and BIP draft for a soft-fork c= hange to the consensus-enforced behaviour of sequence numbers for the purpos= e of supporting transaction replacement via per-input relative lock-times. T= his proposal was previously discussed on the mailing list in the following t= hread: >>>=20 >>> http://sourceforge.net/p/bitcoin/mailman/message/34146752/ >>>=20 >>> In short summary, this proposal seeks to enable safe transaction replace= ment by re-purposing the nSequence field of a transaction input to be a cons= ensus-enforced relative lock-time. >>>=20 >>> The advantages of this approach is that it makes use of the full range o= f the 32-bit sequence number which until now has rarely been used for anythi= ng 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 s= equence numbers for fast mempool transaction replacement. >>>=20 >>> The disadvantages are that external constraints often prevent the full r= ange 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 i= n other contexts. The latter point has been partially addressed by having th= e relative lock-time semantics be enforced only if the most-significant bit o= f nSequence is set. This preserves 31 bits for alternative use when relative= lock-times are not required. >>>=20 >>> The BIP draft can be found at the following gist: >>>=20 >>> https://gist.github.com/maaku/be15629fe64618b14f5a >>>=20 >>> The reference implementation is available at the following git repositor= y: >>>=20 >>> https://github.com/maaku/bitcoin/tree/sequencenumbers >>>=20 >>> I request that the BIP editor please assign a BIP number for this work. >>>=20 >>> Sincerely, >>> Mark Friedenbach >>>=20 >>> ------------------------------------------------------------------------= ------ >>>=20 >>> _______________________________________________ >>> Bitcoin-development mailing list >>> Bitcoin-development@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >=20 --Apple-Mail-53F44E09-CEB9-4E68-B2E0-F81F95D556FF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Do you think it would be useful to hav= e an inverted version of both CSV and CLTV? To verify if an output is spent b= efore 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 exam= ple, just 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 a= ny implementations of such a feature would have to provide the script execut= ion environment with access to information that it doesn't have now, which i= s what we are trying to avoid. 

Best,
Stephen



On Jun 2, 2015, at 12:16 AM, Mark Friede= nbach <mark@friedenbach.org&g= t; wrote:

=
You are correct! I am maintaining a 'checksequenceverify' branch in my g= it repository as well, an OP_RCLTV using sequence numbers:

https://github.c= om/maaku/bitcoin/tree/checksequenceverify

Most of the inter= esting use cases for relative lock-time require an RCLTV opcode. What is int= eresting about this architecture is that it possible to cleanly separate the= relative lock-time (sequence numbers) from the RCLTV opcode (OP_CHECKSEQUEN= CEVERIFY) both in concept and in implementation. Like CLTV, the CSV opcode o= nly checks transaction data and requires no contextual knowledge about block= headers, a weakness of the other RCLTV proposals that violate the clean sep= aration between libscript and libconsensus. In a similar way, this BIP propo= sal only touches the transaction validation logic without any impact to scri= pt.

I would like to propose an additional BIP covering the CHEC= KSEQUENCEVERIFY opcode and its enabling applications. But, well, one thing a= t 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: u= nless 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 lock= ed up by multiple parties, the enforcement of the relative locktime can be d= one by the first-signing party. So, while your solution would probably work i= n cases like this, where multiple signing parties are involved, there may be= other, seen or unforeseen, use cases that require putting the relative lock= time right into the spending contract (the scriptPubKey itself). When there is only one signer, there's nothi= ng that enforces using an nSequence and nVersion=3D2 that would prevent spen= ding the output until a certain time. 

I hope t= his is received as constructive criticism, I do think this is an innovative i= dea. In my view, though, it seems to be less fully-featured than just repurp= osing an OP_NOP to create OP_RCLTV. The benefits are obviously tha= t it saves transaction space by repurposing unused space, and would likely w= ork 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 implementati= on and BIP draft for a soft-fork change to the consensus-enforced behaviour o= f sequence numbers for the purpose of supporting transaction replacement via= per-input relative lock-times. This proposal was previously discussed on th= e mailing list in the following thread:

http://sourcefor= ge.net/p/bitcoin/mailman/message/34146752/

In short su= mmary, this proposal seeks to enable safe transaction replacement by re-purp= osing the nSequence field of a transaction input to be a consensus-enforced r= elative lock-time.

The advantages of this approach is that it makes u= se of the full range of the 32-bit sequence number which until now has rarel= y been used for anything other than a boolean control over absolute nLockTim= e, and it does so in a way that is semantically compatible with the original= ly envisioned use of sequence numbers for fast mempool transaction replaceme= nt.

The disadvantages are that external constraints often p= revent the full range of sequence numbers from being used when interpreted a= s a relative lock-time, and re-purposing nSequence as a relative lock-time p= recludes its use in other contexts. The latter point has been partially addr= essed by having the relative lock-time semantics be enforced only if the mos= t-significant bit of nSequence is set. This preserves 31 bits for alternativ= e 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 i= mplementation 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 w= ork.

Sincerely,
Mark Friedenbach

------------------------------------------------------------= ------------------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-deve= lopment



= --Apple-Mail-53F44E09-CEB9-4E68-B2E0-F81F95D556FF--