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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id DD9F7C0011
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Feb 2022 11:43:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id B940641558
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Feb 2022 11:43:12 +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: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 3LkmJ8EhAv-5
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Feb 2022 11:43:11 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch
[185.70.40.140])
by smtp4.osuosl.org (Postfix) with ESMTPS id 70D09401D6
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Feb 2022 11:43:09 +0000 (UTC)
Date: Wed, 23 Feb 2022 11:42:54 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1645616586;
bh=asXwnXOy8w5yqLL3foG3dTtZgX1hw5vfF84k001Q7tc=;
h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID;
b=ukc2D30GZRXSRDk3otEioTzGI84LykawKv6RYGw2m6Q6bSiwc2MaLbOP6Wl8ohfdO
D8FZ8rTjldY6/uxH77zMfSsf9AlJYTYp/DoJmSGsP3Nx/p7oaWuRM8HmmvUB9KzkKc
Gt8+CJEf8U3qWp0IdQ5ZKZXE5CAaZtt0qmFRLQzLyPn+c+BVbsUJkmqDwkAZEdvio6
w7gDkwcj7+/UWS9j7EFFpo9nGRwR4gWqOn2+ZipgnfmrubhQWo/SyiY3Qw0jbP7i5s
sCPCEeRjNHsdjfDEZTGFtPki7mEF3MHNr0nWF4vtCmlPAefurODLvCx4hs8aFG/Jup
nfU6sgpJaEvuQ==
To: Antoine Riard <antoine.riard@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <EoJPTKIHFCBpB505PNjhQp3Iuou-FhQqNwzqVOvFh5W2qx_d0phXLuVPGdjQhYqEma6BX1TfDxRQ1XpCaqZQPF2PWMhTnyTrEnkmtKFpmnw=@protonmail.com>
In-Reply-To: <CALZpt+EUm06LxMmaQd0wxZ5cNtE_+jCQUWDmVrGTJx6ADQT4mA@mail.gmail.com>
References: <6nZ-SkxvJLrOCOIdUtLOsdnl94DoX_NHY0uwZ7sw78t24FQ33QJlJU95W7Sk1ja5EFic5a3yql14MLmSAYFZvLGBS4lDUJfr8ut9hdB7GD4=@protonmail.com>
<CALZpt+Ee9kuVjpXYgOb_7dB7Yr8HYmicdRhfgXsQkey2szNDHg@mail.gmail.com>
<0mhhHzTun8dpIcLda1CLFihMsgLoWQUEE8woKUKhf_UHYps2w7jVzbJAUJ302kQEB1ZdvMfakP9IBUHLM8bGns-pg0NHmpuak3yjpphjJnw=@protonmail.com>
<CALZpt+EUm06LxMmaQd0wxZ5cNtE_+jCQUWDmVrGTJx6ADQT4mA@mail.gmail.com>
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>,
Anthony Towns <aj@erisian.com.au>
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: Wed, 23 Feb 2022 11:43:13 -0000
Good morning Antoine,
> TLUV doesn't assume cooperation among the construction participants once =
the Taproot tree is setup. EVICT assumes cooperation among the remaining co=
nstruction participants to satisfy the final CHECKSIG.
>
> So that would be a feature difference between TLUV and EVICT, I think ?
`OP_TLUV` leaves the transaction output with the remaining Tapleaves intact=
, and, optionally, with a point subtracted from Taproot internal pubkey.
In order to *truly* revive the construct, you need a separate transaction t=
hat spends that change output, and puts it back into a new construct.
See: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-Februar=
y/003479.html
I describe how this works.
That `OP_EVICT` does another `CHECKSIG` simply cuts through the separate tr=
ansaction that `OP_TLUV` would require in order to revive the construct.
> > I thought it was part of Taproot?
>
> I checked BIP342 again, *as far as I can read* (unreliable process), it s=
ounds like it was proposed by BIP118 only.
*shrug* Okay!
> > A single participant withdrawing their funds unilaterally can do so by =
evicting everyone else (and paying for those evictions, as sort of a "nuisa=
nce fee").
>
> I see, I'm more interested in the property of a single participant withdr=
awing their funds, without affecting the stability of the off-chain pool an=
d without cooperation with other users. This is currently a restriction of =
the channel factories fault-tolerance. If one channel goes on-chain, all th=
e outputs are published.
See also: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-Fe=
bruary/003479.html
Generally, the reason for a channel to go *onchain*, instead of just being =
removed inside the channel factory and its funds redistributed elsewhere, i=
s that an HTLC/PTLC is about to time out.
The blockchain is really the only entity that can reliably enforce timeouts=
.
And, from the above link:
> * If a channel has an HTLC/PTLC time out:
> * If the participant to whom the HTLC/PTLC is offered is
> offline, that may very well be a signal that it is unlikely
> to come online soon.
> The participant has strong incentives to come online before
> the channel is forcibly closed due to the HTLC/PTLC timeout,
> so if it is not coming online, something is very wrong with
> that participant and we should really evict the participant.
> * If the participant to whom the HTLC/PTLC is offered is
> online, then it is not behaving properly and we should
> really evict the participant.
Note the term "evict" as well --- the remaining participants that are presu=
mably still behaving correctly (i.e. not letting HTLC/PTLC time out) evict =
the participants that *are*, and that is what `OP_EVICT` does, as its name =
suggests.
Indeed, I came up with `OP_EVICT` *after* musing the above link.
Regards,
ZmnSCPxj
|
