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 0xFFFFFFFF and the sequence number field is re-purposed for relative lock time. 

This means that legacy transactions that have already been signed but have a locktime in the future will still be able to enter the blockchain (without having to wait significantly longer than expected).

On Thu, May 28, 2015 at 10:56 AM, Mark Friedenbach <mark@friedenbach.org> wrote:

I have no problem with modifying the proposal to have the most significant bit signal use of the nSequence field as a relative lock-time. That leaves a full 31 bits for experimentation when relative lock-time is not in use. I have adjusted the code appropriately:

https://github.com/maaku/bitcoin/tree/sequencenumbers

On Wed, May 27, 2015 at 10:39 AM, Mike Hearn <mike@plan99.net> wrote:

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 miners before the later transactions mature. Did I fail in some way to capture that original intent?

Right, but the original protocol allowed for e.g. millions of revisions of the transaction, hence for high frequency trading (that's actually how Satoshi originally explained it to me - as a way to do HFT - back then the channel concept didn't exist).

As you point out, with a careful construction of channels you should only need to bump the sequence number when the channel reverses direction. If your app only needs to do that rarely, it's a fine approach.And your proposal does sounds better than sequence numbers being useless like at the moment. I'm just wondering if we can get back to the original somehow or at least leave a path open to it, as it seems to be a superset of all other proposals, features-wise.

------------------------------------------------------------------------------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

------------------------------------------------------------------------------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development