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
|
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 3B285C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Feb 2022 16:06:52 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 224B260B96
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Feb 2022 16:06:52 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 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, 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 e6IsMq4vR9U4
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Feb 2022 16:06:51 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by smtp3.osuosl.org (Postfix) with ESMTPS id F14F160B54
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Feb 2022 16:06:50 +0000 (UTC)
Date: Fri, 18 Feb 2022 16:06:39 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1645200407;
bh=w3zZfPBV32gADgUsiRR+VtkMT5aj9mHcLyF/b71TWtg=;
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=tZ0HCH8cgSKcm6AQkv1K0hNyjBPDm8VeBhe2jjX0SzBQNYYQK5ZhxUqDcFJZZZDiF
4j5QDUvhhmdVuR8a36J7rgujPs02e+szQEXGyFuWurcGEZH5FnMih3sysfm+hPve9c
Ecg0uFeb1K3fj2NFb9tV/+nTMg5uDeCK0CS6qrvmmeI1BMOGvJUgIkzGzPALNvciXk
wZZIC6qPZtWa8q5vOiy2JoLXSTFEz5EhNrrVx+lvfeVvRMLty2nGwg1x9NWpmOhr0k
siPe8QcrjA9/4YePDD2OIx2UvOFi6ZDdkUjNYD9brfORCmtS2blkcQ52tPQw6bqgYD
G1hXHqr7zkHPA==
To: Erik Aronesty <erik@q32.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <3YGc8zgpxTXfmj09vOFSHiGqubBn5Tb6PefbEje8vbSvcKt3wWlf2Ue1VCS33WFygsLq5Rvdv9FW8SCvoDqGNUVYT7gAa2z4NSdu5GHqkHc=@protonmail.com>
In-Reply-To: <CAJowKgKEAptvQnOSKc7W=FDtf6DRchaBUyx3QWeHbCN_89w2zQ@mail.gmail.com>
References: <6nZ-SkxvJLrOCOIdUtLOsdnl94DoX_NHY0uwZ7sw78t24FQ33QJlJU95W7Sk1ja5EFic5a3yql14MLmSAYFZvLGBS4lDUJfr8ut9hdB7GD4=@protonmail.com>
<CAJowKg+cK3ZjPCjcDK8v5qFA=uCHD7gcR8ymroXBFicU5jzY8Q@mail.gmail.com>
<mSBTc8Bl5YIXe7LSX_fCNUYhd0wjepa_XhF6uhtwzF7s5h9-AEGWbkfrPA58nn431SjAqTkWEzd7YJ5mC0M7aZf-NmS5eDTN8LKEGQOFGcY=@protonmail.com>
<CAJowKgKEAptvQnOSKc7W=FDtf6DRchaBUyx3QWeHbCN_89w2zQ@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: Fri, 18 Feb 2022 16:06:52 -0000
Good morning Erik,
> > As I understand your counterproposal, it would require publishing one t=
ransaction per evicted participant.
>
> if you also pre-sign (N-2, N-3, etc), you can avoid this
It also increases the combinatorial explosion.
> > In addition, each participant has to store `N!` possible orderings in w=
hich participants can be evicted, as you cannot predict the future and cann=
ot predict which partiicpants will go offline first.
>
> why would=C2=A0the ordering matter?=C2=A0 these are unordered pre commitm=
ents to move funds, right?=C2=A0 =C2=A0you agree post the one that represen=
ts "everyone that's offline"
Suppose `B` is offline first, then the remaining `A` `C` and `D` publish th=
e eviction transaction that evicts only `B`.
What happens if `C` then goes offline?
We need to prepare for that case (and other cases where the participants go=
offline at arbitrary orders) and pre-sign a spend from the `ACD` set and e=
victs `C` as well, increasing combinatorial explosion.
And so on.
We *could* use multiple Tapleaves, of the form `<A> OP_CHECKSIG <BCD> OP_CH=
ECKSIG` for each participant.
Then the per-participant `<A>` signature is signed with `SIGHASH_SINGLE|SIG=
HASH_ANYONECANPAY` and is pre-signed, while the remainder is signed by `<BC=
D>` with default `SIGHASH_ALL`.
Then if one participant `B` is offline they can evict `B` and then the chan=
ge is put into a new UTXO with a similar pre-signed scheme `<A> OP_CHECKSIG=
<CD> OP_CHECKSIG`.
This technique precludes pre-signing multiple evictions.
>
> > But yes, certainly that can work, just as pre-signed transactions can b=
e used instead of `OP_CTV`=C2=A0
>
> i don't see how multiple users can securely share a channel (allowing mas=
sive additional scaling with lighting) without op_ctv
They can, they just pre-sign, like you pointed out.
The same technique works --- `OP_CTV` just avoids having ridiculous amounts=
of combinatorial explosion and just requires `O(log n)` per eviction.
Remember, this proposal can be used for channel factories just as well, as =
pointed out, so any objection to this proposal also applies to `OP_CTV`.
Regards,
ZmnSCPxj
|
