path: root/dc/f7bfaffc06552ca27d3c6a854b5642b85e0944

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 637CBCA5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 18 Sep 2019 05:28:47 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
	[185.70.40.130])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6A39F76D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 18 Sep 2019 05:28:45 +0000 (UTC)
Date: Wed, 18 Sep 2019 05:28:38 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=default; t=1568784522;
	bh=HvgFn5bfTTMPMKVmrBnHFj4E2IZKTzNwlgcpsQU/0Rg=;
	h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
	Feedback-ID:From;
	b=Cx1mm15Tobu4iF/N2TodnW1iSzzJ/OM1l9rv4x9dwhp5PFrhHQeYNHtxXMuNGtW8y
	s/KYDS8TZuWRqN3e5o3FcabvZY/XoUykMe2jR02ZU07uEHA56x+2t6IOhVF9IepmD8
	f3V5ubAFBBgBsUiksw4onaIwZcfOwf0fEL6hoMU8=
To: Richard Myers <rich@gotenna.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <ccotpmyCthtmIqi2aqT6DaWAF_BEYSQh5vPnz9nmVu-zemfA3utpaDsb1Xn1jqaIXlRUzHwS7UlMHR_LJE27pzARxuUCu7PM6w6MEXrL8p8=@protonmail.com>
In-Reply-To: <CACJVCg+wuODW-NoNoAvwdcnr0gZbLFrDyip6-0unw9hFu2-oOg@mail.gmail.com>
References: <87mufhva0k.fsf@gmail.com>
	<G_LSM42y_gQFNVrTfHHN5hqR_foZU6AlOJkfz9zMDLFyQGdk4opZ14QC97w2rjrw4UmWTwEkJDKEc_eUMItdmxEsQOl7S-gBO2y8ovFPBc0=@protonmail.com>
	<CACJVCgLe-hmSoPZtsXBMDToqa-rh04EroppO14zBQqEjdWacQw@mail.gmail.com>
	<RQVxRFj-yzhYfEPMZhVrSYCaEvFhRrlxkSI-sYmqwEE7bRO6hKPV-vdB2ijcFYND-2x_5esnr7aofW6-74B3mHFLiLlHm-FM4WPeiJo-GhQ=@protonmail.com>
	<CACJVCg+wuODW-NoNoAvwdcnr0gZbLFrDyip6-0unw9hFu2-oOg@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: Wed, 18 Sep 2019 05:28:47 -0000

Good morning Richards, and list,

> Thanks for the feedback ZmnSCPxj.
>
> > I imagine a future where most people do not typically have single-signe=
r ownership of coins onchain, but are instead share-owners of coins, with s=
ingle-signer ownership occurring onchain only in the case of dispute or for=
 long-term cold storage.
>
> The change-in-membership ritual you describe seems like a good start for =
elaborating on this idea.=C2=A0
>
> Some aspects of multi-party Decker-Russell-Osuntokun channels have analog=
s to a signet blockchain that use a n-of-n federation of signers. But other=
 places, like change-in-membership, do not have direct analogs.
>
> For example, some signet concepts with multi-party channel analogs:
>
> block script:
> * the first 'update' and 'settle' transactions, aka 'setup' and 'refund' =
transactions, define the set of signers that must sign subsequent channel u=
pdates
>
> genesis block:
> * the initial 'funding' transaction, aka outpoint of the commitment trans=
action, which establishes the funded channel
>
> utxo set:
> * the specific set of on-chain outputs from the 'settlement' transaction =
that spends the balance of the latest 'update' transaction signed by the co=
mplete set of channel parties.
>
> mempool:
> * the set of proposals for specific changes to the set of outputs from th=
e latest 'settlement' transaction (similar to update_add_htlc, update_fail_=
htlc, etc)
>
> Concepts where layer two channels do not have an obvious analog to a laye=
r one signet blockchain:
>
> cooperative close:
> * when all parties mutually agree to close the channel
> * close the channel with a layer one transaction which finalizes the outp=
uts from the most recent channel output state
> * should be optimized for privacy and low on-chain fees

Of note is that a close of an update mechanism does not require the close o=
f any hosted update mechanisms, or more prosaically, "close of channel fact=
ory does not require close of hosted channels".
This is true for both unilateral and cooperative closes.

Of course, the most likely reason you want to unilaterally close an outer m=
echanism is if you have some contract in some deeply-nested mechanism that =
will absolute-locktime expire "soon", in which case you have to close every=
thing that hosts it.
But for example if a channel factory has channels A B C and only A has an H=
TLC that will expire soon, while the factory and A have to close, B and C c=
an continue operation, even almost as if nothing happened to A.

>
> membership change (ZmnSCPxj ritual):
> * when channel parties want to leave or add new members to the channel
> * close and reopen a new channel via something like a channel splicing tr=
ansaction to the layer one blockchain
> * should be optimized for privacy and low on-chain fees paid for by parti=
es entering and leaving the channel

