Note: this PR was already approved by 2 Livepeer Security Committee members inside a private security advisory.

What does this pull request do? Explain your changes. (required)

This PR fixes a vulnerability where an attacker could frontrun a transcoder's redeemWinningTicket() call by depositing a dust amount (1 wei) into the sender's account via fundDepositAndReserveFor(). Because redeemWinningTicket() paid out whatever funds were available and then permanently marked the ticket as used, the transcoder would receive 1 wei instead of the full face value. The same partial-payout and ticket-burn outcome could also occur naturally when multiple tickets from the same sender were redeemed in sequence, and the combined deposit and reserve were insufficient to cover all of them.

The fix enforces an all-or-nothing redemption: redeemWinningTicket() now requires that sender.deposit + remainingReserve >= ticket.faceValue before marking the ticket as used. If the sender is underfunded, the call reverts, leaving the ticket redeemable once the sender tops up.

Specific updates (required)

• contracts/pm/mixins/MixinTicketBrokerCore.sol: Replaced the sender.deposit > 0 || remainingReserve > 0 guard in redeemWinningTicket() with a stricter check requiring deposit + reserve >= faceValue.

How did you test each of these updates (required)

• Added src/test/TicketBrokerDustDepositGriefingPoC.sol to prove both attack scenarios exist: the griefing attack (testDustDepositGriefing) and the race condition (testRaceConditionPartialPayout), described in the analysis report.
• Added src/test/TicketBrokerDustDepositGriefingFix.sol to prove the fix closes both scenarios while the normal flow continues to work.
• Updated three existing unit tests in test/unit/TicketBroker.js where the previous partial-payment behavior was under test. The amounts were adjusted to be fully funded, so the test semantics are preserved
• Added two new unit tests: reverts if faceValue exceeds deposit and reserve combined, and succeeds when faceValue equals deposit and reserve combined.

Does this pull request close any open issues?

Yes, it closes https://github.com/sidestream-tech/livepeer-protocol/security/advisories/GHSA-cfpp-6gv2-r325

Checklist:

• README and other documentation updated
  ℹ️ No relevant section in the README, but the NatSpec on redeemWinningTicket() was updated directly in the contract
• All tests using yarn test pass