Date: Tue, 10 Sep 2019 01:28:04 +0000
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
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
Precedence: list

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