On Wed, Jun 17, 2015 at 1:00 AM, Mark Friedenbach 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 work. Will
> the BIP
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 work. Will
the BIP editor be so kind as to do so to allow the BIP consensus process t
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 ver
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
transac
>
> 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
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 flexibility
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 problem
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
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
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
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
11 matches
Mail list logo
