Zooko Wilcox-OHearn [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-05-25 to 2015-12-17
💬 Posted a total of 6 messages
📚 Participated in the following categories: Bitcoin-development, softfork proposal, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 14:44:26

- reply

📅 Original date posted:2015-09-21
📝 Original message:
Could you please point me to any notes about requirements/desiderata?
Thanks!
--Zooko
On Sep 18, 2015 5:47 PM, "Rusty Russell" <rusty at rustcorp.com.au> wrote:
> Hi all!
>
> So, we've handwaved that we're going to have onion routing, so
> each node can only see the immediate neighbors.
>
> Here's my first attempt; please fix :)
>
> The format of a route looks like so:
>
> required bytes route;
>
> A node decrypts that using its pubkey (probably some counter mode
> scheme, but that's for a different post!), expecting:
>
> // 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;
>
> If the sum is wrong, the routing has failed (it's been corrupted or was
> malformed to start).
>
> 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.
>
> Route Probing Attacks
> =====================
> Now, there's a weakness here: No MAC! A nosy node can't corrupt the
> routing past the next hop, but it could replace it entirely (this is
> fundamental to the scheme of R values). If it guesses the final
> destination right, the HTLC will succeed, otherwise it will fail, so it
> can use this to probe.
>
> One partial defence is to fail to allow two HTLCs with the same R value,
> forcing probe serialization. Unfortunately that allows a simple way to
> probe back to the source, so we shouldn't do this!
>
> We may be able to do some probabalistic backoff of duplicate R values,
> such that you can't tell if I've received one before? A more
> sophisticated probe sequence could get a probability though...
>
> I can't see a fix for this in general. :(
>
> Error Messages
> ==============
> Another issue is that we should try not to leak information to passive
> observers on the route due to errors, so signing errors and using the
> 'sum' field as a secret key seems sensible. This means your padding in
> the original message needs to be "random" so 'sum' is random.
>
> Thoughts welcome!
> Rusty.
> PS. As noted before, nodes can trivially correlate HTLCs by R value, so
> onioning the routing only gets you so far...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150922/1abdd47c/attachment-0001.html>

2023-06-07 17:02:26

- reply

📅 Original date posted:2013-05-25
📝 Original message:jgarzik wrote:
> 1) Rule changes. We don't want these.
In general? What constitutes a rule change?
For example, if I understand correctly (from what Gavin said at
Bitcoin 2013), there is a move afoot to lift the block size limit.
Although, when I went to confirm my understanding by reading the
bitcoin-development list archives, I don't see mention of this. Is
there another forum I should be reading if I want to follow Bitcoin
development?
Anyway, I hope that there are some rule changes that you would
consider for Bitcoin, although I recognize there are vast classes of
such changes that you wouldn't.
I'm trying to figure out what's the most productive way to show you,
and everyone, candidates for such changes. Things that are definitely
not suitable for merging to trunk tomorrow, but might be suitable in a
year or two, or "Next Time We Have A Hardfork".
I don't think alternative bitcoin-clones are the best venue for those.
Although they are certainly good venues for changes which can never
make it into Bitcoin.
Perhaps the best venue for such a thing is just to fork bitcoin.git on github.
Regards,
Zooko Wilcox-O'Hearn
Founder, CEO, and Customer Support Rep
https://LeastAuthority.com