wip-0022: finalize proposal and update adoption plan

wip-0022.md

@@ -12,7 +12,7 @@
 
 ## Abstract
 
-This improvement proposal aims to introduce a data request reward to collateral ratio. This ratio will be enforced using a base ratio at the protocol level, but can also be raised above this level by individual miners.
+This improvement proposal aims to introduce a data request reward to collateral ratio. This ratio will be enforced using a base ratio at the protocol level and data requests not adhering to this ratio will be considered invalid.
 
 ## Motivation and rationale
 
@@ -32,7 +32,7 @@ One additional advantage of a protocol-enforced reward to collateral ratio is th
 
 ### Introduction of a protocol-enforced data request reward collateral ratio
 
-Properly enforcing a reward to collateral ratio at the protocol level requires adding this ratio as a consensus constant. Adding a consensus constant will change the magic number nodes used to validate communication between nodes. Therefore, proper precautions need to be implemented such that this number only changes when the WIP is accepted.
+Properly enforcing a reward to collateral ratio at the protocol level would require adding this ratio as a consensus constant. However, changing a consensus constant changes the magic number nodes used to validate communication between nodes. Since this requires further analysis to make sure the liveness of the network is not endangered, the ratio is currently not encoded as a consensus constant, but simply included as a default value in the code.
 
 The moment the WIP is activated, nodes which receive a data request that does not adhere to the reward to collateral ratio MUST refuse to add it to their local mempool.
 
@@ -51,7 +51,7 @@ if dr_tx_reward_collateral_ratio < self.minimum_reward_collateral_ratio {
 }
 ```
 
-Each and every received by a node is validated, which implies that all transactions in it are checked against a set of rules. If a node receives a block containing a data request that does not adhere to the required reward to collateral ratio, they should mark the block as invalid and refuse it as a candidate.
+Each and every block received by a node is validated, which implies that all transactions in it are checked against a set of rules. If a node receives a block containing a data request that does not adhere to the required reward to collateral ratio, they should mark the block as invalid and refuse it as a candidate.
 
 ```Rust
 pub fn validate_data_request_output(
@@ -74,17 +74,9 @@ pub fn validate_data_request_output(
 }
 ```
 
-### Introduction of a configurable data request reward collateral ratio
-
-Next to a protocol-enforced reward to collateral ratio, node operators SHOULD be able to set a ratio they consider acceptable. This ratio MUST NOT be set lower than the protocol-enforced ratio. Setting the ratio higher than the protocol-enforced ratio implies that these node operators MAY refuse to add received data requests with a lower ratio to their local mempool. However, if they receive a block with a ratio which is lower than the ratio they accept but higher than the protocol-enforced ratio, they MUST accept it as a valid candidate.
-
 ### Reward collateral ratio proposal
 
-There are two sensible values for a protocol-enforced reward to collateral ratio.
-
-The first one is that the ratio should offset the involuntary lie ratio. Assuming this is 0.2%, the minimum reward to collateral ratio should be 1 to 500.
-
-The second one can be derived from the maximum amount of witnesses in a data request which, following [WIP-0007](https://github.com/witnet/WIPs/blob/master/wip-0007.md), is 125. Assuming creating data requests requiring 125 witnesses has as goal to achieve maximum security, the reward for them should be proportional. This implies that such data request should pay out a reward equal to the required collateral, or that the reward to collateral ratio should be 1 to 125.
+This proposal aims for a data request to pay out a reward proportional to its security requirements. The main knobs to tune yhe security are the number of witnesses and the collateral. As per [WIP-0007](https://github.com/witnet/WIPs/blob/master/wip-0007.md), the maximum amount of witnesses in a data request is 125. Assuming creating a data request requiring the maximum amount of witnesses has as goal to achieve maximum security and that its reward should be proportional, this implies that it should pay out a reward equal to the required collateral, or that the reward to collateral ratio should be 1 to 125.
 
 ## Backwards compatibility
 
@@ -109,12 +101,14 @@ Due to this last point, this MUST be considered a consensus-critical protocol im
 
 ## Reference Implementation
 
-A reference implementation for the proposed protocol improvement can be found in the [pull request #2229](https://github.com/witnet/witnet-rust/pull/2229) of the [witnet-rust](https://github.com/witnet/witnet-rust/) repository.
+A reference implementation for this protocol improvement was proposed in [pull request #2229](https://github.com/witnet/witnet-rust/pull/2229) and has been further refined in [pull request #2337](https://github.com/witnet/witnet-rust/pull/2337) of the [witnet-rust](https://github.com/witnet/witnet-rust/) repository.
 
 ## Adoption Plan
 
-To be determined.
+An activation date is proposed for February 21 2023 at 9am UTC, that is, protocol epoch #1651280.
+
+From the perspective of TAPI, the signaling bit is 3 (0b00000000000000000000000000001000) and the first_signaling_epoch is set to #1651280.
 
 ## Acknowledgements
 
-This proposal has been cooperatively discussed and devised by many individuals from the Witnet development community. Thanks to all persons participating in the discussions on Github and Discord to hone this improvement proposal. Furthermore, thanks to [Tomasz Polaczyk](https://github.com/tmpolaczyk) for contributing to the reference implementation in Rust.
+This proposal has been cooperatively discussed and devised by many individuals from the Witnet development community. Thanks to all persons participating in the discussions on Github and Discord to hone this improvement proposal. Furthermore, a special thanks to [Tomasz Polaczyk](https://github.com/tmpolaczyk) for refining the original implementation.