Implementation Guidelines and Best Practices

[plebhash]

Stratum is agnostic with regards to many design decisions on pool and hasher side. Implementers are free to go in any direction they want.

However, while working on protocol specs and reference implementation, we are in a strategic position that allows us to see the mining landscape with a broader and deeper perspective when compared to individual players, which are often blindsighted by their own competitive strategies.

Therefore, it is desirable that the SRI community shares with the community what we see as good Implementation Guidelines and Best Practices.

This discussion aims to get consensus on ideas, which then will turn into actionable documentation items on #79

[plebhash]

Pools shouldn't set difficulty targets for downstream channels based solely on the hashrate that the downstream reports, because the downsteram could simply lie in order to get a low difficulty target and later send too many shares (which technically constitutes a form of spam).

Instead, the pool should collect shares and slowly increase the difficulty target, just like it is currently done on translator_sv2::downstream_sv1::diff_management

[plebhash]

With regards to port standardization, here's a comprehensive list of ports currently used for listening by roles on our development setup:

Role	Port
TP	8442
Pool	34254
JDS	34264
JDC	34265
SV2 Proxy	34255
tProxy	34254

Over Discord, @Sjors suggested the following:

If every role needs it own port, then I would do something like:

Port digits:
network: 0 for mainnet, 1 for regtest, 2 for testnet, 3 for signet, 4 for testnet4
x (e.g. 8)
y (e.g. 8)
z (can't be 3 if x==y==8)
0 pool, 1 job declarator, 2 template provider, etc

So e.g. 8840 for a mainnet pool, 48841 for a testnet4 job declarator.

x = 8, y = 8 feel bitcoiny

Unfortunately I think @Sjors missed the JDC vs JDS split. So I'll take the liberty to shuffle things a bit while still following the overall idea.

Here's a proposal for standardized SV2 ports:

Role	Mainnet Port	Signet Port	Testnet4 Port
TP	8840	38840	48840
Pool	8841	38841	48841
JDS	8842	38842	48842
JDC	8843	38843	48843
SV2 Proxy	8844	38844	48844
tProxy	8845	38845	48845

Implementations should be free to choose different ports, but in case there's need for standardization or interoperability, they could follow this convention in favor of interoperability.

Some production setups could potentially have multiple roles listening on the same port. For example:

• JDS + Pool
• JDC + (t)Proxy

We can highlight that on the guidelines. However, the guidelines also need to cover the most generic case, where each role has its own designated standard port.

Note: I left Testnet3 out of the table, but it should also follow the same pattern 2884*.

[Sjors]

These ports mostly make sense to me, though I didn't check if they clash with any other (important / likely to overlap in users) protocol out there.

By tProxy you mean translator proxy? This should probably listen on the most commonly used stratum v1 port.

Braiins, Antpool and viaBTC use 3333: https://academy.braiins.com/en/braiins-pool/btc-mining-setup/

To to stay close to this potentially familiar feeling range, you could do (x=3, y=3 in my scheme above):

tProxy: 3333 (as if you're connecting to an sv1 pool)
Pool: 3334 (maybe use the same for sv2 proxy)
TP: 3335
JDS: 3336
JDC: 3337

Braiins alternates between 3336 and 3337 for their (now incompatible) stratum v2 endpoints. But I think it's more intuitive to use 3334, as that's just stratum v1 port + 1.

We should ask around what ports miners typically use for other stuff.

[plebhash]

Pools should be aware of protocol attack vectors over (consensus-valid) non-standard transactions.

They have been historically documented, for example: https://bitcointalk.org/?topic=140078%7CCVE-2013-2292

I discussed this briefly with @Fi3 and @Sjors during BTC Prague 2024, and my takeaway is that a practical approach for pools (especially ones with an out-of-band service, like Mara's SplipStream) is to implement a filter based on preemptive timed execution.

Such filter would attempt to execute each transaction arriving out-of-band, while timing such execution. If execution goes above some predefined limit, the transaction is deemed invalid and discarded, regardless of on-chain and out-of-band fees. This aligns with the pool's incentive to avoid introducing net-negative protocol behavior that would arise from blocks including such transaction, which would likely depreciate the value of BTC.

A positive aspect of such approach is that it doesn't require diving into the design space of all possible scripts and playing whack-a-mole on execution paths. Especially with the potential introduction of OP_CAT into the protocol, that kind of approach feels like a non-starter.

[plebhash]

@TheBlueMatt what are your thoughts on this one?

[Sjors]

Maybe @mempool has thoughts here too?

[TheBlueMatt]

Really this is a bug in Bitcoin and the idea that pools need to police what their miners are mining on the basis of some attacks on bitcoin is absurd. Sadly, that's the world we live in today (until GCC at least). With that in mind, it may make sense for any pool worried about this to apply the rules from GCC to what their miners are selecting - disabling OP_CODESEPARATOR for non-segwit scripts, timewarp, etc.

[plebhash]

Sadly, that's the world we live in today (until GCC at least).

100% agree that GCC should be ideal aim. cc @darosior since this touches on Great Consensus Cleanup Revival

Until GCC becomes a reality, it's important that the SRI community advocates for strategies that foster a healthy future of Bitcoin.

I'll echo some words I wrote on the opening post for this Github Discussion:

Stratum is agnostic with regards to many design decisions on pool and hasher side. Implementers are free to go in any direction they want.

However, while working on protocol specs and reference implementation, we are in a strategic position that allows us to see the mining landscape with a broader and deeper perspective when compared to individual players, which are often blindsighted by their own competitive strategies.

Therefore, it is desirable that the SRI community shares with the community what we see as good Implementation Guidelines and Best Practices.

[TheBlueMatt]

Frankly, if I operated a pool today, I'd pay out for any valid work and not worry about miners doing some attack. Doing a big slow-validation exploit takes more than a single block (the impact of a single block is annoying, but not insane, Afaiu) and folks can respond when setup is happening. I think by the time SRI is bulletproof software and large pools are offering custom work, GCC might be active. Best to focus on that rather than worry too much about some miner trying to DoS the network.