<div dir="ltr">I see, so OP_SEQUENCEVERIFY will have a value pushed on the stack right before, and then check that the input spending the prevout has nSequence corresponds to at least the sequence specified by the stack value. Good idea! Keeps the script code from depending on external chain specific data, which is nice. <div><br></div><div>Hopefully we can repurpose one of the OP_NOPs for CHECKLOCKTIMEVERIFY and one for OP_CHECKSEQUENCEVERIFY. Very complementary. </div><div><br></div><div>Best,<br>Stephen</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 2, 2015 at 12:16 AM, Mark Friedenbach <span dir="ltr"><<a href="mailto:mark@friedenbach.org" target="_blank">mark@friedenbach.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>You are correct! I am maintaining a 'checksequenceverify' branch in my git repository as well, an OP_RCLTV using sequence numbers:<br><br><a href="https://github.com/maaku/bitcoin/tree/checksequenceverify" target="_blank">https://github.com/maaku/bitcoin/tree/checksequenceverify</a><br><br></div>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.<br><br></div>I would like to propose an additional BIP covering the CHECKSEQUENCEVERIFY opcode and its enabling applications. But, well, one thing at a time.<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse <span dir="ltr"><<a href="mailto:stephencalebmorse@gmail.com" target="_blank">stephencalebmorse@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Mark,<br><br>Overall, I like this idea in every way except for one: unless I am missing something, we may still need an <font face="monospace, monospace">OP_RCLTV</font> even with this being implemented. <div><br></div><div>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 <font face="monospace, monospace">scriptPubKey</font> 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. </div><div><br></div><div>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 <font face="monospace, monospace">OP_NOP</font> to create <font face="monospace, monospace">OP_RCLTV</font>. The benefits are obviously that it saves transaction space by repurposing unused space, and would likely work for most cases where an <font face="monospace, monospace">OP_RCLTV</font> would be needed.</div><div><br></div><div>Best,<br>Stephen</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach <span dir="ltr"><<a href="mailto:mark@friedenbach.org" target="_blank">mark@friedenbach.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div>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:<br><br><a href="http://sourceforge.net/p/bitcoin/mailman/message/34146752/" target="_blank">http://sourceforge.net/p/bitcoin/mailman/message/34146752/</a><br><br></div><div>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.<br><br>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.<br><br></div><div>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.<br></div><div><br></div><div>The BIP draft can be found at the following gist:<br><br><a href="https://gist.github.com/maaku/be15629fe64618b14f5a" target="_blank">https://gist.github.com/maaku/be15629fe64618b14f5a</a><br><br></div><div>The reference implementation is available at the following git repository:<br></div><div><br><a href="https://github.com/maaku/bitcoin/tree/sequencenumbers" target="_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>
<br></div></div>------------------------------------------------------------------------------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net" target="_blank">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>