Tier Nolan tier.no...@gmail.com writes:
What are the use cases for relative lock time verify? I have 1 and I think
that is the kind of thing it is useful for.
I think that most cases are just to guarantee that the other party has a
chance to react. This means that 8191 blocks should be more
Can you update it so that it only applies to transactions with version
number 3 and higher. Changing the meaning of a field is exactly what the
version numbers are for.
You could even decode version 3 transactions like that.
Version 3 transactions have a sequence number of 0x and the
On Thu, May 28, 2015 at 11:30:18AM +0100, Tier Nolan wrote:
Can you update it so that it only applies to transactions with version
number 3 and higher. Changing the meaning of a field is exactly what the
version numbers are for.
You could even decode version 3 transactions like that.
On Thu, May 28, 2015 at 3:59 PM, Mark Friedenbach m...@friedenbach.org
wrote:
Why 3? Do we have a version 2?
I meant whatever the next version is, so you are right, it's version 2.
As for doing it in serialization, that would alter the txid making it a
hard fork change.
The change is
On Wed, May 27, 2015 at 08:18:52AM +, Gregory Maxwell wrote:
On Wed, May 27, 2015 at 7:47 AM, Peter Todd p...@petertodd.org wrote:
Equally this proposal is no more consensus enforcement than simply
increasing the fee (and possibly decreasing the absolute nLockTime) for
You've
Sequence numbers appear to have been originally intended as a mechanism
for transaction replacement within the context of multi-party transaction
construction, e.g. a micropayment channel.
Yes indeed they were. Satoshis mechanism was more general than micropayment
channels and could do HFT
This could cause legacy transactions to become unspendable.
A new transaction version number should be used to indicate the change of
the field from sequence number to relative lock time.
Legacy transactions should not have the rule applied to them.
On Wed, May 27, 2015 at 9:18 AM, Gregory
On Wed, May 27, 2015 at 7:47 AM, Peter Todd p...@petertodd.org wrote:
Equally this proposal is no more consensus enforcement than simply
increasing the fee (and possibly decreasing the absolute nLockTime) for
You've misunderstood it, I think-- Functionally nlocktime but relative
to each txin's
On Wed, May 27, 2015 at 3:11 AM, Mike Hearn m...@plan99.net wrote:
As I believe out of all proposed protocols Satoshi's is still the most
powerful, I would suggest that any change to the semantics on nSequence be
gated by a high bit or something, so the original meaning remains available
On May 27, 2015 12:58 PM, Peter Todd p...@petertodd.org wrote:
What I'm not seeing is how the relative nLockTime that nSequence
provides fundamentally changes any of this.
This allows the implementation of a rcltv that doesn't make script depend
on the current height, in a similar way that
Mike, this proposal was purposefully constructed to maintain as well as
possible the semantics of Satoshi's original construction. Higher sequence
numbers -- chronologically later transactions -- are able to hit the chain
earlier, and therefore it can be reasonably argued will be selected by
On Tue, May 26, 2015 at 06:50:29PM -0700, Mark Friedenbach wrote:
Sequence numbers appear to have been originally intended as a mechanism for
transaction replacement within the context of multi-party transaction
construction, e.g. a micropayment channel. The idea is that a participant
can sign
Please remove me from the mailing list
2015-05-27 3:50 GMT+02:00 Mark Friedenbach m...@friedenbach.org:
Sequence numbers appear to have been originally intended as a mechanism
for transaction replacement within the context of multi-party transaction
construction, e.g. a micropayment channel.
13 matches
Mail list logo
