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

Postage: silent bucket rollover on mutable batches overwrites previously stamped chunks — make reuse explicit

Aperta
  • Qualcosa non va?
#5,538 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

@martinconic ci sta già lavorando.

Dal 10/8/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

seen
Context

When a postage batch's collision bucket is full, StampIssuer.increment behaves differently depending on the batch type (pkg/postage/stampissuer.go):

  • Immutable batch: returns ErrBucketFull — the upload fails, as expected.
  • Mutable batch: silently resets the bucket counter to 0 and starts issuing stamp indices that were already used.

Because a reused (bucket, index) pair with a newer timestamp displaces the chunk previously holding that slot, uploading past a mutable batch's capacity silently destroys earlier data — including data from the same upload.

Concretely: uploading a ~4 GB file with a ~512 MB batch does not fail. Bee just rolls over the buckets ~8 times, overwriting the earlier parts of the file with the later parts. The upload "succeeds" and returns a reference, but the content is unretrievable. The user gets no signal that anything went wrong.

Proposal

  1. Drop the implicit rollover. On bucket-full, mutable batches should behave the same as immutable ones at stamping time: return ErrBucketFull (surfaced as an appropriate API error) instead of silently reusing slots. Overwriting paid-for data should never be an accidental side effect of an upload.

  2. Add an explicit bucket-reset API. Intentional reuse of a mutable batch is a legitimate use case, so make it deliberate: an endpoint (e.g. POST /stamps/{batch_id}/reset or similar) that resets the issuer's bucket counters for that batch. The docs should make clear that previously stamped chunks may subsequently be displaced.

  3. Randomize the chunk encryption key on bucket-full (encrypted uploads). For encrypted chunks the address is not fixed by content alone, so when the target bucket is full the stamper can re-roll the chunk encryption key until the resulting address lands in a non-full bucket. This lets encrypted uploads utilize the batch's full nominal capacity instead of failing on the first full bucket, and composes with (1): the hard failure only happens when the batch is genuinely exhausted.

Notes
  • (1) is a behavioral/API change: uploads that previously "succeeded" (while corrupting earlier data) will now fail with bucket-full. That failure is strictly more honest than the current behavior, but it deserves an API version note and a changelog entry.
  • (2) needs a decision on scope: reset all buckets vs. per-bucket, and whether the reset should also be reflected in utilization reporting (Utilization/UtilizationRatio).
  • (3) applies only to node-side encrypted uploads; plaintext chunk addresses are content-derived and cannot be re-rolled.

Proposed by Ábel, based on Áron's observation about stamp overwriting on bucket overflow.

Lingua principale
Go
Stelle
1.5k
Fork
390
Merge medio
3g 58m
PR unite (30g)
25

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 ethersphere/bee

Tutte le issue di ethersphere/bee

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.