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

[Mark Friedenbach <mark@friedenbach.org>]

[-- Attachment #1: Type: text/plain, Size: 3066 bytes --]

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.nolan@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 <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
>
>

[-- Attachment #2: Type: text/html, Size: 4692 bytes --]