📅 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>;
Johan Torås Halseth [ARCHIVE] /
npub1pp…hs2fw
2023-06-09 12:51:47
in reply to nevent1q…vzlu
Author Public Key
npub1ppn2nhlfdzkw9gw0ytljpef5dpyzsxzw8ffcyykamt32hw6pge0smhs2fwPublished at
2023-06-09 12:51:47Event JSON
{
"id": "a0f7e240d9939352e40dbc73f8315c95f2fd46c912955118279a33d0b27aec3a",
"pubkey": "0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f",
"created_at": 1686315107,
"kind": 1,
"tags": [
[
"e",
"d33837a10906296cdab5e5ff391835a12bd3f5d27bdac072961b20f094855a4d",
"",
"root"
],
[
"e",
"589ea9182ee0d00e6cf86254e4917d5bb64bb74172cebadb73bd5396593f96ab",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "📅 Original date posted:2018-10-16\n📝 Original message:\n\u003e\n\u003e This is one of the cases where a simpler solution (relatively\n\u003e speaking ^^) is to be preferred imho, allowing for future\n\u003e iterations.\n\u003e\n\nI think we should strive to splice in 1 on-chain tx, as if not the biggest\nbenefit really is lost compared to just closing and reopening the channel.\n\nComplexity wise I don't think it will be that much to gain from the 2-tx\nproposal as (if I understand the proposal correctly) there will be even\nmore transaction types with new scripts to code up and maintain.\n\nOn Tue, Oct 16, 2018 at 5:38 AM Christian Decker \u003cdecker.christian at gmail.com\u003e\nwrote:\n\n\u003e ZmnSCPxj via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e\n\u003e writes:\n\u003e\n\u003e \u003e\u003e One thing that I think we should lift from the multiple funding output\n\u003e \u003e\u003e approach is the \"pre seating of inputs\". This is cool as it would allow\n\u003e \u003e\u003e clients to generate addresses, that others could deposit to, and then\n\u003e have\n\u003e \u003e\u003e be spliced directly into the channel. Public derivation can be used,\n\u003e along\n\u003e \u003e\u003e with a script template to do it non-interactively, with the clients\n\u003e picking\n\u003e \u003e\u003e up these deposits, and initiating a splice in as needed.\n\u003e \u003e\n\u003e \u003e I am uncertain what this means in particular, but let me try to\n\u003e \u003e restate what you are talking about in other terms:\n\u003e \u003e\n\u003e \u003e 1. Each channel has two public-key-derivation paths (BIP32) to create\n\u003e onchain addresses. One for each side of the channel.\n\u003e \u003e 2. When somebody sends to one of the onchain addresses in the path,\n\u003e their client detects this.\n\u003e \u003e 3. The client initiates a splice-in automatically from this UTXO paying\n\u003e to that address into the channel.\n\u003e \u003e\n\u003e \u003e It seems to me naively that the above can be done by the client\n\u003e \u003e software without any modifications to the Lightning Network BOLT\n\u003e \u003e protocol, as long as the BOLT protocol is capable of supporting *some*\n\u003e \u003e splice-in operation, i.e. it seems to be something that a client\n\u003e \u003e software can implement as a feature without requiring a BOLT change.\n\u003e \u003e Or is my above restatement different from what you are talking about?\n\u003e \u003e\n\u003e \u003e How about this restatement?\n\u003e \u003e\n\u003e \u003e 1. Each channel has two public-key-derivation paths (BIP32) to create\n\u003e onchain addresses. One for each side of the channel.\n\u003e \u003e 2. The base of the above is actually a combined private-public keypair\n\u003e of both sides (e.g. created via MuSig or some other protocol). Thus the\n\u003e addresses require cooperation of both parties to spend.\n\u003e \u003e 3. When somebody sends to one of the onchain addresses in the path,\n\u003e their client detects this.\n\u003e \u003e 4. The client updates the current transaction state, such that the new\n\u003e commit transaction has two inputs ( the original channel transaction and\n\u003e the new UTXO).\n\u003e \u003e\n\u003e \u003e The above seems unsafe without trust in the other peer, as, the other\n\u003e \u003e peer can simply refuse to create the new commit transaction. Since\n\u003e \u003e the address requires both parties to spend, the money cannot be spent\n\u003e \u003e and there is no backoff transaction that can be used. But maybe you\n\u003e \u003e can describe some mechanism to ensure this, if this is what is meant\n\u003e \u003e instead?\n\u003e\n\u003e This could easily be solved by making the destination address a Taproot\n\u003e address, which by default is just a 2-of-2, but in the uncooperative\n\u003e case it can reveal the script it commits to, which is just a timelocked\n\u003e refund that requires a single-sig. The only problem with this is that\n\u003e the refund would be non-interactive, and so the entirety of the funds,\n\u003e that may be from a third-party, need to be claimed by one endpoint,\n\u003e i.e., there is no splitting the funds in case of an uncollaborative\n\u003e refund. Not sure how important that is though, since I don't think\n\u003e third-party funds will come from unrelated parties, e.g., most of these\n\u003e funds will come from an on-chain wallet that is under the control of\n\u003e either parties so the refund should go back to that party anyway.\n\u003e\n\u003e Cheers,\n\u003e Christian\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181016/5a6baacf/attachment.html\u003e",
"sig": "9d439aa2e127dc0f7dc6be5481d5b70dbfbaab33997549fe159d1cf81eae4cc0bc10c4912403b924a6d123cc9a8cde2235b556b208ec1a41089bd428b1d1f9f7"
}