From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) id 1Yzdcw-0000yG-9w for bitcoin-development@lists.sourceforge.net; Tue, 02 Jun 2015 04:16:34 +0000 X-ACL-Warn: Received: from mail-ig0-f178.google.com ([209.85.213.178]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yzdcr-0000KN-Ie for bitcoin-development@lists.sourceforge.net; Tue, 02 Jun 2015 04:16:34 +0000 Received: by igblz2 with SMTP id lz2so1192276igb.1 for ; Mon, 01 Jun 2015 21:16:24 -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:cc:content-type; bh=Ti+ojCxfZtPumSqaerOV86ApScUaXBjTp+am9KHpILg=; b=I4qJkaHbqfEAvCCz9ieXxqwjJ3oehsLD2lQLMRrHVTvo94gYGXqDUSjCWTpbXFH/P/ uyohjHhF24E6PO13h8dr1iokbWtM33JuF3dsxjaG6trTKQILp2i7ii3A7XAiGhD3+ieH x+2DHVS/TGRg501cVH2bGJ2bqha+ab1QJ4rFMAELKnErS+rjkOhmJ6WSjAF48EMk2nTZ qqV55Cw5Dg3q5l5Aj7KJRQSYt4vlpvl8S0x1+waYYk88GP/exmkUYPXPKiyM0wlvyGqN NIhV6sn9LRwa2OANiko0OCI0PSu+lwmZ2nPw4nCmP5ASMr2nHmcisBdVkNd5zuG4MWTM 77UA== X-Gm-Message-State: ALoCoQmSASFdGEzUqdY0h1COVm9RHRxYMoBEsAIPTzZc2dCGpCgfC2vt6H5FYYFn0Y0mD1gcZHJY X-Received: by 10.43.40.130 with SMTP id tq2mr32884118icb.46.1433218583924; Mon, 01 Jun 2015 21:16:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.10.197 with HTTP; Mon, 1 Jun 2015 21:16:03 -0700 (PDT) X-Originating-IP: [50.0.37.37] In-Reply-To: References: From: Mark Friedenbach Date: Mon, 1 Jun 2015 21:16:03 -0700 Message-ID: To: Stephen Morse Content-Type: multipart/alternative; boundary=bcaec51dd84994c8610517813468 X-Spam-Score: 2.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 1.0 UC_GIBBERISH_OBFU Multiple instances of "word VERYLONGGIBBERISH word" X-Headers-End: 1Yzdcr-0000KN-Ie 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 04:16:34 -0000 --bcaec51dd84994c8610517813468 Content-Type: text/plain; charset=UTF-8 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 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 >> >> > --bcaec51dd84994c8610517813468 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You are correct! I am maintaining a 'checkse= quenceverify' branch in my git repository as well, an OP_RCLTV using se= quence 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 tha= t it possible to cleanly separate the relative lock-time (sequence numbers)= from the RCLTV opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in impl= ementation. Like CLTV, the CSV opcode only checks transaction data and requ= ires no contextual knowledge about block headers, a weakness of the other R= CLTV proposals that violate the clean separation between libscript and libc= onsensus. 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> w= rote:
Hi Mark,

Ov= erall, I like this idea in every way except for one: unless I am missing so= mething, we may still need an OP_RCLTV<= /font> even with this being implemented.=C2=A0

In use ca= ses 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 t= his, where multiple signing parties are involved, there may be other, seen = or unforeseen, use cases that require putting the relative locktime right i= nto the spending contract (the scriptPu= bKey itself). When there is only one signer, there's nothing tha= t enforces using an nSequence and nVersion=3D2 that would prevent spending = the output until a certain time.=C2=A0

I hope this= is received as constructive criticism, I do think this is an innovative id= ea. 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 t= hat it saves transaction space by repurposing unused space, and would likel= y 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@frieden= bach.org> wrote:
I have written a reference i= mplementation and BIP draft for a soft-fork change to the consensus-enforce= d behaviour of sequence numbers for the purpose of supporting transaction r= eplacement 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 rep= lacement by re-purposing the nSequence field of a transaction input to be a= consensus-enforced relative lock-time.

The advantages of this appro= ach is that it makes use of the full range of the 32-bit sequence number wh= ich until now has rarely been used for anything other than a boolean contro= l over absolute nLockTime, and it does so in a way that is semantically com= patible with the originally envisioned use of sequence numbers for fast mem= pool 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 nSequ= ence as a relative lock-time precludes its use in other contexts. The latte= r point has been partially addressed by having the relative lock-time seman= tics 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 req= uired.

The BIP draft can be found at the follo= wing gist:

https://gist.github.com/maaku/be15629fe64618b14f5a<= /a>

I request that the BIP ed= itor 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-de= velopment



--bcaec51dd84994c8610517813468--