I want to highlight another issue I see with the implementation of RPIP-31 in Houston.
Vanilla Houston (without v10)
To reiterate, if a RPL withdrawal address is set and without a reward tree change only that RPL reward address is able to claim both RPL and smoothing pool rewards for a node. The implementation of the RPL claim executes a call to the primary withdrawal address to send the smoothing pool ETH there. This opens the door to what I view as a griefing attack that goes against what RPIP-31 specifies and should be considered a bug:
The controller of the primary withdrawal address can set it to an arbitrary address at any point. If they set it to a smart contract that doesn’t define a payable fallback, the call to the withdrawal address will revert and therefore the entire claim (including of RPL) will revert as well.
The primary controller has the ability to block the controller of RPL from claiming rewards.
Houston with v10
A side effect of v10 discussed here is that it limits (but doesn’t eliminate) this griefing attack. If the primary is set to an address different from the node wallet, RPL and ETH claims are separated and the griefing is no longer possible.
If the node wallet is used as the primary, the primary controller still has the ability to block the controller of RPL from claiming rewards, because RPL and ETH are still claimed together.
Note that it is possible to switch the primary back to the node wallet if a different primary was set.
By confirming that a node wallet is not a smart contract initially, one can ensure that this attack is impossible.
Is this a bug or not?
The Medium post about Houston introduces the RPL withdrawal address like this:
With this new addition, you can set a withdrawal address for your ETH and a new one for your RPL if you wish. The RPL withdrawal address if set will be able to trigger and claim RPL from inflation rewards and will have no effect on ETH consensus rewards or anything related to ETH.
This creates some interesting opportunities where RPL can be trustlessly supplied by an entity to a node operator that does not wish to have exposure to RPL. That entity can then claim RPL rewards for putting up the required insurance collateral for the node.
The claiming process is presented as trustless, but as explained above the RPL controller needs to trust the primary controller to not block the claim in vanilla Houston and needs to verify that it is not possible in v10 Houston.
RPIP-31 defines claiming of RPL rewards as clearly in the domain of the RPL controller and independent of the primary controller:
As the controller of the RPL for a node, I MUST be able to trigger a claim of RPL rewards
In the Security Considerations section the following limitation is highlighted:
In a situation were the node operator is different to the RPL owner, the RPL owner must rely on the node operator to exit minipools to unlock their RPL stake.
But there is no mention of a reliance on the node operator for claiming rewards, implying that no such thing exists.
In summary, this clearly is unintended behavior and should be viewed as a bug.
Recommendations
- Deploying vanilla Houston without fixing this bug and without v10 shouldn’t be done.
- If Houston is deployed as is and v10 is implemented, we should clearly communicate the risk. This should include editing the medium post and RPIP-31. The latter would require a pDAO vote in my opinion.
- If additional time is spent on fixing RPIP-31 implementation in a future upgrade, this griefing vector should be kept in mind and avoided.