Genuine Currant Mantaray
High
Coinbase transactions have a special property of not being spendable for 100 bocks after creation. If now a staker uses such a transaction as a staking transaction (by adding the required outputs), that transaction will be recognized as a valid staking TX but if the owner of it double-signs, he cannot be slashed for 100 blocks due to the unspendability of the coinbase TX.
Looking at CreateBTCDelegation and ValidateParsedMessageAgainstTheParams which does verification on the provided TX, there are no specific checks for whether a transaction is a coinbase transaction.
None
Attacker needs to be the creator of a block (a miner) in order to build the coinbase TX like they want
- Create a coinbase TX which is a valid staking TX
- Call
CreateBTCDelegationwith that TX - It gets accepted and its value added as voting power
The README states under High impact: Inability to slash BTC stake for which the voting power was involved in double-signing.
That is exactly what happens here. Even if the staker's delegator misbehaves, the staker's stakingTx cannot be spent until 100 blocks after. Adding to the impact, if now the minimum staking time is less than 100 bitcoin blocks, this allows the malicious staker to unstake before getting slashed (if the slashing even gets retried after 100 blocks)
No response
Coinbase transactions can be identified since the ID of their input must be all zeros. Therefore consider checking whether a staking transaction has one input with an ID of all-zeros and reject it if so.