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] Miniscript on LN (was: eltoo implementation in Bitcoin functional test framework)
Good morning all, I saw also this thread: https://www.reddit.com/r/Bitcoin/comments/d19n6l/miniscript_streamlined_bitcoin_scripting/ezjb4ec/ Regards, ZmnSCPxj > Good morning David, > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Saturday, September 7, 2019 2:43 AM, David A. Harding d...@dtrt.org wrote: > > > > Good morning list, > > > I do not see much point in using miniscript for Lightning unless we > > > decide to support transporting arbitrary contracts, as here: > > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-August/001383.html > > > Otherwise, it would be far easier implementation-wise, to just have > > > carefully-coded SCRIPT to transport HTLCs. > > > > Something that has been impressed upon me is that using miniscript to > > create optimized Bitcoin scripts is perhaps not its primary use. > > Miniscript also makes it easy for any miniscript-aware wallet to figure > > out how to create a valid witness for the miniscript (if the wallet has the > > necessary private keys, hash pre-images, and a function to satisfy any > > timelocks). > > For example, right now Pieter Wuille is working on incorporating > > miniscript into Bitcoin Core. If there was then a miniscript for the > > current LN scripts and someone imported their keys and invoice > > pre-images[1] into their Bitcoin Core wallet, then Bitcoin Core could > > sign for their LN update and settlement transactions. E.g., the > > C-Lightning "HSM" module could become a thin wrapper around Bitcoin > > Core's wallet (or any other miniscript-aware wallet). > > This seems an important point-of-fact. > Thank you for informing this. > > It seems, there are some complications here, as the signing keys involved in > various Lightning scripts are derived from base keys. > Thus, it seems to require also to somehow embed how the derivation is done. > BOLT #3 has detail: > https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#key-derivation > Thus the wallet not only needs to know the basepoint secret, but also the > per-commitment-point for the specific state being signed for. > > Still, it should be doable, and I now see the value of using Miniscript for > Lightning scripts. > > Regards, > ZmnSCPxj > > > Later, other wallets such as hardware wallets and exchange HSMs may add > > support for libminiscript, making it easy for LN nodes to delegate > > signing to outside devices without anyone having to change the code of > > those hard-to-change devices. > > Even later than that, y'all may change the LN script either slightly or > > dramatically If both the old script and the new script are miniscript > > based, then maybe none of the wallets that already supported miniscript > > will need to update their signing code---libminiscript will tell them > > what data they need to provide for the witness and, as long as they have > > functions capable of retrieving or generating that data, they'll > > automatically know how to create a witness for the new miniscript. > > Finally, someday consensus changes like taproot and > > SIGHASH_NOINPUT/ANYPREVOUT may be activated. If libminiscript is > > updated for that change, getting wallets to support those changes may be > > as easy as updating their bundled libminiscript version. > > In summary, miniscript does help you produce machine-optimized scripts > > and analyze them (and that's a pretty nifty feature by itself), but > > miniscript's true potential may come from allowing any wallet to sign for > > any miniscript-compatible script, freeing developers from having to > > write lots of sensitive signing code or heavily coordinating changes > > across different software (as is common in LN). > > -Dave > > [1] I don't think this is currently possible, but adding support for it > > using output script descriptors might not be difficult. > > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
