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
|
Return-Path: <dave@dtrt.org>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id A71E5C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 17:25:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 909AF86B05
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 17:25:34 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id BnIr6jjmrnze
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 17:25:33 +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 fraxinus.osuosl.org (Postfix) with ESMTPS id 76C5186B04
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 17:25:33 +0000 (UTC)
Received: from harding by newmail.dtrt.org with local (Exim 4.92)
(envelope-from <dave@dtrt.org>)
id 1kJgc7-0001QC-Bu; Sat, 19 Sep 2020 13:25:31 -0400
Date: Sat, 19 Sep 2020 13:24:17 -0400
From: "David A. Harding" <dave@dtrt.org>
To: Jeremy <jlrubin@mit.edu>
Message-ID: <20200919172417.ajlbqbmtuvk7t7be@ganymede>
References: <CAD5xwhi6+Q-UX2xVnD4TE9uEbe-omQ748tpJJpYdrMNnG6D5vA@mail.gmail.com>
<20200919133716.d5ofags2tprlvpqm@ganymede>
<CAD5xwhjZt25Bx+0MqfuY4OLJRWYmKZrfof86pPUAfJRDDsBQWA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="o5ginote6izy2brv"
Content-Disposition: inline
In-Reply-To: <CAD5xwhjZt25Bx+0MqfuY4OLJRWYmKZrfof86pPUAfJRDDsBQWA@mail.gmail.com>
User-Agent: NeoMutt/20180716
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 17:25:34 -0000
--o5ginote6izy2brv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Sep 19, 2020 at 09:30:56AM -0700, Jeremy wrote:
> Yup, I was aware of this limitation but I'm not sure how practical it is =
as
> an attack because it's quite expensive for the attacker.=20
It's cheap if:
1. You were planning to consolidate all those UTXOs at roughly that
feerate anyway.
2. After you no longer need your pinning transaction in the mempool, you
make an out-of-band arrangement with a pool to mine a small
conflicting transaction.
> But there are a few simple policies that can eliminate it:
>=20
> 1) A Sponsoring TX never needs to be more than, say, 2 inputs and 2
> outputs. Restricting this via policy would help, or more flexibly
> limiting the total size of a sponsoring transaction to 1000 bytes.
I think that works (as policy).
> 2) Make A Sponsoring TX not need to pay more absolute fee, just needs to
> increase the feerate (perhaps with a constant relay fee bump to prevent
> spam).
I think it'd be hard to find a constant relay fee bump amount that was
high enough to prevent abuse but low enough not to unduly hinder
legitimate users.
> I think 1) is simpler and should allow full use of the sponsor mechanism
> while preventing this class of issue mostly.
Agreed.
Thanks,
-Dave
--o5ginote6izy2brv
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl9mPsEACgkQ2dtBqWwi
adP6TxAAonJHGZyqXB0sOZXfcSN7dusHD4lFsh18yGNmgwWk57ZAvnzyh/+AUEGY
naXzxXxlgBrnr43bAROQZg4Lv6tahIxo2JidUOJF0Meok5e8TFAmzuiRXb3WXXOT
9IQsZokwehlO8LifM7Lo1zoTm9xxCPRnKC/IDlhguMUVev6VQu7+y+o/59jpFkZ1
IR9y/Dv3p29MkvRsPW0+xY9TfXHN7Fus9uWLITtUVloDIPVlAsL7jSW3uVyGfLhN
/Rortyfk+vhPTQohiAfkjCV4wg+wuClEUyFzSe5Ox3ePlQ43eQjb3POJRM8ZceoB
JaHkbfc9JEZhswSkBaogkAFXWQZt4tv6wBhZlJRicpR7c22OAlGvpNSx/92PB5TS
V3YVbIcmE1443juDJTJWYM5i+KBUDmElVG7lWAXYYSUxtg+gtGWiZ0i8BxEkF6Mh
jDrFgR8DjKZ/EyIKYp4nJc9vwSDNq7PWpMYCj9SAGjO/a4ljO4xg6ExKRl0Uu3s8
4/Z7pnATBm4yahI3nmYzD+v9i5jw+nNOfhhCaQzDZUPrhYCQFwn5W/f0NU6pSNDC
uIT89cdYPbF+sT9Qw+fv1pC0JO0kx4CfaGJQY6PAEZEa0482/NsxG+TzsMhIpaSd
alKZ0hH94qu9Z0+BGYFp8fB3D8hbUm3S4Ls2TdbueAZXgE167QQ=
=ySgd
-----END PGP SIGNATURE-----
--o5ginote6izy2brv--
|
