> > This is one of the cases where a simpler solution (relatively > speaking ^^) is to be preferred imho, allowing for future > iterations. >
I think we should strive to splice in 1 on-chain tx, as if not the biggest benefit really is lost compared to just closing and reopening the channel. Complexity wise I don't think it will be that much to gain from the 2-tx proposal as (if I understand the proposal correctly) there will be even more transaction types with new scripts to code up and maintain. On Tue, Oct 16, 2018 at 5:38 AM Christian Decker <decker.christ...@gmail.com> wrote: > 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 >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
