From: Gregory Maxwell <gmaxwell@gmail•com>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers
Date: Wed, 27 May 2015 08:18:52 +0000 [thread overview]
Message-ID: <CAAS2fgSjT-dtS8cNoRjvEhtBeG9SUi4OsKAAGkAf_WkxEyg=9g@mail.gmail.com> (raw)
In-Reply-To: <20150527074713.GB22286@savin.petertodd.org>
On Wed, May 27, 2015 at 7:47 AM, Peter Todd <pete@petertodd•org> wrote:
> Equally this proposal is no more "consensus enforcement" than simply
> increasing the fee (and possibly decreasing the absolute nLockTime) for
You've misunderstood it, I think-- Functionally nlocktime but relative
to each txin's height.
But the construction gives the sequence numbers a rational meaning,
they count down the earliest position a transaction can be included.
(e.g. the highest possible sequence number can be included any time
the inputs are included) the next lower sequence number can only be
included one block later than the input its assigned to is included,
the next lower one block beyond that. All consensus enforced. A
miner could opt to not include the higher sequence number (which is
the only one of the set which it _can_ include) it the hopes of
collecting more fees later on the next block, similar to how someone
could ignore an eligible locked transaction in the hopes that a future
double spend will be more profitable (and that it'll enjoy that
profit) but in both cases it must take nothing at all this block, and
risk being cut off by someone else (and, of course, nothing requires
users use sequence numbers only one apart...).
It makes sequence numbers work exactly like you'd expect-- within the
bounds of whats possible in a decentralized system. At the same time,
all it is ... is relative nlocktime.
next prev parent reply other threads:[~2015-05-27 8:19 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 [this message]
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
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='CAAS2fgSjT-dtS8cNoRjvEhtBeG9SUi4OsKAAGkAf_WkxEyg=9g@mail.gmail.com' \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pete@petertodd$(echo .)org \
/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