[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: clarify epoch; Z
|
From: |
gnunet |
|
Subject: |
[lsd0001] branch master updated: clarify epoch; Z |
|
Date: |
Mon, 20 Apr 2020 19:49:52 +0200 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a commit to branch master
in repository lsd0001.
The following commit(s) were added to refs/heads/master by this push:
new c96dee4 clarify epoch; Z
c96dee4 is described below
commit c96dee4ddb017e927d223f59c0fc2f1f3a0f7d37
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Mon Apr 20 19:45:08 2020 +0200
clarify epoch; Z
---
draft-schanzen-gns.html | 73 +++++++++++++++++++++++++++++--------------------
draft-schanzen-gns.txt | 30 ++++++++++----------
draft-schanzen-gns.xml | 21 ++++++++++----
3 files changed, 74 insertions(+), 50 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 9581b2c..57e83a1 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -2467,16 +2467,26 @@ table {
The resulting proofs may then published and disseminated. The concrete
dissemination and publication methods are out of scope of this
document. Given an average difficulty of "D", the proofs have an
- expiration time of 365 days. With each additional bit difficulty, the
- lifetime of the proof is prolonged for another 365 days.
+ expiration time of EPOCH. With each additional bit difficulty, the
+ lifetime of the proof is prolonged for another EPOCH.
Consequently, by calculating a more difficult PoW, the lifetime of the
proof can be increased on demand by the zone owner.<a
href="#section-7-10" class="pilcrow">¶</a></p>
<p id="section-7-11">
+ The paraneters are defined as follows:<a href="#section-7-11"
class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="normal" id="section-7-12">
+ <li id="section-7-12.1">Z: The number of PoWs required is fixed at
32.<a href="#section-7-12.1" class="pilcrow">¶</a>
+</li>
+<li id="section-7-12.2">D: The difficulty is fixed at 25.<a
href="#section-7-12.2" class="pilcrow">¶</a>
+</li>
+<li id="section-7-12.3">EPOCH: A single epoch is fixed at 365 days.<a
href="#section-7-12.3" class="pilcrow">¶</a>
+</li>
+</ol>
+<p id="section-7-13">
Given that proof has been found, a revocation data object is defined
- as follows:<a href="#section-7-11" class="pilcrow">¶</a></p>
+ as follows:<a href="#section-7-13" class="pilcrow">¶</a></p>
<div id="figure_revocationdata">
<figure id="figure-16">
- <div class="artwork art-text alignLeft" id="section-7-12.1">
+ <div class="artwork art-text alignLeft" id="section-7-14.1">
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -2510,52 +2520,52 @@ table {
</div>
<figcaption><a href="#figure-16" class="selfRef">Figure
16</a></figcaption></figure>
</div>
-<p id="section-7-13">where:<a href="#section-7-13" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-7-14">
- <dt id="section-7-14.1">TIMESTAMP</dt>
-<dd id="section-7-14.2">
+<p id="section-7-15">where:<a href="#section-7-15" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-7-16">
+ <dt id="section-7-16.1">TIMESTAMP</dt>
+<dd id="section-7-16.2">
denotes the absolute 64-bit expiration date of the revocation.
In microseconds since midnight (0 hour), January 1, 1970 in network
- byte order.<a href="#section-7-14.2" class="pilcrow">¶</a>
+ byte order.<a href="#section-7-16.2" class="pilcrow">¶</a>
</dd>
-<dt id="section-7-14.3">TTL</dt>
-<dd id="section-7-14.4">
+<dt id="section-7-16.3">TTL</dt>
+<dd id="section-7-16.4">
denotes the relative 64-bit time to live of of the record in
microseconds also in network byte order. This field is informational
for a verifier. The verifier may discard revocation of the TTL
indicates that it is already expired. However, the actual TTL of the
revocation must be determined by examining the leading zeros in the
- proof of work calculation.<a href="#section-7-14.4"
class="pilcrow">¶</a>
+ proof of work calculation.<a href="#section-7-16.4"
class="pilcrow">¶</a>
</dd>
-<dt id="section-7-14.5">POW_i</dt>
-<dd id="section-7-14.6">
+<dt id="section-7-16.5">POW_i</dt>
+<dd id="section-7-16.6">
The POWs calculated as part of the proof-of-work. Each POW_i MUST
- be unique in the set of POW values.<a href="#section-7-14.6"
class="pilcrow">¶</a>
+ be unique in the set of POW values.<a href="#section-7-16.6"
class="pilcrow">¶</a>
</dd>
-<dt id="section-7-14.7">SIGNATURE</dt>
-<dd id="section-7-14.8">
+<dt id="section-7-16.7">SIGNATURE</dt>
+<dd id="section-7-16.8">
A 512-bit ECDSA deterministic signature compliant with
<span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span> over the
public zone zk of the zone
which is revoked and corresponds to the key used in the
proof-of-work.
The signature is created using the private zone key "d" (see
- <a href="#zones" class="xref">Section 2</a>).<a
href="#section-7-14.8" class="pilcrow">¶</a>
+ <a href="#zones" class="xref">Section 2</a>).<a
href="#section-7-16.8" class="pilcrow">¶</a>
</dd>
-<dt id="section-7-14.9">SIZE</dt>
-<dd id="section-7-14.10">
+<dt id="section-7-16.9">SIZE</dt>
+<dd id="section-7-16.10">
A 32-bit value containing the length of the signed data in bytes
- (36 bytes) in network byte order.<a href="#section-7-14.10"
class="pilcrow">¶</a>
+ (36 bytes) in network byte order.<a href="#section-7-16.10"
class="pilcrow">¶</a>
</dd>
-<dt id="section-7-14.11">PURPOSE</dt>
-<dd id="section-7-14.12">
+<dt id="section-7-16.11">PURPOSE</dt>
+<dd id="section-7-16.12">
A 32-bit signature purpose flag. This field MUST be 3 (in network
- byte order).<a href="#section-7-14.12" class="pilcrow">¶</a>
+ byte order).<a href="#section-7-16.12" class="pilcrow">¶</a>
</dd>
-<dt id="section-7-14.13">PUBLIC KEY</dt>
-<dd id="section-7-14.14">
+<dt id="section-7-16.13">PUBLIC KEY</dt>
+<dd id="section-7-16.14">
is the 256-bit public key "zk" of the zone which is being revoked
and
the key to be used to verify SIGNATURE. The
wire format of this value is defined in <span>[<a href="#RFC8032"
class="xref">RFC8032</a>]</span>,
- Section 5.1.5.<a href="#section-7-14.14" class="pilcrow">¶</a>
+ Section 5.1.5.<a href="#section-7-16.14" class="pilcrow">¶</a>
</dd>
</dl>
<div id="revocation_verification">
@@ -2575,10 +2585,13 @@ table {
<li id="section-7.1-2.3">The set of POW values MUST NOT contain duplicates.<a
href="#section-7.1-2.3" class="pilcrow">¶</a>
</li>
<li id="section-7.1-2.4">The average number of leading zeroes resulting from
the provided
- POW values D' MUST be greater than or equal to D.<a
href="#section-7.1-2.4" class="pilcrow">¶</a>
+ POW values D' MUST be greater than D.<a href="#section-7.1-2.4"
class="pilcrow">¶</a>
</li>
-<li id="section-7.1-2.5">The actual expiration time TIMESTAMP + (D'-D) * 365
days
- is in the future.<a href="#section-7.1-2.5" class="pilcrow">¶</a>
+<li id="section-7.1-2.5">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.<a href="#section-7.1-2.5" class="pilcrow">¶</a>
</li>
</ol>
</section>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index 1b85775..7b0fddf 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -1135,21 +1135,21 @@ Internet-Draft The GNU Name System
November 2019
The resulting proofs may then published and disseminated. The
concrete dissemination and publication methods are out of scope of
this document. Given an average difficulty of "D", the proofs have
- an expiration time of 365 days. With each additional bit difficulty,
- the lifetime of the proof is prolonged for another 365 days.
+ an expiration time of EPOCH. With each additional bit difficulty,
+ the lifetime of the proof is prolonged for another EPOCH.
Consequently, by calculating a more difficult PoW, the lifetime of
the proof can be increased on demand by the zone owner.
- Given that proof has been found, a revocation data object is defined
- as follows:
-
-
-
-
+ The paraneters are defined as follows:
+ 1. Z: The number of PoWs required is fixed at 32.
+ 2. D: The difficulty is fixed at 25.
+ 3. EPOCH: A single epoch is fixed at 365 days.
+ Given that proof has been found, a revocation data object is defined
+ as follows:
@@ -1261,10 +1261,12 @@ Internet-Draft The GNU Name System
November 2019
3. The set of POW values MUST NOT contain duplicates.
4. The average number of leading zeroes resulting from the provided
- POW values D' MUST be greater than or equal to D.
+ POW values D' MUST be greater than D.
- 5. The actual expiration time TIMESTAMP + (D'-D) * 365 days is in
- the future.
+ 5. 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.
8. Determining the Root Zone and Zone Governance
@@ -1280,8 +1282,6 @@ Internet-Draft The GNU Name System
November 2019
This is an important distinguishing factor from the Domain Name
System where root zone governance is centralized at the Internet
- Corporation for Assigned Names and Numbers (ICANN). In DNS
- terminology, GNS roughly follows the idea of a hyper-hyper local root
@@ -1290,6 +1290,8 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 23]
Internet-Draft The GNU Name System November 2019
+ Corporation for Assigned Names and Numbers (ICANN). In DNS
+ terminology, GNS roughly follows the idea of a hyper-hyper local root
zone deployment, with the difference that it is not expected that all
deployments use the same local root zone.
@@ -1339,8 +1341,6 @@ Internet-Draft The GNU Name System
November 2019
-
-
Schanzenbach, et al. Expires 13 May 2020 [Page 24]
Internet-Draft The GNU Name System November 2019
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 6510dd7..dc8a81d 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -1204,11 +1204,19 @@
The resulting proofs may then published and disseminated. The concrete
dissemination and publication methods are out of scope of this
document. Given an average difficulty of "D", the proofs have an
- expiration time of 365 days. With each additional bit difficulty, the
- lifetime of the proof is prolonged for another 365 days.
+ expiration time of EPOCH. With each additional bit difficulty, the
+ lifetime of the proof is prolonged for another EPOCH.
Consequently, by calculating a more difficult PoW, the lifetime of the
proof can be increased on demand by the zone owner.
</t>
+ <t>
+ The paraneters are defined as follows:
+ </t>
+ <ol>
+ <li>Z: The number of PoWs required is fixed at 32.</li>
+ <li>D: The difficulty is fixed at 25.</li>
+ <li>EPOCH: A single epoch is fixed at 365 days.</li>
+ </ol>
<t>
Given that proof has been found, a revocation data object is defined
as follows:
@@ -1305,9 +1313,12 @@
<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 or equal to D.</li>
- <li>The actual expiration time TIMESTAMP + (D'-D) * 365 days
- is in the future.</li>
+ POW values D' MUST be greater than 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>
</ol>
</section>
</section>
--
To stop receiving notification emails like this one, please contact
address@hidden.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: clarify epoch; Z,
gnunet <=