Fabrice Drouin [ARCHIVE] on Nostr: š
Original date posted:2018-02-05 š Original message: Hi, On 5 February 2018 at ...
š
Original date posted:2018-02-05
š Original message:
Hi,
On 5 February 2018 at 14:02, Christian Decker
<decker.christian at gmail.com> wrote:
> Hi everyone
>
> The feature bit is even, meaning that it is required from the peer,
> since we extend the `init` message itself, and a peer that does not
> support this feature would be unable to parse any future extensions to
> the `init` message. Alternatively we could create a new
> `set_gossip_timestamp` message that is only sent if both endpoints
> support this proposal, but that could result in duplicate messages being
> delivered between the `init` and the `set_gossip_timestamp` message and
> it'd require additional messages.
We chose the other aproach and propose to use an optional feature
> The reason I'm using timestamp and not the blockheight in the short
> channel ID is that we already use the timestamp for pruning. In the
> blockheight based timestamp we might ignore channels that were created,
> then not announced or forgotten, and then later came back and are now
> stable.
Just to be clear, you propose to use the timestamp of the most recent
channel updates to filter
the associated channel announcements ?
> I hope this rather simple proposal is sufficient to fix the short-term
> issues we are facing with the initial sync, while we wait for a real
> sync protocol. It is definitely not meant to allow perfect
> synchronization of the topology between peers, but then again I don't
> believe that is strictly necessary to make the routing successful.
>
> Please let me know what you think, and I'd love to discuss Pierre's
> proposal as well.
>
> Cheers,
> Christian
Our idea is to group channel announcements by "buckets", create a
filter for each bucket, exchange and use them to filter out channel
announcements.
We would add a new `use_channel_announcement_filters` optional feature
bit (7 for example), and a new `channel_announcement_filters` message.
When a node that supports channel announcement filters receives an
`init` message with the `use_channel_announcement_filters` bit set, it
sends back its channel filters.
When a node that supports channel announcement filters receives
a`channel_announcement_filters` message, it uses it to filter channel
announcements (and, implicitly ,channel updates) before sending them.
The filters we have in mind are simple:
- Sort announcements by short channel id
- Compute a marker height, which is `144 * ((now - 7 * 144) / 144)`
(we round to multiples of 144 to make sync easier)
- Group channel announcements that were created before this marker by
groups of 144 blocks
- Group channel announcements that were created after this marker by
groups of 1 block
- For each group, sort and concatenate all channel announcements short
channel ids and hash the result (we could use sha256, or the first 16
bytes of the sha256 hash)
The new `channel_announcement_filters` would then be a list of
(height, hash) pairs ordered by increasing heights.
This implies that implementation can easily sort announcements by
short channel id, which should not be very difficult.
An additional step could be to send all short channel ids for all
groups for which the group hash did not match. Alternatively we could
use smarter filters
The use case we have in mind is mobile nodes, or more generally nodes
which are often offline and need to resync very often.
Cheers,
Fabrice
Published at
2023-06-09 12:48:49Event JSON
{
"id": "1342c07b361f0f54ffa916c4d97c02c565db71b94bf5e2e6cf6de286a11e44a2",
"pubkey": "81c48ba46c211bc8fdb490d1ccfb03609c7ea090f8587ddca1c990676f09cfd3",
"created_at": 1686314929,
"kind": 1,
"tags": [
[
"e",
"c3f2627a28f3f44c130da7dce36c10040222ba86792d87bfb3e3dcd970958ae9",
"",
"root"
],
[
"e",
"ba0a7ac57e3e0f627a7c81cae73cf66f2d17721809b1a1b2e96636f9f34359e5",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "š
Original date posted:2018-02-05\nš Original message:\nHi,\n\nOn 5 February 2018 at 14:02, Christian Decker\n\u003cdecker.christian at gmail.com\u003e wrote:\n\u003e Hi everyone\n\u003e\n\u003e The feature bit is even, meaning that it is required from the peer,\n\u003e since we extend the `init` message itself, and a peer that does not\n\u003e support this feature would be unable to parse any future extensions to\n\u003e the `init` message. Alternatively we could create a new\n\u003e `set_gossip_timestamp` message that is only sent if both endpoints\n\u003e support this proposal, but that could result in duplicate messages being\n\u003e delivered between the `init` and the `set_gossip_timestamp` message and\n\u003e it'd require additional messages.\n\nWe chose the other aproach and propose to use an optional feature\n\n\u003e The reason I'm using timestamp and not the blockheight in the short\n\u003e channel ID is that we already use the timestamp for pruning. In the\n\u003e blockheight based timestamp we might ignore channels that were created,\n\u003e then not announced or forgotten, and then later came back and are now\n\u003e stable.\n\nJust to be clear, you propose to use the timestamp of the most recent\nchannel updates to filter\nthe associated channel announcements ?\n\n\u003e I hope this rather simple proposal is sufficient to fix the short-term\n\u003e issues we are facing with the initial sync, while we wait for a real\n\u003e sync protocol. It is definitely not meant to allow perfect\n\u003e synchronization of the topology between peers, but then again I don't\n\u003e believe that is strictly necessary to make the routing successful.\n\u003e\n\u003e Please let me know what you think, and I'd love to discuss Pierre's\n\u003e proposal as well.\n\u003e\n\u003e Cheers,\n\u003e Christian\n\nOur idea is to group channel announcements by \"buckets\", create a\nfilter for each bucket, exchange and use them to filter out channel\nannouncements.\n\nWe would add a new `use_channel_announcement_filters` optional feature\nbit (7 for example), and a new `channel_announcement_filters` message.\n\nWhen a node that supports channel announcement filters receives an\n`init` message with the `use_channel_announcement_filters` bit set, it\nsends back its channel filters.\n\nWhen a node that supports channel announcement filters receives\na`channel_announcement_filters` message, it uses it to filter channel\nannouncements (and, implicitly ,channel updates) before sending them.\n\nThe filters we have in mind are simple:\n- Sort announcements by short channel id\n- Compute a marker height, which is `144 * ((now - 7 * 144) / 144)`\n(we round to multiples of 144 to make sync easier)\n- Group channel announcements that were created before this marker by\ngroups of 144 blocks\n- Group channel announcements that were created after this marker by\ngroups of 1 block\n- For each group, sort and concatenate all channel announcements short\nchannel ids and hash the result (we could use sha256, or the first 16\nbytes of the sha256 hash)\n\nThe new `channel_announcement_filters` would then be a list of\n(height, hash) pairs ordered by increasing heights.\n\nThis implies that implementation can easily sort announcements by\nshort channel id, which should not be very difficult.\nAn additional step could be to send all short channel ids for all\ngroups for which the group hash did not match. Alternatively we could\nuse smarter filters\n\nThe use case we have in mind is mobile nodes, or more generally nodes\nwhich are often offline and need to resync very often.\n\nCheers,\nFabrice",
"sig": "880a76dbe03d8d524ec793be817bbf584a2ea82620be547f393dbdbbd07ee08f7c5e3308623e8e53c364af32e21e331632c7481de8f8d393b7227f1620f1d0ee"
}