commit bca2880bc4578f4b2fae983a5b78df4b2b232c79 parent 0507610d2077db8c2256b46e315cc30f22ef42a6 Author: Christian Grothoff <christian@grothoff.org> Date: Tue, 1 Feb 2022 16:23:41 +0100 notes on TTL calculation Diffstat:
| M | draft-schanzen-gns.xml | | | 11 | ++++++++--- |
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml @@ -728,18 +728,23 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62] </dl> <t> In order to verify a revocation the following steps must be taken, - in order: + in order: <!-- FIXME: why can an implementation not change the order, say if one check is slower than other checks? --> </t> <ol> <li>The signature MUST match the public key.</li> <li>The set of POW values MUST NOT contain duplicates.</li> - <li>The average number of leading zeroes resulting from the provided - POW values D' MUST be greater than and not equal to D.</li> + <li>The average number of leading zeroes D' resulting from the provided + POW values MUST be greater than and not equal to D. Implementors + MUST NOT use an integer data type to calculate or represent D'.</li> <li>The validation period (TTL) of the revocation is calculated as (D'-D) * EPOCH * 1.1. The EPOCH is extended by 10% in order to deal with unsynchronized clocks. The TTL added on top of the TIMESTAMP yields the expiration date.</li> + <!-- FIXME: what if the TTL in the message disagrees with our calculations? What should be done? + What if floating point rounding errors cause a disagreement in TTL calculations? + IMO we should simply mandate that when FORWARDING a message, the sender should + use the TTL they calculated themselves. --> <li>The current time MUST be between TIMESTAMP and TIMESTAMP+TTL.</li> </ol>