public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd•org>
To: Mark Friedenbach <mark@friedenbach•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 03:47:13 -0400	[thread overview]
Message-ID: <20150527074713.GB22286@savin.petertodd.org> (raw)
In-Reply-To: <CAOG=w-sfiUQQGUh=RR55NU-TkAi1+2g3_Z+YP3dGDjp8zXYBGQ@mail.gmail.com>

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

On Tue, May 26, 2015 at 06:50:29PM -0700, Mark Friedenbach wrote:
> Sequence numbers appear to have been originally intended as a mechanism for
> transaction replacement within the context of multi-party transaction
> construction, e.g. a micropayment channel. The idea is that a participant
> can sign successive versions of a transaction, each time incrementing the
> sequence field by some amount. Relay nodes perform transaction replacement
> according to some policy rule making use of the sequence numbers, e.g.
> requiring sequence numbers in a replacement to be monotonically increasing.

Can you provide a worked example of this in use? I think I see a major
flaw, but I'd like to see a worked example first.

Keep in mind that there's absolutely no reason to have pending
transactions in mempools until we actually expect them to be mined.
Equally this proposal is no more "consensus enforcement" than simply
increasing the fee (and possibly decreasing the absolute nLockTime) for
each replacement would be; increasing the fee for each mempool
replacement is a hard requirement as an anti-DoS anyway. (this was all
discussed on the mailing list two years ago when RBF was first proposed)

-- 
'peter'[:-1]@petertodd.org
00000000000000000ec0c3a90baa52289171046469fe4a21dc5a0dac4cb758a9

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

  reply	other threads:[~2015-05-27  7:47 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 [this message]
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
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=20150527074713.GB22286@savin.petertodd.org \
    --to=pete@petertodd$(echo .)org \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=mark@friedenbach$(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