Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

2015-06-16 Thread Gregory Maxwell
On Wed, Jun 17, 2015 at 1:00 AM, Mark Friedenbach m...@friedenbach.org wrote: Given that we have had more than two weeks of public discussion, code is available and reviewed, and several community identified issues resolved, I would like to formally request a BIP number be assigned for this

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

2015-06-02 Thread Stephen Morse
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. Very good

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

2015-06-02 Thread Adam Back
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

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

2015-06-02 Thread Stephen
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

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

2015-06-02 Thread Mark Friedenbach
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

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

2015-06-02 Thread Tier Nolan
I am glad to see the transaction version number increase. The commit doesn't update the default transaction version though. The node would still produce version 1 transactions. Does the reference client already produce transactions with final sequence numbers? If so, then they will be valid

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

2015-06-01 Thread Stephen Morse
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

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

2015-06-01 Thread Stephen Morse
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

[Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

2015-06-01 Thread Mark Friedenbach
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