Minor text corrections to The Periodic Table of Elements sub pages and others

source/elements/asset-issuance/index.md

@@ -13,7 +13,7 @@ edit: https://github.com/ElementsProject/elementsproject.github.io/edit/master/s
 </div>
 
 Users can issue their own confidential assets which represent fungible ownership
-of the underlying asset type representing by the newly created units, which
+of the underlying asset type represented by the newly created units, which
 could theoretically represent any asset including vouchers, coupons, currencies,
 deposits, bonds, shares, etc. (subject to the respective jurisdiction’s
 regulatory requirements).

source/elements/confidential-transactions/index.md

@@ -44,7 +44,7 @@ $ elements-cli sendtoaddress CTEwQjyErENrxo8dSQ6pq5atss7Ym9S7P6GGK4PiGAgQRgoh1iP
 ```
 
 The key difference from Bitcoin is the addition of cryptographic privacy. These
-transactions differ in that the the amounts transferred are kept visible only to
+transactions differ in that the amounts transferred are kept visible only to
 participants in the transaction (and those they designate).
 
 <div class="ui icon info message">
@@ -82,7 +82,7 @@ some important limitations to be aware of.
 For example, the implementation only hides a certain number of the digits of the
 amount of each transaction output, dependent on the range proof's "blinding
 coverage" at a desired precision level.  Subsequently, there is a 'minimum
-confidential amount' that around 0.0001 BTC, and a 'maximum confidential amount'
+confidential amount' of around 0.0001 BTC, and a 'maximum confidential amount'
 that is 2<sup>32</sup> times the minimum amount.
 
 Digits smaller than the minimum will be revealed to observers; for example, if

source/elements/deterministic-pegs/index.md

@@ -10,6 +10,6 @@ edit: https://github.com/ElementsProject/elementsproject.github.io/edit/master/s
 
 Deterministic pegs allow Elements Alpha to carry redeemable testnet coins without any modifications to testnet itself. Transfers into Alpha are validated by all full nodes, optionally with the assistance of an RPC call to a testnet node to validate blockchain membership without the presence of compressed SPV proofs in testnet. Transfers out of Alpha are performed by a federation of functionaries which are trusted to hold the coins for Alpha.
 
-Sidechains, like other alternative chains, can also be secured by merge-mining.  However during a bootstrap period of introduction of a new chain, unless the start of merge mining were very well synchronised, there will be a period of lower hashrate. During the early stages of this bootstrap the chain could have low enough hashrate to present a security risk even against a modest powered attacker. Given the challenges of synchronising something as organic and decentralised by design as bitcoin mining, we therefore need a mechanism to bootstrap chain security.  We start in this release with a threshold of functionaries and are plan for a later version to phase in merge-mining.
+Sidechains, like other alternative chains, can also be secured by merge-mining.  However during a bootstrap period of the introduction of a new chain, unless the start of merge mining is very well synchronised, there will be a period of lower hashrate. During the early stages of this bootstrap the chain could have low enough hashrate to present a security risk even against a modestly powered attacker. Given the challenges of synchronising something as organic and decentralised by design as bitcoin mining, we therefore need a mechanism to bootstrap chain security.  We start in this release with a threshold of functionaries and plan in a later version to phase in merge-mining.
 
 A detailed explanation of the implementation in Elements Alpha can be found in the [blog](/posts/the-federated-peg-in-elements-alpha/).

source/elements/opcodes/index.md

@@ -1,6 +1,6 @@
 ---
 title: New Opcodes
-description: Introduces DETERMINISTICRANDOM and CHECKSIGFROMSTACK, in addition to re-enabling several scripts previously enabled in Bitcoin.
+description: Introduces DETERMINISTICRANDOM and CHECKSIGFROMSTACK, in addition to re-enabling several scripts previously disabled in Bitcoin.
 image: /img/new-opcodes.svg
 source: https://github.com/ElementsProject/elementsproject.github.io/blob/master/source/elements/opcodes/index.md
 edit: https://github.com/ElementsProject/elementsproject.github.io/edit/master/source/elements/opcodes/index.md

source/elements/schnorr-signatures/index.md

@@ -11,8 +11,8 @@ edit: https://github.com/ElementsProject/elementsproject.github.io/edit/master/s
 Instead of DER-encoded ECDSA signatures over the secp256k1 curve, the CHECKSIG and related operators now use densely packed Schnorr signatures over the same curve. The advantages are:
 * Efficient threshold signatures for n-of-n. Multiple Schnorr signatures can be combined to end up with a signature valid for the sum of the public keys, so arbitrarily large n-of-n multisig can be done by only communicating the single sum signature, which can be verified with a single CHECKSIG operation.
 * Smaller signatures (64 bytes instead of 71-72) with none of the problems that DER encodings have caused for Bitcoin.
-Potential support for batch validation (up to a factor 2 speedup to verify groups of 32 signatures at once). This requires knowing the R.y coordinate (ECDSA ignores this) and at the script level, guaranteeing that all signature verification failure results in script failure (i.e., all CHECKSIG operators behave like CHECKSIGVERIFY).
-Stronger security proof.
+* Potential support for batch validation (up to a factor 2 speedup to verify groups of 32 signatures at once). This requires knowing the R.y coordinate (ECDSA ignores this) and at the script level, guaranteeing that all signature verification failure results in script failure (i.e., all CHECKSIG operators behave like CHECKSIGVERIFY).
+* Stronger security proof.
 * Provably no inherent signature malleability, while ECDSA has a known malleability, and lacks a proof that no other forms exist. Note that Witness Segregation already makes signature malleability not result in transaction malleability, however.
 * Slightly faster to sign/verify than ECDSA.
 

source/elements/segregated-witness/index.md

@@ -23,4 +23,4 @@ blocks commit separately to the witness data. This has several advantages:
 * Bitcoin has seen some “Normalized Transaction ID” proposals, but these are effectively subsumed by Segregated Witness, which is both more efficient and more usable, as Normalized Transaction ID mechanisms still require rewriting dependent transactions after inputs are malleated. Such normalization is a necessary building block for higher-layer protocols such as Lightning.
 * As transaction IDs no longer cover the signatures, they remove all forms of transaction malleability, in a much more fundamental way than BIP62 aims to do. This results in a larger class of multi-clause contract constructs that become safe to use.
 * Potential for more efficient SPV output creation proofs (used by lightweight clients), as the signatures can be omitted from the transaction data without breaking the Merkle tree structure.
-Potential for nodes that do not wish to store or verify old transaction signatures, to remove the witness data from disk or not transfer it at all even, reducing blockchain storage/bandwidth amounts by a large factor. In Alpha, the witness data size is even more significant than in Bitcoin, as it also includes large range proofs for the output values.
+* Potential for nodes that do not wish to store or verify old transaction signatures, to remove the witness data from disk or not transfer it at all even, reducing blockchain storage/bandwidth amounts by a large factor. In Alpha, the witness data size is even more significant than in Bitcoin, as it also includes large range proofs for the output values.

source/sidechains/alpha/index.md

@@ -43,7 +43,7 @@ decentralized merge-mining of the sidechain, and ultimately to phase in the full
 2-way peg mechanism.
 
 #### Moving coins between Testnet and Alpha
-See [alpha-README.md](https://github.com/ElementsProject/elements/blob/alpha/alpha-README.md) for instructions on how to transfer testnet coins to the alpha network and back.  Note that there is a lengthy confirmation and contest period that you must wait for a peg transfer to complete.
+See [alpha-README.md](https://github.com/ElementsProject/elements/blob/alpha/alpha-README.md) for instructions on how to transfer testnet coins to the alpha network and back.  Note that there is a lengthy confirmation and contest period that you must wait for in order for a peg transfer to complete.
 
 * [testnet-faucet](https://testnet-faucet.elementsproject.org/)
 * [alpha-faucet](https://alpha-faucet.elementsproject.org/)

source/sidechains/creating-your-own.md

@@ -18,7 +18,7 @@ instructions](https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md)
 to get set up.
 
 ### Creating your own blockchain
-Just like in Bitcoin, Elements can be started in `regtest` mode which allows to
+Just like in Bitcoin, Elements can be started in `regtest` mode which allows you to
 easily create test chains and networks.
 
 1. Start Elements:
@@ -42,7 +42,7 @@ easily create test chains and networks.
   >     NEW_BLOCK=`ec getnewblockhex`
   >     BLOCKSIG=`ec signblock $NEW_BLOCK`
     <div class="ui info message">
-      If there were multiple blocksigners, you'd need to distribute `NEW_BLOCK`, collect signatures, then call `combineblocksigs`.  We'll leave this as an excercise to the reader.
+      If there were multiple blocksigners, you'd need to distribute `NEW_BLOCK`, collect signatures, then call `combineblocksigs`.  We'll leave this as an excercise for the reader.
     </div>
   >     SIGNED_BLOCK=`ec combineblocksigs $NEW_BLOCK \[\"$BLOCKSIG\"\] | jq -r '.hex'`
     * ensure that the output of combineblocksigs has "complete" true

source/sidechains/liquid/index.md

@@ -33,7 +33,7 @@ balances and accounts across the market to avoid ISL, increasing overall capital
 requirements and exposure to the possibility of counterparty risk.
 
 Liquid is a powerful sidechain with wide-reaching implications.  To learn more,
-[read the Liquid announcement](https://www.blockstream.com/2015/10/12/introducing-liquid/).
+[read the Liquid announcement](https://www.blockstream.com/2015/10/12/introducing-liquid.html).
 
 <a href="mailto:[email protected]" class="ui button primary huge">Contact Blockstream To Learn More<i class="ui icon chevron right"></i></a>
 <!-- <a href="https://blockstream.io" class="ui button primary huge">Read the Liquid Whitepaper<i class="ui icon chevron right"></i></a> -->