From: Peter Todd <pete@petertodd•org>
To: 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 08:04:34 -0400 [thread overview]
Message-ID: <20150528120434.GA31349@savin.petertodd.org> (raw)
In-Reply-To: <CAE-z3OUG5p_hAOFvaE10kTT7sa=2GrzvZpis5FzATSEcNwZpyw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]
On Thu, May 28, 2015 at 11:30:18AM +0100, Tier Nolan 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).
For that matter, we probably don't want to treat this as a *version*
change, but rather a *feature* flag. For instance, nSequence is
potentially useful for co-ordinating multiple signatures to ensure they
can only be used in certain combinations, a use-case not neccesarily
compatible with this idea of a relative lock. Similarly it's potentially
useful for dealing with malleability.
nSequence is currently the *only* thing in CTxIn's that the signature
signs that can be freely changed; I won't be surprised if we find other
uses for it.
Of course, all of the above is assuming this proposal is useful; that's
not clear to me yet and won't be without fleshed out examples.
--
'peter'[:-1]@petertodd.org
000000000000000008464a6a19387029fa99edace15996d06a6343a8345d6167
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-05-28 12:04 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-27 1:50 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
2015-05-28 12:04 ` Peter Todd [this message]
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=20150528120434.GA31349@savin.petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=tier.nolan@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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