Date: Thu, 1 Mar 2018 10:11:29 -0500
From: Peter Todd <pete@petertodd.org>
To: "Russell O'Connor" <roconnor@blockstream.io>
Message-ID: <20180301151129.GA9373@fedora-23-dvm>
References: <CAMZUoKnGx3p7=Kg96E3EEyJ8aFC7ezsvec_pAnN7oJz7-VbyLA@mail.gmail.com>
	<20180212225828.GB8551@fedora-23-dvm>
	<CAMZUoKnFBVFhaq61wKu_CcZgRKc5aoeTa-wq9h2CXH0WWHd3NQ@mail.gmail.com>
	<20180212234225.GA9131@fedora-23-dvm>
	<CAMZUoK=Htds5fu5vnqAhEoZDrwHALKe6uwqXnmJb17pa_peFFw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V"
Content-Disposition: inline
In-Reply-To: <CAMZUoK=Htds5fu5vnqAhEoZDrwHALKe6uwqXnmJb17pa_peFFw@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


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

On Tue, Feb 27, 2018 at 11:25:59AM -0500, Russell O'Connor wrote:
> On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd <pete@petertodd.org> wrote:
>=20
> >
> > Ah ok, I misunderstood and didn't realise you were talking about the ca=
se
> > where
> > Alice re-spends her unconfirmed payment. Unfortunately I don't think th=
at
> > case
> > is possible to solve without putting some kind of restriction on spendi=
ng
> > unconfirmed outputs; with a restriction it's fairly simple to solve.
>=20
>=20
> When you say that you don't think it is possible to solve, do you mean th=
at
> there is a specific problem with this proposal of replacing transactions
> when offered a new transaction whose fee rate exceeds the package fee rate
> of the original transaction (and ensuring that the fee increase covers the
> size of the transactions being ejected)?  Is your concern only about the
> ability to computing and track the package fee rate for transactions with=
in
> the mempool or is there some other issue you foresee?

I mean, I think in general solving this problem is probably not possible.
Basically, the fundamental problem is someone else has consumed network
bandwidth that should be paid for with fees. What you're trying to do is
replace a transaction without paying those fees, which is identical to what=
 an
attacker is trying to do, and thus any such scheme will be as vulnerable to
attack as not having that protection in the first place.

=2E..which does give you an out: maybe the attack isn't important enough to
matter. :)

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

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

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

iQEzBAEBCAAdFiEEFcyURjhyM68BBPYTJIFAPaXwkfsFAlqYGB0ACgkQJIFAPaXw
kfv9hgf8DU1i+wq9/fT0bklFwNkolvZRrvl7z4A+G4J3toVNeaUHg0OP92G06tpf
FrZqUPQModdVqdjCEUui66ZFgIMvXfsPd8UQ4txlcnUhrqOfYBLY+dJnpHpaxLnR
Qvl2WSRJxNaSPtjNPw07OHEu++G/Ng/spqgyeO772gUPyENx7FNooWcssMHq175p
97NmMDPc9dLFRlPfIOIDCvRm280HfNTfRTAjFnwqqGEUKaEWLy8nCADtqpWe4yFu
zP479GY2dpPJontmmRCLI0yvUOMfOjOhPDugsrVHQ8N7lA+KbcEc/ELQxwJ+dOkz
WNeO5tJIN+yo8kWzx5PpP/FOpMe23A==
=dLAk
-----END PGP SIGNATURE-----

--xHFwDpU9dbj6ez1V--