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
|
Return-Path: <antoine.riard@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 65F88C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Sep 2020 13:53:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 5FCA72000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Sep 2020 13:53:13 +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 CvG+VJkxPFTB
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Sep 2020 13:53:10 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com
[209.85.221.45])
by silver.osuosl.org (Postfix) with ESMTPS id 9B22A1FD7D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Sep 2020 13:53:09 +0000 (UTC)
Received: by mail-wr1-f45.google.com with SMTP id z4so17172272wrr.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Sep 2020 06:53:09 -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=CoSujKLP3faW1AVJkadnIquk03W7kXhS45+7C0Nnhu0=;
b=AV9OSjD0eMQ4aCjXD4+HOxruDV/9dXkW8Qva6EkKiEA6Axh5tFCpBN90kSia3DNItW
FZ5AA23xKp2oxWzjk+4vlB3Ynq7gpN39ToY4LAG/Y+ACEhBs/7f5Dp27VUtjL2IarF7M
t8g47gRNYzXHo8Kg+JZM+EJ7wzCfzhuYW0SJB6HOjCHY0mj32UM1ja+sbMC6G4gRLhg/
xcRbiGh0EsjJWaK7cBWuAiGlkiLAvSi5LTBu2Nh92sKNvVtVegzaVd7ipdImOZYAx8gB
tm/fbLUVE345pKSBY0Onij9uN8x8p7UUACyzJXtPDVlu/C6cuu1HHf0ErgXnv79/rGKV
hR7Q==
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=CoSujKLP3faW1AVJkadnIquk03W7kXhS45+7C0Nnhu0=;
b=jZ1aorwuSVhPpyhqlthW77MRwYHk7nHGtzcP6xc5eU2OGnHfcEj0E+bqR0O/m9UnMS
Kbz2+x/bT0vyoWpHxehyH7qi32Lp10XhfdSN7zbrptvFFnpzYLnWHP5dzUQQ3Ew3+5Gh
gdpsY89QhSswnqwCUGZlR+I4NGATNM+YhMUJxeYTm5MSpnuIz+/88/U+p59vNV83K12U
NO9SBgr5AyaybckfMqeQVbJ5yJmyQYeOcrfFBJ/KSGqK12O5mT732WaEi3akUgnwjsoo
wZnACN6+YP7u2hex62zrvLNRB0QhNUcSBDoWVhmVwxlSWbBNPaBasyDwidPPC0bk5aaY
vs5Q==
X-Gm-Message-State: AOAM533wcb8XYbmpuUeV3hhr+DmikgtOTijwKWIzb6JZMA2rtRseRrXK
QRx31nGcOYGgdeNvixCtjeEhsekETzr5QL5HZz0=
X-Google-Smtp-Source: ABdhPJxKvmSE4VX2gsT+Mp7kMmNCmdghCL8eyVhzXpCaU8Z03k+lpV4Q/1+2KOEHp+Jq6OJaO7AYRtoDo4MdcCh71m4=
X-Received: by 2002:adf:ffc3:: with SMTP id x3mr4853567wrs.290.1600782787987;
Tue, 22 Sep 2020 06:53:07 -0700 (PDT)
MIME-Version: 1.0
References: <Jilb-w5AFlMx809pICIKdhhj3xBynWDlPtRTiJVIoxnC5_1gi6sK7rhOjl4e5HeMr7DDk9NjLdSGc8nWXaDIePDsjroiTd5xLU0xL3_INiY=@protonmail.com>
In-Reply-To: <Jilb-w5AFlMx809pICIKdhhj3xBynWDlPtRTiJVIoxnC5_1gi6sK7rhOjl4e5HeMr7DDk9NjLdSGc8nWXaDIePDsjroiTd5xLU0xL3_INiY=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 22 Sep 2020 09:52:55 -0400
Message-ID: <CALZpt+E19yodt3_LG+5x7G-bZ=6egrcGsTMR1+75aePNa1YPfw@mail.gmail.com>
To: ArmchairCryptologist <ArmchairCryptologist@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000070cb6405afe7498f"
X-Mailman-Approved-At: Tue, 22 Sep 2020 14:27:34 +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: Tue, 22 Sep 2020 13:53:13 -0000
--00000000000070cb6405afe7498f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hello AC,
Yes that's a real issue. In the context of multi-party protocols, you may
pre-signed transactions with the feerate of _today_ and then only going to
be broadcast later with a feerate of _tomorrow_.
In that case the pre-signed feerate may be so low that the transaction
won't even propagate across network mempools with a local minimal feerate
higher.
That's why you want to be sure that the feerate of your package of
transactions (either sponsor+sponsoree or parent+CPFP) is going to be
evaluated as a whole to decide acceptance of each element of the package.
Antoine
Le mar. 22 sept. 2020 =C3=A0 03:28, ArmchairCryptologist via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :
> Not sure if I'm missing something, but I'm curious if (how) this will wor=
k
> if the sponsored transaction's feerate is so low that it has been largely
> evicted from mempools due to fee pressure, and is too low to be widely
> accepted when re-broadcast? It seems to me that the following requirement
>
> >1. The Sponsor Vector's entry must be present in the mempool
>
> means that you enter a catch-22 where the sponsor transaction cannot be
> broadcast because the sponsored transaction is not in the mempool, and th=
e
> sponsored transaction cannot be (re-)broadcast because the fee is too low=
.
> This requirement might therefore need to be revised.
>
> There is of course no global mempool, but RBF by its nature would still
> work in this case, by replacing the transaction if it exists and insertin=
g
> it if it does not.
>
> --AC
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--00000000000070cb6405afe7498f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div>Hello AC,<br><br></div>Yes that's a rea=
l issue. In the context of multi-party protocols, you may pre-signed transa=
ctions with the feerate of _today_ and then only going to be broadcast late=
r with a feerate of _tomorrow_.<br></div>In that case the pre-signed feerat=
e may be so low that the transaction won't even propagate across networ=
k mempools with a local minimal feerate higher.<br><br></div><div>That'=
s why you want to be sure that the feerate of your=C2=A0 package of transac=
tions (either sponsor+sponsoree or parent+CPFP) is going to be evaluated as=
a whole to decide acceptance of each element of the package.<br><br></div>=
<div>Antoine<br></div><div>=C2=A0</div></div><br><div class=3D"gmail_quote"=
><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mar. 22 sept. 2020 =C3=A0=C2=
=A003:28, ArmchairCryptologist via bitcoin-dev <<a href=3D"mailto:bitcoi=
n-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&=
gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div>Not sure if I'm missing something, but I'm curious if =
(how) this will work if the sponsored transaction's feerate is so low t=
hat it has been largely evicted from mempools due to fee pressure, and is t=
oo low to be widely accepted when re-broadcast? It seems to me that the fol=
lowing requirement<br></div><div><br></div><div>>1. The Sponsor Vector&#=
39;s entry must be present in the mempool<br></div><div><br></div><div>mean=
s that you enter a catch-22 where the sponsor transaction cannot be broadca=
st because the sponsored transaction is not in the mempool, and the sponsor=
ed transaction cannot be (re-)broadcast because the fee is too low. This re=
quirement might therefore need to be revised.<br></div><div><br></div><div>=
There is of course no global mempool, but RBF by its nature would still wor=
k in this case, by replacing the transaction if it exists and inserting it =
if it does not.<br></div><div><br></div><div>--AC</div>____________________=
___________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--00000000000070cb6405afe7498f--
|