Assuming you mean that any owned funds will eventually have to be claimed o=
nchain, I suppose this is doable as splice-out.

But note that currently we have some issues with splice-in.

As far as I can tell (perhaps Lisa Neigut can correct me, I believe she is =
working on this), splice-in has the below tradeoffs:

1.  Option 1: splice-in is async (other updates can continue after all part=
icipants have sent the needed signatures for the splice-in).
    Drawback is that spliced-in funds need to be placed in a temporary n-of=
-n, meaning at least one additional tx.
2.  Option 2: splice-in is efficient (only the splice-in tx appears onchain=
).
    Drawback is that subsequent updates can only occur after the splice-in =
tx is deeply confirmed.
    * This can be mitigated somewhat by maintaining a pre-splice-in and pos=
t-splice-in mechanism, until the splice-in tx is deeply confirmed, after wh=
ich the pre-splice-in version is discarded.
      Updates need to be done on *both* mechanisms until then, and any intr=
oduced money is "unuseable" anyway until the splice-in tx confirms deeply s=
ince it would not exist in the pre-splice-in mechanism yet.

But perhaps a more interesting thing (and more in keeping with my sentiment=
 "a future where most people do not typically have single-signer ownership =
of coins onchain") would be to transfer funds from one multiparticipant off=
chain mechanism to another multiparticipant offchain, by publishing a singl=
e transaction onchain.
It may be doable via some extension of my proposed ritual for changing memb=
ership set.

>
> balance change (similar to membership change):
> * when channel parties want to add or remove some of the finalized value =
in the channel
> * close and reopen a new channel via something like a channel splicing tr=
ansaction to the layer one blockchain
> * should be optimized for privacy and low on-chain fees paid for by parti=
es adding and removing value from the channel
>
> uncooperative close:
> * when one or more nodes fails to sign the next channel state update
> * use a layer one transaction to commit both finalized and un-finalized o=
utputs from the most recent channel output state
> * script timeouts determine when channel parties should uncooperatively c=
lose the channel if not all parties have signed the next 'update' and 'sett=
lement' transaction
>
> uncooperative membership change:
> * a subset of channel parties might want to cooperatively sign a channel =
splicing transaction to 'splice out' uncooperative parties

I believe this is currently considered unsafe.
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001975=
.html

Unless you refer to another mechanism...?

I believe this will end up requiring deep confirmation of the uncooperative=
 close followed by a new mechanism open.

>
> mining, mining reward and difficulty adjustment
> * no equivalent concept for multi-party channels

Fees for each update.
Consider how HTLC routing in Lightning implicitly pays forwarding nodes to =
cooperate with the forwarding.
I imagine most nodes in a multiparticipant offchain system will want to be =
paid for cooperation, even if just a nominal sub-satoshi amount.

>
> transaction fees:
> * updates to layer two channels do not incur transactions fees
> * invalid updates dropped to layer one should be paid by cheating node
> * splice in/out transactions should be paid by requesting signers only
> * do transaction fees prevent 'griefing' attacks?
>
> privacy:
> * disassociate a particular update from signer(s)
> * disassociate IP address of signers from signature
> * using SIGHASH_ALL for cooperative closes

I suppose Tor can be used to disassociate IP address from signers if everyo=
ne is from a hidden service.
However, we need to include some kind of mix mechanism to allow individual =
signers to disassociate their ownership of funds from their identity as sig=
ners.
Though such mechanisms already exist as theoretical constructs, so "just ne=
eds implementing".

But then again: if you own funds in the mechanism, you *should* be a signer=
 (else you are trusting a federation).
So a basic fact here is that if you are a participant in some offchain mech=
anism, you are likely (approaching 100% probability) to own money in it.

>
> liveness:
> * if signers know they will be offline, can they pre-sign updates that ju=
st commit their own outputs, rather then splice out?
> * contingent tap-leafs to splice out non-responsive signers

It might be possible to create a new mechanism-within-mechanism layer, if a=
 signer knows they will be offline.

For example, suppose entities A, B, and C have an offchain update mechanism=
, which we shall call a "factory".
Suppose this factory contains an A-B channel, a B-C channel, a A-C channel,=
 and some funds owned by B only.
Then suppose A knows he or she will be offline for some time.
Before A goes offline, they can move from this UTXO set:

* A-B channel
* B-C channel
* A-C channel
* B funds

To this UTXO set:

* A-B channel
* A-C channel
* B-C offchain update mechanism (sub-factory), which itself has its own UTX=
O set:
  * B-C channel
  * B funds

This allows B and C to manage the B-C channels and B funds without cooperat=
ion of A.
Then, later, when A returns online, the B-C offchain update mechanism is co=
llapsed back to the parent A-B-C offchain update mechanism.

This assumes A knows it will be offline (which it might do for e.g. regular=
 maintenance, or software updates).

Regards,
ZmnSCPxj