[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0003] branch master updated: Corrected
|
From: |
gnunet |
|
Subject: |
[lsd0003] branch master updated: Corrected |
|
Date: |
Thu, 10 Jun 2021 22:19:20 +0200 |
This is an automated email from the git hooks/post-receive script.
elias-summermatter pushed a commit to branch master
in repository lsd0003.
The following commit(s) were added to refs/heads/master by this push:
new f5d269f Corrected
f5d269f is described below
commit f5d269f37c7b1c3b65921b3f02e1b1713a227004
Author: Elias Summermatter <elias.summermatter@seccom.ch>
AuthorDate: Thu Jun 10 22:16:30 2021 +0200
Corrected
---
draft-summermatter-set-union.pdf | Bin 517627 -> 516646 bytes
draft-summermatter-set-union.xml | 42 +++++++++++----------------------------
2 files changed, 12 insertions(+), 30 deletions(-)
diff --git a/draft-summermatter-set-union.pdf b/draft-summermatter-set-union.pdf
index af78ba2..22b0a80 100644
Binary files a/draft-summermatter-set-union.pdf and
b/draft-summermatter-set-union.pdf differ
diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index f10454a..ad5f17f 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -70,7 +70,7 @@
Our primary envisioned application domain is the
distribution of revocation messages in the GNU Name
- System (GNS) <xref target="GNUNET" format="default" /><xref
target="GNS" format="default"/>. In GNS,
+ System (GNS) <xref target="GNS" format="default" /><xref
target="GNS" format="default"/>. In GNS,
key revocation messages are usually flooded across the
peer-to-peer overlay network to all connected peers
whenever a key is revoked. However, as peers may be
@@ -2626,7 +2626,7 @@ FUNCTION END
<dd>
<t>
It needs to be checked that the full synchronisation
mode with receiving peer
- sending first, is plausible according to the algorithm
deciding which operation mode
+ sending first is plausible according to the algorithm
deciding which operation mode
is applicable as described in <xref
target="performance_formulas_operationmode" format="default"/>.
</t>
@@ -2730,7 +2730,7 @@ FUNCTION END
<dd>
<t>
If an element that never has been requested by
- a demand or is received double the operation MUST
be terminated.
+ a demand or is received double, the operation MUST
be terminated.
The sending and receiving of <xref
target="messages_elements" format="title" /> messages should
always be protected with an <xref
target="security_generic_functions_mfc" format="title" />
to secure the protocol against missing, doubled,
not in order or unexpected messages.
@@ -2890,10 +2890,10 @@ FUNCTION END
<name>Finish Waiting</name>
<t>
In the <strong>Finish Waiting</strong> state the protocol
waits for
- all send demands to be fulfilled.
+ all sent demands to be fulfilled.
</t>
<t>
- In case not all sent demands have ben answered in time,
the operation
+ In case not all sent demands have been answered in time,
the operation
has failed and MUST be terminated.
</t>
<t>Security considerations for received messages:</t>
@@ -2925,11 +2925,11 @@ IBF_FACTOR* | 2 | The factor
by which the size of the I
set difference
MAX_BUCKETS_PER_MESSAGE | 1120 | Maximum bucket of an IBF that are
transmitted in single message
IBF_MIN_SIZE* | 37 | Minimal number of buckets in an IBF
-DIFFERENTIAL_RTT_MEAN* | 3.65145 | The average RTT that is needed for
a differential syncronisation
+DIFFERENTIAL_RTT_MEAN* | 3.65145 | The average RTT that is needed for
a differential synchronisation
SECURITY_LEVEL* | 2^80 | Security level for probabilistic
security algorithms
PROBABILITY_FOR_NEW_ROUND* | 0.15 | The probability for a IBF decoding
failure in the differential
synchronisation mode
-DIFFERENTIAL_RTT_MEAN* | 3.65145 | The average RTT that is needed for
a differential syncronisation
+DIFFERENTIAL_RTT_MEAN* | 3.65145 | The average RTT that is needed for
a differential synchronisation
MAX_IBF_SIZE | 1048576 | Maximal number of buckets in an IBF
AVG_BYTE_SIZE_SE* | 4221 | Average byte size of a single
strata estimator
VALID_NUMBER_SE* | [1,2,4,8] | Valid number of SE in
@@ -2951,16 +2951,16 @@ Type | Name | References |
Description
559 | SETU_P2P_REQUEST_FULL | [This.I-D] | Request the full set of
the other peer
710 | SETU_P2P_SEND_FULL | [This.I-D] | Signals to send the full
set to the other peer
560 | SETU_P2P_DEMAND | [This.I-D] | Demand the whole element
from the other peer, given only the hash code.
- 561 | SETU_P2P_INQUIRY | [This.I-D] | Tell the other peer to
send us a list of hashes that match an IBF key.
+ 561 | SETU_P2P_INQUIRY | [This.I-D] | Tell the other peer to
send a list of hashes that match an IBF key.
562 | SETU_P2P_OFFER | [This.I-D] | Tell the other peer which
hashes match a given IBF key.
563 | SETU_P2P_OPERATION_REQUEST | [This.I-D] | Request a set union
operation from a remote peer.
564 | SETU_P2P_SE | [This.I-D] | Strata Estimator
uncompressed
- 565 | SETU_P2P_IBF | [This.I-D] | InvertibFle Bloom Filter
Slice.
+ 565 | SETU_P2P_IBF | [This.I-D] | Invertible Bloom Filter
slices.
566 | SETU_P2P_ELEMENTS | [This.I-D] | Actual set elements.
567 | SETU_P2P_IBF_LAST | [This.I-D] | Invertible Bloom Filter
Last Slice.
568 | SETU_P2P_DONE | [This.I-D] | Set operation is done.
569 | SETU_P2P_SEC | [This.I-D] | Strata Estimator compressed
- 570 | SETU_P2P_FULL_DONE | [This.I-D] | All elements in full
synchronisation mode have been send is done.
+ 570 | SETU_P2P_FULL_DONE | [This.I-D] | All elements in full
synchronisation mode have been sent is done.
571 | SETU_P2P_FULL_ELEMENT | [This.I-D] | Send an actual element in
full synchronisation mode.
]]></artwork>
@@ -2970,7 +2970,7 @@ Type | Name | References |
Description
<section anchor="contributors" numbered="true" toc="default">
<name>Contributors</name>
<t>
- The original GNUnet implementation of the byzantine fault
tolerant Set Reconciliation
+ The original GNUnet implementation of the byzantine fault
tolerant set reconciliation
protocol has mainly been
written by Florian Dold and Christian Grothoff.
</t>
@@ -3004,7 +3004,7 @@ Type | Name | References |
Description
<reference anchor="CryptographicallySecureVoting"
target="https://git.gnunet.org/bibliography.git/plain/docs/ba_dold_voting_24aug2014.pdf";>
<front>
- <title>Cryptographically Secure, DistributedElectronic
Voting</title>
+ <title>Cryptographically Secure, Distributed Electronic
Voting</title>
<author initials="F." surname="Dold" fullname="Florian
Dold">
<organization>Technische Universität
München</organization>
</author>
@@ -3023,24 +3023,6 @@ Type | Name | References |
Description
</author>
</front>
</reference>
-
-
-
- <reference anchor="GNUNET"
target="https://git.gnunet.org/bibliography.git/plain/docs/gns2014wachs.pdf";>
- <front>
- <title>A Censorship-Resistant, Privacy-Enhancing andFully
Decentralized Name System</title>
- <author initials="M." surname="Wachs" fullname="Matthias
Wachs">
- <organization>Technische Universität
München</organization>
- </author>
- <author initials="M." surname="Schanzenbach"
fullname="Martin Schanzenbach">
- <organization>Technische Universität
München</organization>
- </author>
- <author initials="C." surname="Grothoff"
fullname="Christian Grothoff">
- <organization>Technische Universität
München</organization>
- </author>
- </front>
- </reference>
-
<reference anchor="Eppstein"
target="https://doi.org/10.1145/2018436.2018462";>
<front>
<title>What’s the Difference? Efficient Set Reconciliation
without Prior Context</title>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
- [lsd0003] branch master updated: Corrected,
gnunet <=