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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 6244AC000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Feb 2022 01:17:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 5441260B20
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Feb 2022 01:17:31 +0000 (UTC)
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_H5=0.001,
RCVD_IN_MSPIKE_WL=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 (2048-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 gka9860VNovR
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Feb 2022 01:17:30 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24])
by smtp3.osuosl.org (Postfix) with ESMTPS id E08F560ACA
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Feb 2022 01:17:28 +0000 (UTC)
Date: Sat, 19 Feb 2022 01:17:20 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1645233445;
bh=U0TZB46+Lc9PsdF8SObGjQ6CAeYrY+K+ropWtcA+R48=;
h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References:
From:To:Cc:Date:Subject:Reply-To:Feedback-ID:Message-ID;
b=jlgwQQFGKB3Tp5joKpyf7D5r3eAmnrPmRI3thpjTov+m6XkKvBOHtlWHW/NSKW4u3
oUCxOWbSE9Yc9SUgMj3+zi5CTxu7s/7xuZmTysNbQLpF7m99kZhdIUvdijHoeQrHJP
Ujs4PB8+nk3VBEFC1dkTudpotczLxkNSW1SGRI9tdJweU+HwWCEZYaGt7ha1XMzLok
4FaFPmh5q906krEm82JzPT9b16Qmt4x5buzoyozZ75amOY1XT47YwNV25TjUkOEN3X
B+G0FOuzM34vGO8uJzx3Jtr9H03Km6cPn2oswvO6DXwa4sS1JTIR8HJNli6BEVBLJO
Ea9oOzGuwkA4g==
To: Jeremy Rubin <jeremy.l.rubin@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <3ev2Zqf5SyEHMQvtRbaTBnP8wADZPis-2YvawQr0k6vM4ftjlggJhQHRup44LkMtaoCTUF6EWm5FC86xuMFxOtb7Di7KQza8k4rn5Xs96Hw=@protonmail.com>
In-Reply-To: <CAD5xwhh9JHE0QAfRMeKs7w=L-GB5DaEomsQ0aH4ibSDi9Oe8Rg@mail.gmail.com>
References: <6nZ-SkxvJLrOCOIdUtLOsdnl94DoX_NHY0uwZ7sw78t24FQ33QJlJU95W7Sk1ja5EFic5a3yql14MLmSAYFZvLGBS4lDUJfr8ut9hdB7GD4=@protonmail.com>
<CALZpt+Ee9kuVjpXYgOb_7dB7Yr8HYmicdRhfgXsQkey2szNDHg@mail.gmail.com>
<0mhhHzTun8dpIcLda1CLFihMsgLoWQUEE8woKUKhf_UHYps2w7jVzbJAUJ302kQEB1ZdvMfakP9IBUHLM8bGns-pg0NHmpuak3yjpphjJnw=@protonmail.com>
<CAD5xwhh9JHE0QAfRMeKs7w=L-GB5DaEomsQ0aH4ibSDi9Oe8Rg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] `OP_EVICT`: An Alternative to
`OP_TAPLEAFUPDATEVERIFY`
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 Feb 2022 01:17:31 -0000
Good morning Jeremy,
> This is a fascinating post and I'm still chewing on it.
>
> Chiming in with two points:
>
> Point 1, note with respect to evictions, revivals, CTV, TLUV:
>
> CTV enables 1 person to be evicted in O(log N) or one person to leave in =
O(log N). TLUV enables 1 person to leave in O(1) O(log N) transactions, but=
evictions take (AFAICT?) O(N) O(log N) transactions because the un-live pa=
rty stays in the pool. Hence OP_EVICT helps also make it so you can kick so=
meone out, rather than all having to leave, which is an improvement.
>
> CTV rejoins work as follows:
>
> suppose you have a pool with 1 failure, you need to do log N txns to evic=
t the failure, which creates R * log_R(N) outputs, which can then do a tran=
saction to rejoin.
>
> For example, suppose I had 64 people in a radix 4 tree. you'd have at the=
top level 4 groups of 16, then 4 groups of 4 people, and then 1 to 4 txns.=
Kicking 1 person out would make you do 3 txns, and create 12 outputs total=
. A transaction spending the 11 outputs that are live would capture 63 peop=
le back into the tree, and with CISA would not be terribly expensive. To be=
a bit more economical, you might prefer to just join the 3 outputs with 16=
people in it, and yield 48 people in one pool. Alternatively, you can lazi=
ly re-join if fees make it worth it/piggybacking another transaction, or op=
erate independently or try to find new, better, peers.
>
> Overall this is the type of application that necessitates *exact* byte co=
unting. Oftentimes things with CTV seem inefficient, but when you crunch th=
e numbers=C2=A0it turns out not to be so terrible. OP_EVICT seems promising=
in this regard compared to TLUV or accumulators.
>
> Another option is to randomize the CTV trees with multiple outputs per pa=
rty (radix Q), then you need to do Q times the evictions, but you end up wi=
th sub-pools that contain more people/fractional liquidity (this might happ=
en naturally if CTV Pools have channels in them, so it's good to model).
Do note that a weakness of CTV is that you *have to* split up the CoinPool =
into many smaller pools, and re-merging them requires waiting for onchain c=
onfirmation.
This overall means you have no real incentive to revive the original CoinPo=
ol minus evicted parties.
`OP_EVICT` lets the CoinPool revival be made into the same transaction that=
performs the evict.
> Point 2, on Eltoo:
>
> One point of discomfort I have with Eltoo that I think is not universal, =
but is shared by some others, is that non-punitive channels may not be good=
for high-value channels as you do want, especially in a congested blockspa=
ce world, punishments to incentivize correct behavior (otherwise cheating m=
ay look like a free option).
>
> Thus I'm reluctant to fully embrace designs which do not permit nested tr=
aditional punitive channels in favor of Eltoo, when Eltoo might not have pr=
oduct-market-fit for higher valued channels.
>
> If someone had a punitive-eltoo variant that would ameliorate this concer=
n almost entirely.
Unfortunately, it seems the way to any kind of N > 2 construction *with* pe=
nalty would require bonds, such as the recent PathCoin idea (which is an N =
> 2 construction *with* penalty, and is definitely offchain for much of its=
operation).
Having a Decker-Russell-Osuntokun "factory" layer that hosts multiple Poon-=
Dryja channels is not quite a solution; if old state on Decker-Russell-Osun=
tokun layer pushes through, then its obsolete Poon-Dryja channels will have=
all states invalid and unclaimable, but in case of Sybil where some partic=
ipants are sockpuppets, it would still be possible for a thief to claim the=
funds from an "invalidated" Poon-Dryja channel if that channel is with a s=
ockpuppet.
Regards,
ZmnSCPxj
|
