📅 Original date posted:2016-09-04
📝 Original message:
Christian Decker <decker.christian at gmail.com> writes:
> I'd like to pick up the conversation about the onion routing protocol
> again, since we are close to merging our implementation into the
> lightningd node.
>
> As far as I can see we mostly agree on the spec, with some issues that
> should be deferred until later/to other specs:
>
> - Key-rotation policies
OK, I've been thinking about the costs of key-rotation.
Assumptions:
1) We simply use a single pubkey for everything about a node, aka its ID.
2) Medium-scale public network, 250,000 nodes and 1M channels.
3) Every node knows the entire public network.
Each node ID is 33 bytes (pubkey) each channel is 6 bytes (blocknum +
txnum). You need to associate channels -> ids, say another 8 bytes per
channel.
That's 22.25MB each node has to keep.
The proofs are larger: to prove which IDs owns a channel, each one needs
a merkle proof (12 x 32 bytes) plus the funding tx (227 bytes, we can
skip some though), the two pubkeys (66 bytes), and a signature of the ID
using those pubkeys (128 bytes, schnorr would be 64?).
That's an additional 800M each node has to download to completely
validate, and of course some nodes will have to keep this so we can
download it from somewhere. That's even bigger than Pokemon Go :(
Change Assumptions:
1) We use a "comms" key for each node instead of its ID.
2) Nodes send out a new comms key, signed by ID.
That's another 33 bytes each to keep, or 8.25MB. To rotate a comms key,
we need the new key (33 bytes), and a signature from the id (64 bytes),
and probably a timestamp, (4 bytes), that's 25.25MB.
That's not too bad if we rotate daily. Probably not if we rotate
hourly..
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:46:41
in reply to nevent1q…aw26
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:46:41Event JSON
{
"id": "4d1d67b7194e92a07491ece3d73f04f445fa30c1bfdbb692432d218f1491e16f",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314801,
"kind": 1,
"tags": [
[
"e",
"6e65ece61bd323b60e8549dd5955ce1565ad06118112038c52f2e00d9538477b",
"",
"root"
],
[
"e",
"b3f19c20c87c09846bee709ff504e85106e0e7d904d9f8ddabb51e4d907b388a",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "📅 Original date posted:2016-09-04\n📝 Original message:\nChristian Decker \u003cdecker.christian at gmail.com\u003e writes:\n\u003e I'd like to pick up the conversation about the onion routing protocol\n\u003e again, since we are close to merging our implementation into the\n\u003e lightningd node.\n\u003e\n\u003e As far as I can see we mostly agree on the spec, with some issues that\n\u003e should be deferred until later/to other specs:\n\u003e\n\u003e - Key-rotation policies\n\nOK, I've been thinking about the costs of key-rotation.\n\nAssumptions:\n1) We simply use a single pubkey for everything about a node, aka its ID.\n2) Medium-scale public network, 250,000 nodes and 1M channels.\n3) Every node knows the entire public network.\n\nEach node ID is 33 bytes (pubkey) each channel is 6 bytes (blocknum +\ntxnum). You need to associate channels -\u003e ids, say another 8 bytes per\nchannel.\n\nThat's 22.25MB each node has to keep.\n\nThe proofs are larger: to prove which IDs owns a channel, each one needs\na merkle proof (12 x 32 bytes) plus the funding tx (227 bytes, we can\nskip some though), the two pubkeys (66 bytes), and a signature of the ID\nusing those pubkeys (128 bytes, schnorr would be 64?).\n\nThat's an additional 800M each node has to download to completely\nvalidate, and of course some nodes will have to keep this so we can\ndownload it from somewhere. That's even bigger than Pokemon Go :(\n\nChange Assumptions:\n1) We use a \"comms\" key for each node instead of its ID.\n2) Nodes send out a new comms key, signed by ID.\n\nThat's another 33 bytes each to keep, or 8.25MB. To rotate a comms key,\nwe need the new key (33 bytes), and a signature from the id (64 bytes),\nand probably a timestamp, (4 bytes), that's 25.25MB.\n\nThat's not too bad if we rotate daily. Probably not if we rotate\nhourly..\n\nCheers,\nRusty.",
"sig": "73fbc7a9352a9a41539941fb4d76e305347cef26b8fd25705d95130ae69f41f6110849becc3cde409524ec6f5b98bdbdf01309c1b6ecd47905ab78a9744eb84a"
}