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

Mark Friedenbach mark at friedenbach.org
Thu May 28 09:56:36 UTC 2015


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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150528/ae531ae4/attachment.html>


More information about the bitcoin-dev mailing list