📅 Original date posted:2021-06-30
📝 Original message:
>
> - MUST NOT send `announcement_signatures` messages until `funding_locked`
> has been sent and received AND the funding transaction has at least
> six confirmations.
>
> So still compliant there?
>
Great, I hadn't spotted that one, so we're good on the
`announcement_signatures` side.
I'm wondering if `option_zeroconf` implies that we should set `min_depth =
0` in
`accept_channel`, since that's the number of confirmations before we can
send
`funding_locked`.
We need a signal that this channel uses zero-conf, and the two obvious
choices are:
- set `min_depth = 0`
- use a `channel_type` that sets `option_zeroconf`
I think the second option is better, this way we can keep a "normal"
`min_depth` set
and when we send `funding_locked`, we know that the channel is now
perfectly safe
to use (out of the zero-conf zone).
Cheers,
Bastien
Le mer. 30 juin 2021 à 02:09, Rusty Russell <rusty at rustcorp.com.au> a
écrit :
> Bastien TEINTURIER <bastien at acinq.fr> writes:
> > 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.
>
> This would be backward compatible, I think. Eclair would send
> `funding_locked`, which is perfectly legal, but a normal peer would
> still wait for confirms before also sending `funding_locked`; it's
> just that option_zeroconf_channels would mean it doesn't have to
> wait for that before sending HTLCs?
>
> > 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?
>
> You can't send it before you know the channel_id, so it has to be at
> least 1. Spec says:
>
> - MUST NOT send `announcement_signatures` messages until
> `funding_locked`
> has been sent and received AND the funding transaction has at least
> six confirmations.
>
> So still compliant there?
>
> Cheers,
> Rusty.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210630/f022c575/attachment.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:02:46
in reply to nevent1q…ejyv
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:02:46Event JSON
{
"id": "fdbf5788850e78c3f2b2d2e4987f3f186d8e0b771427c090e7c423c659825837",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315766,
"kind": 1,
"tags": [
[
"e",
"3799a67fd30858efdd7d44ee6820ce9de24dd896f00c609e7e8a5782f9aa9e6b",
"",
"root"
],
[
"e",
"d1541a9a4be286a8d01648849455d9093832858bff5152d06ef39ca1bb3bab32",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2021-06-30\n📝 Original message:\n\u003e\n\u003e - MUST NOT send `announcement_signatures` messages until `funding_locked`\n\u003e has been sent and received AND the funding transaction has at least\n\u003e six confirmations.\n\u003e\n\u003e So still compliant there?\n\u003e\n\nGreat, I hadn't spotted that one, so we're good on the\n`announcement_signatures` side.\n\nI'm wondering if `option_zeroconf` implies that we should set `min_depth =\n0` in\n`accept_channel`, since that's the number of confirmations before we can\nsend\n`funding_locked`.\n\nWe need a signal that this channel uses zero-conf, and the two obvious\nchoices are:\n\n - set `min_depth = 0`\n - use a `channel_type` that sets `option_zeroconf`\n\nI think the second option is better, this way we can keep a \"normal\"\n`min_depth` set\nand when we send `funding_locked`, we know that the channel is now\nperfectly safe\nto use (out of the zero-conf zone).\n\nCheers,\nBastien\n\n\n\nLe mer. 30 juin 2021 à 02:09, Rusty Russell \u003crusty at rustcorp.com.au\u003e a\nécrit :\n\n\u003e Bastien TEINTURIER \u003cbastien at acinq.fr\u003e writes:\n\u003e \u003e Hi Rusty,\n\u003e \u003e\n\u003e \u003e On the eclair side, we instead send `funding_locked` as soon as we\n\u003e \u003e see the funding tx in the mempool.\n\u003e \u003e\n\u003e \u003e But I think your proposal would work as well.\n\u003e\n\u003e This would be backward compatible, I think. Eclair would send\n\u003e `funding_locked`, which is perfectly legal, but a normal peer would\n\u003e still wait for confirms before also sending `funding_locked`; it's\n\u003e just that option_zeroconf_channels would mean it doesn't have to\n\u003e wait for that before sending HTLCs?\n\u003e\n\u003e \u003e We may want to defer sending `announcement_signatures` until\n\u003e \u003e after the funding tx has been confirmed? What `min_depth` should\n\u003e \u003e we use here? Should we keep a non-zero value in `accept_channel`\n\u003e \u003e or should it be zero?\n\u003e\n\u003e You can't send it before you know the channel_id, so it has to be at\n\u003e least 1. Spec says:\n\u003e\n\u003e - MUST NOT send `announcement_signatures` messages until\n\u003e `funding_locked`\n\u003e has been sent and received AND the funding transaction has at least\n\u003e six confirmations.\n\u003e\n\u003e So still compliant there?\n\u003e\n\u003e Cheers,\n\u003e Rusty.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210630/f022c575/attachment.html\u003e",
"sig": "a88f2ee4660088d0a94cf23eac9a98b4c1610634a5c42c6ec3f37fc7ceaeda78f13fa29da6060300f65f5135b8e6f18066ce46ede19ae88559c2f3f86f0416da"
}