📅 Original date posted:2016-02-01
📝 Original message:
Fabrice Drouin <fabrice.drouin at acinq.fr> writes:
> On 27 January 2016 at 04:07, Rusty Russell <rusty at rustcorp.com.au> wrote:
> Hello,
>
> We (Pierre and I, the guys who work on the scala thingy :-) would
> rather use a "standard" binary format and protobuf seems to be a very
> good choice. Since incoming messages are encrypted, text based formats
> (JSON, ...) would not help that much for debugging and are not imho a
> good fit for binary protocols.
Well, I'm thinking of providing a binary which will do the crypto and
provide a (generated) JSON interface. That will keep the JSON people
happy, separate out the crypto and wire-protocol issues, and generally
give one less thing to worry about. I can also keep it up to date as we
debate formats...
>> - Length prefix for initial key exchange
>> - Both lnd and c-lightning begin by exchanging a 33-byte EC key for DH.
>> - We should prefix with a length word, so we can extend this later
>> (eg. for new crypto)
> Agreed.
>
>> - HTLC pipelining
>> - lnd's protocol supports multiple in-flight HTLC negotiations; this
>> would allow much greater throughput, with some complexity.
>> - lightning-c uses a simple one-at-a-time scheme, with alternating
>> priority in case of simultaneous sends.
>
> Just to be sure that we understand this, you mean grouping HTLCs and
> sending them with one message (so just one signature will be
> exchanged). It becomes more complex for clients because they will have
> to buffer and group incoming HTLCs but the protocol and the
> transitions remain pretty much the same ?
I haven't got a description of lnd's protocol, but I've been thinking
about it. We can certainly be more optimal than the 4 trips per change
we have now (amortized).
See the other thread "Protocol for multiple in-flight updates.".
>> Misc
>> ----
>> - shachain vs elkrem
>> - We use this to generate the revocation secrets, to minimize storage
>> and computation for a huge number of old commitment txs.
>> - They're actually very similar, but elkrem is much easier to grok.[6]
> I like both, they're easy to implement and elkrem was indeed much
> easier to understand. I don't know precisely why yet but I would
> choose shachain though.
I have to write up a better explanation of shachain. And as AJ points
out, it should be defined in the other direction to be more like chains
in the literature, so seed is index 0, first value is index 2^64-1...
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:45:37
in reply to nevent1q…7jut
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:45:37Event JSON
{
"id": "e6cd11e74faced0e4c752fb433b716a85b1a950fef2b461d902192c9991251c9",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314737,
"kind": 1,
"tags": [
[
"e",
"771d658c92b68acdc5def78ff79f0e01ddc0e6bfbf6060824e7ed3f8eca99874",
"",
"root"
],
[
"e",
"5933170c7b9f53d2a9c776e5c8c1af172c10641fbe7bf7307190d30c694b75d0",
"",
"reply"
],
[
"p",
"81c48ba46c211bc8fdb490d1ccfb03609c7ea090f8587ddca1c990676f09cfd3"
]
],
"content": "📅 Original date posted:2016-02-01\n📝 Original message:\nFabrice Drouin \u003cfabrice.drouin at acinq.fr\u003e writes:\n\u003e On 27 January 2016 at 04:07, Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\u003e Hello,\n\u003e\n\u003e We (Pierre and I, the guys who work on the scala thingy :-) would\n\u003e rather use a \"standard\" binary format and protobuf seems to be a very\n\u003e good choice. Since incoming messages are encrypted, text based formats\n\u003e (JSON, ...) would not help that much for debugging and are not imho a\n\u003e good fit for binary protocols.\n\nWell, I'm thinking of providing a binary which will do the crypto and\nprovide a (generated) JSON interface. That will keep the JSON people\nhappy, separate out the crypto and wire-protocol issues, and generally\ngive one less thing to worry about. I can also keep it up to date as we\ndebate formats...\n\n\u003e\u003e - Length prefix for initial key exchange\n\u003e\u003e - Both lnd and c-lightning begin by exchanging a 33-byte EC key for DH.\n\u003e\u003e - We should prefix with a length word, so we can extend this later\n\u003e\u003e (eg. for new crypto)\n\u003e Agreed.\n\u003e\n\u003e\u003e - HTLC pipelining\n\u003e\u003e - lnd's protocol supports multiple in-flight HTLC negotiations; this\n\u003e\u003e would allow much greater throughput, with some complexity.\n\u003e\u003e - lightning-c uses a simple one-at-a-time scheme, with alternating\n\u003e\u003e priority in case of simultaneous sends.\n\u003e\n\u003e Just to be sure that we understand this, you mean grouping HTLCs and\n\u003e sending them with one message (so just one signature will be\n\u003e exchanged). It becomes more complex for clients because they will have\n\u003e to buffer and group incoming HTLCs but the protocol and the\n\u003e transitions remain pretty much the same ?\n\nI haven't got a description of lnd's protocol, but I've been thinking\nabout it. We can certainly be more optimal than the 4 trips per change\nwe have now (amortized).\n\nSee the other thread \"Protocol for multiple in-flight updates.\".\n\n\u003e\u003e Misc\n\u003e\u003e ----\n\u003e\u003e - shachain vs elkrem\n\u003e\u003e - We use this to generate the revocation secrets, to minimize storage\n\u003e\u003e and computation for a huge number of old commitment txs.\n\u003e\u003e - They're actually very similar, but elkrem is much easier to grok.[6]\n\u003e I like both, they're easy to implement and elkrem was indeed much\n\u003e easier to understand. I don't know precisely why yet but I would\n\u003e choose shachain though.\n\nI have to write up a better explanation of shachain. And as AJ points\nout, it should be defined in the other direction to be more like chains\nin the literature, so seed is index 0, first value is index 2^64-1...\n\nCheers,\nRusty.",
"sig": "13ab7c5464d0af2b578e2069c67a413ab25db2aff6d39ddc7e3e55f1075f9e76ba95d7c785ba6526041862af0e641b0031749ae59ed07e9cd84d55b20d966d38"
}