Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2018-10-16 📝 Original message: ZmnSCPxj via ...

📅 Original date posted:2018-10-16
📝 Original message:
ZmnSCPxj via Lightning-dev <lightning-dev at 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