From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Richard Myers <rich@gotenna•com>
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
Date: Wed, 18 Sep 2019 05:28:38 +0000 [thread overview]
Message-ID: <ccotpmyCthtmIqi2aqT6DaWAF_BEYSQh5vPnz9nmVu-zemfA3utpaDsb1Xn1jqaIXlRUzHwS7UlMHR_LJE27pzARxuUCu7PM6w6MEXrL8p8=@protonmail.com> (raw)
In-Reply-To: <CACJVCg+wuODW-NoNoAvwdcnr0gZbLFrDyip6-0unw9hFu2-oOg@mail.gmail.com>
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
next prev parent reply other threads:[~2019-09-18 5:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-06 13:18 [bitcoin-dev] " Christian Decker
2019-09-06 14:32 ` ZmnSCPxj
[not found] ` <CACJVCgLe-hmSoPZtsXBMDToqa-rh04EroppO14zBQqEjdWacQw@mail.gmail.com>
2019-09-10 1:28 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
[not found] ` <CACJVCg+wuODW-NoNoAvwdcnr0gZbLFrDyip6-0unw9hFu2-oOg@mail.gmail.com>
2019-09-18 5:28 ` ZmnSCPxj [this message]
2019-09-18 13:44 ` Christian Decker
2019-09-19 2:01 ` ZmnSCPxj
2019-09-19 10:26 ` Christian Decker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='ccotpmyCthtmIqi2aqT6DaWAF_BEYSQh5vPnz9nmVu-zemfA3utpaDsb1Xn1jqaIXlRUzHwS7UlMHR_LJE27pzARxuUCu7PM6w6MEXrL8p8=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
--cc=rich@gotenna$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox