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
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
|
Return-Path: <adam.ficsor73@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 1F1F6C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 15:01:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 12685867E3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 15:01:22 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Uai5j241plac
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 15:01:21 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com
[209.85.167.53])
by whitealder.osuosl.org (Postfix) with ESMTPS id D574882504
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 15:01:20 +0000 (UTC)
Received: by mail-lf1-f53.google.com with SMTP id w11so9335118lfn.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 08:01:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=5feZFeh/b4gIhU4rFLnbMYyow00L48FaJJL2Mg6982E=;
b=UYLLASOOkZx+/FL0xu5YE6HKs9Xa1ujAMlhPYRdSbboumEuCxlLGrLEpgpNkdREdlF
GW2pHG03Sd6+NVtAHH8Y9twWNWUsVb377llUWf6pDqqAYtEiG0Ndpm2GgJLA8h9H06Oa
sGcZnApVm24tDq/Qj5Mu/og0okBUbKRgqisij1jrhmxlHzz7B/BfX7KckhDznq8VRDTJ
X2Yfu1m9HDOKYJq3TtyGpDP6KojIVUhyspg4UfHmd0dvssWYvNHEtIetbVrFzOmvIyEi
OlJiRiVQRH3AsZ53otgy8wR9L2tPy4gda0o1W91eSWtECxECs+d4FtLhs4nnIqmDP0u4
/oAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=5feZFeh/b4gIhU4rFLnbMYyow00L48FaJJL2Mg6982E=;
b=pzvD2xQH+CYoUVCmbceInjutKYbG/80BosPxs+W4NTCR4hGcv6HbTvC+UXJ5QtIzU9
yw7fONDw9fTT0P7F3kQYVnsyun5Cpf+dyT6bT7VyBrsXSWyJ4xFZ9m6KQvQsd5xfq4Dt
hYaiaN4m4CG7fl9r+aPkE6v/JjZ6ny4erqnRqLNfNm3ZYq8oOHm/e+3t/Xfu6lY6tB6Z
KptswCewnff2Ek/edNVNCTIWPeIyUGIFOZYPgLfA47h8ziGuMOuTP2NG00jJpLjHRBvV
jkbDz00lQUj8xrlT2Chfrv2h3vLc7cK7ClDW6rDDtHdpX91/mUbq3X19ptUrhD88I7rR
nKJA==
X-Gm-Message-State: AOAM532BbA8xfugSBS+UsfS0Ub7fnPgm83Dt1/1W/26D1nXjC3xrk63N
ifKSA1VNJL4z5cidotsxLNO7U3H93cMwwbZQoSY=
X-Google-Smtp-Source: ABdhPJzpYoGs+TARqZvNhMUcW42pq/gCaqxeJzlH2KCmH05FRbQjwJK0bmJxDWm0BxwmV898rUP17ZSsGHBjyLfxcGg=
X-Received: by 2002:ac2:4c19:: with SMTP id t25mr11762656lfq.375.1600527678851;
Sat, 19 Sep 2020 08:01:18 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhi6+Q-UX2xVnD4TE9uEbe-omQ748tpJJpYdrMNnG6D5vA@mail.gmail.com>
<20200919133716.d5ofags2tprlvpqm@ganymede>
In-Reply-To: <20200919133716.d5ofags2tprlvpqm@ganymede>
From: nopara73 <adam.ficsor73@gmail.com>
Date: Sat, 19 Sep 2020 17:01:07 +0200
Message-ID: <CAEPKjge4pMYg7MBnApV0Rtn88LSM8i6kYHAKeaR8o-dSxfREAQ@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c04f7605afabe364"
X-Mailman-Approved-At: Sat, 19 Sep 2020 15:04:23 +0000
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 15:01:22 -0000
--000000000000c04f7605afabe364
Content-Type: text/plain; charset="UTF-8"
Wouldn't this enable a passive adversary listening the mempool to associate
unrelated TXO clusters to the same user?
On Sat, Sep 19, 2020, 15:38 David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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:
> >
> > 1. The Sponsor's feerate must be greater than the Sponsored's ancestor
> fee rate
> >
> > 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000c04f7605afabe364
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Wouldn't this enable a passive adversary listening th=
e mempool to associate unrelated TXO clusters to the same user?</div><br><d=
iv class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Sep =
19, 2020, 15:38 David A. Harding via bitcoin-dev <<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a=
>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Sep 18, 2020 a=
t 05:51:39PM -0700, Jeremy via bitcoin-dev wrote:<br>
> I'd like to share with you a draft proposal for a mechanism to rep=
lace<br>
> CPFP and RBF for increasing fees on transactions in the mempool that<b=
r>
> should be more robust against attacks.<br>
<br>
Interesting idea!=C2=A0 This is going to take a while to think about, but I=
<br>
have one immediate question:<br>
<br>
> To prevent garbage sponsors, we also require that:<br>
> <br>
> 1. The Sponsor's feerate must be greater than the Sponsored's =
ancestor fee rate<br>
> <br>
> We allow one Sponsor to replace another subject to normal replacement<=
br>
> policies, they are treated as conflicts.<br>
<br>
Is this in the reference implementation?=C2=A0 I don't see it and I'=
;m<br>
confused by this text.=C2=A0 I think it could mean either:<br>
<br>
1. Sponsor Tx A can be replaced by Sponsor Tx B if A and B have at least<br=
>
=C2=A0 =C2=A0one input in common (which is part of the "normal replace=
ment policies")<br>
<br>
2. A can be replaced by B even if they don't have any inputs in common<=
br>
=C2=A0 =C2=A0as long as they do have a Sponsor Vector in common (while othe=
rwise<br>
=C2=A0 =C2=A0using the "normal replacement policies").<br>
<br>
In the first case, I think Mallory can prevent Bob from<br>
sponsor-fee-bumping (sponsor-bumping?) his transaction by submitting a<br>
sponsor before he does; since Bob has no control over Mallory's inputs,=
<br>
he can't replace Mallory's sponsor tx.<br>
<br>
In the second case, I think Mallory can use an existing pinning<br>
technique to make it expensive for Bob to fee bump.=C2=A0 The normal<br>
replacement policies require a replacement to pay an absolute higher fee<br=
>
than the original transaction, so Mallory can create a 100,000 vbyte<br>
transaction with a single-vector sponsor at the end pointing to Bob's<b=
r>
transaction.=C2=A0 This sponsor transaction pays the same feerate as Bob=
9;s<br>
transaction---let's say 50 nBTC/vbyte, so 5 mBTC total fee.=C2=A0 In or=
der<br>
for Bob to replace Mallory's sponsor transaction with his own sponsor<b=
r>
transaction, Bob needs to pay the incremental relay feerate (10<br>
nBTC/vbyte) more, so 6 mBTC total ($66 at $11k/BTC).<br>
<br>
Thanks,<br>
<br>
-Dave<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--000000000000c04f7605afabe364--
|
