doc: minor formatting chore

doc/src/arch/anonymous_assets.md

@@ -98,4 +98,4 @@ blinding factor for the amounts.
 
 ![](diagram-dkzk.png)
 
-*Note: In the diagram $s$ correspond to the $\rho$*
+> Note: In the diagram $s$ correspond to the $\rho$*

doc/src/arch/consensus.md

@@ -425,11 +425,11 @@ following properties:
 2. *One-way*, for any $y ∈ 𝕀$, we are unable to construct an $x ∈ ℕ$
    such that $H(x) = y$.
 
-Note: the above notions rely on purely algebraic properties of $H$
-without requiring the machinery of probability. The second property of
-being one-way is a stronger notion than $\ran(H)$ being statistically
-random. Indeed if the probability is non-zero then we could find such
-an $(x, y)$ which breaks the one-way property.
+> Note: the above notions rely on purely algebraic properties of $H$
+> without requiring the machinery of probability. The second property
+> of being one-way is a stronger notion than $\ran(H)$ being
+> statistically random. Indeed if the probability is non-zero then we
+> could find such an $(x, y)$ which breaks the one-way property.
 
 **Theorem:** *given a hash function $H : ℕ → 𝕀$ as defined above, it's
 impossible to construct two distinct sequences $𝐚 = (a₁, …, aₘ)$ and

doc/src/arch/net/p2p-network.md

@@ -196,8 +196,8 @@ Apps should be able to configure:
 
 * Reject hosts, for example based off current overall resource
   utilization or the host addr.
-    * Note: we have a configurable setting called `blacklist` which
-      allows us to reject hosts by addr.
+> Note: we have a configurable setting called `blacklist` which allows
+> us to reject hosts by addr.
 * Accounting abstraction for scoring connections.
 
 ## Swarming

doc/src/arch/sc/sc.md

@@ -314,8 +314,8 @@ which simulates the previous trace.
 ~~State changes occur linearly after all `process()` calls have passed
 successfully.~~
 
-NOTE: we can iterate depth first through the tree to simulate the normal
-calling pattern.
+> Note: we can iterate depth first through the tree to simulate the
+> normal calling pattern.
 
 An upside of this strict separation, is that it makes reentrancy attacks
 impossible. Say for example we have this code:

doc/src/misc/tau.md

@@ -106,7 +106,7 @@ for a description which allows entering multiline text.
 
 #### Modify tasks
 
