Decide merge-mining payout policy before block 2,000,000 #36

Closed
opened 2026-09-14 14:13:15 +00:00 by btcbob · 2 comments
Owner

HARDFORK_AUXPOW_MAIN = 2000000 (src/pow.h:37). At present height ~1,904,400
that is ~95,500 blocks, roughly 132 days at 2-minute spacing.

The question

createauxblock takes a single payout address, and consensus only checks the
coinbase does not exceed the subsidy — not whose address it is. So the first pool
operator to bolt (BOB) onto their existing LTC/DOGE merkle tree collects the whole
issuance for hashes they were already producing.

Raised in forum topic 31, msg 79, still unanswered:

  • does the pool credit that to its miners, or keep it, and is that our call or theirs
  • what stops one operator collecting indefinitely
  • what happens to people mining on our own pool the day this switches on

Why the deadline is real

AuxPoW activation is a hard fork in both directions (src/main.cpp:2682-2693):
before 2M a nonzero chain ID is rejected, from 2M a chain ID that is not 0x00B0
is rejected. Every node must upgrade.

Today the upgrade audience is our own operators. After 2M it includes foreign
pool operators who merge-mine us incidentally and have no reason to rebuild a node
for a fringe aux chain.
A second hard fork after that point is not a coordination
problem, it is a request strangers can simply decline.

So: if the answer requires a consensus rule, it has to land at 2M or not at all.

Prior art in-house

The Offerings chain already enforces a split in consensus — a required coinbase
output matching an exact script and an exact fraction of subsidy, rejected if
absent (main.cpp:2227 in that tree, GetTreasurySubsidy() / TreasuryScript()).
That is the same shape a merge-mining split would take here.

No policy proposed in this issue. Filing so the deadline is written down.

`HARDFORK_AUXPOW_MAIN = 2000000` (`src/pow.h:37`). At present height ~1,904,400 that is **~95,500 blocks, roughly 132 days** at 2-minute spacing. ### The question `createauxblock` takes a single payout address, and consensus only checks the coinbase does not exceed the subsidy — not whose address it is. So the first pool operator to bolt (BOB) onto their existing LTC/DOGE merkle tree collects the whole issuance for hashes they were already producing. Raised in forum topic 31, msg 79, still unanswered: - does the pool credit that to its miners, or keep it, and is that our call or theirs - what stops one operator collecting indefinitely - what happens to people mining on our own pool the day this switches on ### Why the deadline is real AuxPoW activation is a **hard fork in both directions** (`src/main.cpp:2682-2693`): before 2M a nonzero chain ID is rejected, from 2M a chain ID that is not `0x00B0` is rejected. Every node must upgrade. Today the upgrade audience is our own operators. **After 2M it includes foreign pool operators who merge-mine us incidentally and have no reason to rebuild a node for a fringe aux chain.** A second hard fork after that point is not a coordination problem, it is a request strangers can simply decline. So: if the answer requires a consensus rule, it has to land at 2M or not at all. ### Prior art in-house The Offerings chain already enforces a split in consensus — a required coinbase output matching an exact script and an exact fraction of subsidy, rejected if absent (`main.cpp:2227` in that tree, `GetTreasurySubsidy()` / `TreasuryScript()`). That is the same shape a merge-mining split would take here. No policy proposed in this issue. Filing so the deadline is written down.
Author
Owner

Correcting something I wrote in this issue, and adding what the test chain says.

"Every node must upgrade" was too strong

The activation gate and the conditional block serialization have both been in the
source since v0.12.0 (tagged 2026-06-01, ef31ce50). src/primitives/block.h
is byte-identical at that tag and at HEAD. So block 2,000,000 does not require a
new release — it requires that a node is not running something older than v0.12.0.
Every release since June already carries the fork.

Merge mining is optional after activation

The post-fork rule requires the chain ID; it does not require the AuxPoW bit
(src/main.cpp:2694-2697). A miner pointing scrypt hashrate straight at (BOB)
after 2M keeps working exactly as today. Verified on regtest: blocks 10 through 15
were mined natively post-fork by setgenerate and accepted, carrying
0x00b00003.

Activation makes merge mining possible alongside solo mining. It does not strand
anyone and it does not force a switch.

The mechanism is now tested

qa/auxpow-smoke/run-parent-pow-tests.sh (commit 47cb4fcc) merge-mines a block
against a synthetic parent chain with real scrypt proof of work, and submits eight
single-field mutations that must all be refused — each checked against the
validator error it was meant to trigger, not merely against a false return.

What does not change

The payout question in this issue is still open and still the only item with a
clock on it.
None of the above touches who receives the coinbase when a foreign
pool starts finding our blocks. Mechanism is proven; policy is not decided.

Also worth noting for scheduling: at the 120.4 s average of the last 2,000 blocks,
block 2,000,000 lands around late January 2027.

