Date: Mon, 12 Feb 2018 18:42:25 -0500
From: Peter Todd <pete@petertodd.org>
To: "Russell O'Connor" <roconnor@blockstream.io>
Message-ID: <20180212234225.GA9131@fedora-23-dvm>
References: <CAMZUoKnGx3p7=Kg96E3EEyJ8aFC7ezsvec_pAnN7oJz7-VbyLA@mail.gmail.com>
	<20180212225828.GB8551@fedora-23-dvm>
	<CAMZUoKnFBVFhaq61wKu_CcZgRKc5aoeTa-wq9h2CXH0WWHd3NQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv"
Content-Disposition: inline
In-Reply-To: <CAMZUoKnFBVFhaq61wKu_CcZgRKc5aoeTa-wq9h2CXH0WWHd3NQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.
Precedence: list


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

On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote:
> On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd <pete@petertodd.org> wrote:
>=20
> >
> > I don't actually see where the problem is here. First of all, suppose we
> > have a
> > transaction T_a that already pays Alice with a feerate sufficiently high
> > that
> > 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 Al=
ice,
> > T_{ab}. BIP125 only requires that double-spend to have an absolute fee
> > higher
> > than the minimum relay feerate * size of the transaction.
> >
>=20
> The problem is that rule 3 of BIP 125 requires you pay a fee that is high=
er
> than the the fee of T_a *plus* the fee of the sweep-transaction that the
> Alice has added as a unconfirmed child transaction to T_a because
> double-spending to pay Alice and Bob invalidates Alice's
> sweep-transaction.  Alice's sweep-transaction is very large, and hence pa=
ys
> a large absolute fee even though her fee-rate is very low.  We do not have
> any control over its value, hence Alice has "pinned" our RBF transaction.

Ah ok, I misunderstood and didn't realise you were talking about the case w=
here
Alice re-spends her unconfirmed payment. Unfortunately I don't think that c=
ase
is possible to solve without putting some kind of restriction on spending
unconfirmed outputs; with a restriction it's fairly simple to solve.

> > I think what you mean here should be the effective fee rate of the maxi=
mum
> > feerate package that can be built from the set of transactions that beg=
ins
> > 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 f=
irst
> > implemented.
> >
>=20
> Yes, that is what I mean.  My proposal was off-the-mark.
>=20
> Surely CPFP is already computing the package-fee rates of mempool
> transactions.  That is the value we need to compute.

True, maybe we can just reuse the CPFP calculation now. That said, AFAIK th=
at's
only done in the miner code, not the mempool, so that may not be trivial to
actually do.

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

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

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

iQEzBAEBCAAdFiEEFcyURjhyM68BBPYTJIFAPaXwkfsFAlqCJl0ACgkQJIFAPaXw
kfsZjggAjXkZVdlnC9GSKOyTixz0f4qROGpCZ7IMF3O+Nb0x+LSlj0vZAnu+k5oZ
7cTkzed3MXVdmfKPw463PMPh2uhp8D1oLatgLk+PkRtsTkoNphDARoJAFpJXHKSV
gRYRKLjhLZXZt4Hu+ZLJI8Gifm9tjevaNw3yUKFGaZC1BWF8gFxYaSYtWT/IalsU
rlElk+VASwwKg0bXTxVp9K4dbY+3l/skfzcTpQ4u+bniPwQmkSzr2KHlMTkWj6jk
1v5myMdcQ2/dP485551kjGwoURqiXDUo1DEH59Bf+pRU553QTYrysjInxQqYG0TT
D4/ZdrjPoG9JWRXoiSBaXoVy3wtU6Q==
=/I+S
-----END PGP SIGNATURE-----

--ZGiS0Q5IWpPtfppv--