Merge UIP-15 and UIP-25

Signed-off-by: Azat Nizametdinov <azat@thirdhash.com>

README.md

@@ -17,7 +17,6 @@ protocol and APIs.
 |[UIP-0018](https://github.com/dtr-org/uips/blob/master/UIP-0018.md)|unit-e Transaction Types|Draft|2018-11-02|
 |[UIP-0021](https://github.com/dtr-org/uips/blob/master/UIP-0021.md)|Transfer Esperanza Transactions|Draft|2018-11-08|
 |[UIP-0024](https://github.com/dtr-org/uips/blob/master/UIP-0024.md)|CTOR - Canonical Transactions Ordering Rule|Proposed|2018-12-14|
-|[UIP-0025](https://github.com/dtr-org/uips/blob/master/UIP-0025.md)|Remote staking with P2SH|Draft|2019-01-25|
 
 The UnitE team is committed to fostering a welcoming and harassment-free
 environment. All participants are expected to adhere to our [code of

UIP-0015.md

@@ -13,22 +13,36 @@ them. The mechanism is similar to the
 [cold staking in Particl](https://particl.wiki/staking#cold_staking) and to the
 [account leasing in NXT](https://nxtwiki.org/wiki/Account_Leasing).
 
+
 ## Motivation
-The Proof-of-Stake protocol requires users to keep their wallets (usually with
-a significant amounts of money) online to propose and validate blocks. If
+
+Remote staking solves the following problems:
+
+1. The Proof-of-Stake protocol requires users to keep their wallets (usually 
+with a significant amounts of money) online to propose and validate blocks. If
 a computer with the staking wallet gets hacked then the attacker will be able
 to steal the money.
 
-Another potential problem is that public keys get revealed during the process of
-staking. It makes wallets vulnerable to quantum computing attacks. Obviously,
-those kinds of attacks are purely theoretical at the moment.
+2. Currently, it is not possible to use P2SH (and P2WSH) outputs as a stake. The
+reason is that a block must be signed with the same key which is used to unlock
+the stake, and P2SH might have `redeemScript` which does not involve public key
+cryptography at all.
+
+3. Public keys get revealed during the process of staking which makes wallets
+vulnerable to quantum computing attacks. Obviously, those kinds of attacks are
+purely theoretical at the moment.
+
 
 ## Specification
-Remote staking is enabled by a special kind of unlocking script which requires
-different keys for staking and spending transactions.
 
-The segwit remote-staking `scriptPubKey` consists of 1-byte push opcode `OP_1`
-followed by two data pushes of 20 and 32 bytes:
+Remote staking is enabled by a special kind of unlocking scripts which require
+different keys for staking and spending transactions. There are two versions of
+remote-staking scripts: version 1 and version 2 which extend respectively P2WPKH
+and P2WSH.
+
+The version 1 remote-staking `scriptPubKey`, remote-staking P2WPKH (RSP2WPKH),
+consists of 1-byte push opcode `OP_1` followed by two data pushes of 20 and 32
+bytes:
 
 ```
 1 <20-byte-staking-pubkey-hash> <32-byte-spending-pubkey-hash>
@@ -39,8 +53,22 @@ Where data pushes correspond to the following hashes:
    (i.e. `RIPEMD160(SHA256(compressed pubkey))`);
 2. `<32-byte-spending-pubkey-hash>` is a SHA256 of a public key for spending.
 
-The witness MUST be validated in the same way as it is validated for P2WPKH (as
-specified in
+The version 2 remote-staking `scriptPubKey`, remote-staking P2WSH (RSP2WSH),
+consists of 1-byte push opcode `OP_2` followed by two data pushes of 20 and 32
+bytes:
+
+```
+2 <20-byte-staking-pubkey-hash> <32-byte-spending-script-hash>
+```
+
+Where data pushes have the following meaning:
+1. `<20-byte-staking-pubkey-hash>` is a HASH160 of a public key for staking;
+2. `<32-byte-spending-script-hash>` is a SHA256 of a `witnessScript`.
+
+### Validation of the witness
+
+For RSP2WPKH, the witness MUST be validated in the same way as it is validated
+for P2WPKH (as specified in
 [BIP-141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#witness-program))
 except for the validation of a public key hash:
 * The witness MUST consist of exactly 2 items (≤ 520 bytes each). The first one
@@ -53,21 +81,23 @@ except for the validation of a public key hash:
     `<32-byte-spending-pubkey-hash>`.
 * The signature is verified against the public key with CHECKSIG operation. The
   verification MUST result in a single TRUE on the stack.
-
-The following is an example of a version 1 remote staking `scriptPubKey` and
-corresponding witness and `scriptSig`.
-```
-  witness:      <signature> <pubkey>
-  scriptSig:    (empty)
-  scriptPubKey: 1 <20-byte-staking-key-hash> <32-byte-spending-key-hash>
-                (0x0114{20-byte-staking-key-hash}20{32-byte-spending-key-hash})
-```
-
-The usage of 256-bit destinations (SHA256 of a public key) SHOULD be hidden from
-the users (more about it in the rationale section). Hence, _we do not need to
-introduce new 256-bit address format_.
+
+For RSP2WPKH, the validation of the witness depends on the type of the
+transaction which spends an output with RSP2WSH script. When the transaction is
+a coinbase transaction (`TxType::COINBASE`) then it MUST be validated as
+described above for RSP2WPKH. Otherwise, it MUST be validated as P2WSH (as
+specified in 
+[BIP-141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#witness-program)):
+* The witness must consist of an input stack to feed to the script, followed by
+  a serialized script (`witnessScript`).
+* The `witnessScript` (≤ 10,000 bytes) is popped off the initial witness stack.
+  SHA256 of the `witnessScript` must match the 32-byte spending script hash.
+* The `witnessScript` is deserialized, and executed after normal script
+  evaluation with the remaining witness stack (≤ 520 bytes for each stack item).
+* The script must not fail and result in exactly a single TRUE on the stack.
 
 ### Transaction Signature Verification
+
 [BIP-143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki)
 specifies the transaction digest algorithm for version 0 witness programs.
 According to it, the transaction digest algorithm looks as follows:
@@ -86,16 +116,25 @@ According to it, the transaction digest algorithm looks as follows:
     10. sighash type of the signature (4-byte little endian)
 ```
 
-For version 1 witness program the algorithm is the same as specified in BIP-143
-except for the fifth field `scriptCode` value of which depends on the type of
-the transaction:
-* if the transaction is a coinbase transaction then `scriptCode` is
-  `0x1976a914{20-byte-staking-pubkey-hash}88ac` (
-  `OP_DUP OP_HASH160 <20-byte-staking-pubkey-hash> OP_EQUALVERIFY OP_CHECKSIG`).
-* otherwise `scriptCode` is `0x2576a820{32-byte-spending-pubkey-hash}88ac` (
-  `OP_DUP OP_SHA256 <32-byte-spending-pubkey-hash> OP_EQUALVERIFY OP_CHECKSIG`).
+For version 1 and 2 witness programs the algorithm is the same as specified in
+BIP-143 except for the fifth field `scriptCode` value of which depends on the
+type of the transaction.  If the transaction is a coinbase transaction then
+`scriptCode` is `0x1976a914{20-byte-staking-pubkey-hash}88ac` (
+`OP_DUP OP_HASH160 <20-byte-staking-pubkey-hash> OP_EQUALVERIFY OP_CHECKSIG`).
+If the transaction has any other type
+* for RSP2WPKH (version 1) `scriptCode` is `0x2576a820{32-byte-spending-pubkey-hash}88ac` 
+  (`OP_DUP OP_SHA256 <32-byte-spending-pubkey-hash> OP_EQUALVERIFY OP_CHECKSIG`).
+* for RSP2WSH (version 2): 
+  * if the `witnessScript` does not contain any `OP_CODESEPARATOR`, the
+    `scriptCode` is the `witnessScript` serialized as scripts inside `CTxOut`.
+  * if the `witnessScript` contains any `OP_CODESEPARATOR`, the scriptCode is
+    the `witnessScript` but removing everything up to and including the last
+    executed `OP_CODESEPARATOR` before the signature checking opcode being
+    executed, serialized as scripts inside `CTxOut`. (See examples in
+    [BIP-143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Native_P2WSH))
 
 ### Consensus rule
+
 To prevent the remote-staking node from spending funds in coinbase
 transactions the following consensus rule is required:
 
@@ -106,8 +145,21 @@ transactions the following consensus rule is required:
 Note that the reward does not have to be sent to the same script. This fact can
 be used to add reward address to remote-staking node settings.
 
+### Examples
+
+The following is an example of a version 1 remote-staking `scriptPubKey` and
+corresponding witness and `scriptSig`.
+```
+  witness:      <signature> <pubkey>
+  scriptSig:    (empty)
+  scriptPubKey: 1 <20-byte-staking-key-hash> <32-byte-spending-key-hash>
+                (0x0114{20-byte-staking-key-hash}20{32-byte-spending-key-hash})
+```
+
 ## Rationale
+
 ### SegWit vs non-SegWit
+
 Alternatively remote staking can be implemented with the following script:
 
 ```
@@ -135,6 +187,7 @@ to P2SH but doing so with the segwit will require the introduction of a new
 script version.
 
 ### 256-bit destination (SHA256 of a public key)
+
 SHA256 of a public key is used to prevent the situation when users can receive
 funds which are stakeable by someone else. Suppose the remote-staking script has
 the following form:
@@ -165,7 +218,11 @@ Why someone might want to do so:
 256-bit destinations do not completely prevent this scenario but make it much
 harder since they are not normally revealed.
 
+Note that _we do not need to introduce new 256-bit address format_ as the usage
+of 256-bit destinations SHOULD be hidden from the users.
+
 ## Use cases
+
 The main use case is the following. Suppose Alice wants to securely stake her
 UTEs. To do so she setups a remote-staking unit-e node (probably on some cheap
 hardware like Raspberry Pi) which does not own any UTEs. Then she sends her
@@ -182,14 +239,21 @@ these UTXOs as a stake when proposing a block and send rewards back to the same
 Another use case is staking pools. But the description of staking pools is out
 of the scope of this UIP.
 
+
 ## Reference implementation
 
-Implemented in [Unit-e](https://github.com/dtr-org/unit-e/pull/402).
+Pull requests [#402](https://github.com/dtr-org/unit-e/pull/402) and
+[#517](https://github.com/dtr-org/unit-e/pull/517) implement RSP2PKH.
+Pull request [#592](https://github.com/dtr-org/unit-e/pull/592) implements
+RSP2WSH.
+
 
 ## Changelog
 
 * 2019-01-17 Added a link to the reference implementation and changed the status 
   to proposed.
+* 2019-02-21 Extended UIP with the specification of RSP2WSH.
+
 
 ## Copyright