commit da2d89045c2fc10ea393e4eb917c3dca480486bc
parent aab0ce19452466c8290c700f1f6fddefa1c12ec2
Author: Christian Grothoff <christian@grothoff.org>
Date: Sat, 12 Jun 2021 16:49:12 +0200
chapter 1
Diffstat:
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git 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="GNS" format="default" /><xref target="GNS" format="default"/>. In GNS,
+ System (GNS) <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
@@ -91,7 +91,7 @@
computational results. We note that for such systems,
the set reconciliation protocol is merely a component of
a multiparty consensus protocol, such as the one
- described in F.Dold's "Byzantine set-union consensus using
+ described in Dold's "Byzantine set-union consensus using
efficient set reconciliation" <xref target="ByzantineSetUnionConsensusUsingEfficientSetReconciliation" format="default"/>.
</t>
<t>
@@ -108,12 +108,14 @@
the number of network round-trips and the number of bytes
sent over the network. Thus, for the protocol to choose
the right parameters for a given situation, applications
- using the protocol SHOULD provide a parameter that specifies
+ using an implementation of the protocol SHOULD provide a
+ parameter that specifies
the cost-ratio of round-trips vs. bandwidth usage. Given
- this trade-off factor, the protocol will then choose parameters
- that minimize the total execution costs. In particular, there
+ this trade-off factor, an implementation CAN then choose parameters
+ that minimize total execution cost. In particular, there
is one major choice to be made, namely between sending the
- complete set of elements, or sending only the elements that differ.
+ complete set of elements, or computing the set differences and
+ transmitting only the elements in the set differences.
In the latter case, our design is basically a concrete
implementation of a proposal by Eppstein.<xref target="Eppstein" format="default" />
</t>
@@ -123,9 +125,7 @@
fault-tolerant because it provides cryptographic and
probabilistic methods to discover if the other peer
is dishonest or misbehaving.
- </t>
- <t>
- The objective here is to limit resources wasted on
+ Here, the security objective is to limit resources wasted on
malicious actors. Malicious actors could send malformed
messages, including malformed set elements, claim to
have much larger numbers of valid set elements than they
@@ -141,27 +141,27 @@
</t>
<t>
To defend against some of these attacks, applications
- need to remember the number of elements previously
- shared with a peer, and provide a way to check that
- elements are well-formed. Applications may also be able
- to provide an upper bound on the total number of valid
- elements that may exist. For example, in E-voting, the
- number of eligible voters could be used to provide such
+ SHOULD remember the number of elements previously
+ shared with a peer, and SHOULD provide a way to check that
+ elements are well-formed. Applications MAY also
+ provide an upper bound on the total number of valid
+ elements that exist. For example, in E-voting, the
+ number of eligible voters MAY be used to provide such
an upper bound.
</t>
-
<t>
- Initially, this RFC was created as part of Elias Summermatter's
- bachelor thesis. Many of the algorithms and parameters
- documented in this RFC are derived in detail in this thesis.
- <xref target="byzantine_fault_tolerant_set_reconciliation" format="default"/>
+ A first draft of this RFC is part of Elias Summermatter's
+ bachelor thesis. Many of the algorithms and parameters
+ documented in this RFC are derived from experiments
+ detailed in this thesis.
+ <xref target="byzantine_fault_tolerant_set_reconciliation" format="default"/>
</t>
<t>
- This document defines the normative wire format of resource records, resolution processes,
- cryptographic routines and security considerations for use by implementors.
- SETU requires a bidirectional secure communication channel between the two parties.
- Specification of the communication channel is out of scope of this document.
+ This document defines the normative wire format of resource records, resolution processes,
+ cryptographic routines and security considerations for use by implementors.
+ SETU requires a bidirectional secure communication channel between the two parties.
+ Specification of the communication channel is out of scope of this document.
</t>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
@@ -1600,7 +1600,7 @@ FUNCTION get_bucket_id (key, number_of_buckets_per_element, ibf_size)
<t>
The <em><xref target="messages_request_full" format="title" /></em> message is sent by the initiating peer in <strong>Expect SE</strong> state to the receiving peer, if
the operation mode "<xref target="modeofoperation_full-sync" format="title" />" is
- determined to be the superior <xref target="modeofoperation" format="title" /> and that it is the better choice that
+ determined to be the superior <xref target="modeofoperation" format="title" /> and that it is the better choice that
the other peer sends his elements first. The initiating peer changes after sending the <em><xref target="messages_request_full" format="title" /></em> message into
<strong>Full Receiving</strong> state.
</t>
@@ -1659,7 +1659,7 @@ FUNCTION get_bucket_id (key, number_of_buckets_per_element, ibf_size)
<t>
The <em><xref target="messages_send_full" format="title" /></em> message is sent by the initiating peer in <strong>Expect SE</strong> state to the receiving peer if
the operation mode "<xref target="modeofoperation_full-sync" format="title" />" is
- determined as superior <xref target="modeofoperation" format="title" /> and that it is the better choice that the
+ determined as superior <xref target="modeofoperation" format="title" /> and that it is the better choice that the
peer sends his elements first. The initiating peer changes after sending the <em><xref target="messages_request_full" format="title" /></em> message into
<strong>Full Sending</strong> state.
</t>
@@ -2557,7 +2557,7 @@ FUNCTION END
<t>
In order to calculate this plausibility, in Summmermatters paper <xref target="byzantine_fault_tolerant_set_reconciliation" format="default"/>
a formula was developed, which depicts the probability with which one
- can calculate the corresponding plausibility based on the number of
+ can calculate the corresponding plausibility based on the number of
new and repeated elements after each received element.
</t>
<t>
