Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-18 📝 Original message: On 19 September 2015 ...
📅 Original date posted:2015-09-18
📝 Original message:
On 19 September 2015 9:39:44 am AEST, Rusty Russell <rusty at rustcorp.com.au> wrote:
> // Sum of this whole thing after decryption.
> required sha256_hash sum = 1;
>
> // Where to next?
> oneof next {
> // Actually, this is the last one
> bool end = 2;
> // Next lightning node.
> pubkey lightning = 3;
> // Other realms go here...
> }
>
> // How much fee you can take (== all, if last node)
> required int32 fee = 4;
>
> // Remainder (route blob for next node).
> required bytes route = 5;
>Nodes create the route backwards, to calculate the size. Then picks a
>total size randomly between 1024 and 4096, and pads to that size (at
>least 32 bytes of random padding). Then walks backwards to wrap and
>encrypt it.
>
>This offers some protection from guessing the route length.
Wouldn't it be better to store the expected balance to be forwarded rather than the fee? That way if someone takes too much, the next node can immediately abort the transaction.
Shouldn't the onion blob be re-padded when forwarded? Otherwise it'd sometimes drop below 1024 bytes and you'd be able to tell you're near the end of the chain. Just adding random bytes on to the end should work I think - they'll just be treated as extra padding and ignored. Alternatively, maybe you could just append the encrypted bytes that made up your post of the payload from your incoming message: it was encrypted to you so should be effectively random to anyone else and will be garbled further when the next node "decrypts" it. That would save on entropy/crypto ops, and a constant message size would leak minimal info I think.
Cheers,
aj
--
Sent from my phone.
📝 Original message:
On 19 September 2015 9:39:44 am AEST, Rusty Russell <rusty at rustcorp.com.au> wrote:
> // Sum of this whole thing after decryption.
> required sha256_hash sum = 1;
>
> // Where to next?
> oneof next {
> // Actually, this is the last one
> bool end = 2;
> // Next lightning node.
> pubkey lightning = 3;
> // Other realms go here...
> }
>
> // How much fee you can take (== all, if last node)
> required int32 fee = 4;
>
> // Remainder (route blob for next node).
> required bytes route = 5;
>Nodes create the route backwards, to calculate the size. Then picks a
>total size randomly between 1024 and 4096, and pads to that size (at
>least 32 bytes of random padding). Then walks backwards to wrap and
>encrypt it.
>
>This offers some protection from guessing the route length.
Wouldn't it be better to store the expected balance to be forwarded rather than the fee? That way if someone takes too much, the next node can immediately abort the transaction.
Shouldn't the onion blob be re-padded when forwarded? Otherwise it'd sometimes drop below 1024 bytes and you'd be able to tell you're near the end of the chain. Just adding random bytes on to the end should work I think - they'll just be treated as extra padding and ignored. Alternatively, maybe you could just append the encrypted bytes that made up your post of the payload from your incoming message: it was encrypted to you so should be effectively random to anyone else and will be garbled further when the next node "decrypts" it. That would save on entropy/crypto ops, and a constant message size would leak minimal info I think.
Cheers,
aj
--
Sent from my phone.