Would it help if instead of increasing the entropy by requiring a larger
N, instead the % operation is made more expensive.

I'm thinking of this instead of the usual flat flood fill broadcast
network, where everyone is connected to random nodes. If instead nodes
are able to cluster, then messages spread first within that cluster
before migrating to neighbouring ones. This lessens network load as
messages are routed predictably through the network.

On 02/01/14 19:52, Gregory Maxwell wrote:
> 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.
>