📅 Original date posted:2021-07-01
📝 Original message:
Thanks!
On 6/29/21 01:34, Rusty Russell wrote:
> Hi all!
>
> John Carvalo recently pointed out that not every implementation
> accepts zero-conf channels, but they are useful. Roasbeef also recently
> noted that they're not spec'd.
>
> How do you all do it? Here's a strawman proposal:
>
> 1. Assign a new feature bit "I accept zeroconf channels".
> 2. If both negotiate this, you can send update_add_htlc (etc) *before*
> funding_locked without the peer getting upset.
Does it make sense to negotiate this per-direction in the channel init message(s)? There's a pretty different threat
model between someone spending a dual-funded or push_msat balance vs someone spending a classic channel-funding balance.
> 3. Nodes are advised *not* to forward HTLCs from an unconfirmed channel
> unless they have explicit reason to trust that node (they can still
> send *out* that channel, because that's not their problem!).
>
> It's a pretty simple change, TBH (this zeroconf feature would also
> create a new set of channel_types, altering that PR).
>
> I can draft something this week?
>
> Thanks!
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
Matt Corallo [ARCHIVE] /
npub1e4…jxmcu
2023-06-09 13:03:00
in reply to nevent1q…75tw
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuPublished at
2023-06-09 13:03:00Event JSON
{
"id": "9ddadc9dfc0a085fafba10da880e1b7b830d6eff8f554986153a1ad334b1f998",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686315780,
"kind": 1,
"tags": [
[
"e",
"5b939faaa8b1530f86472b2f9c4dc55b9f8dea6f71ca80ce3563af20d2a12ae1",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2021-07-01\n📝 Original message:\nThanks!\n\nOn 6/29/21 01:34, Rusty Russell wrote:\n\u003e Hi all!\n\u003e \n\u003e John Carvalo recently pointed out that not every implementation\n\u003e accepts zero-conf channels, but they are useful. Roasbeef also recently\n\u003e noted that they're not spec'd.\n\u003e \n\u003e How do you all do it? Here's a strawman proposal:\n\u003e \n\u003e 1. Assign a new feature bit \"I accept zeroconf channels\".\n\u003e 2. If both negotiate this, you can send update_add_htlc (etc) *before*\n\u003e funding_locked without the peer getting upset.\n\nDoes it make sense to negotiate this per-direction in the channel init message(s)? There's a pretty different threat \nmodel between someone spending a dual-funded or push_msat balance vs someone spending a classic channel-funding balance.\n\n\u003e 3. Nodes are advised *not* to forward HTLCs from an unconfirmed channel\n\u003e unless they have explicit reason to trust that node (they can still\n\u003e send *out* that channel, because that's not their problem!).\n\u003e \n\u003e It's a pretty simple change, TBH (this zeroconf feature would also\n\u003e create a new set of channel_types, altering that PR).\n\u003e \n\u003e I can draft something this week?\n\u003e \n\u003e Thanks!\n\u003e Rusty.\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",
"sig": "a53d344c89474163006c227967bdd6733f65049f10b3e188c38157386a5bc3fc7795ae8acdcb01c727090037090cd8f921f340b918b923f419ec8c6eac77885c"
}