From rich at gotenna.com Mon Sep 16 14:08:56 2019 From: rich at gotenna.com (Richard Myers) Date: Mon, 16 Sep 2019 16:08:56 +0200 Subject: [Lightning-dev] [bitcoin-dev] Reconciling the off-chain and on-chain models with eltoo In-Reply-To: References: <87mufhva0k.fsf@gmail.com> Message-ID: 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 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 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 mining, mining reward and difficulty adjustment * no equivalent concept for multi-party channels 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 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 The "block" that would need to be signed by the participants would actually > be a Decker-Russell-Osuntokun update+state transaction, and would commit to > the UTXO set rather than the transaction set. > Unless I misunderstand your meaning here. > Oops, ya, I did mean a "block" to be a particular Decker-Russell-Osuntokun update+state transaction. I think it will be useful to have these ideas in the back of my mind as I work on making eltoo scripts that support multi-party channels. -- Richard Myers Decentralized Applications Engineer, goTenna gotenna.com @gotenna -------------- next part -------------- An HTML attachment was scrubbed... URL: