Re: Prop 110 revisions

[mrwigglet <mrwigglet@xxxxxxxxx>]

That's how I was thinking of doing it also, but I'm content to wait for however everybody thinks it should all be done.  Meanwhile, I've got the patches with the minor issues ready and am willing to go along with however you all want it done, be that with prop 105 changes or other!

Thanks,

Nate

On 8/23/07, Christian Grothoff <christian@xxxxxxxxxxxx> wrote:

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