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!
<br><br>Thanks,<br><br>Nate<br><br><div><span class="gmail_quote">On 8/23/07, <b class="gmail_sendername">Christian Grothoff</b> &lt;<a href="mailto:christian@grothoff.org">christian@grothoff.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thursday 23 August 2007 19:31, Nick Mathewson wrote:<br>&gt; &gt;&nbsp;&nbsp;Third question<br>&gt; &gt; is about where to put the two fields.&nbsp;&nbsp;Moving the counter for seen<br>&gt; &gt; extend cells to or_circuit_t is fine, but I&#39;m not sure the other can
<br>&gt; &gt; be moved to origin_circuit_t.&nbsp;&nbsp;The reason is that the only place I<br>&gt; &gt; can find that the CELL_RELAY type is set is in<br>&gt; &gt; relay_send_command_from_edge and the type of circuit in that function is
<br>&gt; &gt; circuit_t not<br>&gt; &gt; origin_circuit_t.<br>&gt;<br>&gt; This will probably depend on which implementation we wind up doing.<br>&gt; If RELAY_EXTEND cells only originate from the client, then the counter
<br>&gt; can go into origin_circuit_t, since every client circuit is an<br>&gt; origin_circuit_t.&nbsp;&nbsp;If other nodes in the circuit decide to sometimes<br>&gt; originate RELAY_EXTEND cells (as they do in the migration phase in my
<br>&gt; half-backed idea in my last email in this thread), then everybody<br>&gt; needs a count.<br><br>How about this: if a peer (starting at patch level 2) receives a normal,<br>non-RELAY_EXTEND cell and its counter of # relay-extend-cells received is
<br>still &lt; MAX, it just converts the cell type (and decrements the<br>EXTEND-received counter).&nbsp;&nbsp;Yes, this will prevent the initiator from sending<br>RELAY-EXTEND cells after the first 10, but no harm done there (and would be
<br>as in Proposal 110 anyway).&nbsp;&nbsp;As for anonymity sets, just having a single<br>patch-level 2 peer on the path would result in the exit-level seeing<br>RELAY_EXTEND, so your anonymity sets are preserved.&nbsp;&nbsp; In essence, we use the
<br>same counter that we use to reject RELAY_EXTEND to automatically convert to<br>RELAY_EXTEND.&nbsp;&nbsp;I think if we do this, we can get away with just a single<br>counter.<br><br>I think this is either what you were proposing or at least an equally
<br>effective alternative ;-).<br><br>&gt; Cool!&nbsp;&nbsp;Sorry for the indecisiveness here; I really wish we had this<br>&gt; all designed well ahead of time. :/<br><br>No problem, these things need to be considered thoroughly.<br>
<br>Cheers!<br><br>Christian<br></blockquote></div><br>