-Note: mod commands are: start, open, pause, stop and modify.
+> Note: mod commands are: start, open, pause, stop and modify.
 
 ```shell
 % tau 5 stop                    # will stop task 5

doc/src/spec/contract/dao/concepts.md

@@ -1,42 +1,47 @@
 # Concepts
 
-The governance process is divided in a few steps that are outlined below:
+The governance process is divided in a few steps that are outlined
+below:
 
 * **Propose:** a proposal is submitted to the blockchain.
 * **Vote:** governance token holdens can vote on the proposal.
-* **Exec:** if the proposal passes within the time limit then the proposal is
-  executed.
+* **Exec:** if the proposal passes within the time limit then the
+  proposal is executed.
 
-> Note:
-> There is a special case where a proposal can be executed before voting period
-> passes, if its strongly supported, based on the configured early execution quorum.
+> Note: There is a special case where a proposal can be executed before
+> voting period passes, if its strongly supported, based on the
+> configured early execution quorum.
 
 ## Propose
 
-To prevent spam, proposals must be submitted by holders with a certain number
-of governance tokens and the DAO proposers key. Several members of the DAO can
-add inputs separately to a proposal before it is posted on chain so that their
-combined inputs meet the proposal governance token limit.
+To prevent spam, proposals must be submitted by holders with a certain
+number of governance tokens and the DAO proposers key. Several members
+of the DAO can add inputs separately to a proposal before it is posted
+on chain so that their combined inputs meet the proposal governance
+token limit.
 
 Once proposals are posted on chain, they are immediately active.
 
 ### Proposal States
 
 * *Active*: the proposal is open to voting.
-* *Expired*: the proposal passed its duration and can no longer be voted on.
-* *Accepted*: the proposal gained sufficient votes but is not yet executed.
-* *Executed*: the proposal was accepted and has been confirmed on chain.
+* *Expired*: the proposal passed its duration and can no longer be
+  voted on.
+* *Accepted*: the proposal gained sufficient votes but is not yet
+  executed.
+* *Executed*: the proposal was accepted and has been confirmed on
+  chain.
 
 ## Vote
 
 ### Participants
 
-*Participants* are users that have the right to vote on proposals. Participants
-are holders of governance tokens specified in the DAO.
+*Participants* are users that have the right to vote on proposals.
+Participants are holders of governance tokens specified in the DAO.
 
-Note that only participants from before the proposal is submitted on chain
-are eligible to vote. That means receivers of governance tokens after a proposal is
-submitted will *not* be eligible to vote.
+Note that only participants from before the proposal is submitted on
+chain are eligible to vote. That means receivers of governance tokens
+after a proposal is submitted will *not* be eligible to vote.
 
 There are currently two voting options:
 
@@ -45,22 +50,23 @@ There are currently two voting options:
 
 ### Voting Period
 
-Once a proposal passes its duration, which is measured in 4 hour block windows, participants can
-no longer vote on the proposal, and it is considered *expired*.
+Once a proposal passes its duration, which is measured in 4 hour block
+windows, participants can no longer vote on the proposal, and it is
+considered *expired*.
 
 ### Quorum
 
-Quorum is defined as the minimal threshold of participating total governance tokens needed for
-a proposal to pass. Normally this is implemented as min % of voting power, but we do this in
-absolute value.
+Quorum is defined as the minimal threshold of participating total
+governance tokens needed for a proposal to pass. Normally this is
+implemented as min % of voting power, but we do this in absolute value.
 
 ### Early Execution Quorum
-Early execution quorum is defined as the minimal threshold of participating total tokens needed
-for a proposal to be considered strongly supported, enabling early execution. Must be greater
-than or equal to normal quorum.
+Early execution quorum is defined as the minimal threshold of
+participating total tokens needed for a proposal to be considered
+strongly supported, enabling early execution. Must be greater than or
+equal to normal quorum.
 
 ### Approval Ratio
 
-The approval ratio is defined as the minimum proportion of yes votes for the
-proposal to be accepted.
-
+The approval ratio is defined as the minimum proportion of yes votes
+for the proposal to be accepted.

doc/src/spec/crypto-schemes.md

@@ -66,8 +66,9 @@ $$ \mathcal{X}((x, y)) = x $$
 $$ \mathcal{Y}(∞_{Eₚ}) = 0 $$
 $$ \mathcal{Y}((x, y)) = y $$
 
-**Note:** There is no $P = (0, y) ∈ Eₚ$ so $\mathcal{X}(P) = 0 ⟹  P = ∞$.
-Likewise there is no $P = (x, 0) ∈ Eₚ$ so $\mathcal{Y}(P) = 0 ⟹  P = ∞$.
+> Note: There is no $P = (0, y) ∈ Eₚ$ so $\mathcal{X}(P) = 0 ⟹  P = ∞$.
+> Likewise there is no $P = (x, 0) ∈ Eₚ$ so
+> $\mathcal{Y}(P) = 0 ⟹  P = ∞$.
 
 ### Hashing to $𝔽ₚ$
 
@@ -112,10 +113,10 @@ $$ ℙₚ2𝔹³² = \begin{cases}
 ℕ2𝔹³²(\mathcal{X}(P) + 2²⁵⁵\t{sgn}(\mathcal{Y}(P)) & \text{otherwise}
 \end{cases} $$
 
-**Security note:** apart from the case when $P = ∞$, this function is mostly
-constant time. In cases such as key agreement, where constant time decryption
-is desirable and $P ≠ ∞$ is mostly guaranteed, this provides a strong
-approximation.
+> Security note: apart from the case when $P = ∞$, this function is
+> mostly constant time. In cases such as key agreement, where constant
+> time decryption is desirable and $P ≠ ∞$ is mostly guaranteed, this
+> provides a strong approximation.
 
 ## Group Hash
 

doc/src/start-here.md

@@ -108,8 +108,8 @@ Source code is under `src/` subdirectory. Main interesting modules are:
       are anonymous including the token weighted vote amount, and user
       identity. You cannot see who is in the DAO.
 
-NOTE: We try to minimize external dependencies in our code as much as
-possible. We even try to limit dependencies within submodules.
+> Note: We try to minimize external dependencies in our code as much as
+> possible. We even try to limit dependencies within submodules.
 
 Inside `bin/` contains utilities and applications:
 

doc/src/testnet/atomic-swap.md

@@ -1,22 +1,24 @@
 # Atomic Swaps
 
-In order to do an atomic swap with someone, you will first have to agree
-on what tokens you wish to swap. For example, let's say you want to swap
-`40` `ANON` for your counterparty's `20` `DAWN`. You can do this tutorial
-with a real counterparty or with yourself. This tutorial assumes the
-counterparty is yourself, but we will indicate which steps differ so
-you should be able to do the tutorial with a real counterparty as well.
+In order to do an atomic swap with someone, you will first have to
+agree on what tokens you wish to swap. For example, let's say you want
+to swap `40` `ANON` for your counterparty's `20` `DAWN`. You can do
+this tutorial with a real counterparty or with yourself. This tutorial
+assumes the counterparty is yourself, but we will indicate which steps
+differ so you should be able to do the tutorial with a real
+counterparty as well.
 
 The swap uses one coin per party so the counterparty only sees the
 single coin you're using, not your other coins.
 
-Note: A "coin" is a single cryptographic record. Your wallet balance is
-the sum of all coins you own, and each coin must be spent entirely.
+> Note: A "coin" is a single cryptographic record. Your wallet balance
+> is the sum of all coins you own, and each coin must be spent
+> entirely.
 
-You must use a coin worth the exact amount you want to swap. To create a
-smaller coin denomination, send yourself the amount you want to swap. Then
-check you have a spendable coin to swap with. Note that the coin overview
-might look very different depending on your activity:
+You must use a coin worth the exact amount you want to swap. To create
+a smaller coin denomination, send yourself the amount you want to swap.
+Then check you have a spendable coin to swap with. Note that the coin
+overview might look very different depending on your activity:
 
 ```shell
 drk> wallet coins
