Hi all. A protocol bug was patched by the security committee, which was reported through the Livepeer Immunefi Bug Bounty program. This fix addresses a potential griefing opportunity in which a bad actor could prevent a delegating token holder from accessing their rewards in a new round. Due to the patch no user funds are at risk, nor was this scenario intentionally exploited on the network in the past to our knowledge. A bounty will be paid to the reporter, and we thank the reporter for their responsible disclosure.
Unlike many previous security committee bug fixes this one:
- Does introduce a slight behavior change to the protocol
- It is suggested that the community consider an LIP in the coming weeks to update the behavior of the protocol and eliminate the logic around this fix in favor of slightly new semantics.
The issue
The core of this issue lies in the fact that in invoking transferBond or bondForWithHint a user chooses the receiving account of the new stake. If the receiver is delegated towards an O that has not yet called reward in the current round, then the receiver loses the ability to earn their rewards or fees going forward for that round. It has long been known that if you take a staking action before your delegate calls reward, then you lose out on that opportunity. However in this instance it is possible for someone else to grief you and force you to miss out by simply transferBond’ing as small as 1 base unit LPT towards you.
This patch puts in a restriction that these methods will only succeed if the delegator’s orchestrator has already called reward in the current round.
Note: This could have the side effect of causing some existing scripts that call transferBond automatically to fail in circumstances where an O hasn’t called reward yet. It’s believed that this tradeoff is worth it in line with the security committee’s mandate to protect user funds. Most O’s call reward within blocks of the initialize round call, so in practice this should rarely effect any live workflows.
The go forward LIP
The behavior of the above patch could be considered reasonable. The protocol has a series of instances of known behaviors like this, such as delegators needing to be aware that if they take a bonding action before reward is called in a round, they miss out on the rewards. However it could be considered as temporary in favor of a cleaner behavior to be considered in a future LIP.
One such behavior is to introduce the concept of address approvals for actions that the protocol lets you take on another recipient’s behalf, such as transferBond and bondForWithHint. Simply put, the receiving address could submit at approveAddress txn that gives approval for another address to transfer bond its way. It could revoke this permission as well.
This would eliminate the need for the patch introduced by this bug fix, as well as any other potential side effects that come with anyone being able to transferBond to an account they don’t own or have a relationship with. The security committee did not consider this to be a viable patch option however, as it would introduce a breaking change to all transferBond txns, being that none of them would start out with the requisite approvals.
A more formal specification for this functionality, as well as debating other options, can be left to a future community discussion and LIP process.
Thank you. Stand by for further details on the retrospective in the coming days.