channels_sv2: fix coinbase scriptSig size/serialization defects that yield consensus-invalid coinbases

[plebhash]

close #2242
close https://github.com/project-loupe/audit-stratum/issues/20
close https://github.com/project-loupe/audit-stratum/issues/30
close https://github.com/project-loupe/audit-stratum/issues/79
close https://github.com/project-loupe/audit-stratum/issues/88

companion stratum-mining/sv2-apps#658

[bit-aloo]

One suggestion, and rest looks ok

[bit-aloo]

ACK

[GitGab19]

Clanker review:

Verdict: request changes on [PR #2243](#2243).

Finding

• [High] The scriptSig guard is bypassed for custom jobs. The new “authoritative” check exists only in [JobFactory::coinbase](https://github.com/stratum-mining/stratum/blob/18029b1e86b19a2d3d76ac5cb0046f5414cce625/sv2/channels-sv2/src/server/jobs/factory.rs#L626-L635). [new_custom_job](https://github.com/stratum-mining/stratum/blob/18029b1e86b19a2d3d76ac5cb0046f5414cce625/sv2/channels-sv2/src/server/jobs/factory.rs#L416) and the receiving [custom_coinbase](https://github.com/stratum-mining/stratum/blob/18029b1e86b19a2d3d76ac5cb0046f5414cce625/sv2/channels-sv2/src/server/jobs/factory.rs#L542) path never call it.

  I reproduced this with the PR’s boundary configuration: a 52-byte pool tag, 32-byte extranonce, and 9-byte template prefix produce a 101-byte scriptSig. Both new_custom_job and new_extended_job_from_custom_job return Ok, so the JDC can still create—and the pool can still accept—consensus-invalid work. Larger custom prefixes also invalidate the custom prefix/suffix code’s assumption that the CompactSize script length occupies exactly one byte.

  I’d factor an exact-size validator out of coinbase() and call it from new_custom_job; the receiving path should independently enforce:

  set_custom_mining_job.coinbase_prefix.len() + full_extranonce_size <= MAX_SCRIPT_SIG_SIZE

[plebhash]

Clanker review:

Verdict: request changes on [PR #2243](#2243).

Finding

• [High] The scriptSig guard is bypassed for custom jobs. The new “authoritative” check exists only in [JobFactory::coinbase](https://github.com/stratum-mining/stratum/blob/18029b1e86b19a2d3d76ac5cb0046f5414cce625/sv2/channels-sv2/src/server/jobs/factory.rs#L626-L635). [new_custom_job](https://github.com/stratum-mining/stratum/blob/18029b1e86b19a2d3d76ac5cb0046f5414cce625/sv2/channels-sv2/src/server/jobs/factory.rs#L416) and the receiving [custom_coinbase](https://github.com/stratum-mining/stratum/blob/18029b1e86b19a2d3d76ac5cb0046f5414cce625/sv2/channels-sv2/src/server/jobs/factory.rs#L542) path never call it.
  I reproduced this with the PR’s boundary configuration: a 52-byte pool tag, 32-byte extranonce, and 9-byte template prefix produce a 101-byte scriptSig. Both new_custom_job and new_extended_job_from_custom_job return Ok, so the JDC can still create—and the pool can still accept—consensus-invalid work. Larger custom prefixes also invalidate the custom prefix/suffix code’s assumption that the CompactSize script length occupies exactly one byte.
  I’d factor an exact-size validator out of coinbase() and call it from new_custom_job; the receiving path should independently enforce:

  set_custom_mining_job.coinbase_prefix.len() + full_extranonce_size <= MAX_SCRIPT_SIG_SIZE

addressed, clanker answer:

Good catch on the custom job path — confirmed, and fixed in fa1cd824.

I reproduced all three cases before touching anything:

JDC new_custom_job (52-byte tag, 9-byte prefix): Ok -> 101-byte scriptSig
pool new_extended_job_from_custom_job:           Ok
hostile 250-byte prefix from downstream:         Ok -> 282-byte scriptSig

The delegation argument doesn't hold for the receiving path: new_extended_job_from_custom_job takes coinbase_prefix from a downstream JDC over the wire, so the "upstream caller" is a remote peer and there is nothing in-tree left to delegate to. That one is worth fixing regardless of scope, so I did — the 250-byte case above is a hostile downstream, not a misconfigured local one.

The two paths can't share one validator. Factoring the exact-size check out of coinbase() and calling it from both doesn't work, because the arithmetic differs:

• new_custom_job (JDC builds the prefix): the factory adds the pool/miner tag itself, so script_sig_size(template.coinbase_prefix.len(), full_extranonce_size) applies.
• new_extended_job_from_custom_job (pool receives it): the tag is already embedded in the incoming coinbase_prefix, so it's coinbase_prefix.len() + full_extranonce_size — exactly your second snippet. Reusing script_sig_size here would double-count the tag.

Both are bounded now. The receiving check sits in custom_coinbase so the prefix and suffix builders are covered by a single choke point, mirroring how coinbase() owns the template path. Bounding the custom path to 100 bytes also closes the CompactSize concern you raised, since the scriptSig can no longer reach 253.

Covered by test_new_custom_job_rejects_oversized_script_sig and test_custom_job_rejects_oversized_script_sig: exact-100 → Ok, 101 → Err, plus the 250-byte hostile case.