summaryrefslogtreecommitdiff
path: root/f0/4701f30a913c82c1fa6b62083662ae713ad17e
blob: 605c56dfba4d59af14c5f2ee349a75144bad8e6f (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
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
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 66D81C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Sep 2023 06:51:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 48AEA820FC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Sep 2023 06:51:12 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 48AEA820FC
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=aeL6/XvN
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level: 
X-Spam-Status: No, score=-1.599 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_H4=0.001,
 RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id qqDaJC9pwN_R
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Sep 2023 06:51:09 +0000 (UTC)
Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 4B800820ED
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Sep 2023 06:51:09 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 4B800820ED
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1695711066; x=1695970266;
 bh=UBM47mVJBEcvAOIU3X0DFCJKw2D6eTo6cIAJK3QpUhg=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector;
 b=aeL6/XvNpBeEZDRFrjsT4W6+0yB+ScUP4hBlwrUZMkzf7+RzkCY1r3EOS/n5VNgbw
 U6a6E413w8mvm7hFY8uovBPWjwUwZwWpPeu5TXY3AcTHnRs8f+9mMEn9zlRfK+STWN
 tuaJVG2MIX3Q6IbDPPre6PNfDdBZ2TexkjTU3RvKgSYvMgZwPPo8n7mr1grr0uVS1K
 CcyIlw2LIuG4/QtfWw9v/wMP+miDa1wL1MzgQ1QgVmkUXlEWqQpKFtbh/Hx/tNIq6n
 Zh04N9jiuArf654MYYQoIrlznpjhbYG/kL0RIx2PM3lA3qb7bm9LyhpXf4a0OAtOhV
 Pk09Wfiovkshw==
Date: Tue, 26 Sep 2023 06:50:50 +0000
To: Antoine Riard <antoine.riard@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <OUAbM8ii-HE8M-kRAkMvdDkbiwKuG_wcYlrvC276eIsKXcW6Yh6iNcxy_PtchHNL3jIIc-nz-ucv2H11EznrZbYhKqyVPhE8__GeIDLxPNw=@protonmail.com>
In-Reply-To: <CALZpt+F26bArqU7aZj8VN-zDN-3_VZS1K1ibaJOeCrsLDL2_4Q@mail.gmail.com>
References: <CALZpt+F26bArqU7aZj8VN-zDN-3_VZS1K1ibaJOeCrsLDL2_4Q@mail.gmail.com>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Solving CoinPool high-interactivity issue with
	cut-through update of Taproot leaves
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 Sep 2023 06:51:12 -0000

Good morning Antoine,

Does `OP_EVICT` not fit?

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/01992=
6.html

Regards,
ZmnSCPxj


Sent with Proton Mail secure email.

------- Original Message -------
On Monday, September 25th, 2023 at 6:18 PM, Antoine Riard via bitcoin-dev <=
bitcoin-dev@lists.linuxfoundation.org> wrote:


> Payment pools and channel factories are afflicted by severe interactivity=
 constraints worsening with the number of users owning an off-chain balance=
 in the construction. The security of user funds is paramount on the abilit=
y to withdraw unilaterally from the off-chain construction. As such any upd=
ate applied to the off-chain balances requires a signature contribution fro=
m the unanimity of the construction users to ensure this ability is conserv=
ed along updates.
> As soon as one user starts to be offline or irresponsive, the updates of =
the off-chain balances must have to be halted and payments progress are lim=
ited among subsets of 2 users sharing a channel. Different people have prop=
osed solutions to this issue: introducing a coordinator, partitioning or la=
yering balances in off-chain users subsets. I think all those solutions hav=
e circled around a novel issue introduced, namely equivocation of off-chain=
 balances at the harm of construction counterparties [0].
>=20
> As ZmnSCPxj pointed out recently, one way to mitigate this equivocation c=
onsists in punishing the cheating pre-nominated coordinator on an external =
fidelity bond. One can even imagine more trust-mimized and decentralized fr=
aud proofs to implement this mitigation, removing the need of a coordinator=
 [1].
>=20
> However, I believe punishment equivocation to be game-theory sound should=
 compensate a defrauded counterparty of the integrity of its lost off-chain=
 balance. As one cheating counterparty can equivocate in the worst-case aga=
inst all the other counterparties in the construction, one fidelity bond sh=
ould be equal to ( C - 1 ) * B satoshi amount, where C is the number of con=
struction counterparty and B the initial off-chain balance of the cheating =
counterparty.
>=20
> Moreover, I guess it is impossible to know ahead of a partition or transi=
tion who will be the "honest" counterparties from the "dishonest" ones, the=
refore this ( C - 1 ) * B-sized fidelity bond must be maintained by every c=
ounterparty in the pool or factory. On this ground, I think this mitigation=
 and other corrective ones are not economically practical for large-scale p=
ools among a set of anonymous users.
>=20
> I think the best solution to solve the interactivity issue which is reali=
stic to design is one ruling out off-chain group equivocation in a prophyla=
ctic fashion. The pool or factory funding utxo should be edited in an effic=
ient way to register new off-chain subgroups, as lack of interactivity from=
 a subset of counterparties demands it.
>=20
> With CoinPool, there is already this idea of including a user pubkey and =
balance amount to each leaf composing the Taproot tree while preserving the=
 key-path spend in case of unanimity in the user group. Taproot leaves can =
be effectively regarded as off-chain user accounts available to realize pri=
vacy-preserving payments and contracts.
>=20
> I think one (new ?) idea can be to introduce taproot leaves "cut-through"=
 spends where multiple leaves are updated with a single witness, interactiv=
ely composed by the owners of the spent leaves. This spend sends back the l=
eaves amount to a new single leaf, aggregating the amounts and user pubkeys=
. The user leaves not participating in this "cut-through" are inherited wit=
h full integrity in the new version of the Taproot tree, at the gain of no =
interactivity from their side.
>=20
> Let's say you have a CoinPool funded and initially set with Alice, Bob, C=
aroll, Dave and Eve. Each pool participant has a leaf L.x committing to an =
amount A.x and user pubkey P.x, where x is the user name owning a leaf.
>=20
> Bob and Eve are deemed to be offline by the Alice, Caroll and Dave subset=
 (the ACD group).
>=20
> The ACD group composes a cut-through spend of L.a + L.c + L.d. This spend=
s generates a new leaf L.(acd) leaf committing to amount A.(acd) and P.(acd=
).
>=20
> Amount A.(acd) =3D A.a + A.c + A.d and pubkey P.(acd) =3D P.a + P.c + P.d=
.
>=20
> Bob's leaf L.b and Eve's leaf L.e are left unmodified.
>=20
> The ACD group generates a new Taproot tree T' =3D L.(acd) + L.b + L.e, wh=
ere the key-path K spend including the original unanimity of pool counterpa=
rties is left unmodified.
>=20
> The ACD group can confirm a transaction spending the pool funding utxo to=
 a new single output committing to the scriptpubkey K + T'.
>=20
> From then, the ACD group can pursue off-chain balance updates among the s=
ubgroup thanks to the new P.(acd) and relying on the known Eltoo mechanism.=
 There is no possibility for any member of the ACD group to equivocate with=
 Bob or Eve in a non-observable fashion.
>=20
> Once Bob and Eve are online and ready to negotiate an on-chain pool "refr=
esh" transaction, the conserved key-path spend can be used to re-equilibrat=
e the Taproot tree, prune out old subgroups unlikely to be used and provisi=
on future subgroups, all with a compact spend based on signature aggregatio=
n.
>=20
> Few new Taproot tree update script primitives have been proposed, e.g [2]=
. Though I think none with the level of flexibility offered to generate lea=
ves cut-through spends, or even batch of "cut-through" where M subgroups ar=
e willing to spend N leaves to compose P new subgroups fan-out in Q new out=
puts, with showing a single on-chain witness. I believe such a hypothetical=
 primitive can also reduce the chain space consumed in the occurrence of na=
ive mass pool withdraws at the same time.
>=20
> I think this solution to the high-interactivity issue of payment pools an=
d factories shifts the burden on each individual user to pre-commit fast Ta=
proot tree traversals, allowing them to compose new pool subgroups as fluct=
uations in pool users' level of liveliness demand it. Pool efficiency becom=
es the sum of the quality of user prediction on its counterparties' livelin=
ess during the construction lifetime. Recursive taproot tree spends or more=
 efficient accumulator than merkle tree sounds ideas to lower the on-chain =
witness space consumed by every pool in the average non-interactive case.
>=20
> Cheers,
> Antoine
>=20
> [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/02=
0370.html
> [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August=
/004043.html
> [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Septembe=
r/019420.html