Re: [Lightning-dev] [bitcoin-dev] Reconciling the off-chain and on-chain models with eltoo
ZmnSCPxj 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
Re: [Lightning-dev] [bitcoin-dev] Reconciling the off-chain and on-chain models with eltoo
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
Re: [Lightning-dev] [bitcoin-dev] Reconciling the off-chain and on-chain models with eltoo
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 ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] Reconciling the off-chain and on-chain models with eltoo
Good morning Richard, > I believe using the eltoo update scheme as a way to consolidate blocks of > off-chain transactions is an interesting idea worth exploring. > > ZmnSCPxj brings up some limitations on arbitrary outputs scripts in eltoo. > Although using CSV is more complicated and outputs must also use > SIGHASH_NOINPUT [1], the ability to have multiple party channels and the most > used types of scripts makes eltoo compelling compared to LN-Penalty for this > kind of application. I broadly agree. 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 multiple party aspect in particular introduces an interesting way to > unify concepts from different second layer protocols like federated > sidechains and statechains (ht. aakselrod [2]). > > Though the Statechains proposal relies on eltoo [3], I think what Christian > suggested does not try to solve the dynamic membership problem. That's why I > think of this as more an evolution of the channel factory paper towards > something like a federated sidechain. > > > I think this reconciliation between the off-chain model and the on-chain > > model, with many concepts cleanly mapping from one context to another > > (state outputs = UTXO, off-chain update = on-chain transactions, > > cut-through = confirmation, operation batching = block creation) is > > rather nice :-) > > One additional concept that could be new to this off-chain blockchain model > would be something like batched multi-party loop-in/out. In a Schnorr/Taproot > world you could add signers/inputs and remove signers/outputs with a single > multi-signature negotiated off-chain. You'd still like to limit these onchain > txs, even if they are small, but updating channels periodically seems like a > straight forward way to address the dynamic membership problem. Indeed. Such a change-in-membership transaction would be a 1-input 1-output transaction, and with use of n-of-n MuSig would be as small (and as private, modulo the fact that you are coordinating this with a bunch of other participants) as a single-sig user making a 1-input 1-output transaction (which generally is not very private because such transactions are usually "send-to-self" and changing membership generally means ownership does not actually change much). The cost of this transaction would be small (certainly smaller than the update+state transactions needed in Decker-Russell-Osuntokun) For setting this up, it might be useful to have the below ritual. This assumes only a change in the membership set is desired, without a simultaneous change in the UTXO set. 1. Create a new update+state transaction for the current Decker-Russell-Osuntokun mechanism. The state transaction pays out to a single output paying to the new membership set rather than the current UTXO set of the mechanism. Do *not* sign this yet. Call this the "final" update+state transaction. 2. Create a new Decker-Russell-Osuntokun mechanism initial update+state transaction. This pays out to the current UTXO set of the previous mechanism. This will spend from the new membership set. Completely sign these transactions. * The update transaction can spend the above "final" transaction, as it is `SIGHASH_NOINPUT`. 3. Sign the final update+state transaction of the previous Decker-Russell-Osuntokun mechanism. Do *not* broadcast the update+state transaction yet. 4. Create and sign the membership-change onchain transaction. This spends the current onchain funding transaction output and outputs to the same new membership set. Broadcast this onchain. The above ritual ensures that, after step 3 completes, the mechanism can continue operating without waiting for onchain activity to complete. It ensures that, even if the membership-change onchain transaction becomes invalid later (by somebody bribing a miner to publish a previous update transaction from the older membership set), we will still enter an update that will eventually put the new membership set onchain. This reduces the critical path to only steps 1 to 3, and we can continue operating with the new membership set as soon as step 3 completes and we do not need to wait for the membership-change transaction to be deeply-confirmed in order to use the new membership set mechanism. However, it has the drawback that, until the membership-change onchain transaction is deeply-confirmed onchain, the CSV parameter is temporarily doubled (as there is the possibility that the previous mechanism is closed). Also, the mechanism cannot be mutually closed until the membership-change onchain transaction is deeply-confirmed, as there is no stable txid we can spend from (we would strongly prefer to use `SIGHASH_ALL` for cooperative closes to improve
Re: [Lightning-dev] [bitcoin-dev] Reconciling the off-chain and on-chain models with eltoo
I believe using the eltoo update scheme as a way to consolidate blocks of off-chain transactions is an interesting idea worth exploring. ZmnSCPxj brings up some limitations on arbitrary outputs scripts in eltoo. Although using CSV is more complicated and outputs must also use SIGHASH_NOINPUT [1], the ability to have multiple party channels and the most used types of scripts makes eltoo compelling compared to LN-Penalty for this kind of application. The multiple party aspect in particular introduces an interesting way to unify concepts from different second layer protocols like federated sidechains and statechains (ht. aakselrod [2]). Though the Statechains proposal relies on eltoo [3], I think what Christian suggested does not try to solve the dynamic membership problem. That's why I think of this as more an evolution of the channel factory paper towards something like a federated sidechain. I think this reconciliation between the off-chain model and the on-chain > model, with many concepts cleanly mapping from one context to another > (state outputs = UTXO, off-chain update = on-chain transactions, > cut-through = confirmation, operation batching = block creation) is > rather nice :-) One additional concept that could be new to this off-chain blockchain model would be something like batched multi-party loop-in/out. In a Schnorr/Taproot world you could add signers/inputs and remove signers/outputs with a single multi-signature negotiated off-chain. You'd still like to limit these onchain txs, even if they are small, but updating channels periodically seems like a straight forward way to address the dynamic membership problem. I guess this all gets back to how to design an off-chain protocol for managing these negotiations. Ultimately I can imagine a sort of multi-party eltoo based 'signet' with the same RPC interface, but different transaction validation and block creation logic. Perhaps there would be a new message where the channel parties would add their signature before forwarding a valid block, and the block wouldn't be built on until all parties had signed. [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-August/001383.html [2] https://twitter.com/stile65/status/1171030423394078720 [3] https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39 ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] Reconciling the off-chain and on-chain models with eltoo
Good morning Christian, This is effectively transaction cut-through. I mention this in passing here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001986.html > I observe that one may consider any offchain system a specialization of an > offchain transaction cut-through system. > Thus, one may model changes to the offchain system state as the creation of > some transactions, followed by a cut-through of those transactions into the > new state. Basically, we can send a transaction that spends a subset of the current state txos to the participants in the update mechanism. Then the participants can agree that it is a valid spend of the specified state txos, and agree to sign a new state with the spent txos deleted and the new txos of the transaction inserted. Disagreement at this point is essentially a "if your tx is so valid why do you not try it on the base blockchain layer huh?" challenge and is basically an invitation to close it unilaterally and enforce the contract on the blockchain. The "difficulty" in Poon-Dryja is not very onerous in my opinion; see the sketch here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-August/001383.html Of note is that any contract with a relative locktime requirement would not make sense to maintain offchain. If one wishes to select a relative locktime relative to the current moment, one can quite easily compute an absolute timelock. Another note, is that contracts with timelocks need to be enforced onchain on or before the timelock. Under Decker-Russell-Osuntokun the onchain enforcement needs to be triggered early according to the CSV security parameter; this is not an issue under Poon-Dryja (as the CSV is in a later transaction). Under Decker-Russell-Osuntokun due to the use of `SIGHASH_NOINPUT` and the non-stable txids involved, any transaction you wish to transport in the offchain update mechanism needs to also be signed under `SIGHASH_NOINPUT`, but again this is not onerous. In any case it is "only" a matter of tradeoffs one is willing to work under anyway, and Decker-Russell-Osuntokun is very cool and uses `nLockTime` and `OP_CHECKLOCKTIMEVERIFY` in a very clever way. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
