Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YxW3l-0007yy-AO for bitcoin-development@lists.sourceforge.net; Wed, 27 May 2015 07:47:29 +0000 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; Received: from outmail148102.authsmtp.net ([62.13.148.102]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YxW3i-0001oO-Bq for bitcoin-development@lists.sourceforge.net; Wed, 27 May 2015 07:47:29 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt16.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t4R7lJ0u074681; Wed, 27 May 2015 08:47:19 +0100 (BST) Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com [75.119.251.161]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t4R7lDTk095849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 27 May 2015 08:47:16 +0100 (BST) Date: Wed, 27 May 2015 03:47:13 -0400 From: Peter Todd To: Mark Friedenbach Message-ID: <20150527074713.GB22286@savin.petertodd.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kORqDWCi7qDJ0mEj" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 98a8d405-0444-11e5-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAUUFVQNAgsB AmMbW1xeVFp7WGQ7 bA9PbARUfEhLXhtr VklWR1pVCwQmRRhj AUJqNkJyfgBOfHc+ bU5gXT5SVBVyIUJ9 R1NUEWkCeGZhPWUC WRZfcx5UcAFPdx8U a1N6AHBDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4gGTgn ShYZAC5qEEsLQD84 IhBuNkQVGl0YOVkz Nl1pQ18ANxYZBwhT GV0vSDFYLhEaSjM2 AAVRUAYYDThXTD1H agAA X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.119.251.161/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record -0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YxW3i-0001oO-Bq Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 07:47:29 -0000 --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--