@@ -33,7 +35,6 @@ drk> wallet coins
 
 You'll have to initiate the swap and build your half of the swap tx:
 
-
 ```shell
 drk> otc init 40.0:20.0 ANON:DAWN > half_swap
 ```
@@ -48,9 +49,9 @@ drk> otc join < half_swap > full_swap
 The counterparty can now send it back to you. Finally, to make the swap
 transaction valid, you need to sign it as well.
 
-Note: If you are doing this tutorial by yourself, you don't need to send
-the `half_swap` or `full_swap` file anywhere, and can just create the
-`full_swap` followed by the `signed_swap` directly.
+> Note: If you are doing this tutorial by yourself, you don't need to
+> send the `half_swap` or `full_swap` file anywhere, and can just
+> create the `full_swap` followed by the `signed_swap` directly.
 
 ```shell
 drk> otc sign < full_swap > signed_swap

doc/src/testnet/contract.md

@@ -23,17 +23,19 @@ $ cd smart-contract
 ```
 
 We will use the provided Makefile to generate the contract WASM bincode
-and its client. The Makefile uses [zkas][5], DarkFi's zero-knowledge proof
-circuit compiler, to do this.
+and its client. The Makefile uses [zkas][5], DarkFi's zero-knowledge
+proof circuit compiler, to do this.
 
 Running `make` will compile the ZK proof circuits that protect the
