Merge remote-tracking branch 'bu/master'

glossary/outpoint.md

@@ -1 +0,0 @@
-An outpoint is a (transaction [hash identifier](/glossary/hash__identifier), index pair) that uniquely identifies a particular [UTXO](/glossary/UTXO).

glossary/output__script.md

@@ -1,8 +0,0 @@
-<div class="cwikmeta">
-{
-"title":"Output Script",
-"related":["/glossary/redeem__script","/glossary/input__script"]
-}
-</div>
-
-The output script constrains the subsequent spend of Bitcoins.

glossary/spv.md

@@ -1 +0,0 @@
-SPV is an acronym for "Simplified Payment Validation".

glossary/utxo__set.md

@@ -1,6 +0,0 @@
-<!-- TITLE: UTXO Set -->
-<!-- SUBTITLE: Unspent Transaction Output Set -->
-
-The UTXO set contains information that describes the current spending constraints on every coin in the blockchain at a particular moment (generally "now").  This information is used to determine the validity of new transactions, and to report information such as wallet balances.
-
-This data is extracted from the blockchain, which contains the full history (all transfers, spent or unspent) of all coins since their creation.

objects/bloom__filter.md

@@ -1,17 +0,0 @@
-<div class="cwikmeta">{
-"title":"Bloom Filter",
-"related":["/protocol/p2p/filterload"]
-}</div>
-
-A bloom filter is an imperfect but efficient set membership test.  The filter will never incorrectly report that member is NOT in the set.  However, it may report that a member is in a set when it is actually not.  See [wikipedia](https://en.wikipedia.org/wiki/Bloom_filter), or the [original paper](https://dl.acm.org/citation.cfm?id=362686.362692) for details.   
-
-Therefore bloom filters are often used during set membership testing as a quick pre-check to eliminate most elements.
-
-### Use in the Bitcoin Peer-to-Peer Protocol
-Bloom filters are used in the bitcoin peer-to-peer protocol to filter the transactions and blocks that a client is sent from another node.  The client first "installs" a bloom filter that contains information about the objects it is interested in by sending a [FILTERLOAD](/protocol/p2p/filterload) message to a peer.   The peer will subsequently only provide objects that match the installed filter.
-
-At a minimum, an [SPV](/glossary/SPV) client must insert addresses and [outpoints](/glossary/outpoint) into the bloom filter.  The addresses will cause every transaction that pays INTO the wallet to be reported, and the outpoints will cause every transaction that pays OUT OF the wallet to be reported.
-
-Bitcoin Bloom filters have an additional feature.  Based on the setting of a flag byte, it is possible to direct the peer to automatically insert new data into the bloom filter based on transactions that match.  In particular, outpoints will be automatically inserted that correspond to the outputs of addresses that match the filter.  This facility is extremely important because if a receive and spend occur within the same transaction, the client does not have the opportunity to update the filter.  Bloom filters should therefore be sized with the expectation that new elements will be inserted.
-
-However, due to the bloom filter's tendency to have false positives, these insertions means that unnecessary data will be inserted into the filter, creating even more false positives in a positive feedback loop.  Eventually the node will start sending a lot of unnecessary traffic to the client.  Therefore, it is essential for clients to periodically refresh (using [FILTERLOAD](/protocol/p2p/filterload)) the bloom filter to remove these unnecessary entries.

protocol/blockchain.md

@@ -168,4 +168,4 @@ The serialized genesis block has the hex encoded value of:
     7962E0EA 1F61DEB6 49F6BC3F 4CEF38C4
     F35504E5 1EC112DE 5C384DF7 BA0B8D57
     8A4C702B 6BF11D5F AC000000 00
-    
+

protocol/blockchain/transaction/transaction-signing.md

@@ -1,5 +1,4 @@
-
+# Transaction Signing
-# Transaction Signatures
 
 Transaction signatures are central to how [Bitcoin Cash transactions](/protocol/blockchain/transaction) are generally secured, preventing people other than the intended recipient of funds from spending them.
 Bitcoin Cash signatures are created using [asymmetric cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography) and involve generating a [hash](/protocol/blockchain/hash) of the transaction and performing a signature operation using the sender's private key.

protocol/blockchain/transaction/unlocking-script.md

@@ -5,4 +5,4 @@ This is accomplished by first executing the unlocking script and then executing
 If this execution triggers no failures and leaves a single non-zero (TRUE) value on the stack, the UTXO has been successfully unlocked.
 One way to look at this is that the unlocking script provides an initial state that acts as an inverse to the previously published locking script.
 
-For more information about how script execution works, see [Script](/protocol/blockchain/script).  For information on how signatures (which typically go in the unlocking script) are generated, see [Transaction Signatures](/protocol/blockchain/transaction/signatures).
+For more information about how script execution works, see [Script](/protocol/blockchain/script).  For information on how signatures (which typically go in the unlocking script) are generated, see [Transaction Signatures](/protocol/blockchain/transaction/transaction-signing).