Correcting something I wrote in this issue, and adding what the test chain says. ### "Every node must upgrade" was too strong The activation gate and the conditional block serialization have both been in the source since **v0.12.0** (tagged 2026-06-01, `ef31ce50`). `src/primitives/block.h` is byte-identical at that tag and at HEAD. So block 2,000,000 does not require a new release — it requires that a node is not running something older than v0.12.0. Every release since June already carries the fork. ### Merge mining is optional after activation The post-fork rule requires the chain ID; it does **not** require the AuxPoW bit (`src/main.cpp:2694-2697`). A miner pointing scrypt hashrate straight at (BOB) after 2M keeps working exactly as today. Verified on regtest: blocks 10 through 15 were mined natively post-fork by `setgenerate` and accepted, carrying `0x00b00003`. Activation makes merge mining *possible* alongside solo mining. It does not strand anyone and it does not force a switch. ### The mechanism is now tested `qa/auxpow-smoke/run-parent-pow-tests.sh` (commit `47cb4fcc`) merge-mines a block against a synthetic parent chain with real scrypt proof of work, and submits eight single-field mutations that must all be refused — each checked against the validator error it was meant to trigger, not merely against a false return. ### What does not change **The payout question in this issue is still open and still the only item with a clock on it.** None of the above touches who receives the coinbase when a foreign pool starts finding our blocks. Mechanism is proven; policy is not decided. Also worth noting for scheduling: at the 120.4 s average of the last 2,000 blocks, block 2,000,000 lands around late January 2027.
Author
Owner

Closing — this was already decided, and this issue should not have been filed as open

The issue says the question was "raised in forum topic 31, msg 79, still unanswered." It was answered in msg 82 of the same thread, by BtcBob, at length. I read msg 79 and stopped three messages short of the answer.

The decision

"i thought about it properly and i'm not doing it. It's a real option and it's sitting right there — we're already opening the hood, the subsidy is a consensus rule, and merge mining costs the miner nothing extra so they'd take a much smaller number and still secure us. I still won't. That's us writing special case economics under a clock, one shot at picking a number, to solve something that hasn't happened yet, with a thing we can't take back."

"So we stay on schedule. 2,000,000, auxpow, no split, no touching the emission on the way past."

And the framing, which answers the premise rather than the question:

"What merge mining is, is this — you give up the issuance and you get a chain nobody can afford to attack. That's not a side effect I'm tolerating, that's the deal."

What that means concretely

  • No consensus rule about the coinbase. createauxblock takes an address, hands it to CreateNewBlock as the scriptPubKey, and consensus checks only that the amount does not exceed the subsidy. That is by design and stays that way.
  • We have no say in who collects, and are not seeking one. A pool that merge-mines (BOB) and keeps the full 1.5 is doing nothing the code objects to, because there is nothing in the code about it.
  • The cost was stated, not discovered. The four questions in msg 79 were answered plainly, including the one that matters: miners on small dedicated hardware stop finding blocks entirely, not merely fewer. That was said out loud before block 2,000,000 rather than left for someone to work out from their own balance.

Consequence for the 2M change set

The only reason this had a deadline was the possibility of a consensus split rule, which would have had to land at the AuxPoW fork or become a second hard fork. That option is declined, so the deadline is gone. Nothing about the merge-mining fork now requires a decision before block 2,000,000.

The items that do land at 2M — AuxPoW activation and CLTV — are both already in main.

Closing as decided. Reopening would mean revisiting a settled call, not answering an open question.

## Closing — this was already decided, and this issue should not have been filed as open The issue says the question was "raised in forum topic 31, msg 79, still unanswered." It was answered in **msg 82 of the same thread**, by BtcBob, at length. I read msg 79 and stopped three messages short of the answer. ### The decision > *"i thought about it properly and i'm not doing it. It's a real option and it's sitting right there — we're already opening the hood, the subsidy is a consensus rule, and merge mining costs the miner nothing extra so they'd take a much smaller number and still secure us. I still won't. That's us writing special case economics under a clock, one shot at picking a number, to solve something that hasn't happened yet, with a thing we can't take back."* > > *"So we stay on schedule. 2,000,000, auxpow, no split, no touching the emission on the way past."* And the framing, which answers the premise rather than the question: > *"What merge mining is, is this — you give up the issuance and you get a chain nobody can afford to attack. That's not a side effect I'm tolerating, that's the deal."* ### What that means concretely - **No consensus rule about the coinbase.** `createauxblock` takes an address, hands it to `CreateNewBlock` as the scriptPubKey, and consensus checks only that the amount does not exceed the subsidy. That is by design and stays that way. - **We have no say in who collects, and are not seeking one.** A pool that merge-mines (BOB) and keeps the full 1.5 is doing nothing the code objects to, because there is nothing in the code about it. - **The cost was stated, not discovered.** The four questions in msg 79 were answered plainly, including the one that matters: miners on small dedicated hardware stop finding blocks entirely, not merely fewer. That was said out loud before block 2,000,000 rather than left for someone to work out from their own balance. ### Consequence for the 2M change set The only reason this had a deadline was the possibility of a consensus split rule, which would have had to land at the AuxPoW fork or become a second hard fork. **That option is declined, so the deadline is gone.** Nothing about the merge-mining fork now requires a decision before block 2,000,000. The items that do land at 2M — AuxPoW activation and CLTV — are both already in `main`. Closing as decided. Reopening would mean revisiting a settled call, not answering an open question.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
SubGeniusFinance/dobbscoin-source#36
No description provided.