Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

MixinReserve.claimableReserve() mid-round accounting mismatch when transcoder pool size and current-round active set diverge

Aperta
#656 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
solidity

Direzione di ricerca

Inizia con contracts/pm/mixins/MixinReserve.sol, quindi segui MixinTicketBrokerCore.redeemWinningTicket() e BondingManager.resignTranscoder() o tryToJoinActiveSet(). L’issue descrive una discrepanza contabile documentata e fuori ambito e non specifica alcuna modifica al codice né alcun test di accettazione, quindi non viene fornita alcuna condizione concreta di completamento.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

known-issue
Summary

MixinReserve.claimableReserve() reads two data structures that can fall out of sync within one round. Claimant eligibility is gated on bondingManager().isActiveTranscoder(_claimant) (a current-round snapshot), while the reserve allocation is divided by bondingManager().getTranscoderPoolSize() (the live pending transcoder pool counter). When the pending pool shrinks or grows mid-round (e.g. via resignTranscoder() or tryToJoinActiveSet()), the eligible active set and the divisor diverge, causing the per-claimant reserve cap to deviate from the fair R / N allocation in either direction.

Root cause

isActiveTranscoder() is gated on activationRound <= currentRound < deactivationRound, which is a round-level snapshot. getTranscoderPoolSize() returns the live size of the transcoderPool linked list, which is mutated immediately by bonds, unbonds, evictions, and resignations.

When an active transcoder fully unbonds in round r:

The set of eligible claimants has size N, but the divisor is N - 1. Every eligible share is inflated by N / (N - 1). The symmetric case (new transcoder joining via tryToJoinActiveSet() when a slot is free) deflates the cap in the same way.

Why it's not an issue
  • No theft. The redeemed amount is bounded by the ticket's faceValue and can never exceed the face value the broadcaster explicitly signed. No funds are created beyond what the broadcaster committed.
  • Grief is temporary. claimFromReserve is explicitly designed to pay min(shortfall, claimableReserve), not the full face value. Partial reserve payment for a valid ticket is normal protocol behavior. After a revert, usedTickets[hash] remains false and the ticket can be retried in a later round (subject to ticketValidityPeriod).
  • Restrictive preconditions. The attack requires (1) a valid pre-signed winning ticket where faceValue - deposit > R / N, (2) the attacker accepting the opportunity cost of fully unbonding (or coordinating with a separate pool-shrinker), and (3) no other transcoder bonding into the freed slot between the pool shrink and the redeem call. Splitting the pool-shrinker and the overclaimer into separate accounts reintroduces a race: the pool shrink and the redemption can no longer be bundled into one transaction, so any transcoder bonding into the free slot between the two steps restores the pool size and cancels the inflation.
  • Protocol spec acknowledges the behavior. The Livepeer technical spec documents a scenario where an orchestrator sets their ticket's face value to R / N, but by the time they redeem, the active set has grown to N + 1, dropping the cap to R / (N + 1). This is treated as a known limitation of the reserve mechanism. The invariant claimableReserve == R / active_set_size at all times is not guaranteed by the spec.
Out of scope for bug bounty

Reports targeting the claimableReserve accounting mismatch in MixinReserve.sol, and the associated griefing/payment-disruption paths through MixinTicketBrokerCore.redeemWinningTicket(), BondingManager.resignTranscoder(), or BondingManager.tryToJoinActiveSet(), are closed as known issues and not eligible for rewards under the Livepeer Immunefi bug bounty program.

References
Lingua principale
JavaScript
Stelle
155
Fork
50
Merge medio
9g 22h
PR unite (30g)
1

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di livepeer/protocol

Tutte le issue di livepeer/protocol

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.