-contract's privacy, build the WASM module that runs on the DarkFi network,
-and build a command-line client for interacting with the contract.
+contract's privacy, build the WASM module that runs on the DarkFi
+network, and build a command-line client for interacting with the
+contract.
 
 We first need to ensure the Makefile is configured so that it can find
-the `zkas` binary. That might mean you need to modify the path shown below.
+the `zkas` binary. That might mean you need to modify the path shown
+below.
 
-```
+```makefile
 # Path to the zkas compiler (or just `zkas` if it's in your $PATH)
 ZKAS = ../darkfi/zkas
 ```
@@ -63,10 +65,11 @@ return back to your `drk` interactive shell.
 
 Each contract is controlled by a secret key, from which its Contract
 ID derives. To deploy a smart contract, we first need to generate an
-authority keypair. The Contract ID shown in the outputs is a placeholder
-for the one that will be generated from you. In the rest of the guide, use
-the one you generated by replacing the corresponding placeholder. We can
-create our own contract authority by executing the following command:
+authority keypair. The Contract ID shown in the outputs is a
+placeholder for the one that will be generated from you. In the rest of
+the guide, use the one you generated by replacing the corresponding
+placeholder. We can create our own contract authority by executing the
+following command:
 
 ```shell
 drk> contract generate-deploy
@@ -177,7 +180,7 @@ Secret key: {IDENTITY_SECRET_KEY}
 Public key: {IDENTITY_PUBLIC_KEY}
 ```
 
-> NOTE: This is a very basic example client so secret keys are used
+> Note: This is a very basic example client so secret keys are used
 > as plaintext for simplicity. Do not run this in a machine with
 > commands history or in a hostile environment where your secret key
 > can be exposed.

doc/src/testnet/dao.md

@@ -150,9 +150,9 @@ Wallet Address: DX7N6v...5Lz8Pp
 
 ## Minting
 
-The parameters shown confirm the DAO was successfully imported. We use the
-DAO name to reference it. Now we can create and broadcast a transaction to
-mint the DAO on-chain (requires holding all its keys):
+The parameters shown confirm the DAO was successfully imported. We use
+the DAO name to reference it. Now we can create and broadcast a
+transaction to mint the DAO on-chain (requires holding all its keys):
 
 ```shell
 drk> dao mint AnonDAO | broadcast
@@ -163,9 +163,9 @@ Broadcasting transaction...
 Transaction ID: 2e7931f200c1485ea7752076e199708b011a504d71e69d60ed606817c5ff4bd5
 ```
 
-Now the transaction has been broadcast to the network. After confirmation
-you should see a leaf position, a mint height and a transaction hash
-when running:
+Now the transaction has been broadcast to the network. After
+confirmation you should see a leaf position, a mint height and a
+transaction hash when running:
 
 ```shell
 drk> dao list AnonDAO
@@ -271,8 +271,8 @@ drk> dao balance AnonDAO
 Now that the DAO has funds, we can create a transfer proposal to send
 tokens somewhere. The proposal will be open to vote for 1 [block
 period][blockwindow](~4h), if we hold the DAO proposer key. Let's
-propose sending 5 of the 10 tokens to our address (we can find that with
-`wallet address`):
+propose sending 5 of the 10 tokens to our address (we can find that
+with `wallet address`):
 
 [blockwindow]: ../spec/contract/dao/model.md#blockwindow
 

doc/src/testnet/merge-mining.md

@@ -156,7 +156,7 @@ or press `p` to pause mining.
 
 ## p2pool setup with merge-mining
 
-> NOTE: `p2pool` uses plain `http` connections for RPC calls, as its
+> Note: `p2pool` uses plain `http` connections for RPC calls, as its
 > assumed to be running on a localnet. Don't run a `p2pool` instance
 > with a `darkfid` instance outside of your network, since someone
 > snooping your traffic can see your wallet address used for the block

doc/src/testnet/node.md

