path: root/25/3ec308fb58d859da9d54340b2bebeda7d2fcc0

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 <pete@petertodd.org>) id 1Yx7Az-0007lj-Sa
	for bitcoin-development@lists.sourceforge.net;
	Tue, 26 May 2015 05:13:17 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.109 as permitted sender)
	client-ip=62.13.148.109; envelope-from=pete@petertodd.org;
	helo=outmail148109.authsmtp.co.uk; 
Received: from outmail148109.authsmtp.co.uk ([62.13.148.109])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1Yx7Ay-00065m-2P for bitcoin-development@lists.sourceforge.net;
	Tue, 26 May 2015 05:13:17 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
	by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t4Q5D9jn059413
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 26 May 2015 06:13:09 +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 t4Q5D5gb086343
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 26 May 2015 06:13:08 +0100 (BST)
Date: Tue, 26 May 2015 01:13:05 -0400
From: Peter Todd <pete@petertodd.org>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <20150526051305.GA23502@savin.petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: e5f6c322-0365-11e5-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd
	P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXQN1
	LRkAXVBSFQB4ARoL Bx0UUhE8cABYeX95 e0RnX25aWkVlcE56
	XU8aUWlnYBNlPzIf WEZbcwAacQVLfBkL P1UpUiAOY2caZnlm
	QkpqZj1seD8EeXoQ GllXcANKSB9WEjdj UT4DBy4zWHYISiN2
	FBUoJxYmEV4VO04/ dFEwHHwVPnc8
X-Authentic-SMTP: 61633532353630.1023: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: 1Yx7Ay-00065m-2P
Subject: [Bitcoin-development] First-Seen-Safe Replace-by-Fee
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2015 05:13:17 -0000


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

Summary
-------

First-seen-safe replace-by-fee (FSS RBF) does the following:

1) Give users effective ways of getting "stuck" transactions unstuck.
2) Use blockchain space efficiently.

without:

3) Changing the status quo with regard to zeroconf.

The current Bitcoin Core implementation has "first-seen" mempool
behavior. Once transaction t1 has been accepted, the transaction is
never removed from the mempool until mined, or double-spent by a
transaction in a block. The author's previously proposed replace-by-fee
replaced this behavior with simply accepting the transaction paying the
highest fee.

FSS RBF is a compromise between these two behaviors. Transactions may be
replaced by higher-fee paying transactions, provided that all outputs in
the previous transaction are still paid by the replacement. While not as
general as standard RBF, and with higher costs than standard RBF, this
still allows fees on transaction to be increased after the fact with
less cost and higher efficiency than child-pays-for-parent in many
common situations; in some situations CPFP is unusable, leaving RBF as
the only option.


Semantics
---------

For reference, standard replace-by-fee has the following criteria for
determining whether to replace a transaction.

1) t2 pays > fees than t1

2) The delta fees pay by t2, t2.fee - t1.fee, are >=3D the minimum fee
   required to relay t2. (t2.size * min_fee_per_kb)

3) t2 pays more fees/kb than t1

FSS RBF adds the following additional criteria to replace-by-fee before
allowing a transaction t1 to be replaced with t2:

1) All outputs of t1 exist in t2 and pay >=3D the value in t1.

2) All outputs of t1 are unspent.

3) The order of outputs in t2 is the same as in t1 with additional new
   outputs at the end of the output list.

4) t2 only conflicts with a single transaction, t1

5) t2 does not spend any outputs of t1 (which would make it an invalid
   transaction, impossible to mine)

These additional criteria respect the existing "first-seen" behavior of
the Bitcoin Core mempool implementation, such that once an address is
payed some amount of BTC, all subsequent replacement transactions will
pay an equal or greater amount. In short, FSS-RBF is "zeroconf safe" and
has no affect on the ability of attackers to doublespend. (beyond of
course the fact that any changes what-so-ever to mempool behavior are
potential zeroconf doublespend vulnerabilities)


Implementation
--------------

Pull-req for git HEAD: https://github.com/bitcoin/bitcoin/pull/6176

A backport to v0.10.2 is pending.

An implementation of fee bumping respecting FSS rules is available at:

https://github.com/petertodd/replace-by-fee-tools/blob/master/bump-fee.py


Usage Scenarios
---------------

Case 1: Increasing the fee on a single tx
-----------------------------------------

