SRI standard for Sv2 coinbase tags

[plebhash]

SRI channels_sv2 crate establishes a convention for how Pool and Miner get to write their own vanity tags inside the Coinbase Tx scriptSig

(more specifically, that is defined by the implementation of channels_sv2::server::jobs::JobFactory::op_pushbytes_pool_miner_tag method)

here's some examples of possible combinations:

• A: /pool_tag/miner_tag/
• B: //miner_tag/
• C: /pool_tag//
• D: ///

some notes:

• A has a few different ways to be achieved:
  • via a Sv2 protocol extension, which would allow JDS to dinamically inform the expected pool_tag during JD message flow
  • by hardcoding pool_tag to JDC implementations
  • by allowing pool_tag to be set by JDC user
• B pool must be identified by block explorers via heuristics (e.g.: payout address)
• C will be the most likely for no-JD blocks
• D will be pretty unlikely

if Pool chooses to enforce A, they are incentivized to reject DeclareMiningJob and SetCustomMiningJob where pool_tag differs from the expected string

if Pool chooses to enforce B, they are incentivized to reject DeclareMiningJob and SetCustomMiningJob where pool_tag is not empty

[plebhash]

by reading the above, one might wonder:

why does A require a protocol extension, or for pool_tag to be hardcoded or configured on JDC?

if we look at the Sv2 JD message flow:

• JDC sends AllocateMiningJobToken to JDS
• JDS replies with AllocateMiningJobToken.Success
• JDC uses the token on DeclareMiningJob, which contains the Coinbase Tx it intends to work on

AllocateMiningJobToken.Success does not have any field that would allow JDS to dinamically inform the intended pool_tag

a protocol extension would add a new field to AllocateMiningJobToken.Success for this specific purpose

and for use-cases without protocol extensions, JDC implementations could either enforce that by:

• associating specific hardcoded pool_tags to hardcoded upstream addresses
• allowing the user to configure it (under the assumption that JDS might reject custom jobs with typos etc)

[average-gary]

Are the / characters always needed? Would there not be an option to have no signature at all?

Edit: This would be the case with no extension enabled.

[plebhash]

Would there not be an option to have no signature at all?

what's the use-case?

theoretically yeah it's possible (why not), but it's not currently implemented

end of the day, it's extra complexity so there needs to be a compelling reason to justify the added maintainability burden to SRI

---

moreover, it's important to remember this is simply an opinionated implementation detail of channels_sv2 crate of SRI stack

it's not really something imposed by spec