On Thu, Jan 2, 2014 at 11:27 AM, Amir Taaki <genjix@???> wrote:
> Hey instead of the hacks and workarounds, bitcoin should use swarming
> techniques:
>
> # hash(ip addr, port) % N = swarm_id
> # index node address list db by hash(ip addr, port)
> # N = total number of nodes in address list
> # when connecting, progressively try swarm_ids closest to ours and move
> outwards.
> # when a connection is dropped, repeat the above steps.
>
> this would allow efficient routing and broadcast of messages in bitcoin
> while maintaining a resilient network that is not a victim of shaping.
> if we're always doing getaddr (as we should) and N is unpredictable
> (rather can't be predicted precisely- you could be 2028 or 2029 but it
> changes your swarm_id completely.

This kind of construction is generally not strongly attack resistant
if hash() is public (which it must be if you use it for routing). The
suggestion of % N doesn't seem to be helpful to me, the entropy of N
is small so you can guess and attack under multiple assumptions,
resulting in only constant factor overhead for the attacker, and also
for routing cases it doesn't generally matter if you hit the ID
exactly, you just need proximity.

Bitcoin-QT does use a a randomize algorithm based on cryptographic
hashing for peer maintenance, but the hash is secret.

Also, the connect-only-to-proximal-nodes with all nodes using nearly
the same definition of proximal results in a topology which lacks the
expander property, and will have a small min-cut, high median path
length, etc. But perhaps I misunderstand what you're suggesting, I
appear to be missing context.