We start with a 1-in-2-out P2PKH using transaction t1, 226 bytes in size
with the minimal relay fee, 2.26uBTC. Increasing the fee while
respecting FSS-RBF rules requires the addition of one more txin, with
the change output value increased appropriately, resulting in
transaction t2, size 374 bytes. If the change txout is sufficient for
the fee increase, increasing the fee via CPFP requires a second
1-in-1-out transaction, 192 bytes, for a total of 418 bytes; if another
input is required, CPFP requires a 2-in-1-out tx, 340 bytes, for a total
of 566 bytes.

Benefits: 11% to 34%+ cost savings, and RBF can increase fees even in
          cases where the original transaction didn't have a change
          output.


Case 2: Paying multiple recipients in succession
------------------------------------------------

We have a 1-in-2-out P2PKH transaction t1, 226 bytes, that pays Alice.
We now need to pay Bob. With plain RBF we'd just add a new outptu and
reduce the value of the change address, a 90% savings. However with FSS
RBF, decreasing the value is not allowed, so we have to add an input.

If the change of t1 is sufficient to pay Bob, a second 1-in-2-out tx can
be created, 2*226=3D452 bytes in total. With FSS RBF we can replace t1
with a 2-in-3-out tx paying both, increasing the value of the change
output appropriately, resulting in 408 bytes transaction saving 10%

Similar to the above example in the case where the change address of t1
is insufficient to pay Bob the end result is one less transaction output
in the wallet, defragmenting it. Spending these outputs later on would
require two 148 byte inputs compared to one with RBF, resulting in an
overall savings of 25%


Case 3: Paying the same recipient multiple times
------------------------------------------------

For example, consider the situation of an exchange, Acme Bitcoin Sales,
that keeps the majority of coins in cold storage. Acme wants to move
funds to cold storage at the lowest possible cost, taking advantage of
periods of higher capacity. (inevitable due to the poisson nature of
block creation) At the same time they would like to defragment their
incoming outputs to keep redemption costs low, particularly since
spending their high-security 3-of-7 P2SH multisigs is expensive. Acme
creates a low fee transaction with a single output to cold storage,
periodically adding new inputs as funds need to be moved to storage.
Estimating the cost savings here is complex, and depends greatly on
details of Acme's business, but regardless the approach works from a
technical point of view. For instance if Acme's business is such that
the total hotwallet size needed heavily depends on external factors like
volatility, as hotwallet demand decreases throughout a day they can add
inputs to the pending transaction. (simply asking customers to deposit
funds directly to the cold storage is also a useful strategy)

However this is another case where standard RBF is significantly more
useful. For instance, as withdrawal requests come in the exchange can
quickly replace their pending transactions sending funds to cold storage
with transactions sending those funds to customers instead, each time
avoiding multiple costly transactions. In particular, by reducing the
need to access cold storage at all, the security of the cold-stored
funds is increased.


Wallet Compatibility
--------------------

All wallets should treat conflicting incoming transactions as equivalent
so long as the transaction outputs owned by them do not change. In
addition to compatibility with RBF-related practices, this prevents
unnecessary user concern if transactions are mutated. Wallets must not
assume TXIDs are fixed until confirmed in the blockchain; a fixed TXID
is not guaranteed by the Bitcoin protocol.

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

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

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

iQGrBAEBCACVBQJVZADdXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwM2NlOWYyZjkwNzM2YWI3YmQyNGQyOWY0MDM0NjA1N2Y5
ZTIxN2IzNzUzODk2YmIvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkft25Af9E+U1G0q9VgelfcK6E6IqtL53
cd53dKlpZqQJijfyuduh5HEnbCPNuv1nEYRR3oEVhikenMlJMHeQiAaNR1FDKRZz
TUNa619CbRrlQaxj92aJivCZQ79ToP739jXvk6Q1PLnVoaAj/RtpbLhiSPw7vd3m
fYpM/bpNTWhZMVjpf8iq2q06RYkfO9WyBF5tnbluIxEoqJpnycrEPE/eOF0f7siD
ulLAM7NfwZAS9ft9vNNCsNBnoYI9PlF6gEgFR/Y8N39+N+U4IKA8TQ92JvVKFiKP
PJfs2fOPPQdg+k+q5dIpzttG278bQzKJAaNc7zbvBQ2TmSycYH0oym7r36B7pg==
=Bixj
-----END PGP SIGNATURE-----

--qMm9M+Fa2AknHoGS--