From: Mark Friedenbach <mark@friedenbach•org>
To: Stephen Morse <stephencalebmorse@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers
Date: Mon, 1 Jun 2015 21:16:03 -0700 [thread overview]
Message-ID: <CAOG=w-tDdJTkkqGaEEpDZ6pX0kXT7f2wvoN_cEpd6+MVnu1CdQ@mail.gmail.com> (raw)
In-Reply-To: <CABHVRKQD4YPt0NA8VnXW4VYx0fmCgSHUYq-73F2esHZqX-FUxw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4442 bytes --]
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
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 6003 bytes --]
next prev parent reply other threads:[~2015-06-02 4:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-02 1:49 Mark Friedenbach
2015-06-02 3:45 ` Stephen Morse
2015-06-02 4:16 ` Mark Friedenbach [this message]
2015-06-02 4:34 ` Stephen Morse
2015-06-02 15:42 ` Tier Nolan
2015-06-02 12:52 ` Stephen
2015-06-02 13:11 ` Adam Back
2015-06-02 14:10 ` Stephen Morse
2015-06-02 15:44 ` Mark Friedenbach
2015-06-17 1:00 ` Mark Friedenbach
2015-06-17 1:20 ` Gregory Maxwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAOG=w-tDdJTkkqGaEEpDZ6pX0kXT7f2wvoN_cEpd6+MVnu1CdQ@mail.gmail.com' \
--to=mark@friedenbach$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=stephencalebmorse@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox