Changes between Initial Version and Version 5 of Ticket #1767


Ignore:
Timestamp:
2012-09-05T00:17:25Z (12 years ago)
Author:
warner
Comment:

fixed some typos in the description.

Two other thoughts:

  • if two nodes are somehow configured with the same private key, they'll fight over the announcements: each inbound announcement will trigger an outbound one with the higher seqnum, and they won't ever converge because they'll undoubtedly have different swissnums for the storage-server FURLs. They'll just chase each other up to infinity.
  • it's probably ok to just switch to a locally-managed persistent counter for 1.10 . I think we can safely defer the feedback/quake-handling code until later.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #1767

    • Property Status changed from new to assigned

  • Ticket #1767 – Description

    initial v5  
    2323sequence number. The advantage of a seqnum would be that it would
    2424reveal less information about the client (which might help a
    25 de-anonymying attacker correlate the tahoe node's behavior with
     25de-anonymyzing attacker correlate the tahoe node's behavior with
    2626other externally-visible things).
    2727
    … …  
    4040* initialize all counters to 0 at node creation
    4141* increment the counter each time {{{IntroducerClient.publish}}} is called
    42 * if we receive a valid signed announcement from out own pubkey:
     42* if we receive a valid signed announcement from our own pubkey:
    4343  * if the seqnum is higher than our current value, set our counter
    4444    to one greater than the received value, and re-publish