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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 22315A55;
Tue, 10 Sep 2019 01:28:13 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch
[185.70.40.136])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BBF2A76F;
Tue, 10 Sep 2019 01:28:11 +0000 (UTC)
Date: Tue, 10 Sep 2019 01:28:04 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1568078889;
bh=+xNy5BbgDCQgnDUoPhAZ/ODMmkHX0zXvQnDneF0adlc=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=t4HEksokB5BG442rG550/oiLXH6Y/vdel+LwrmkMwVp4gBS1G8w20051kx8Wn6PRB
oWN/C3zB0Qhx76izPtcv4aE6Hg2EOD2TTvUeCA7luv4doiWgxA62iszUJtMVPJc0Dt
qYVGDJFbx31oBmmQYzzMYqdFHOGgz9gZSdLEc9xM=
To: Richard Myers <rich@gotenna.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <RQVxRFj-yzhYfEPMZhVrSYCaEvFhRrlxkSI-sYmqwEE7bRO6hKPV-vdB2ijcFYND-2x_5esnr7aofW6-74B3mHFLiLlHm-FM4WPeiJo-GhQ=@protonmail.com>
In-Reply-To: <CACJVCgLe-hmSoPZtsXBMDToqa-rh04EroppO14zBQqEjdWacQw@mail.gmail.com>
References: <87mufhva0k.fsf@gmail.com>
<G_LSM42y_gQFNVrTfHHN5hqR_foZU6AlOJkfz9zMDLFyQGdk4opZ14QC97w2rjrw4UmWTwEkJDKEc_eUMItdmxEsQOl7S-gBO2y8ovFPBc0=@protonmail.com>
<CACJVCgLe-hmSoPZtsXBMDToqa-rh04EroppO14zBQqEjdWacQw@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
"lightning-dev@lists.linuxfoundation.org"
<lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Reconciling the off-chain and
on-chain models with eltoo
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 10 Sep 2019 01:28:13 -0000
Good morning Richard,
> I believe using the eltoo update scheme as a way to consolidate blocks of=
off-chain transactions is an interesting idea worth exploring.=C2=A0=C2=
=A0
>
> ZmnSCPxj brings up some limitations on arbitrary outputs scripts in eltoo=
. Although using CSV is more complicated and outputs must also use SIGHASH_=
NOINPUT [1], the ability to have multiple party channels and the most used =
types of scripts makes eltoo compelling compared to LN-Penalty for this kin=
d of application.
I broadly agree.
I imagine a future where most people do not typically have single-signer ow=
nership of coins onchain, but are instead share-owners of coins, with singl=
e-signer ownership occurring onchain only in the case of dispute or for lon=
g-term cold storage.
>
> The multiple party aspect in particular introduces an interesting way to =
unify concepts from different second layer protocols like federated sidecha=
ins and statechains (ht.=C2=A0aakselrod [2]).
>
> Though the Statechains proposal relies on eltoo [3], I think what Christi=
an suggested does not try to solve the dynamic membership problem. That's w=
hy I think of this as more an evolution of the channel factory paper toward=
s something like a federated sidechain.
>
> > I think this reconciliation between the off-chain model and the on-chai=
n
> > model, with many concepts cleanly mapping from one context to another
> > (state outputs =3D UTXO, off-chain update =3D on-chain transactions,
> > cut-through =3D confirmation, operation batching =3D block creation) is
> > rather nice :-)
>
> One additional concept that could be new to this off-chain blockchain mod=
el would be something like batched multi-party loop-in/out. In a Schnorr/Ta=
proot world you could add signers/inputs and remove signers/outputs with a =
single multi-signature negotiated off-chain. You'd still like to limit thes=
e onchain txs, even if they are small, but updating channels periodically s=
eems like a straight forward way to address the dynamic membership problem.
Indeed.
Such a change-in-membership transaction would be a 1-input 1-output transac=
tion, and with use of n-of-n MuSig would be as small (and as private, modul=
o the fact that you are coordinating this with a bunch of other participant=
s) as a single-sig user making a 1-input 1-output transaction (which genera=
lly is not very private because such transactions are usually "send-to-self=
" and changing membership generally means ownership does not actually chang=
e much).
The cost of this transaction would be small (certainly smaller than the upd=
ate+state transactions needed in Decker-Russell-Osuntokun)
For setting this up, it might be useful to have the below ritual.
This assumes only a change in the membership set is desired, without a simu=
ltaneous change in the UTXO set.
1. Create a new update+state transaction for the current Decker-Russell-Os=
untokun mechanism.
The state transaction pays out to a single output paying to the new mem=
bership set rather than the current UTXO set of the mechanism.
Do *not* sign this yet.
Call this the "final" update+state transaction.
2. Create a new Decker-Russell-Osuntokun mechanism initial update+state tr=
ansaction.
This pays out to the current UTXO set of the previous mechanism.
This will spend from the new membership set.
Completely sign these transactions.
* The update transaction can spend the above "final" transaction, as it=
is `SIGHASH_NOINPUT`.
3. Sign the final update+state transaction of the previous Decker-Russell-=
Osuntokun mechanism.
Do *not* broadcast the update+state transaction yet.
4. Create and sign the membership-change onchain transaction.
This spends the current onchain funding transaction output and outputs =
to the same new membership set.
Broadcast this onchain.
The above ritual ensures that, after step 3 completes, the mechanism can co=
ntinue operating without waiting for onchain activity to complete.
It ensures that, even if the membership-change onchain transaction becomes =
invalid later (by somebody bribing a miner to publish a previous update tra=
nsaction from the older membership set), we will still enter an update that=
will eventually put the new membership set onchain.
This reduces the critical path to only steps 1 to 3, and we can continue op=
erating with the new membership set as soon as step 3 completes and we do n=
ot need to wait for the membership-change transaction to be deeply-confirme=
d in order to use the new membership set mechanism.
However, it has the drawback that, until the membership-change onchain tran=
saction is deeply-confirmed onchain, the CSV parameter is temporarily doubl=
ed (as there is the possibility that the previous mechanism is closed).
Also, the mechanism cannot be mutually closed until the membership-change o=
nchain transaction is deeply-confirmed, as there is no stable txid we can s=
pend from (we would strongly prefer to use `SIGHASH_ALL` for cooperative cl=
oses to improve our privacy).
>
> I guess this all gets back to how to design an off-chain protocol for man=
aging these negotiations. Ultimately I can imagine a sort of multi-party el=
too based 'signet' with the same RPC interface, but different transaction v=
alidation and block creation logic.=C2=A0 Perhaps there would be a new mess=
age where the channel parties would add their signature before forwarding a=
valid block, and the block wouldn't be built on until all parties had sign=
ed.
The "block" that would need to be signed by the participants would actually=
be a Decker-Russell-Osuntokun update+state transaction, and would commit t=
o the UTXO set rather than the transaction set.
Unless I misunderstand your meaning here.
Regards,
ZmnSCPxj
|
