Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2021-08-12 📝 Original message: Sorry this took so long. ...
📅 Original date posted:2021-08-12
📝 Original message:
Sorry this took so long.
https://github.com/lightningnetwork/lightning-rfc/pull/895
This changed quite a bit, based on discussion here and more coherent
thinking.
1. You can simply send funding_locked early, no feature needed.
2. It's a bit useless unless you are the (sole) funder or you trust the
other side. Without that, you can neither accept payments nor route
them; in theory if they used push_msat you could send payments out,
but that seems a niche case.
3. We do want to know the short_channel_id they're going to use for the
channel, so we can add it to routehints for incoming payments.
Adding the scid is nice anyway, for chainsplit scenarios.
Here is the new text, a little formatted:
1. `tlv_stream`: `funding_locked_tlvs`
2. types:
1. type: 1 (`short_channel_id`)
2. data:
* [`short_channel_id`:`short_channel_id`]
#### Requirements
The sender:
...
- SHOULD set `short_channel_id`
- if it is the sole contributor to the funding transaction, or
has reason to trust the peer:
- MAY send `funding_locked` before the funding transaction
has reached `minimum_depth`
- MAY set `short_channel_id` to a fake value, if it will
route payments to that `short_channel_id`.
- otherwise:
- MUST wait until the funding transaction has reached
`minimum_depth` before sending this message.
- SHOULD re-transmit `funding_locked` if the
`short_channel_id` for this chanel has changed.
...
The receiver:
- SHOULD ignore the `funding_locked` if it knows the
`short_channel_id` of the channel and it differs from the
value in `funding_locked`.
...
Nodes which have funded the channel or trust their peers to have done,
can simply start using the channel instantly by sending
`funding_locked`. This raises the problem of how to use this new
channel in route hints, since it does not yet have a block number.
For this reason, a convincing fake number can be use; when the real
funding transaction is finally mined, it can re-send `funding_locked`
with the real value.
📝 Original message:
Sorry this took so long.
https://github.com/lightningnetwork/lightning-rfc/pull/895
This changed quite a bit, based on discussion here and more coherent
thinking.
1. You can simply send funding_locked early, no feature needed.
2. It's a bit useless unless you are the (sole) funder or you trust the
other side. Without that, you can neither accept payments nor route
them; in theory if they used push_msat you could send payments out,
but that seems a niche case.
3. We do want to know the short_channel_id they're going to use for the
channel, so we can add it to routehints for incoming payments.
Adding the scid is nice anyway, for chainsplit scenarios.
Here is the new text, a little formatted:
1. `tlv_stream`: `funding_locked_tlvs`
2. types:
1. type: 1 (`short_channel_id`)
2. data:
* [`short_channel_id`:`short_channel_id`]
#### Requirements
The sender:
...
- SHOULD set `short_channel_id`
- if it is the sole contributor to the funding transaction, or
has reason to trust the peer:
- MAY send `funding_locked` before the funding transaction
has reached `minimum_depth`
- MAY set `short_channel_id` to a fake value, if it will
route payments to that `short_channel_id`.
- otherwise:
- MUST wait until the funding transaction has reached
`minimum_depth` before sending this message.
- SHOULD re-transmit `funding_locked` if the
`short_channel_id` for this chanel has changed.
...
The receiver:
- SHOULD ignore the `funding_locked` if it knows the
`short_channel_id` of the channel and it differs from the
value in `funding_locked`.
...
Nodes which have funded the channel or trust their peers to have done,
can simply start using the channel instantly by sending
`funding_locked`. This raises the problem of how to use this new
channel in route hints, since it does not yet have a block number.
For this reason, a convincing fake number can be use; when the real
funding transaction is finally mined, it can re-send `funding_locked`
with the real value.