[lsd0003] branch master updated: Fixed some typos and rearanged intro

[gnunet]

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 77d72f6  Fixed some typos and rearanged intro
77d72f6 is described below

commit 77d72f6dd3b7e29b67f24124d5a5c25889a0e52d
Author: Elias Summermatter <elias.summermatter@seccom.ch>
AuthorDate: Mon Dec 21 14:08:04 2020 +0100

    Fixed some typos and rearanged intro
---
 draft-summermatter-set-union.xml | 55 ++++++++++++++++++++--------------------
 1 file changed, 28 insertions(+), 27 deletions(-)

diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index c42e198..27be5cb 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -74,25 +74,29 @@
             <t>
                 This document describes the Byzantine Fault Tolerant Set 
Reconciliation used to efficient and securely
                 synchronize two sets of elements in a peer-to-peer network. It 
provides cryptographic and
-                probabilistic proceedings to discover dishonest and bad 
behaving peers. The Protocol should prevent
-                bad acting peers from wasting resources by sending wrong 
formed elements, pretending to have more elements
-                than the peer actually has or requesting more than the full 
set from a peer. This is for example achieved by
+                probabilistic proceedings to discover dishonest and bad 
behaving peers.
+            </t>
+            <t>
+                The Protocol should prevent bad acting peers from waisting 
resources by sending wrong formed elements, pretending to have a multiple
+                of elements or request more elements than the size of the full 
set. This is achieved by
                 remembering how much elements already have been sent and how 
many elements are possible by some real world
-                limiting factor in E-Voting this for example is the people who 
are permitted to vote. Another probabilistic
-                approach to discover bad behaving peers is sampling, in this 
case a the peer has to prove to the other peer
-                that the peer has the amount of elements he claims to have. To 
prove this the verifying peer chooses some
-                random salt and sends the salt to the proving peer. The 
proving peer then salts the hash of elements with the given
-                salt. In the next step the proving peer calculates the modulo 
(depending on the set sized difference) of the new
-                hashes and sends all the elements where the modulo is 0(?) to 
the verifying peer.
-                As soon as the verifying peer has received the elements the 
verifying peer can verify that all the elements
-                are valid and in the right split of the set then the verifying 
peer can assured with a high probability
+                limiting factor in E-Voting this for example is the people who 
are permitted to vote.
+            </t>
+            <t>
+                Another probabilistic approach to discover bad behaving peers 
is sampling, in this case the proving peer need
+                to prove to the verifying peer that he really has the amount 
of elements he claims to have. To prove this the verifying peer chooses some
+                random salt and sends the salt to the proving peer. The 
proving peer salts the hash of elements with the given
+                salt from the verifying peer. Then the proving peer calculates 
the new hashes modulo a number depending on the set sized difference and
+                sends all the elements where the modulo calculation equals 
0(?) to the verifying peer.
+                As soon as the verifying peer receives the elements the 
verifying peer can verify that all the elements
+                are valid and the modulo calculation equals 0 then the 
verifying peer can be assured with a high probability
                 that the peer is honest about his set size.
             </t>
              <t>
                 The Byzantine Fault Tolerant Set Reconciliation can be used in 
a variety of different fields of application,
                 primarily in Bulletin Boards where multipart computation is 
required.
-                Some real world application are for example in GNS the 
distribute revocations over the peer-to-peer network
-                or it could be used as a central component in distributed 
E-Voting systems to exchange the votes between peer
+                Some real world applications are the distributed revocations 
in the GNS peer-to-peer network
+                or it can be used as a central component in distributed 
E-Voting systems to exchange the votes between peer
                 who do not trust each other (Zero-Trust).
             </t>
             <t>
@@ -117,15 +121,12 @@
                 "OPTIONAL" in this document are to be interpreted as described
                 in<xref target="RFC2119"/>.
             </t>
-            <t>
-
-            </t>
         </section>
 
         <section anchor="contributors" numbered="true" toc="default">
         <name>Contributors</name>
         <t>
-            The original GNU NET implementation of the  Byzantine Fault 
Tolerant Set Reconciliation has been mainly
+            The original GNU NET implementation of the  Byzantine Fault 
Tolerant Set Reconciliation has mainly been
             written by Florian Dold and Christian Grothoff.
         </t>
         </section>
@@ -311,7 +312,7 @@
                         To demonstrate the set difference operation we compare 
IBF-A with IBF-B and generate as described
                         IBF-AB
                     </t>
-                    <t>IBF-A:</t>
+                    <t>IBF-A containing elements with hash 0101 and 4242:</t>
                     <figure anchor="figure_ibf_setdiff_A">
                         <artwork name="" type="" align="left" alt=""><![CDATA[
              bit-1          bit-2        bit-3         bit-4
@@ -322,7 +323,7 @@
         +-------------+-------------+-------------+-------------+
                  ]]></artwork>
                     </figure>
-                    <t>IBF-B:</t>
+                    <t>IBF-B containing elements with hash 4242 and 5050</t>
                     <figure anchor="figure_ibf_setdiff_B">
                         <artwork name="" type="" align="left" alt=""><![CDATA[
              bit-1          bit-2        bit-3         bit-4
@@ -333,7 +334,7 @@
         +-------------+-------------+-------------+-------------+
                  ]]></artwork>
                     </figure>
-                <t>IBF-AB (XOR value and subtract count):</t>
+                <t>IBF-AB XOR value and subtract count:</t>
                 <figure anchor="figure_ibf_setdiff_AB">
                     <artwork name="" type="" align="left" alt=""><![CDATA[
              bit-1          bit-2        bit-3         bit-4
@@ -344,11 +345,10 @@
         +-------------+-------------+-------------+-------------+
                  ]]></artwork>
                 </figure>
-                <t>
-                    In IBF-AB there are 3 pure buckets and its obvious that in 
the IBF-A were the elements with hash
-                    0101 and 4242 and in the IBF-B where the elements with the 
hash 4242 and 5050. In IBF-A the element
-                    wit the hash 5050 is missing (-1 in bit-3) while in IBF-B 
the element with the hash 0101 is missing
-                    (1 in bit-1 and bit-2).
+                <t>After calculating and decoding the IBF-AB its clear that in 
IBF-A the element with the hash 5050
+                    is missing (-1 in bit-3) while in IBF-B the element with 
the hash 0101 is missing
+                    (1 in bit-1 and bit-2). The element with hash 4242 is 
present in IBF-A and IBF-B and is
+                    removed by the set difference operation (bit-4).
                 </t>
             </section>
 
@@ -375,7 +375,6 @@
                     how big the difference between two sets is by adding the 
number of extracted hashes up (C) and scale it
                     by the expected number of elements (E) in the remaining 
unencoded IBF's (C*E=[estimated count of objects]).
                     If no of the SE decoded choose a smaller stratum or try a 
other hash function.
-
                 </t>
             </section>
         </section>
@@ -414,7 +413,9 @@
                     In all other cases the initiating peer sends all set 
elements to the other peer followed by the <em>Full Done</em> message and
                     changes into <strong>Full Sending</strong> state.
                 </t>
-
+                <t>
+                ############# Statemaschine diagram full mode 
##################
+                </t>
                 <t><strong>STATES:</strong></t>
                 <dl>
                     <dt><strong>Expecting IBF:</strong></dt>

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.