From: Christian Decker <decker.christian@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, Richard Myers <rich@gotenna.com>
In-Reply-To: <ccotpmyCthtmIqi2aqT6DaWAF_BEYSQh5vPnz9nmVu-zemfA3utpaDsb1Xn1jqaIXlRUzHwS7UlMHR_LJE27pzARxuUCu7PM6w6MEXrL8p8=@protonmail.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>
	<ccotpmyCthtmIqi2aqT6DaWAF_BEYSQh5vPnz9nmVu-zemfA3utpaDsb1Xn1jqaIXlRUzHwS7UlMHR_LJE27pzARxuUCu7PM6w6MEXrL8p8=@protonmail.com>
Date: Wed, 18 Sep 2019 15:44:47 +0200
Message-ID: <87ef0doh0w.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain
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

ZmnSCPxj <ZmnSCPxj@protonmail.com> writes:
>> cooperative close:
>> * when all parties mutually agree to close the channel
>> * close the channel with a layer one transaction which finalizes the outputs 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 of any hosted update mechanisms, or more prosaically, "close of
> channel factory 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 mechanism is if you have some contract in some deeply-nested
> mechanism that will absolute-locktime expire "soon", in which case you
> have to close everything that hosts it.  But for example if a channel
> factory has channels A B C and only A has an HTLC that will expire
> soon, while the factory and A have to close, B and C can continue
> operation, even almost as if nothing happened to A.

Indeed this is something that I think we already mentioned back in the
duplex micropayment channel days, though it was a bit hidden and only
mentioned HTLCs (though the principle carries over for other structures
built on the raw update mechanism):

> The process simply involves one party creating the teardown
> transaction, both parties signing it and committing it to the
> blockchain. HTLC outputs which have not been removed by agreement can
> be copied over to the summary transaction such that the same timelocks
> and resolution rules apply.

Notice that in the case of eltoo the settlement transaction is already
the same as the teardown transaction in DMC.

>> 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 transaction to the layer one blockchain
>> * should be optimized for privacy and low on-chain fees paid for by parties entering and leaving the channel
>
> Assuming you mean that any owned funds will eventually have to be
> claimed onchain, 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 participants 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.

Indeed this is the first proposal I had back at the Milan spec meeting,
and you are right that it requires stashing the funds in a temporary
co-owned output to make sure the transition once we splice in is
atomic. Batching could help here, if we have 3 participants joining they
can coordinate to set the funds aside together and then splice-in at the
same time. The downside is the added on-chain transaction, and the fact
that the funds are not operational until they reach the required depth
(I don't think we can avoid this with the current security guarantees
provided by Bitcoin). Notice that there is still some uncertainty
regarding the confirmation of the splice-in even though the funds were
stashed ahead of time, and we may end up in a state where we assumed
that the splice-in will succeed, but the fees we attached turn out to be
too low. In this case we built a sandcastle that collapses due to our
foundation being washed away, and we'd have to go back and agree on
re-splicing with corrected fees (which a malicious participant might
sabotage) or hope the splice eventually confirms.

> 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 post-splice-in mechanism, until the splice-in tx is deeply
>     confirmed, after which the pre-splice-in version is discarded.
>       Updates need to be done on *both* mechanisms until then, and any
>     introduced money is "unuseable" anyway until the splice-in tx
>     confirms deeply since it would not exist in the pre-splice-in
>     mechanism yet.

This is the more complex variant we discussed during the last
face-to-face in Australia, and it seemed to me that people were mostly
in favor of doing it this way. It adds complexity since we maintain
multiple variants (making it almost un-implementable in LN-penalty),
however the reduced footprint, and the uncertainty regarding
confirmations in the first solution are strong arguments in favor of
this option.

> 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 offchain mechanism to another
> multiparticipant offchain, by publishing a single transaction onchain.
> It may be doable via some extension of my proposed ritual for changing
> membership set.

Aside from a bit more coordination I don't see any roadblocks to do
this, and it'd be an awesome improvement. It even allows sub-dust
transfers between channels, as long as the total funds in the channel
remain above dust :-)

>> 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.

Not necessarily. If we have an escape hatch in the scripts that allows
to spend any output attached to the settlement transaction by n-1
participants we could reclaim these into a new open right away. The
footprint would be 1 unilateral close, n outputs for participants, m
outputs for contracts built on top, and 1 open transaction that
recollects all outputs in which the non-responding participant is not a
co-signer. The main advantage is that we can avoid downtime.

Just spit-balling here, since it'd leak some of the update logic back
into the contracts built on top of the update mechanism, which for me is
enough to discard this idea again.

>> 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.

If we allow generic contracts on top of the base update mechanism it'll
be rather difficult to identify the beneficiary of an update, so it's
hard to know who should pay a fee. I'd rather argue that cooperating is
in the interest of all participants since they'd eventually want to
create an update of their own, and there is no upside to become
unresponsive.

Notice that the fees we leverage in LN are because we expose our funds
to the risk of not being available by allocating them to an HTLC, not
for the updates themselves. Since in the forwarding scenario we're only
exposing the funds of the forwarding nodes to this risk it's only
natural that they'd be the ones leveraging a fee, not the other
participants that simply sign off on the change.

>> 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
> everyone 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 signers.  Though such
> mechanisms already exist as theoretical constructs, so "just needs
> 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 mechanism, you are
> likely (approaching 100% probability) to own money in it.

Notice that we are negotiating whether or not to apply generic
transactions to a shared state. This also means that there is no direct
relationship between the ownership of an output and the ID signing off
on a change.

The privacy guarantees are identical to Bitcoin on-chain, with the one
caveat that we may identify the proposing participant, but we can defend
against this by mixing as you propose.

>> liveness:
>> * if signers know they will be offline, can they pre-sign updates that just 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 UTXO set:
>   * B-C channel
>   * B funds
>
> This allows B and C to manage the B-C channels and B funds without
> cooperation of A.  Then, later, when A returns online, the B-C
> offchain update mechanism is collapsed 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).

We could theoretically play this game, having each participant create
two updates with the same state-number at each update:

 1) A normal one that just keeps them in the contract
 2) A fallback splice all outputs they own (direct ones, HTLCs, ...) and
    putting the rest back into a channel without them.

In case of one user becoming inactive the others can sign the splice,
dropping the inactive participant and continue like nothing
happened. The worst case scenario is that the normal update gets
broadcast and confirmed instead, which means we are back to the
unilateral close that we'd have to do anyway without this mechanism.

Notice however that this only works if participants drop off one by one,
otherwise we get a combinatorial explosion for the fallback cases where
each combination of inactive participants needs to splice themselves
out. It also adds the complexity of having to identify which participant
is the co-owner of an output, otherwise I can claim ownership of an
unrelated output and force that to move on-chain by including it in my
fallback and then becoming unresponsive (added rounds of communication
can help here, but are cumbersome).

It may be a bit much added complexity for a small complexity to be
honest, hopefully this won't be needed too often :-)

Cheers,
Christian