path: root/04/7c4c55f74f5a63225e523d390430f1c6a5d1e5

Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5D875FF1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 12 Feb 2018 22:58:37 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148109.authsmtp.co.uk (outmail148109.authsmtp.co.uk
	[62.13.148.109])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 14BD3D0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 12 Feb 2018 22:58:35 +0000 (UTC)
Received: from mail-c245.authsmtp.com (mail-c245.authsmtp.com [62.13.128.245])
	by punt21.authsmtp.com. (8.15.2/8.15.2) with ESMTP id w1CMwXg4039417;
	Mon, 12 Feb 2018 22:58:33 GMT (envelope-from pete@petertodd.org)
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
	[52.5.185.120]) (authenticated bits=0)
	by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPSA id w1CMwUbi099131
	(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); 
	Mon, 12 Feb 2018 22:58:31 GMT (envelope-from pete@petertodd.org)
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by petertodd.org (Postfix) with ESMTPSA id DA1F540110;
	Mon, 12 Feb 2018 22:58:29 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
	id 132BF20630; Mon, 12 Feb 2018 17:58:28 -0500 (EST)
Date: Mon, 12 Feb 2018 17:58:28 -0500
From: Peter Todd <pete@petertodd.org>
To: "Russell O'Connor" <roconnor@blockstream.io>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20180212225828.GB8551@fedora-23-dvm>
References: <CAMZUoKnGx3p7=Kg96E3EEyJ8aFC7ezsvec_pAnN7oJz7-VbyLA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="K8nIJk4ghYZn606h"
Content-Disposition: inline
In-Reply-To: <CAMZUoKnGx3p7=Kg96E3EEyJ8aFC7ezsvec_pAnN7oJz7-VbyLA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: 3f228c0b-1048-11e8-9f3b-9cb654bb2504
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aAdMdwAUHlAWAgsB Am4bWVZeVVV7WmI7 bghPaBtcak9QXgdq
	T0pMXVMcUwQbfFtk VEceWxBzdAQIeXZ0 YEIsXSZZXkwpdRRg
	Q05QHXAHZDJodWlJ UxJFflAGdgZOLE1H b1B7GhFYa3VsNCMk
	FAgyOXU9MCtqYB5Y XAAWLE4TR0lDNB8E D0lYQH0VN2NNXyI3 Lhc3bDYn
X-Authentic-SMTP: 61633532353630.1039:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
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: Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Feb 2018 22:58:37 -0000


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

On Mon, Feb 12, 2018 at 10:52:30AM -0500, Russell O'Connor via bitcoin-dev =
wrote:
> I think it is worth revisiting BIP 125's replace-by-fee policy for when to
> replace transactions.
>=20
> The current policy can be problematic. As noted earlier by Rhavar,
> sometimes one's transaction becomes pinned making it infeasible to fee bu=
mp
> with RBF.  This happens when one makes a normal payment to a large
> commercial service, and, while the transaction remains unconfirmed, the
> commercial service creates a low-fee-rate sweep of one's payment, among a
> collection of others.  If one wants to RBF this original payment, for
> example to get confirmation of the change output for use in further
> transactions, the current BIP 125 rules require that you make a fee bump
> that exceeds the combined total fees of the original transaction and the
> low-fee-rate sweep of the commercial service.
>=20
> The problem is that, while the fee rate of the sweep is low, the absolute
> size of the fee can still be large, making it infeasible to RBF the
> original transaction.  BIP 125 was defined back in 2015, when perhaps
> rational miners did care about absolute fee amounts. However, today we are
> in an era where rational miners care about fee-rates more than absolute
> fees.  The fee-rate of the large sweep transaction is low enough that we =
do
> not expect that miners will be mining it in the same block as the original
> transaction.  Today, a rational miner will prefer a fee-bumped version of
> original transaction without consideration of the low-fee sweep transacti=
on
> (or at least discounting the low-fee sweep in proportion to the miner's
> hash-rate fraction).

I don't actually see where the problem is here. First of all, suppose we ha=
ve a
transaction T_a that already pays Alice with a feerate sufficiently high th=
at
we expect it to get mined in the near future. If we want to pay Bob, we can=
 do
that by simply creating a double-spend of T_a that pays both Bob and Alice,
T_{ab}. BIP125 only requires that double-spend to have an absolute fee high=
er
than the minimum relay feerate * size of the transaction.

I just checked one of my nodes, and the absolute minimum relay fee is about
1/5th that of what estimatefee returns for the longest possible estimate, 48
blocks. Depends on the exact circumstances, but it'll likely be worth it to=
 pay
Bob with a replacement of T_a rather than create a second transaction due to
that difference.

Secondly, if for some reason you need to broadcast a separate transaction
paying Bob before you do the replacement, again I don't see an issue: just =
make
a minimum fee T_b that pays Bob, and replace both with T_{ab}. Again, the b=
ig
difference between minimum fee and what you might actually pay in fees means
that you'll still save money in most cases, so long as your wallet is
intelligent enough to pick a low feerate for T_b.

