ZmnSCPxj via Lightning-dev <lightning-dev@lists.linuxfoundation.org> writes:
>> One thing that I think we should lift from the multiple funding output >> approach is the "pre seating of inputs". This is cool as it would allow >> clients to generate addresses, that others could deposit to, and then have >> be spliced directly into the channel. Public derivation can be used, along >> with a script template to do it non-interactively, with the clients picking >> up these deposits, and initiating a splice in as needed. > > I am uncertain what this means in particular, but let me try to > restate what you are talking about in other terms: > > 1. Each channel has two public-key-derivation paths (BIP32) to create > onchain addresses. One for each side of the channel. > 2. When somebody sends to one of the onchain addresses in the path, their > client detects this. > 3. The client initiates a splice-in automatically from this UTXO paying to > that address into the channel. > > It seems to me naively that the above can be done by the client > software without any modifications to the Lightning Network BOLT > protocol, as long as the BOLT protocol is capable of supporting *some* > splice-in operation, i.e. it seems to be something that a client > software can implement as a feature without requiring a BOLT change. > Or is my above restatement different from what you are talking about? > > How about this restatement? > > 1. Each channel has two public-key-derivation paths (BIP32) to create > onchain addresses. One for each side of the channel. > 2. The base of the above is actually a combined private-public keypair of > both sides (e.g. created via MuSig or some other protocol). Thus the > addresses require cooperation of both parties to spend. > 3. When somebody sends to one of the onchain addresses in the path, their > client detects this. > 4. The client updates the current transaction state, such that the new > commit transaction has two inputs ( the original channel transaction and the > new UTXO). > > The above seems unsafe without trust in the other peer, as, the other > peer can simply refuse to create the new commit transaction. Since > the address requires both parties to spend, the money cannot be spent > and there is no backoff transaction that can be used. But maybe you > can describe some mechanism to ensure this, if this is what is meant > instead? This could easily be solved by making the destination address a Taproot address, which by default is just a 2-of-2, but in the uncooperative case it can reveal the script it commits to, which is just a timelocked refund that requires a single-sig. The only problem with this is that the refund would be non-interactive, and so the entirety of the funds, that may be from a third-party, need to be claimed by one endpoint, i.e., there is no splitting the funds in case of an uncollaborative refund. Not sure how important that is though, since I don't think third-party funds will come from unrelated parties, e.g., most of these funds will come from an on-chain wallet that is under the control of either parties so the refund should go back to that party anyway. Cheers, Christian _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev