Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.102 as permitted sender)
	client-ip=62.13.148.102; envelope-from=pete@petertodd.org;
	helo=outmail148102.authsmtp.net; 
Date: Wed, 27 May 2015 03:47:13 -0400
From: Peter Todd <pete@petertodd.org>
To: Mark Friedenbach <mark@friedenbach.org>
Message-ID: <20150527074713.GB22286@savin.petertodd.org>
References: <CAOG=w-sfiUQQGUh=RR55NU-TkAi1+2g3_Z+YP3dGDjp8zXYBGQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="kORqDWCi7qDJ0mEj"
Content-Disposition: inline
In-Reply-To: <CAOG=w-sfiUQQGUh=RR55NU-TkAi1+2g3_Z+YP3dGDjp8zXYBGQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Consensus-enforced transaction
 replacement via sequence numbers
Precedence: list


--kORqDWCi7qDJ0mEj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, May 26, 2015 at 06:50:29PM -0700, Mark Friedenbach wrote:
> Sequence numbers appear to have been originally intended as a mechanism f=
or
> 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 increasin=
g.

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)

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

--kORqDWCi7qDJ0mEj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJVZXZ9XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwZWMwYzNhOTBiYWE1MjI4OTE3MTA0NjQ2OWZlNGEyMWRj
NWEwZGFjNGNiNzU4YTkvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvzfAf9Fi8rKqat2Y6cyhkSK0cUlgWS
WjJqS+09La9shwi2B7fRiAPWKfdAP5h7x/4gdgUavc8tSCEj1G226APWqJW4x2ZD
MdH3Qxo6Am/aHoey1bY3mEWGXAsAiBKVndqzxcL5i8BQD+qvLR23jHhpEKawUTbv
nS1/Vw3qR3/igakymG6PfhWpZudUPnh0i6wsJzwwTBOoEkwRJ5FlLcUCctjNC5ss
l49tIDQh7H59B34Jv98m9p7VShrafRBiBRZ9pzESlGivbH9G1EaZtb+V+cP4tdpK
zVu32AqDf5H2bnAp57X4yIjOTYkhDqbsRYnpKnuHwBcn0ZDx0fYFRDpPD4qEBA==
=2++E
-----END PGP SIGNATURE-----

--kORqDWCi7qDJ0mEj--