Why 3? Do we have a version 2? As for doing it in serialization, that would alter the txid making it a hard fork change. On May 28, 2015 03:30, "Tier Nolan" <tier.no...@gmail.com> 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. > > 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 <m...@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 <m...@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 > >
------------------------------------------------------------------------------
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
