From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 05B1B69 for ; Tue, 17 Nov 2015 00:42:26 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148110.authsmtp.com (outmail148110.authsmtp.com [62.13.148.110]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 4E64910F for ; Tue, 17 Nov 2015 00:42:25 +0000 (UTC) Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt20.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tAH0gOrl099668 for ; Tue, 17 Nov 2015 00:42:24 GMT 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 tAH0gIGr069621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 17 Nov 2015 00:42:21 GMT Date: Mon, 16 Nov 2015 19:42:18 -0500 From: Peter Todd To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20151117004218.GB6302@savin.petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TRYliJ5NKNqkz5bu" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 102917b6-8cc4-11e5-829e-00151795d556 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hyKltILEZaQVBf Ri5dBBEKBAw1ADwr dVUTOktcZVUwAEN1 UkhIR0JSFA9sAxYD B1AZVwdzdgxYentx e0dkX29eVENldAg5 MzZUQhRxJ2dmYWYd UQ5cdgtdPgJKfBZE bQJ5SXteMmEaZ3s1 QkpjZWE8eG0HcXkM HVBQIQ9PH1AsBiJ5 RhZKMygrGQU/Sj03 Jhcrb3QNWWgcPw1y H0YlXRciGTFTYgAA X-Authentic-SMTP: 61633532353630.1037: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-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] Opt-in Full Replace-By-Fee (Full-RBF) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 00:42:26 -0000 --TRYliJ5NKNqkz5bu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Summary ------- Opt-In Full-RBF allows senders to opt-into full-RBF semantics for their transactions in a way that allows receivers to detect if the sender has done so. Existing "first-seen" mempool semantics are left unchanged for transactions that do not opt-in. At last week's IRC meeting(1) we decided to merge the opt-in Full-RBF pull-req(2), pending code review and this post, so this feature will likely make it into Bitcoin Core v0.12.0 Specification ------------- A transaction is considered to have opted into full-RBF semantics if nSequence < 0xFFFFFFFF-1 on at least one input. Nodes that respect the opt-in will allow such opt-in transactions (and their descendents) to be replaced in the mempool if they meet the economic replacement criteria. Transactions in blocks are of course unaffected. To detect if a transaction may be replaced check if it or any unconfirmed ancestors have set nSequence < 0xFFFFFFFF-1 on any inputs. Rational -------- nSequence is used for opting in as it is the only "free-form" field available for that purpose. Opt-in per output was proposed as well by Luke-Jr, however the CTxOut data structure simply doesn't contain any extra fields to use for that purpose. nSequence-based opt-in is also compatible with the consensus-enforced transaction replacement semantics in BIP68. Allowing replacement if any input opts in vs. all inputs opting in is chosen to ensure that transactions authored by multiple parties aren't held up by the actions of a single party. Additionally, in the multi-party scenario the value of any zeroconf guarantees are especially dubious. Replacement is allowed even if unconfirmed children did not opt-in to ensure receivers can't maliciously prevent a replacement by spending the funds. Additionally, any reasonable attempt at determining if a transaction can be double-spent has to look at all unconfirmed parents anyway. Feedback from wallet authors indicates that first-seen-safe RBF isn't very useful in practice due to the limitations inherent in FSS rules; opt-in full-RBF doesn't preclude FSS-RBF from also being implemented. Compatibility ------------- Opt-in RBF transactions are currently mined by 100% of the hashing power. Bitcoin Core has been producing transactions with non-maxint nSequence since v0.11.0 to discourage fee sniping(3), and currently no wallets are known that display such transactions yet do not display opt-in RBF transactions. Demonstrations -------------- https://github.com/petertodd/replace-by-fee-tools#incremental-send-many 1) http://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2015-November= /000010.html 2) https://github.com/bitcoin/bitcoin/pull/6871 3) https://github.com/bitcoin/bitcoin/pull/2340 --=20 'peter'[:-1]@petertodd.org 00000000000000000f30567c63f8f4f079a8ecc2ab3d380bc7dc370e792b0a3a --TRYliJ5NKNqkz5bu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJWSnflXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwYWE1ZTY5MmU0ZGIxMjk1NDYwNmE5ZmExZGIwNThiZDlj YjA4ZmQyYjE5Njc4NTMvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvkAwf/XmV6P4NESL5BUsHfOJF+I0RA xYBAbGhfyYztfRGkjpLuWysO49c1q9CH1b4GoFkPXBHLC0C0vEY9TXdCOZ213y9P GZrQGdwvkWP4f4//GjQ21MUPQnP9A1P6IGcSuBdMOIA5pcK2L7MpS9gGUaOxRImG cJdl265LokAZoJ+MTCVEbhRZzkv2oQwtsdYk0sl8nED+DNESPNfm13XsoKNmhx0l bEyIQ6OjrbR0ZoRUlPA4XiWVsnZt5RRA5dQy6o6cDSDeYPYIuu5gApcXlwnsh1rn v0AttWoccStKPxQjXUdIoavgPtl2sfUNED42NoEVngxXs+vgmYWO5tXRuOqJpA== =rLPd -----END PGP SIGNATURE----- --TRYliJ5NKNqkz5bu--