BIP 141: Segregated Witness (Consensus layer) #265

   0 | @@ -0,0 +1,300 @@
   1 | +<pre>
   2 | +  BIP: x
   3 | +  Title: Segregated Witness (Consensus layer)
   4 | +  Author: 

---

 293 | +SPV clients should reject nVersion < 5 blocks if 950 out of 1000 preceding blocks have
 294 | +nVersion >= 5 to prevent false confirmations from the remaining 5% of
 295 | +non-upgraded miners when the 95% threshold has been reached.
 296 | +
 297 | +== Credits ==
 298 | +

---

  32 | +# '''Additional data required for fraud proofs can be added to witness'''. Extra data can be committed that allows short proofs of block invalidity that SPV nodes can quickly verify.
  33 | +#* Backlinks for the outputs spent by the transaction's inputs can be provided. These backlinks consist of a block hash and an offset that thin clients can easily query and check to verify that the outputs exist.
  34 | +#* Sum trees for transaction inputs and outputs can be committed making it possible to construct short proofs that no new coins are created in any noncoinbase transaction and that the miner does not add excessive fees to the coinbase transaction. 
  35 | +
  36 | +==Specification==
  37 | +Maybe a seperate BIP

---

  59 | +used in some tests) to be interpreted as new serialized data.
  60 | +- Rationale for the 0x01 flag byte in between: this will allow us to
  61 | +easily add more extra non-committed data to transactions (like txouts
  62 | +being spent, ...). It can be interpreted as a bitvector.
  63 | +
  64 | +* A new message 'havewitness' is sent after receiving 'verack' to

---

 208 | +# 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.
 209 | +
 210 | +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.
 211 | +
 212 | +=== New script system ===
 213 | +Since all witness programs begin with a version byte, 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.

---

 222 | +With a soft fork, it is possible to introduce a separate witness structure to allow per-input lock-time and relative-lock-time, and a new script system that could sign and manipulate the new data (like BIP65 and BIP112).
 223 | +
 224 | +== Backward compatibility ==
 225 | +As a soft fork, older software will continue to operate without modification.  Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features.
 226 | +
 227 | +=== Version 0 witness programs ===

---

  87 | +
  88 | +The new rule is s<sub>v</sub> <= 1 MB.
  89 | +
  90 | +=== Witness program ===
  91 | +
  92 | +* A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a single push of 2 to 41 bytes gets a new special meaning. The byte vector pushed by it is called the "witness program".

---

 138 | +
 139 | +The following example is a version 0 witness program, equivalent to the existing Pay-to-Pubkey-Hash (P2PKH) output.
 140 | +
 141 | +    witness:      <signature> <pubkey>
 142 | +    scriptSig:    (empty)
 143 | +    scriptPubKey: <0x0076A914{20-byte-hash-value}88AC>

---

 163 | +
 164 | +    1 <33-byte-pubkey1> <33-byte-pubkey2> 2 CHECKMULTISIG
 165 | +
 166 | +The script is executed with the remaining data from witness:
 167 | +
 168 | +    0 <signature1> 1 <33-byte-pubkey1> <33-byte-pubkey2> 2 CHECKMULTISIG

---

 137 | +
 138 | +The following example is a version 0 witness program, equivalent to the existing Pay-to-Pubkey-Hash (P2PKH) output.
 139 | +
 140 | +    witness:      <signature> <pubkey>
 141 | +    scriptSig:    (empty)
 142 | +    scriptPubKey: OP_0 <0x76A914{20-byte-hash-value}88AC>

---