Yes, my question was more, how does the client decide, which timelines it trusts/tracks, and how is this updated? At the moment, this point is a bit vague in the design document. As you outlined, when too many timelines are not operational anymore, the whole system stops working. So if a timeline goes down, it needs to be replaced rather soon then late.
Am Dienstag, den 28.02.2012, 09:27 +0100 schrieb g.koppena: > > All client, that insist opon this timeline would act like under an > > attack, because no fresh responses from this timeline are available > > anymore. > > Forgot to point you to > > "MAX_DERELICT_TIMELINES=2 # Timelines are derelict if nobody is > seeing updates > # from them. We will tolerate this number > of them" > > in the algorithm outlined in section 4.b. as well... > > > Georg > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 455 bytes > Desc: OpenPGP digital signature > URL: > <https://mail1.eff.org/pipermail/sovereign-keys/attachments/20120228/bd80a7dd/attachment.pgp>
signature.asc
Description: This is a digitally signed message part
