Merge pull request #2 from alp-bitcoin/patch-1

Fixed typos.
TierNolan · Jan 2, 2016 · 90367c0 · 90367c0
2 parents 038a4c1 + 2f06ee5
commit 90367c0
Showing 1 changed file with 2 additions and 2 deletions.
diff --git a/bip-codeshark-jl2012-segwit.mediawiki b/bip-codeshark-jl2012-segwit.mediawiki
@@ -202,11 +202,11 @@ Bitcoin right now only has two real security models. A user either runs a full-n
 
 In the current Bitcoin protocol, it is possible to generate compact fraud proof for almost all rules except a few:
 
-# It is not possible to proof a miner has introduced too many Bitcoins in the coinbase transaction outputs without showing the whole block itself and all input transactions.
+# It is not possible to prove a miner has introduced too many Bitcoins in the coinbase transaction outputs without showing the whole block itself and all input transactions.
 # It is not possible to prove the violation of any block specific constraints, such as size and sigop limits, without showing the whole block (and all input transactions in the case of sigop limit)
 # It is not possible to prove the spending of a non-existing input without showing all transaction IDs in the blockchain way back to the genesis block.
 
-It is possible to proof the first 2 types of fraud if a block is committed to a Merkle-sum-tree of the fee, size, and sigop count of each transaction. It is also possible to proof the last type of fraud if a block is committed to a Merkle tree with the originating block height and transaction index of all inputs. These commitments could be included in the extensible witness commitment through a soft fork and will be transparent to nodes that do not understand such new rules.
+It is possible to prove the first 2 types of fraud if a block is committed to a Merkle-sum-tree of the fee, size, and sigop count of each transaction. It is also possible to prove the last type of fraud if a block is committed to a Merkle tree with the originating block height and transaction index of all inputs. These commitments could be included in the extensible witness commitment through a soft fork and will be transparent to nodes that do not understand such new rules.
 
 === New script system ===
 Since a version byte is pushed before a witness program, and programs with unknown versions are always considered as anyone-can-spend script, it is possible to introduce any new script system with a soft fork. The witness as a structure is not restricted by any existing script semantics and constraints, the 520-byte push limit in particular, and therefore allows arbitrarily large scripts and signatures.