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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id D930FC000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Oct 2021 16:38:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id BAF07608CE
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Oct 2021 16:38:39 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level:
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H2=-0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=protonmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id b4H8qc5xLOgo
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Oct 2021 16:38:39 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4325.protonmail.ch (mail-4325.protonmail.ch [185.70.43.25])
by smtp3.osuosl.org (Postfix) with ESMTPS id E284A60774
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Oct 2021 16:38:38 +0000 (UTC)
Date: Tue, 26 Oct 2021 16:38:27 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1635266316;
bh=B1+ao6L5t2tGYGGNmmwW8HMZHglIHrAKDK9oX1yUQmk=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=kpNPdRUDoENTqPcOJ4dUpzLVN4tBxwfrDoTZ53mv8ZjdYZOugu+zyS7nx42mB7AOC
e/04CYdkAkH9h0DjFaPD1/F4XccU2myVu2jdyu6TcOF774ZR4r6xgqH+x+O71pQ8BG
e+ZD1LRgCwU0+Cx131OxJSct63uC9g1iOKNv9cPU=
To: darosior <darosior@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <9_2myR-nlP12e_UV4y5HTY8vLzvFirBNZSnNh4kiYP9BTvvHaByALKV1D5kl2BqTyexYYtmVbBZ1xLPYgtbTp-nNsfXEzc1ZlNN8wMGeiVg=@protonmail.com>
In-Reply-To: <Opd1OVGiyYCh2nGyCF1WbAozszMGHZSXiiC4cxN80cuIGS8TLzfzDjzcGulIOZDrq1bffF_UV6DO4QPFq1jmMY9UI0g5baUZMjWoeFqQvtM=@protonmail.com>
References: <CAM1a7P04apCwwmqNp4VLRam5_uk59tVRWv74UVD_g0-DUGNghw@mail.gmail.com>
<Opd1OVGiyYCh2nGyCF1WbAozszMGHZSXiiC4cxN80cuIGS8TLzfzDjzcGulIOZDrq1bffF_UV6DO4QPFq1jmMY9UI0g5baUZMjWoeFqQvtM=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: lisa neigut <niftynei@gmail.com>
Subject: Re: [bitcoin-dev] death to the mempool, long live the mempool
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, 26 Oct 2021 16:38:39 -0000
Good morning Antoine,
> However, as we discussed recently, i do believe their is a failure mode h=
ere. On one hand, directly connecting to pools is already possible today an=
d pretty effective given the current mining centralization. On the other ha=
nd, it's not possible for most pre-signed txs protocols to reliably (secure=
ly) use the Bitcoin tx relay network today to propagate time-sensitive tran=
sactions. Furthermore, even if these are fixed (eg via package-relay for (t=
oday's) Lightning Network) it seems like there is a stark contrast between =
what "L2 [0] protocols" need and what regular node operators can reasonably=
offer. A node operator is incentivized to relay transactions to:
> - have more privacy *if* they use their node to broadcast transactions (m=
ake it less distinguishable which relayed transaction comes from the wallet=
)
> - provide fee estimates *if* they need them
> - avoid bandwidth spikes on block connection (compact block relay)
To be clear: it is possible to design L2 protocols such that various counte=
rparties (whose incentives may not align perfectly) can bid to put their vi=
ews of the L2 state on the blockchain.
For instance, in Lightning, you may wish to close a channel at a high feera=
te in order to use your onchain funds quickly, yet your channel counterpart=
y has no similar time pressure to get their onchain funds in a usable state=
.
Solutions such as anchor outputs have been devised to allow each counterpar=
ty to pay fees as they see fit, however, for instance for anchor outputs th=
e commitment transaction has to be at the minimum relay feerate.
At times of high blockchain congestion, node operators may raise the minimu=
m feerate they are willing to relay (in order to alleviate bandwidth use), =
which may prevent commitment transactions from being relayed; even if a CPF=
P were relayed later, since the parent transaction is not propagated in the=
first place, the CPFP transaction spending the anchor outputs cannot propa=
gate too.
I believe that is what you are referring to here as an example of how an L2=
protocol cannot rely on the current L1 network for timely confirmation?
> L2s would ideally need the tx relaying nodes to do more computation and l=
ift their DOS mitigations for all miner-incentive-compatible transactions t=
o eventually be relayed to most of the miners. One obvious instance of such=
a dilemma is the RBF rules.
> Such protocols getting increasingly developed and used create a strong in=
centive for their users/stakeholders to directly connect to mining pools [1=
], with all the consequences for the network mentioned in the replies to yo=
ur mail and elsewhere.
> Before we get to this, i think there is a strong case for an opt-in and p=
ublicly accessible "overlay" network to relay miner-incentive compatible tr=
ansactions with higher DOS limits. This way the cost is not imposed to L1 n=
ode runners, and L2s can operate with more safety assumptions without (enti=
rely) falling for centralization.
Let us imagine how such a network would operate.
It seems to me that an issue here is that *relay is free*.
And: "you get what you pay for".
Since mere relay is free (i.e. nodes do not charge any fee to merely *relay=
* transactions) the quality of that relay is low.
Thus, L1 node operators may insist on policies that do not support well min=
er-incentive transaction packages.
So the question is: who should pay for relay?
Ultimately of course the transactor pays, but it seems to me that the direc=
t payer should be miners; transactors would offer higher fees, and miners w=
ould then pay part of those fees to relayers to get those transactions.
So, perhaps, let us consider a sketch (which is probably impossible, but ma=
y trigger other ideas):
Ideally, a relayer system (whether a single node, or some cooperating/compe=
ting overlay network of nodes) would gather a bunch of transactions in a pr=
oposed package of high-paying transactions.
Miners then offer to pay the relayer contingent on learning such a package.
The miner wants:
* To be given proof, before paying, that the package:
* Pays some certain value in fees.
* Consist of valid transactions.
* To atomically get the actual package once they pay.
The relayer wants:
* To be paid when it reveals such a package of transaction.
Transactors want:
* Fees to the relayer to be included as part of the mining fees in their tr=
ansaction.
The flow would be something like this:
* A transactor has a group of transactions it wants confirmed.
* It goes to some relayer and feeds the transactions to them.
* The relayer figures out the most lucrative package (a task that may be NP=
-hard? Knapsack problem equivalent?).
* Miners look for relayers who have figured out the most lucrative next pac=
kage.
* Miners pick the best package and pay for the package.
* Miners compete on mining.
The issues are:
* We need some way to prove that a bunch of transactions are valid, without=
showing the actual transactions.
* Maybe part of Utreexo or similar concepts can be used?
* We need some way to prove that a bunch of transactions pays some fee.
* Again, Utreexo? Maybe? Probably not?
* Fees =3D inputs - outputs, so the delta between the input UTXO set and =
the output UTXO set should be the fee, how do we prove that?
* We need some way to actually get the actual transaction data contingent o=
n some PTLC or HTLC.
Hmm.
Thoughts?
Regards,
ZmnSCPxj
|