> Let me quote the five rules that define the current BIP 125 policy:
>=20
> One or more transactions currently in the mempool (original transactions)
> > will be replaced by a new transaction (replacement transaction) that sp=
ends
> > one or more of the same inputs if,
> >
> >    1. The original transactions signal replaceability explicitly or
> >    through inheritance as described in the above Summary section.
> >    2. The replacement transaction does not contain any new unconfirmed
> >    inputs that did not previously appear in the mempool. (Unconfirmed i=
nputs
> >    are inputs spending outputs from currently unconfirmed transactions.)
> >    3. The replacement transaction pays an absolute fee of at least the
> >    sum paid by the original transactions.
> >    4. The replacement transaction must also pay for its own bandwidth at
> >    or above the rate set by the node's minimum relay fee setting. For e=
xample,
> >    if the minimum relay fee is 1 satoshi/byte and the replacement trans=
action
> >    is 500 bytes total, then the replacement must pay a fee at least 500
> >    satoshis higher than the sum of the originals.
> >    5. The number of original transactions to be replaced and their
> >    descendant transactions which will be evicted from the mempool must =
not
> >    exceed a total of 100 transactions.
> >
> > To address the new reality of rational miners' consideration, I propose
> changing rules 3 and 4 to something like the following.
>=20
> 3'. The replacement transaction pays a fee rate of at least the effective
> fee rate of any chain of transactions from the set of original transactio=
ns
> that begins with the root of the original transaction set.

I think what you mean here should be the effective fee rate of the maximum
feerate package that can be built from the set of transactions that begins =
with
the candidate replacement. But actually calculating this is I believe
non-trivial, which is why I didn't implement it this way when RBF was first
implemented.

> 4'. The replacement transaction must also pay for replacing the original
> transactions at or above the rate set by the node's minimum relay fee
> setting. For example, if the minimum relay fee is 1 satoshi/byte and the
> replacement transaction and the original transactions are 1000 bytes tota=
l,
> then the replacement must pay a fee at least 1000 satoshis higher than the
> fee of the root transaction of the original transactions.

So the previous version of condition #4 does this implicitly because the
absolute fee isn't allowed to go down; you're effectively re-adding this
condition. But as I've shown above, you can get the same *behavior* by simp=
ly
ensuring that the transactions you broadcast that you'll want to double-spe=
nd
have a minimum feerate in the first place.

> Rule 3' is a fancy way of saying that the replacement transaction must ha=
ve
> a fee rate that is larger than the package fee rate of the root of the set
> of transactions it replaces, where the package fee rate is the fee rate
> implied by considering CPFP.
>=20
> Rule 4' is an amended anti-spam rule that is intended to avoid DOS attacks
> from churning the mempool. I don't know if it is really necessary to pay
> for the size of the original transactions being evicted, but some people I
> chatted with thought it could be important.

I think this is very important. For example, without this condition I could=
 do
a DoS attack by repeatedly broadcasting a transaction, then spending the
outputs of that transaction with a very large number of child transactions,=
 all
of minimum fee. With up to 100 transactions allowed for consideration, and a
100KB max transaction size, that could be up to ~10MB of transactions.

Next I double spend the root, increasing it's feerate but *not* paying for =
the
child transactions. Those ~10MB are now evicted from the mempool, and I can
repeat the cycle again. The cost is whatever the root tx replacement cost,
which will be much less than the cost of broadcasting 10MB should have been.

> Other people on the mailing list have been thinking about RBF policy for
> far longer than I have, so I wouldn't be surprised if my proposal above is
> naive.  However, I think it can start a conversation about addressing the
> problems with the current RBF policy.

A better way to solve this class of problems may be diffed tx replacement
propagation: basically broadcast a diff between the original tx and the
proposed replacement, allowing you to do the minimum bandwidth accounting b=
ased
on the size of the diff instead.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

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

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

iQEzBAEBCAAdFiEEFcyURjhyM68BBPYTJIFAPaXwkfsFAlqCHBAACgkQJIFAPaXw
kfs9QAgAr3A9QSkyLTVEctTkM6ig2lpbjwULXwOjAhk1ujwebKOpNgbCgP+xGCM5
oQ+HhSixpUb8ky6L4T/6bf6P51lim0pbrEUVdnHc4nsxYjh2rCb+hEsFLJOcYrIb
7Ru+GgyyBUC5/OIA+U2OesR8I5BWNluG2vG2d8aNJPzYeoFUCiYxw07Pj4sXuwJn
mzQzeKvTRSdVbvbnx8bXdCmyUUPk90NYOxLGd9GS1Zv125T1Wdx7MfYCSUcKeqGR
K64fpAoOe67V6MOKH2c1YWSQ7d5Q5yuldUC8zdlQOScwW83axIOJ+TOTKJOC1a8b
DebEyGFThzY2SpostB18MlUrFH1f0A==
=aknT
-----END PGP SIGNATURE-----

--K8nIJk4ghYZn606h--