Spark's cascading exit problem
Note: I'm publishing this as a technical discussion. Appreciate correction if needed. This is premature analysis based on protocol specs alone, no tests or live data to validate the mechanics yet.
A previous leaf owner broadcasts their stale exit tx at zero cost. Spark Operators must counter-broadcast the current owner's exit to defend, which spends the root UTXO on-chain, confirming the branch transaction and all its outputs.
If a tree has N leaves (say N=50 for a moderately sized tree), all N holders must broadcast their own leaf-level exit transactions to claim funds from the now-confirmed branch outputs. That's N on-chain transactions from one free broadcast.
The attacked user bears the highest fee burden. Their exit chain includes the heavy branch transaction (N outputs) plus possible CPFP to beat the timelock deadline. Siblings each pay for just one small leaf transaction.
Not catastrophic. Funds are recoverable but 1 free broadcast forces N users on-chain, with the attacked user footing the largest bill. No penalty mechanism for the attacker.
The coupling is architectural: one root backs many leaves, one exit kills the tree.
#Bitcoin #Spark #Layer2 #asknostr #plebchain
