On 13/09/17 21:23, Arne Babenhauserheide wrote: > > Matthew John Toseland <matt...@toselandcs.co.uk> writes: > >> On 12/09/17 22:34, Arne Babenhauserheide wrote: >>> >>> Matthew John Toseland <matt...@toselandcs.co.uk> writes: >>>> But we need *something* in this approximate area. >>> >>> I fully agree with that. I think however that we need to be careful not >>> to require user interaction for that. Users already added the friend, we >>> can’t require more than maintaining the friend connections. Otherwise >>> that would be the next bottleneck. >> >> What makes you think we'd need user interaction? > > That’s how I understood it. > >> If there is any deconfliction it's all at the client level, not the >> node. The client can enforce any appropriate rules and decide to cast a >> vote by reinserting the block it most prefers. The user might get >> involved if there's a dispute about e.g. eliminating spammers. > > I don’t understand how the client casts votes without exposing the > data it uses to decide how to vote. How do you avoid coupling private > data with the insert decisions?
For the one proposal that involves votes, a vote is effectively an insert. > >> Proposal 0: Bundles >> ------------------- >> >> If an SSK insert has maximum HTL, we pre-route it along a fixed >> pseudo-random path, which ideally doesn't change for a given source >> node. It only uses friend connections, and stays at max HTL until a >> pseudo-random termination point (always the same node on a static >> network). After that it turns into an ordinary insert. > > Do I understand it correctly that this means that all inserts from a > given source initially travel along the same path? > > If yes, then it sounds good. Right, this is the poor man's tunneling scheme. Although one day perhaps we could have something like PISCES. > >> There are tricks we can use to compensate for churn by using shadow >> nodes so that even if we can't route it to fixed peer A, we route it to >> fixed peer B instead, but the following hop is the same (possibly using >> FOAF connections and proof of previous arrangements and whatever). > > That sounds like quite a bit of additional complexity but a nice > longterm goal. > > It would be great to have this for requests, too, since this would > clearly stop most correlation attacks which are used right now. > >> Proposal 1: Scarce SSKs with global (per-node) scarcity >> ------------------------------------------------------- > … >> Proposal 2: Scarce SSKs with per-key scarcity and multiple versions >> ------------------------------------------------------------------- > … >> Proposal 3: Scarce SSKs with voting >> ----------------------------------- > … > I don’t really understand these three. They all sound like they could > leak information from the anonymous ID layer to the networking layer. I don't see why. Maybe you can make an argument re voting schemes. But what is wrong with proposal 1 that makes it any different security-wise to what happens now?
signature.asc
Description: OpenPGP digital signature