@@ -284,7 +284,7 @@ which wallet:
 $ ./xmrig -u x+1 -r 1000 -R 20 -o 127.0.0.1:18347 -t {XMRIG_THREADS} -u {YOUR_DARKFI_WALLET_ADDRESS}
 ```
 
-> NOTE: All miners should use the lowest possible resources so other
+> Note: All miners should use the lowest possible resources so other
 > people can mine blocks to retrieve `DRK` for testing.
 
 In `darkfid`, you should see a notification like this:

doc/src/testnet/token.md

@@ -2,9 +2,9 @@
 
 Now that you have your wallet set up, you will need some native `DRK`
 in order to be able to perform transactions, since `DRK` is used to pay
-the transaction fees. You can obtain `DRK` either by successfully mining
-a block that gets confirmed or by asking for some from the community on
-`darkirc`.
+the transaction fees. You can obtain `DRK` either by successfully
+mining a block that gets confirmed or by asking for some from the
+community on `darkirc`.
 
 If the latter, don't forget to tell them to add the `--half-split` flag
 when they create the transfer, so you get more than one coin to play
@@ -12,8 +12,8 @@ with. Once your friend has submitted a transaction to the network, it
 should be in the consensus' mempool, waiting for inclusion in the next
 block(s). Depending on your network configuration, confirmation of the
 blocks could take some time. You'll have to wait for this to happen. If
-your `drk` subscription is running, then after some time your new balance
-should be in your wallet.
+your `drk` subscription is running, then after some time your new
+balance should be in your wallet.
 
 ![pablo-waiting0](img/pablo0.jpg)
 
@@ -29,14 +29,14 @@ drk> wallet balance
 
 # Creating tokens
 
-On the DarkFi network, we can mint custom tokens with a given supply. To
-do this, we first need to generate a mint authority keypair, and derive a
-token ID from it.
+On the DarkFi network, we can mint custom tokens with a given supply.
+To do this, we first need to generate a mint authority keypair, and
+derive a token ID from it.
 
-Note: The token data shown in the outputs (Token ID, Mint Authority,
-Token Blind) are placeholders for the data that will be created by
-you. For the rest of the guide, replace the placeholder token data with the
-data that you generate.
+> Note: The token data shown in the outputs (Token ID, Mint Authority,
+> Token Blind) are placeholders for the data that will be created by
+> you. For the rest of the guide, replace the placeholder token data
+> with the data that you generate.
 
 For this tutorial we will be minting two sets of tokens. For each token
 we will create the mint authority keypair that sets the token ID and
@@ -61,8 +61,8 @@ drk> token list
 
 ```
 
-Now execute the command again to generate the mint authority for a second
-set of tokens.
+Now execute the command again to generate the mint authority for a
+second set of tokens.
 
 ```shell
 drk> token generate-mint
@@ -84,9 +84,9 @@ drk> token list
 
 ## Aliases
 
-To make our life easier, we can create token ID aliases, which we can use
-instead of the token ID when performing transactions. Multiple aliases
-per token ID are supported.
+To make our life easier, we can create token ID aliases, which we can
+use instead of the token ID when performing transactions. Multiple
+aliases per token ID are supported.
 
 The native token alias `DRK` should already exist, and we can use that
 to refer to `DRK` when executing transactions using it.
@@ -101,8 +101,8 @@ drk> alias show
  DRK   | 241vANigf1Cy3ytjM1KHXiVECxgxdK4yApddL8KcLssb
 ```
 
-Note: these aliases are local to your machine. When exchanging with
-other users, always verify that your aliases' token IDs match.
+> Note: these aliases are local to your machine. When exchanging with
+> other users, always verify that your aliases' token IDs match.
 
 Now let's create aliases for the two token IDs generated earlier:
 
@@ -130,8 +130,9 @@ drk> alias show
 
 ## Mint transaction
 
-Now let's mint some tokens for ourselves. First grab your wallet address,
-then create the token mint transaction, and finally - broadcast it:
+Now let's mint some tokens for ourselves. First grab your wallet
+address, then create the token mint transaction,
+and finally - broadcast it:
 
 ```shell
 drk> wallet address