Merge pull request #419 from rsksmart/powpeg-validation-protocol

Powpeg utxos spendability validation protocol

IPs/RSKIP419.md

@@ -0,0 +1,244 @@
+---
+rskip: 419
+title: Powpeg Spendability Validation Protocol
+created: 31-AUG-23
+author: JD, JZ
+purpose: Sec
+layer: Core
+complexity: 2
+status: Draft
+description: New Mechanism for current Powpeg to ensure the newly elected Powpeg will safely hold user funds
+---
+
+|RSKIP          |419           |
+| :------------ |:-------------|
+|**Title**      |Powpeg Spendability Validation Protocol |
+|**Created**    |31-AUG-23 |
+|**Author**     |JD, JZ |
+|**Purpose**    |Sec|
+|**Layer**      |Core|
+|**Complexity** |2|
+|**Status**     |Draft|
+
+
+## Abstract
+
+The Powpeg composition changes from time to time for different reasons, mainly members joining or leaving and/or POWHSM upgrades that require onboarding.
+The Powpeg Bitcoin address also changes when the redeemscript is upgraded, for instance when the ERP redeemscript was added.
+
+Everytime this happens, the Bridge undergoes a process that is irreversible: after a certain amount of blocks, the new Powpeg composition will receive all the funds and become responsible for its safety. If the newly elected Powpeg were to be unable to securely store the funds, the users could have their funds at risk.
+
+This RSKIP proposes a new process that will happen before the elected Powpeg is actually committed, and could imply discarding it and stopping the change process if it is considered not safe.
+
+
+## Motivation
+
+The Powpeg election is a critical process that should have as many reassurances as possible.
+As mentioned in the previous section, nowadays once the election takes place, the process is irreversible.
+This RSKIP proposes an automated and decentralized process to add one more layer of security to this process to avoid any human mistake putting funds at risk.
+
+This process protects funds from:
+- An invalid redeemscript that would render the funds burned.
+- A composition of pegnatories that are not responsive and, therefore, unable to sign transactions.
+
+
+## Specification
+
+This RSKIP proposes changes in the Powpeg change process. The subsections will expand on the changes for each step.
+
+The current process consists in the following phases:
+1. Election start: m/n authorized members propose to start a new election.
+2. Composition proposal: m/n vote for the new composition.
+3. New composition commitment: m/n vote to commit new composition. New elections are disabled.
+4. Pre activation phase: immediately after commitment and during a number of blocks. No real change for end users.
+5. Activation phase: new Powpeg address activates, two-way peg starts operating from this new address.
+6. Migration phase: Funds from the retiring Powpeg wallet are moved to the active Powpeg.
+7. Post migration phase: Retiring Powpeg information is removed from the Bridge. New elections are re-enabled.
+
+The election process in itself doesn't change: the authorized members will still propose a new composition and once the voting finishes the commit event will be emitted, but the proposed Powpeg will not be committed yet and its validation will start.
+
+
+### New phase - Validation
+
+A new phase will be added, in between the _composition proposal_ and _new composition commitment_ phases, the _validation_ phase.
+During a certain number of blocks a new protocol will be started, Spendability Validation Protocol (SVP).
+
+If this protocol succeeds, the Bridge will progress to the next phase (_new composition commitment_).
+If this protocol fails, things will return to their previous state.
+
+
+### Spendability Validation Protocol (SVP)
+
+The Spendability Validation Protocol is a new process in which the current Powpeg will send funds to the newly elected Powpeg, for it to send them back, proving that it can truly hold and spend funds, before proceeding with the activation and migration of the funds in the wallet.
+
+This protocol involves three parts:
+- Proposed Powpeg funding: the proposed Powpeg won't have funds to create the proof so the current Powpeg will create an UTXO covering the expenses.
+- Proof transaction creation: once the proposed Powpeg receives the funds, it will create an UTXO to the current Powpeg to proof that it can spend them.
+- Proof transaction verification: the current Powpeg will receive the proposed Powpeg spending-proof transaction, validate it was created by the proposed Powpeg from the funding transaction and proceed with the commitment.
+
+#### Proposed Powpeg funding
+
+Once the SVP starts, the Bridge will send the required satoshis to the proposed Powpeg address. It should be enough for it to be able to send back a transaction. Since the size of the Proof transaction will vary depending on the size of the proposed Powpeg input script, the calculation of the funds sent from the current Powpeg should consider that.
+
+
+The process consists of the following 3 steps:
+
+##### 1. Funding transaction creation
+
+As soon as the proposed Powpeg has been voted (and saved in a new Bridge storage entry, key `proposedFederation`), the Bridge will create a SVP funding transaction for it.
+
+This transaction is similar to a peg-out but with two outputs, where the recipients are the proposed Powpeg Bitcoin address, and the proposed Powpeg Bitcoin address with a custom flyover prefix to make sure the flyover protocol would work too. The amount to receive by both is calculated based on the minimum amount of satoshis required to spend an UTXO by each of them (+ bitcoin fees).
+
+Once the transaction is created, it has to be stored in the set for peg-outs waiting for confirmations, and the sighash has to be stored in the pegout index so the change could be registered.
+
+Also, a new value in the storage should be added to identify this special kind of transaction:
+
+    KEY: "svpFundTxHashUnsigned"
+    VALUE: hash of SVP funding tx without signatures
+
+##### 2. Funding transaction confirmation
+
+The SVP funding transaction goes through the usual peg-out confirmation process. Once the transaction accumulates at least 4_000 Rootstock blocks (for mainnet) it should be ready to be moved from the current set to the waiting for signatures set.
+
+##### 3. Funding transaction signing
+
+The funding transaction should be signed as any other peg-out. Once it is fully signed it should be removed from the set and a release_btc event should be emitted.
+Eventually, when the funding transaction is registered in the Bridge, the Proof transaction could be created.
+
+
+### Proof transaction creation
+
+Once the funding transaction is registered, the Proof will be created for the proposed Powpeg to sign and broadcast it so it can prove it can spend funds.
+
+##### Funding transaction registration
+The funding transaction should be registered through the registerBtcTransaction method.
+For that purpose, the method will be modified to be able to identify it.
+It should verify:
+- SVP period is ongoing
+(i.e. proposedFederation exists & CURRENT_RSK_BLOCK < PROPOSED_FED_CREATION_BLOCK_NUMBER + SVP_PERIOD)
+- Transaction hash without signatures matches the record in the svpFundTxHashUnsigned storage entry
+
+
+Once everything is verified, the transaction will be registered and the transaction hash will be saved in a new storage entry, svpFundTxHashSigned. Also, the svpFundTxHashUnsigned will be removed from the storage.
+The funding transaction hash signed being saved means that the proof Transaction can be created.
+
+
+#### Proof transaction creation or validation process failure
+
+A new method, `processPowpegChangeValidation` will be called from the `updateCollections` method.
+
+The `processPowpegChangeValidation` will perform some actions if a proposedFederation exists depending on this two scenarios:
+- SVP period ended.
+Since the proposedFederation still exists, this implies the proof transaction was not received, and therefore that the validation was not successful
+    -  The Bridge will emit a new event,
+
+        `COMMIT_FEDERATION_FAILED(bytes proposedFederationRedeemScript, uint blockNumber)`
+    - The proposed Powpeg redeem script will be logged for debugging.
+    - The proposed Powpeg will be eliminated.
+    - The election will be allowed once again.
+
+- SVP period still ongoing        
+    - If the funding transaction signed hash is registered in the svpFundTxHashSigned storage entry, the Bridge will:
+        - Create it as described [here](#proof-transaction)
+        - Add it to a new storage set, key `svpSpendTxWaitingForSignatures`
+        - Set it in a new Storage entry:
+            ```
+            KEY: "svpSpendTxHash"
+            VALUE: hash of SVP proof tx without signatures
+            ```
+        - Remove the svpFundTxHashSigned from the storage    
+
+##### Proof transaction
+
+The Proof transaction is a Bitcoin transaction where an UTXO from the proposed Powpeg is sent to the current Powpeg.
+This transaction will be as simple and small as possible to avoid spending much satoshis as fees.
+
+Proof transaction structure:
+```
+{
+    inputs: [
+        {
+            txid: SVP_FUND_TX_HASH_SIGNED,
+            output_index: SVP_FUNDING_TX_OUTPUT_INDEX
+        },
+        {
+            txid: SVP_FUND_TX_HASH_SIGNED,
+            output_index: SVP_FLYOVER_FUNDING_TX_OUTPUT_INDEX
+        }
+    ],
+    outputs: [
+        {
+            script: CURRENT_POWPEG_OUTPUT_SCRIPT,
+            value: TOTAL_UTXO - FEES
+        }
+    ]
+}
+```
+
+#### Proof transaction confirmation
+
+The SVP proof transaction should go through a new "peg-out signing process", since it has to be signed for the proposed pegnatories which belong neither the active nor the retiring powpeg, but the proposed one.
+
+#### Proof transaction signing
+
+The proof transaction should be signed as any other peg-out, but by the proposed powpeg. For this to happen, two new Bridge methods `getStateForSvpClient` and `addSvpSpendTxSignature` should be created.
+
+The first one should perform the exact same actions as the `getStateForBtcReleaseClient` but to inform if the SVP spend tx is waiting for signatures (i.e., that `svpSpendTxWaitingForSignatures` is not empty).
+
+The second one should perform the exact same actions as the `addSignature` but to accept signatures from public keys that belong to the proposed Powpeg instead of the active/retiring ones (let's recall the proposed Powpeg is not active at this point), and to check that the hash of the transaction intended to be signed exists in the `svpSpendTxHash` storage entry.
+
+Once fully signed, the Bridge should remove the entry from the `svpSpendTxWaitingForSignatures`.
+
+### Proof verification
+
+With the SVP proof transaction broadcasted, the Bridge now needs to validate it and proceed with the election commitment as expected.
+
+The proof transaction should be registered through a new `registerSvpSpendTxTransaction` method that would behave similar to the `registerBtcTransaction`. As before, it should verify:
+- SVP period is ongoing
+- Transaction hash without signatures is registered in the `svpSpendTxHash` storage key.
+
+If the hash matches the one registered in the storage, then the SVP process is considered completed and we can proceed with the committment of the proposed -and now validated- Powpeg.
+The `svpSpendTxHash` and the `proposedFederation` will be removed from storage. The utxo sent to the current Powpeg will be registered so it can be spend.
+
+### Validation phase duration
+
+The duration of this phase must account for:
+- Spending an UTXO from the current Powpeg (Bridge confirmations + pegnatories signing)
+- Confirming the UTXO on Bitcoin (Bitcoin confirmations for the UTXO to be accepted)
+- Sending back the UTXO to the current Powpeg (Proposed pegnatories signing)
+
+The recommendation is that this phase takes approximately the blocks a peg-out confirmation has plus the bitcoin blocks needed to register the chance, twice. And a couple of thousands more blocks to be safe.
+- Mainnet: 16_000
+- Testnet: 80 - For testnet it is recommended to wait a bit longer as the Bitcoin miners don't tend to follow the 10' block creation time.
+- Regtest: 15
+
+### New Bridge storage fields
+
+|Storage Key   |Description   |
+|:------------ |:-------------|
+|svpFundTxHashUnsigned | hash of SVP funding tx unsigned|
+|svpFundTxHashSigned | hash of SVP funding tx signed|
+|svpSpendTxHash | hash of SVP proof tx|
+|svpSpendTxWaitingForSignatures | SVP proof tx that is to be signed|
+
+### New Bridge methods
+```
+addSvpSpendTxSignature(bytes federatorPublicKeySerialized, bytes[] signatures)
+```
+
+```
+getStateForSvpClient() returns bytes 
+```
+
+```
+registerSvpSpendTxTransaction(bytes svpSpendTxSerialized, uint256 height, bytes pmtSerialized) returns int
+```
+
+## References
+
+- [Rootstock devportal - Powpeg](https://dev.rootstock.io/rsk/architecture/powpeg/)
+- [Building the Most Secure, Permissionless and Uncensorable Bitcoin Peg](https://medium.com/iovlabs-innovation-stories/building-the-most-secure-permissionless-and-uncensorable-bitcoin-peg-b5dc7020e5ec)
+
+### Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

README.md

@@ -227,6 +227,7 @@ You can find an easily browseable version of this information [here](https://ips
 | 414 |[Network Upgrade: Arrowhead](IPs/RSKIP414.md)| 7-DEC-23 | VK | Usa,Sec | Core | 2 | Adopted |
 | 415 |[Fix pegnatories address derivation from public keys](IPs/RSKIP415.md)| 30-JAN-24 | MI | Usa | Core | 1 | Adopted |
 | 417 |[Avoid transactions to be reverted when Bridge method calls from smart contracts return an empty response](IPs/RSKIP417.md)| 28-FEB-24 | MI | Usa | Core | 1 | Adopted |
+| 419 |[Powpeg Spendability Validation Protocol](IPs/RSKIP419.md)| 31-AUG-23 | JD, JZ | Sec | Core | 2 | Draft |
 
 (*) Under evaluation to be implemented in the next reference client release
 
@@ -239,13 +240,14 @@ You can find an easily browseable version of this information [here](https://ips
 | AM       | Ariel Mendelzon              | [email protected] |
 | DLL      | Diego López León             |                        |
 | DM       | Diego Masini                 | [email protected]    |
-| FJ       | Federico Jinich              | [email protected]    |
+| FJ       | Federico Jinich              | [email protected]   |
 | GM       | Guido Medina                 |                        |
 | IO       | Ilan Olkies                  | [email protected]       |
 | JIO      | Jose Ignacio Orlicki         |                        |
 | JD       | Jose Dahlquist               | [email protected]            |
 | JL       | Julian Len                   | [email protected]     |
 | JT       | Jeremy Then                  | [email protected]|
+| JZ       | Julia Zack                   | [email protected] |
 | KI       | Kelvin Isievwore             | [email protected]     |
 | LS       | Lisandro Sebrie              |                        |
 | MC       | Martín Coll                  |                        |