Coinbase Maturity Scheduling

Paano nag-eescrow ang Parallax ng miner subsidies hanggang maturity gamit ang deterministic, canonical state updates.

Maturity Parameters
ParameterSymbolValue / SourceNotes
Coinbase maturity blocks
M
100 blocks
Bitcoin-like coinbase maturity
Lockbox address
—
0x0000000000000000000000000000000000000042
Reserved system account
Key prefixes
—
"maturity:addr:", "maturity:amt:"
Keccak256(prefix || big-endian height)
Overview
Inie-escrow ng Parallax ang block subsidies hanggang fixed maturity height, at nire-release ang mga ito deterministically mula sa lockbox sa state trie.
  • Bawat block ay nagsi-schedule ng sariling coinbase payout para sa height + M blocks, kung saan M = 100 blocks.
  • May special lockbox account na nag-iimbak ng "when" (height) → (addr, amt) pairs bilang state slots.
  • Sa bawat height h, sinusuri ng protocol kung may due payout para sa h at inililipat ito sa naka-recordna address.
  • Pinaghihiwalay nito ang pending issuance sa spendable supply at pinaaayos ang reorg handling.
High-level flow
pseudocode
Finalize(header, state):
  h = header.number
  R = calcBlockReward(h)
  M = 100 blocks
  if R > 0:
    putScheduledPayout(state, h + M, header.coinbase, R)
  if due(h):
    (addr, amt) = popDuePayout(state, h)
    state.AddBalance(addr, amt)
  header.Root = state.IntermediateRoot(...)
State Keys at Lockbox Address
Dalawang storage slots kada unlock height sa ilalim ng reserved system address.
  • Para sa given unlock height H: i-store ang address sa schedKeyAddr(H) at amount sa schedKeyAmt(H).
  • Pareho silang derived ng keccak256 ng fixed ASCII prefix kasama ang H na encoded bilang big-endian uint64.
  • Naka-key ang presence sa amount slot; inii-clear ng payout ang parehong slots para mabawi ang trie space.
Key derivation (mula sa consensus.go)
pseudocode
schedKeyAddr(H):
  b = bigEndianUint64(H)
  return keccak256("maturity:addr:" || b)

schedKeyAmt(H):
  b = bigEndianUint64(H)
  return keccak256("maturity:amt:" || b)
Payout Lifecycle
Mula sa block inclusion hanggang matured transfer.
  • Na-mine ang Block N → kinacompute ang reward R_N mula sa halving schedule.
  • Mag-schedule ng (addr=coinbase_N, amt=R_N) sa unlock height U = N + M.
  • Sa height U, binabasa ng node ang (addr_U, amt_U); kung amt_U ≠ 0, nag-credit at nag-clear ng slots.
  • Walang spendable subsidy ang Genesis (height 0).
Timeline (textual diagram)
pseudocode
N:   mine block, schedule payout for U=N+M
...
U-1: pending only
U:   popDuePayout → AddBalance(addr_U, amt_U) → clear slots
U+1: nothing due for U anymore
Validation at Security Properties
Deterministic na unlocks, replay-safe, at reorg-resilient.
  • Kinacompute ang unlock logic mula sa canonical height; walang kailangang signatures o off-chain triggers.
  • Protocol-computed ang amounts (calcBlockReward) — hindi pwedeng i-inflate ng peers ang payouts.
  • Ang presence ng state key ang 'due' indicator; pinipigilan ang double-spend sa pag-clear pagkatapos mag-credit.
  • Pina-defer ng maturity ang miner spendability, na nagpapababa sa incentives para sa near-tip reorgs na mahuli kaagad ang fees+subsidy.
Due detection at clearing
pseudocode
popDuePayout(state, H):
  rawAmt  = state.Get(lockbox, schedKeyAmt(H))
  if rawAmt == 0: return (zero, 0, false)
  rawAddr = state.Get(lockbox, schedKeyAddr(H))
  state.Set(lockbox, schedKeyAmt(H), 0)
  state.Set(lockbox, schedKeyAddr(H), 0)
  return (Address(rawAddr), BigInt(rawAmt), true)
Reorg Behavior
Ano ang nangyayari kung mag-reorganize ang chain sa paligid ng unlock heights.
  • Sa reorg, kinacompute ulit ang state mula sa bagong canonical chain; sumasalamin ang scheduled entries sa canonical sequence ng blocks.
  • Kung naganap ang payout sa height H sa lumang tip pero hindi sa bagong chain, ang state replay ay magkre-credit lang ng due sa bagong history.
  • Dahil naka-key ang entries sa height, hindi makakapasa ang "phantom credits" sa reorg — sumusunod ang cleared/uncleared status sa canonical execution.
  • Sumasalamin ito sa kung paano nag-re-compute ang balances at receipts sa block re-execution.
Conceptual reorg pseudocode
pseudocode
ReorgTo(newTip):
  rewind state → parent of fork
  for block in pathTo(newTip):
    Execute(block) // schedules & payouts naturally recompute
Configuration
Saan nakatira ang maturity parameter at paano ito kinakain ng clients.
  • Ang Maturity M ay defined bilang 100 blocks
  • Dapat ipakita ng clients ang parehong 'pending' (scheduled) at 'spendable' balances para sa miners.
  • Pwedeng ipakita ng explorers ang upcoming unlocks sa pamamagitan ng pag-scan para sa non-zero schedKeyAmt(h).
  • Dapat balaan ng wallets ang miners na ang reward UTXOs (account credits) ay hindi available hanggang sa height U.
Explorer hint (pseudo-RPC)
pseudocode
for h in [current..current+K]:
  if getState(lockbox, schedKeyAmt(h)) != 0:
    // list upcoming payout at height h
Block Reward at HalvingDifficulty Algorithm