Johan Torås Halseth [ARCHIVE] on Nostr: 📅 Original date posted:2018-10-16 📝 Original message: > > This is one of the ...
📅 Original date posted:2018-10-16
📝 Original message:
>
> 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.christian at gmail.com>
wrote:
> 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
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181016/5a6baacf/attachment.html>;
📝 Original message:
>
> 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.christian at gmail.com>
wrote:
> 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
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181016/5a6baacf/attachment.html>;