public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers
Date: Thu, 28 May 2015 11:30:18 +0100	[thread overview]
Message-ID: <CAE-z3OUG5p_hAOFvaE10kTT7sa=2GrzvZpis5FzATSEcNwZpyw@mail.gmail.com> (raw)
In-Reply-To: <CAOG=w-vusO30sBZfsuP94wbkUUfHupmhQtScGsJ2463sO=EpzA@mail.gmail.com>

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

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
>
>

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

  parent reply	other threads:[~2015-05-28 10:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-27  1:50 [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers Mark Friedenbach
2015-05-27  7:47 ` Peter Todd
2015-05-27  8:18   ` Gregory Maxwell
2015-05-27 10:00     ` Tier Nolan
2015-05-27 10:58     ` Peter Todd
2015-05-27 17:07       ` Jorge Timón
2015-05-27  8:04 ` Telephone Lemien
2015-05-27 10:11 ` Mike Hearn
2015-05-27 15:26   ` Mark Friedenbach
2015-05-27 17:39     ` Mike Hearn
2015-05-28  9:56       ` Mark Friedenbach
2015-05-28 10:23         ` Mike Hearn
2015-05-28 10:30         ` Tier Nolan [this message]
2015-05-28 12:04           ` Peter Todd
2015-05-28 13:35             ` Tier Nolan
2015-05-28 16:22               ` s7r
2015-05-28 17:21                 ` Tier Nolan
2015-05-28 14:59           ` Mark Friedenbach
2015-05-28 15:18             ` Tier Nolan
2015-05-28 15:38               ` Mark Friedenbach
2015-05-28 15:57                 ` Tier Nolan
2015-06-10  2:40                   ` Rusty Russell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAE-z3OUG5p_hAOFvaE10kTT7sa=2GrzvZpis5FzATSEcNwZpyw@mail.gmail.com' \
    --to=tier.nolan@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox