Merge pull request #46 from tvolk131/hbbft_to_alephbft

Switch HBBFT to AlephBFT

docs/CommonTerms/HBBFTConsensus.md → docs/CommonTerms/AlephBFTConsensus.md

@@ -9,9 +9,9 @@ Because it takes such a central part in a federated mint we will begin with expl
 
 A byzantine fault not only allows a party to go offline, but also to maliciously continue participating in the protocol. In the following we will use  `n` as the total number of participants in a protocol and `f` as the maximum amount of faulty ones among them.
 
-We define a BFT consensus algorithm as an algorithm that allows all honest parties to agree on a common set of items as long as fewer than `f + 1` of the participants are malicious. 
+We define a BFT consensus algorithm as an algorithm that allows all honest parties to agree on a common set of items as long as fewer than `f + 1` of the participants are malicious. These items may be contributed by any participant and there should be no risk of targeted censorship of items.
 
-These items may be contributed by any participant and there should be no risk of targeted censorship of items. One such protocol is [Honey Badger](https://eprint.iacr.org/2016/199.pdf) BFT (HBBFT). We will mainly use it as a reference for BFT consensus properties but note that similar but more efficient ones exist (most notably [Dumbo](https://eprint.iacr.org/2020/841.pdf) and [hybrids](https://arxiv.org/pdf/2103.09425) built on top of it).
+The BFT consensus algorithm used by Fedimint is [AlephBFT](https://arxiv.org/pdf/1908.05156.pdf). We will mainly use it as a reference for BFT consensus properties but note that similar protocols exist (most notably [Dumbo](https://eprint.iacr.org/2020/841.pdf) and [hybrids](https://arxiv.org/pdf/2103.09425) built on top of it).
 
 We generally assume the consensus runs in rounds, producing a common subset of the contributions made by the participants. At the start of each round each participant `i` is expected to propose a set of items `Ci` to the consensus. 
 

docs/GettingStarted/03-What-is-a-Fedimint.md

@@ -32,7 +32,7 @@ All of these are supported by three core technology components, discussed in gre
 
 Fedimint guardians are the technical community members responsible for setting up and running the Federated Chaumian eCash system. They custody and backup funds and are responsible for the minting and redemption of eCash notes, that are claims against the Bitcoin reserves. A fedimint member is explicitly trusting that the federation guardians will not form a majority quorum to collude to steal user funds.
 
-The guardians coordinate using a [distributed consensus protocol (HBBFT)](../CommonTerms/HBBFTConsensus) which is part of the Fedimint software deployed on personal servers. The consensus mechanism is Asynchronous, Byzantine Fault Tolerant, and can survive and operate even if a minority of individual federation guardians disconnect from the network. If a majority of the federation guardians disconnect, the consensus protocol will halt execution until a quorum of guardians come back online, at which point the consensus will continue.
+The guardians coordinate using a [distributed consensus protocol (AlephBFT)](../CommonTerms/AlephBFTConsensus) which is part of the Fedimint software deployed on personal servers. The consensus mechanism is Asynchronous, Byzantine Fault Tolerant, and can survive and operate even if a minority of individual federation guardians disconnect from the network. If a majority of the federation guardians disconnect, the consensus protocol will halt execution until a quorum of guardians come back online, at which point the consensus will continue.
 
 The federation guardians are specific roles within the system that can only be added or removed with consensus of the existing set of guardians.
 

docs/MiniMintDetails/Consensus.md

@@ -24,7 +24,7 @@ set of items as long as less or equal than
 
 $$f$$
 
-of the participants are malicious. These items may be contributed by any participant and there should be no risk of targeted censorship of items. One such protocol is [Honey Badger] BFT (HBBFT). We will mainly use it as a reference for BFT consensus properties but note that similar but more efficient ones exist (most notably [Dumbo] and [hybrids] built on top of it).
+of the participants are malicious. These items may be contributed by any participant and there should be no risk of targeted censorship of items. One such protocol is [AlephBFT]. We will mainly use it as a reference for BFT consensus properties but note that similar but more efficient ones exist (most notably [Dumbo] and [hybrids] built on top of it).
 
 We generally assume the consensus to run in rounds, producing a common subset of the contributions made by the
 participants. At the start of each round each participant
@@ -64,6 +64,6 @@ $$\frac{1}{3}$$
 
 faulty nodes, so this will also be our assumption when building our protocol on top if not stated otherwise.
 
-[honey badger]: https://eprint.iacr.org/2016/199.pdf
+[alephbft]: https://arxiv.org/pdf/1908.05156.pdf
 [dumbo]: https://eprint.iacr.org/2020/841.pdf
 [hybrids]: https://arxiv.org/pdf/2103.09425

docs/MiniMintDetails/Wallet.md

@@ -83,7 +83,7 @@ The median argument works similarly and we achieve an honest consensus on fee ra
 In some cases it is useful to have access to agreed-upon, fair randomness. Thus every round every participant also
 proposes 32bytes of random data. The ones included in the consensus outcome are then XORed to form the round's
 randomness beacon. We note that this is only safe if the items proposed to the consensus are encrypted till there is
-agreement on which contributions will be included. This is the case for HBBFT. Otherwise an attacker could wait for the
+agreement on which contributions will be included. This is the case for AlephBFT. Otherwise an attacker could wait for the
 other participants to announce their contribution and then adaptively chose his own to influence the outcome.
 
 ## Address Derivation