Re: Prop 110 revisions

[Christian Grothoff <christian@xxxxxxxxxxxx>]

On Thursday 23 August 2007 19:31, Nick Mathewson wrote:
> >  Third question
> > is about where to put the two fields.  Moving the counter for seen
> > extend cells to or_circuit_t is fine, but I'm not sure the other can
> > be moved to origin_circuit_t.  The reason is that the only place I
> > can find that the CELL_RELAY type is set is in
> > relay_send_command_from_edge and the type of circuit in that function is
> > circuit_t not
> > origin_circuit_t.
>
> This will probably depend on which implementation we wind up doing.
> If RELAY_EXTEND cells only originate from the client, then the counter
> can go into origin_circuit_t, since every client circuit is an
> origin_circuit_t.  If other nodes in the circuit decide to sometimes
> originate RELAY_EXTEND cells (as they do in the migration phase in my
> half-backed idea in my last email in this thread), then everybody
> needs a count.

How about this: if a peer (starting at patch level 2) receives a normal, 
non-RELAY_EXTEND cell and its counter of # relay-extend-cells received is 
still < MAX, it just converts the cell type (and decrements the 
EXTEND-received counter).  Yes, this will prevent the initiator from sending 
RELAY-EXTEND cells after the first 10, but no harm done there (and would be 
as in Proposal 110 anyway).  As for anonymity sets, just having a single 
patch-level 2 peer on the path would result in the exit-level seeing 
RELAY_EXTEND, so your anonymity sets are preserved.   In essence, we use the 
same counter that we use to reject RELAY_EXTEND to automatically convert to 
RELAY_EXTEND.  I think if we do this, we can get away with just a single 
counter.  

I think this is either what you were proposing or at least an equally 
effective alternative ;-).

> Cool!  Sorry for the indecisiveness here; I really wish we had this
> all designed well ahead of time. :/

No problem, these things need to be considered thoroughly.

Cheers!

Christian