📅 Original date posted:2018-02-08
📝 Original message:
Hi all!
Finally catching up. I prefer the simplicity of the timestamp
mechanism, with a more ambitious mechanism TBA.
Deployment suggestions:
1. This should be a feature bit pair. As usual, even == 'support this or
disconnect', and odd == 'ok even if you don't understand'.
2. This `timestamp_routing_sync`? feature overrides `initial_routing_sync`.
That lets you decide what old nodes do, using the older
`initial_routing_sync` option. Similarly, a future `fancy_sync` would
override `timestamp_routing_sync`.
3. We can append an optional 4 byte `routing_sync_timestamp` field to to
`init` without issues, since all lengths in there are explicit. If you
don't offer the `timestamp_sync` feature, this Must Be Zero (for appending
more stuff in future).
Now, as to the proposal specifics.
I dislike the re-transmission of all old channel_announcement and
node_announcement messages, just because there's been a recent
channel_update. Simpler to just say 'send anything >=
routing_sync_timestamp`.
Background: c-lightning internally keeps an tree of gossip in the order
we received them, keeping a 'current' pointer for each peer. This is
very efficient (though we don't remember if a peer sent us a gossip msg
already, so uses twice the bandwidth it could).
But this isn't *quite* the same as timestamp order, so we can't just set
the 'current' pointer based on the first entry >=
`routing_sync_timestamp`; we need to actively filter. This is still a
simple traverse, however, skipping over any entry less than
routing_sync_timestamp.
OTOH, if we need to retransmit announcements, when do we stop
retransmitting them? If a new channel_update comes in during this time,
are we still to dump the announcements? Do we have to remember which
ones we've sent to each peer?
If missing announcements becomes a problem, we could add a simple query
message: I think this is going to be needed for any fancy scheme anyway.
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:48:52
in reply to nevent1q…n8ex
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:48:52Event JSON
{
"id": "4caf03649dd256a5a76e7a1329517f441cc212d6e0facd9e8ee272c1487211c2",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314932,
"kind": 1,
"tags": [
[
"e",
"c3f2627a28f3f44c130da7dce36c10040222ba86792d87bfb3e3dcd970958ae9",
"",
"root"
],
[
"e",
"d8b35a7c9245cda518a356553e6c8020c10ef983028846d7e11b966e4930766a",
"",
"reply"
],
[
"p",
"9e2723f47c6c16d3093735bd6acdc8b0dd1b91c78216f7001bdd2f7562b69ed1"
]
],
"content": "📅 Original date posted:2018-02-08\n📝 Original message:\nHi all!\n\n Finally catching up. I prefer the simplicity of the timestamp\nmechanism, with a more ambitious mechanism TBA.\n\nDeployment suggestions:\n\n1. This should be a feature bit pair. As usual, even == 'support this or\n disconnect', and odd == 'ok even if you don't understand'.\n\n2. This `timestamp_routing_sync`? feature overrides `initial_routing_sync`.\n That lets you decide what old nodes do, using the older\n `initial_routing_sync` option. Similarly, a future `fancy_sync` would\n override `timestamp_routing_sync`.\n\n3. We can append an optional 4 byte `routing_sync_timestamp` field to to\n `init` without issues, since all lengths in there are explicit. If you\n don't offer the `timestamp_sync` feature, this Must Be Zero (for appending\n more stuff in future).\n\nNow, as to the proposal specifics.\n\nI dislike the re-transmission of all old channel_announcement and\nnode_announcement messages, just because there's been a recent\nchannel_update. Simpler to just say 'send anything \u003e=\nrouting_sync_timestamp`.\n\nBackground: c-lightning internally keeps an tree of gossip in the order\nwe received them, keeping a 'current' pointer for each peer. This is\nvery efficient (though we don't remember if a peer sent us a gossip msg\nalready, so uses twice the bandwidth it could).\n\nBut this isn't *quite* the same as timestamp order, so we can't just set\nthe 'current' pointer based on the first entry \u003e=\n`routing_sync_timestamp`; we need to actively filter. This is still a\nsimple traverse, however, skipping over any entry less than\nrouting_sync_timestamp.\n\nOTOH, if we need to retransmit announcements, when do we stop\nretransmitting them? If a new channel_update comes in during this time,\nare we still to dump the announcements? Do we have to remember which\nones we've sent to each peer?\n\nIf missing announcements becomes a problem, we could add a simple query\nmessage: I think this is going to be needed for any fancy scheme anyway.\n\nCheers,\nRusty.",
"sig": "570f5d9ec6f07247df4024b8b3a93c45ec509ffc7eb09713d1dfaab33a05893d5cc4a842f16680e7c3866bbffedac4e64d518341ba62e1afc9a966690875a5f1"
}