📅 Original date posted:2021-06-29
📝 Original message:
Hi Rusty,
On the eclair side, we instead send `funding_locked` as soon as we
see the funding tx in the mempool.
But I think your proposal would work as well.
We may want to defer sending `announcement_signatures` until
after the funding tx has been confirmed? What `min_depth` should
we use here? Should we keep a non-zero value in `accept_channel`
or should it be zero?
Cheers,
Bastien
Le mar. 29 juin 2021 à 07:34, Rusty Russell <rusty at rustcorp.com.au> a
écrit :
> 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.
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210629/a9f7eb76/attachment.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:02:46
in reply to nevent1q…u8gm
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:02:46Event JSON
{
"id": "5800281c7c82341f13b1d7ad3fa97a5545e561e1cdd9033fda4388806ce3e076",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315766,
"kind": 1,
"tags": [
[
"e",
"3799a67fd30858efdd7d44ee6820ce9de24dd896f00c609e7e8a5782f9aa9e6b",
"",
"root"
],
[
"e",
"5c3070b666880c094a0d45015c3e1f08bbdcb11593e5b946d717ab4d908a7583",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2021-06-29\n📝 Original message:\nHi Rusty,\n\nOn the eclair side, we instead send `funding_locked` as soon as we\nsee the funding tx in the mempool.\n\nBut I think your proposal would work as well.\n\nWe may want to defer sending `announcement_signatures` until\nafter the funding tx has been confirmed? What `min_depth` should\nwe use here? Should we keep a non-zero value in `accept_channel`\nor should it be zero?\n\nCheers,\nBastien\n\n\n\nLe mar. 29 juin 2021 à 07:34, Rusty Russell \u003crusty at rustcorp.com.au\u003e a\nécrit :\n\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\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\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210629/a9f7eb76/attachment.html\u003e",
"sig": "920d86d672cb410d69e1595413df76a0d2bc6a0d877c70e6b6cf7178624f877d7473e90930656775c5af4ea542aa683d89ebee37db9ff47edda699a1652bf69d"
}