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
|
Return-Path: <jlrubin@mit.edu>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 21501C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 19:46:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id 1012A86FD9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 19:46:41 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id mqsSm8vnBVq9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 19:46:40 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
by hemlock.osuosl.org (Postfix) with ESMTPS id F0E0B86FD7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 19:46:39 +0000 (UTC)
Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com
[209.85.208.47]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 08JJkbtf018216
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 19 Sep 2020 15:46:38 -0400
Received: by mail-ed1-f47.google.com with SMTP id t16so9210030edw.7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 12:46:38 -0700 (PDT)
X-Gm-Message-State: AOAM533nJhRNQ+eoM0yRySo36hcA+5NJrDa0Y7v9vyIDMZqfA6m67yJ9
y+7SR8VCCN7AVMahI7affDLrC46hevt5zN0an4Q=
X-Google-Smtp-Source: ABdhPJzzuOut7RUGYTfSqndolEuo1BW26BARfmF1hel7KHI+6pSEDpwxCAV1HdbQ51ZXdvFMA4n+HVfZK8saCZ+4ocg=
X-Received: by 2002:a05:6402:1558:: with SMTP id
p24mr43792799edx.194.1600544797223;
Sat, 19 Sep 2020 12:46:37 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhi6+Q-UX2xVnD4TE9uEbe-omQ748tpJJpYdrMNnG6D5vA@mail.gmail.com>
<CALZpt+FbRGrcW7LZY=4NtR9w4CP=kavVdqutfrX86OYnouHUJg@mail.gmail.com>
<CALZpt+EAWbPWh_knT7yDdPT396jEL1g+XSEv1JALuwaJVqNS7w@mail.gmail.com>
In-Reply-To: <CALZpt+EAWbPWh_knT7yDdPT396jEL1g+XSEv1JALuwaJVqNS7w@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Sat, 19 Sep 2020 12:46:25 -0700
X-Gmail-Original-Message-ID: <CAD5xwhgw4Hsco73B1D5+EafXFbcr3227MM2ZNPtycyv2TS-n7g@mail.gmail.com>
Message-ID: <CAD5xwhgw4Hsco73B1D5+EafXFbcr3227MM2ZNPtycyv2TS-n7g@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000015f02105afafe07a"
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 19:46:41 -0000
--00000000000015f02105afafe07a
Content-Type: text/plain; charset="UTF-8"
Antoine,
Yes I think you're a bit confused on where the actual sponsor vector is. If
you have a transaction chain A->B->C and a sponsor S_A, S_A commits to txid
A and A is unaware of S.
W.r.t your other points, I fully agree that the 1-to-N sponsored case is
very compelling. The consensus rules are clear that sponsor commitments are
non-rival, so there's no issue with allowing as many sponsors as possible
and including them in aggregate. E.g., if S_A and S'_A both sponsor A with
feerate(S*) > feerate(A), there's no reason not to include all of them in a
block. The only issue is denial of service in the mempool. In the future,
it would definitely be desirable to figure out rules that allow mempools to
track both multiple sponsors and multiple sponsor targets. But in the
interest of KISS, the current policy rules are designed to be minimally
invasive and maximally functional.
In terms of location for the sponsor vector, I'm relatively indifferent.
The annex is a possible location, but it's a bit odd as we really only need
to allow one such vector per tx, not one per input, and one per input would
enable some new use cases (maybe good, maybe bad). Further, being in the
witness space would mean that if two parties create a 2 input transaction
with a desired sponsor vector they would both need to specify it as you
can't sign another input's witness data. I wholeheartedly agree with the
sentiment though; there could be a more efficient place to put this data,
but nothing jumps out to me as both efficient and simple in implementation
(a new tx-level field sounds like a lot of complexity).
> n >=1 ? I think you can have at least one vector and this is matching the
code
yes, this has been fixed in the gist (cred to Dmitry Petukhov for pointing
it out first), but is correct in the code. Thank you for your careful
reading.
--00000000000015f02105afafe07a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)" class=3D"gmail_default">Antoine,</div><div sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Y=
es I think you're a bit confused on where the actual sponsor vector is.=
If you have a transaction chain A->B->C and a sponsor S_A, S_A commi=
ts to txid A and A is unaware of S.</div><div style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default=
"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:=
small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=
=3D"gmail_default">W.r.t your other points, I fully agree that the 1-to-N s=
ponsored case is very compelling. The consensus rules are clear that sponso=
r commitments are non-rival, so there's no issue with allowing as many =
sponsors as possible and including them in aggregate. E.g., if S_A and S=
9;_A both sponsor A with feerate(S*) > feerate(A), there's no reason=
not to include all of them in a block. The only issue is denial of service=
in the mempool. In the future, it would definitely be desirable to figure =
out rules that allow mempools to track both multiple sponsors and multiple =
sponsor targets. But in the interest of KISS, the current policy rules are =
designed to be minimally invasive and maximally functional.</div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">In =
terms of location for the sponsor vector, I'm relatively indifferent. T=
he annex is a possible location, but it's a bit odd as we really only n=
eed to allow one such vector per tx, not one per input, and one per input w=
ould enable some new use cases (maybe good, maybe bad). Further, being in t=
he witness space would mean that if two parties create a 2 input transactio=
n with a desired sponsor vector they would both need to specify it as you c=
an't sign another input's witness data. I wholeheartedly agree with=
the sentiment though; there could be a more efficient place to put this da=
ta, but nothing jumps out to me as both efficient and simple in implementat=
ion (a new tx-level field sounds like a lot of complexity).<br></div><span =
class=3D"gmail-im"></span><br><span class=3D"gmail-im"></span><div style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" c=
lass=3D"gmail_default"><span class=3D"gmail-im"><br></span>> n >=3D1 =
? I think you can have at least one vector and this is matching the code</d=
iv><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail=
_default">yes, this has been fixed in the=C2=A0gist (cred to Dmitry Petukho=
v for pointing it out first), but is correct in the code. Thank you for you=
r careful reading.<br></div><br></div>
--00000000000015f02105afafe07a--
|
