summaryrefslogtreecommitdiff
path: root/8f/d6e39cc349d7f57f30558902787c25b5960580
blob: be13e6d8e834b9e7f769079819a901ecb8850b14 (plain)
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&#39;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&#39;t even propagate across networ=
k mempools with a local minimal feerate higher.<br><br></div><div>That&#39;=
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 &lt;<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&#39;m missing something, but I&#39;m curious if =
(how) this will work if the sponsored transaction&#39;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>&gt;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--