Good morning Richards, and list,
> Thanks for the feedback ZmnSCPxj.
>
> > I imagine a future where most people do not typically have single-signer
> > ownership of coins onchain, but are instead share-owners of coins, with
> > single-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.
>
> Some aspects of multi-party Decker-Russell-Osuntokun channels have analogs 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
> updates
>
> genesis block:
> * the initial 'funding' transaction, aka outpoint of the commitment
> transaction, 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 complete
> set of channel parties.
>
> mempool:
> * the set of proposals for specific changes to the set of outputs from the
> 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 layer
> 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 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.
>
> 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.
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.
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.
>
> 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
> transaction to the layer one blockchain
> * should be optimized for privacy and low on-chain fees paid for by parties
> 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
> outputs from the most recent channel output state
> * script timeouts determine when channel parties should uncooperatively close
> the channel if not all parties have signed the next 'update' and 'settlement'
> 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 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.
>
> 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).
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
