Commit and reveal, and what to do when a reveal sticks

Inscribing is always two transactions, ten minutes apart, and the second one holds your inscription while it waits. Here is why, and what makes the difference between a reveal you can rescue and one you cannot.

Inscribing is two transactions and it cannot be one.

1. Commit. Build the script holding the data, derive a Taproot address that commits to it, and pay that address. Nothing about the content is public yet.
2. Reveal. Spend that output through the script path. The script — and with it the inscription — appears in the witness.

Wait for the commit to confirm

A reveal spends an output the receiving node may not have seen. If the commit is still in the mempool when the reveal arrives, the node answers missing-inputs and drops it. Running your own node lets you submit both as a package; without one, the answer is to wait for a confirmation.

Ten minutes of waiting is the cost. It buys you a reveal that will actually relay, and it is much cheaper than the alternative.

What is at stake while the reveal waits

The reveal spends the inscription's own output. From the moment it is broadcast, that inscription is pending-spent: it cannot be moved, listed or sold until the transaction confirms or the mempool forgets it. That can be weeks if the fee was too low.

So the fee on a reveal matters more than the fee on an ordinary payment. Two things protect you.

Replacement

If every input signals it — a sequence at or below 0xfffffffd — the transaction can be replaced by one paying more. The extra fee has to come from somewhere, and the only place it can come from is the change output, since the inscription's own output must be returned intact.

Child-pays-for-parent

Alternatively, spend the reveal's change in a new transaction with a large fee. Miners consider the pair together, so a rich child drags a poor parent along.

The arithmetic that decides whether either works

Both mechanisms spend the change output, so its size decides whether you have a rescue or a story. This is worth doing the sums on, because the intuitive answer is wrong.

A CPFP child is one input and one output: about 112 vbytes. Suppose the reveal is 295 vbytes at 4 sat/vB — a fee of 1,180 sats — and it left the dust minimum of 330 sats as change. Spend all of it in a child:

package size  = 295 + 112       = 407 vbytes
package fee   = 1,180 + 330     = 1,510 sats
package rate  = 1,510 / 407     = 3.71 sat/vB

The rate went down. The child costs more in weight than the 330 sats adds in fee, so the "bump" makes the package less attractive than the reveal was on its own.

A change output at the dust limit is not a rescue. It looks like one, which is worse than not having one, and this project shipped exactly that mistake before doing the arithmetic. The fix is to fund the commit generously — enough that the change is a multiple of the reveal's own fee rather than the smallest output that will relay.

What to check before you broadcast

• Does every input signal replaceability?
• Is there a change output, and is it several times the dust limit rather than exactly the dust limit?
• Is the fee rate the one the mempool is asking now, not the one it was asking when the commit was drafted a block ago?
• Do you still hold the key that signs the reveal's script-path input? Without it you cannot sign a replacement, so throwing it away at broadcast throws away your ability to bump.