-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Matthew Toseland wrote:
> We could even send the insert twice in one insert: have a counter
> ParallelInserts on an insert, then:
>
> int newParallelInserts = 0;
> for(int i=0;i<ParallelInserts;i++) {
> if(rand() > 0.95)
> newParallelInserts++;
> }
>
> If newParallelInserts is 0, terminate on that hop.
>
> Obviously this is more state than simple weighted coin, which is bad - but it
> should give less information than actually sending the request more than
> once, because there's only one set of routing info.
>
> 0.95*0.95 is ~ 90%, so if PI started at 2, and 10% of the samples are at 2
> and
> 90% at 1, we can conclude that we are 1 hop from the target. Likewise with
> simple weighted coin, if we know the inserter is sending two inserts for
> every block, and for 95% of keys we get two inserts and for 5% we get one, we
> can draw the same conclusion.
>
> Even weighted-coin-followed-by-HTL gives significantly better security than
> the current scheme: against a global remote search, dramatically better
> security because no nearestLoc. Against a local attacker, it's still better:
>
> Weighted coin followed by HTL:
> At 1 hop, 10% of requests have HTL 10 (rather than no HTL). If we get an HTL
> 10 request, we know the sender is not the originator.
>
> Current scheme:
> At 1 hop, 50% of requests have HTL 10 (rather than HTL 9). If we get HTL 9,
> we
> know the sender is not the originator. If we get HTL 10, and nearestLoc is
> *not* the same as the sender's, we know the sender is not the originator. If
> it is, there is a 1 in (average # resets + 1) chance that the sender is the
> originator.
>
> So I propose to implement weighted-coin-followed-by-HTL. This should cause
> very little disruption, as we won't have very short requests, in fact the
> code changes would be very minor. We can always change it later on to for
> example pure weighted coin (although I'm not convinced that will work well
> for inserts).
I hope what i'm about to write is not complete rubbish, in the case that it is i
apologise.
You could have 2 separate drop factor, one small and another large. The first
one is used to get you to a location which at least stores the content, the
second for the secondary insert.
Inserter sends out an insert marked 'initial', and uses a small drop factor.
This insert goes until just like is described with weighted coin, but with two
differences: 1. If the decision to drop this insert is made RNF is returned. 2.
If the node stores the content it changes the state to 'follow-up'.
- From there insert still follows normally, but now uses the higher drop factor.
The 'follow-up' tells you that you are near the location of the node that stored
the key, which gives you nothing.
The 'initial' tells you that you are somewhat close to the inserter, but since
drop factor is small, the probabilities become smaller also.
You at least know that the key has been stored somewhere (or hasn't) when you
insert it.
- Volodya
- --
http://freedom.libsyn.com/ Voice of Freedom, Radical Podcast
http://eng.anarchopedia.org/ Anarchopedia, A Free Knowledge Portal
"None of us are free until all of us are free." ~ Mihail Bakunin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHodo8uWy2EFICg+0RAviyAKDZeXtHn/mdlMGc/QAdeQ3lJGFsAACgx1di
FW5UmDdBCGh9Jgi7A1a4UnY=
=a9Bn
-----END PGP SIGNATURE-----
