1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
|
Return-Path: <dave@dtrt.org>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id F3AF1C0859
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 13:38:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id E25352033D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 13:38:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id RQawFMJKSI5t
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 13:38:32 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from newmail.dtrt.org (li1228-87.members.linode.com [45.79.129.87])
by silver.osuosl.org (Postfix) with ESMTPS id C93611FEED
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 13:38:32 +0000 (UTC)
Received: from harding by newmail.dtrt.org with local (Exim 4.92)
(envelope-from <dave@dtrt.org>)
id 1kJd4R-0001ur-Cp; Sat, 19 Sep 2020 09:38:31 -0400
Date: Sat, 19 Sep 2020 09:37:16 -0400
From: "David A. Harding" <dave@dtrt.org>
To: Jeremy <jlrubin@mit.edu>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200919133716.d5ofags2tprlvpqm@ganymede>
References: <CAD5xwhi6+Q-UX2xVnD4TE9uEbe-omQ748tpJJpYdrMNnG6D5vA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="2q76l6a6fd2jepv6"
Content-Disposition: inline
In-Reply-To: <CAD5xwhi6+Q-UX2xVnD4TE9uEbe-omQ748tpJJpYdrMNnG6D5vA@mail.gmail.com>
User-Agent: NeoMutt/20180716
Subject: Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive
TXID Dependencies for Fee Sponsoring
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Sat, 19 Sep 2020 13:38:34 -0000
--2q76l6a6fd2jepv6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Sep 18, 2020 at 05:51:39PM -0700, Jeremy via bitcoin-dev wrote:
> I'd like to share with you a draft proposal for a mechanism to replace
> CPFP and RBF for increasing fees on transactions in the mempool that
> should be more robust against attacks.
Interesting idea! This is going to take a while to think about, but I
have one immediate question:
> To prevent garbage sponsors, we also require that:
>=20
> 1. The Sponsor's feerate must be greater than the Sponsored's ancestor fe=
e rate
>=20
> We allow one Sponsor to replace another subject to normal replacement
> policies, they are treated as conflicts.
Is this in the reference implementation? I don't see it and I'm
confused by this text. I think it could mean either:
1. Sponsor Tx A can be replaced by Sponsor Tx B if A and B have at least
one input in common (which is part of the "normal replacement policies")
2. A can be replaced by B even if they don't have any inputs in common
as long as they do have a Sponsor Vector in common (while otherwise
using the "normal replacement policies").
In the first case, I think Mallory can prevent Bob from
sponsor-fee-bumping (sponsor-bumping?) his transaction by submitting a
sponsor before he does; since Bob has no control over Mallory's inputs,
he can't replace Mallory's sponsor tx.
In the second case, I think Mallory can use an existing pinning
technique to make it expensive for Bob to fee bump. The normal
replacement policies require a replacement to pay an absolute higher fee
than the original transaction, so Mallory can create a 100,000 vbyte
transaction with a single-vector sponsor at the end pointing to Bob's
transaction. This sponsor transaction pays the same feerate as Bob's
transaction---let's say 50 nBTC/vbyte, so 5 mBTC total fee. In order
for Bob to replace Mallory's sponsor transaction with his own sponsor
transaction, Bob needs to pay the incremental relay feerate (10
nBTC/vbyte) more, so 6 mBTC total ($66 at $11k/BTC).
Thanks,
-Dave
--2q76l6a6fd2jepv6
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl9mCYwACgkQ2dtBqWwi
adOspg/+JFtCGY4wV9MP4WOoM85Oyzff1VViM6sC+boiTfQJ+vMvxYqiNvJe07lZ
G5YGVjs3VwAX8ss7L0PT7uQ9dtYP5PHwJCgY3LUIDEcmbauV9oEiv/1DoNZeq8Kn
79mZ7uHexdpRRXSf1El9muQPVB6wtUrj02IiHR+mEh+/sGcgIpDrP8n3x6XVNkDF
sIiBxRvjci0pZREIZ+kXkfpShyl7Tx2pNHUf1eDMPQiJHxgQ6k2RgOcy3Cqjcbh4
P4MYAz2zvUPQU4ZF5/F4MaXundySbQL38FAiQ83hYMXnrTeGMncS2+YofbZLrqp/
a7UG7/79ITcivYBVLd3chg6dS20ba5o6sHqp1IdApz9i1sEYKYBvWIz/8MvqwN81
VXgxnBQIlxUVsb95RW8ei14zG5gpFRqr7RXI8P7XGLvMDQZfi2dGMwcifbdfMcWy
mZ7FKRzhsWQeXvmPO9MVW6ZET/bDHo3tOnPrlHBFhi5d5ihWPdyfyvf+om2gDITj
Tz/AkGD0M6Z50DOmHG8kgHGIZYbqzsy0hr/hLdKnUmnjBdMY4faMDz49k6FdRq0F
/sKEZfixt2CZzDNkQqLEU0k05y9Ri4sqF8Bu6ajI9Y5NsExmBpAp5ryK7dKfhM/w
Y+I0P05PE5dJm2gwO9jJSWZE783ftRy5m5oIbmEnmTw/PpMWVDo=
=D9WZ
-----END PGP SIGNATURE-----
--2q76l6a6fd2jepv6--
|
