Thanks for the proposal, Nick! I think it's definitely discussion in a good direction!
On Wed, Feb 06, 2019 at 11:18:12AM +0100, Karsten Loesing wrote:
On 2019-02-05 18:44, Michael Rogers wrote:
Argh, I'm really sorry, I thought I'd reached the end of the proposal but my questions were addressed further down. Sorry for the noise.
Hang on. The issues you mentioned are indeed addressed in the proposal, and there are also solutions given in the proposal. But it might be that your solution goes beyond the one in the proposal.
It's this part in your solution:
"[...], then send *that relay's index* in its extend cell, so the relay receiving the extend cell wouldn't know whether the index was picked randomly by a client with no special requirements, or non-randomly by a client with special requirements?"
This is also related to the concern in 3.12 of the proposal where falling back to the old mechanism for route selection is said to be fingerprintable.
I'd be curious whether your solution is really fingerprintable.
At some point, you hit the problem that if there's a really unusual port that not many relays will exit to, and a very-low-bandwidth relay does support that port, then anyone extending to that relay is pretty likely doing so in order to exit to that port. (This happens today, not just with Walking Onions.) So the question is whether the solution is *more* fingerprintable than that.
for the wonderful future where we have tens of thousands relays.
Think bigger. :-)
[And to be clear in the proposal itself, I was not _advocating_ using SNARKs, but rather just pointing out that that's a thing one could conceivably use if you really wanted to keep the current consensus format, but still prove that this SNIP was part of it, Cinderella[0]-style.]
[0] https://www.andrew.cmu.edu/user/bparno/papers/cinderella.pdf
Another issue not addressed by the current proposal is how to handle the "not all the relays have upgraded" problem.