A 256-bucket reuse guard and packed UTXO incarnations were implemented against the same stale-opening threat: one physical slot can later hold an output with the same visible value but a different identity. Incarnations distinguish successive outputs, reject old openings and remove the second guard root and its proof families. Same-block physical-slot conflicts remain forbidden by the block-wide uniqueness rule. The identifier remains branch-local and composes with canonical history.
The slot-reuse problem
A UTXO is an unspent transaction output. Parano1d stores current UTXOs in a bounded State whose physical slots are reusable indexes rather than permanent outpoint names. An exact-State opening is the Merkle proof that authenticates the complete leaf stored at one such slot. If the same slot later contains the same amount and owner, an old opening must not authenticate the new output. This is the classic A→B→A, or ABA, shape: the visible value returns to A while its logical identity has changed.
Experiment 1. Consensus quarantine
The first construction used ReuseGuard, a second State structure that recorded when freed slots could become eligible again. It was organized as a 256-bucket ring. A freed slot remained quarantined for one block longer than the protocol's finality window; consensus carried a separate guard root, bucket paths and proof relations.
The guard prevented immediate reuse, but imposed costs unrelated to the UTXO value itself:
- an additional consensus State root and rollback domain;
- three proof components for guard buckets and State-root binding;
- two transition paths that had to advance the guard identically.
A prototype parity test deliberately exercised both transition paths and rejected a divergent guard-advance rule before design selection. The paths could be made identical, but maintaining that equivalence would remain a permanent proof obligation created by the second State machine.
Experiment 2. Put identity in the value
The alternative packs the amount and a monotone creation identifier into the existing 128-bit value lane:
Every ordinary minted output receives the next branch-local creation_id. The primary block reward also advances the allocation counter, but stores a height-tagged identifier from a separate namespace. The exact-State leaf and input leaf therefore commit to logical incarnation as well as slot, owner and amount.
Adversarial and boundary tests
| Case | Expected property | Result |
|---|---|---|
| Same slot, owner and amount; new ID | Old exact opening must fail | Distinct State and input leaf hashes |
| One physical slot appears in two live actions in the same block | Reject before applying the transition | BlockSlotConflict |
| Gapped, repeated or reordered IDs | Reject | Rejected |
Next allocator ID enters the reserved reward namespace or overflows u64 | No namespace overlap or wraparound | Consensus-invalid |
The prototype also checked that creation_id = 0 preserves the baseline hash schedules. Incarnation data fit into an existing field lane; no extra leaf, header root or proof family was required.
Scope
The identifier is branch-local. Rollback restores the allocation counter with State, so competing branches may assign the same numeric identifier to different outputs. Branch and epoch binding remain the responsibility of canonical history. The construction solves stale exact-State openings within one canonical branch; it does not create a global outpoint namespace.
Result
The incarnation design replaced the quarantine ring and removed its guard proof relations. More generally, when a reusable physical location represents successive logical objects, committing a monotone incarnation directly into the object is simpler than maintaining a second consensus structure that remembers when the location may be reused.