wiki commit

glossary/block.md

@@ -0,0 +1,8 @@
+<div class="cwikmeta">
+{
+"title":"Block",
+"related":[]
+} </div>
+
+
+A block is a group of (transactions)[/glossary/transaction] that have been committed to the blockchain.

glossary/constraint__script.md

@@ -0,0 +1,10 @@
+<div class="cwikmeta">
+{
+"title":"Constraint Script",
+"related":["/glossary/output__script","/glossary/redeem__script","/glossary/input__script"]
+}
+</div>
+
+Bitcoins are not sent to addresses, they are actually encumbered by a program (generally called a script, which is a term for a short, simple program that typically focuses on one thing).  Spending transactions supply input parameters (in the form of an input script) to this constraint script.  If the constraint script returns success, the coins are able to be spent.  Otherwise the transaction is invalid.
+
+The term "constraint script" refers generally to any script that adds spending constraints.  In Bitcoin, there are actually two different scripts that can do this -- the [output script](/glossary/output__script) and the [redeem script](/glossary/redeem__script).

glossary/hash__identifier.md

@@ -0,0 +1,11 @@
+A hash identifier is sequence of bytes derived from some source data that forms a probabilistically globally unique identifier that can be used to reference the source data.
+
+Hash identifiers are calculated by running a cryptographically secure hash function on the source data.  Due to the properties of cryptographic hash functions, it is theoretically very hard (and in practice, impossible given current or future processing power) to find 2 different pieces of source data that form the same hash identifier in a reasonable time frame.  
+
+This allows hash identifiers to be used in multiple applications, most importantly:
+
+ - As a global "pointer" or "reference" to a piece of source data
+ - As a "fingerprint" that identifies source data.
+ - As a "commitment" that allows an entity to prove it knows some data at this time, without revealing that data until a later time. 
+
+In Bitcoin, hash identifiers (sometimes just called a "hash" for short) are generally calculated using a double sha256 algorithm: SHA256(SHA256(source data)), resulting an a 32 byte hash identifier.  However, when a smaller hash is desirable and Wagner's Birthday attack cannot be deployed, bitcoin sometimes uses RIPEMD(SHA256(source data)) which results in a 20 byte hash identifier.  Notably, this is used in standard ([P2PKH](/glossary/p2pkh)) bitcoin addresses.

glossary/out__point.md

@@ -0,0 +1 @@
+see [outpoint](/glossary/outpoint)

glossary/p2pkh.md

@@ -0,0 +1,4 @@
+<!-- TITLE: P2PKH -->
+<!-- SUBTITLE: Pay to Public Key Hash (script) -->
+
+A P2PKH script is the most common [constraint script](/glossary/constraint_script).

glossary/p2sh.md

@@ -0,0 +1,12 @@
+<!-- TITLE: P2SH -->
+<!-- SUBTITLE: Pay To Script Hash (script) -->
+
+Pay to script hash is a special payment destination that consists of two [constraint scripts](/glossary/constraint__script).  The first is the output script which must follow a specific form that is recognised by bitcoin software.  This output script requires a parameter which is actually another constraint script, called the [redeem script](/glossary/redeem_script).  To spend a P2SH output, the input script therefore supplies the redeem script and additional data as stack parameters.  The bitcoin software verifies that the redeem script's hash matches that in the output script, and then executes the redeem script (which uses the additional data pushed by the input script).  Since the redeem script stack item is executed without any explicit instruction to do so, the P2SH script form breaks the original [script execution model](script/execution__model).
+
+## Comparison with P2PKH
+
+The P2SH form places all interesting constraints in the redeem script, whereas previously these constraints were placed in the output script.  It is arguably better to place constraints in the redeem script for several reasons:
+1. Simple Addresses: P2SH allows the receiver to have funds sent to any constraint script, by providing the sender with an address.  Previously, a new address form had to be created for every new script type, or in theory the entire constraint script could be sent from receiver to sender (no protocol to do this has been specced or implemented).
+2. Information Containment:  In the original model, the sender places constraints on the receiver's __next__ spend.  But what the receiver does with the money next is and should be irrelevant to the sender, except in special circumstances.  In those circumstances, P2SH still works -- the receiver and sender can agree on the redeem script beforehand. 
+3. Space Efficiency: P2SH defers providing the redeem script until it is used, replacing it with a 20 byte hash.  For non-trivial scripts, this will make the [UTXO set](/glossary/UTXO__set) smaller.
+4. Privacy: P2SH does not reveal the script contents until it is spent.  One drawback of this is that it is not possible to determine whether certain instructions are in use or not.  This makes retirement of opcodes impossible.  However, its also possible for people to create transactions and not commit them to the blockchain, so the viability of opcode retirement is questionable anyway.

glossary/redeem__script.md

@@ -0,0 +1,3 @@
+<!-- TITLE: Redeem Script -->
+
+The redeem script is a constraint script that is used in the P2SH payment mode.  The redeem script is provided by the spender's input script, however, it is chosen by the original spender.  This is possible because the output script constrains the redeem script's hash to match a specific value.  In P2SH this is the only constraint allowed by the output script, so the redeem script must implement all other constraints (such as signature checking).

glossary/transaction.md

@@ -0,0 +1,4 @@
+<!-- TITLE: Transaction -->
+<!-- SUBTITLE: means of transfer -->
+
+A transaction is how transfers are made in the blockchain.  It comprises of a set of input [UTXOs](/glossary/UTXO) which will be spent to a set of output [UTXOs](/glossary/UTXO).  The blockchain mining and full node software ensures that every transaction follows the blockchain's rules before admitting the transaction into a block.  Verification of a transaction ensures that the input UTXOs have not already been spent, that quantity of input coins is greater than or equal to the quantity of output coins (any extra is given to the miner as a transaction fee), and that the transaction satisifies all spending constraints specified by the UTXO's constraint scripts.

glossary/utxo.md

@@ -0,0 +1,4 @@
+<!-- TITLE: UTXO -->
+<!-- SUBTITLE: Unspent Transaction Output -->
+
+An unspent transaction output, also called a "coin", is a record in the blockchain of money that can be spent (used as an input in a new transaction).  It is essentially a positive balance in the blockchain ledger, and contains a quantity and a spending constraint script.