new features to backport on `v0.3.5`

[GitGab19]

This issue is going to be used to track important features we want to backport to the older JDC/tProxy applications, which we want to maintain to keep compatibility with Bitcoin Core v30.2.

• expose stable_hashrate via monitoring HTTP APIs #496
• enable payout verification in tProxy in case of SOLO mining #497
• represent share work as u64 (where appropriate) #449
• adapt sv2-apps with channels_sv2::server::share_accounting keeping track of rejected shares #491

[plebhash]

branch release/v0.3.6 pushed

cherry-picked from #496:
a4029fe from 44f2b3c (JDC vardiff keeps track of stable hashrate)
29eb999 from 049019f (Pool vardiff keeps track of stable hashrate)
3620948 from 79cb965 (stratum-apps::monitoring keeps track of stable_hashrate)
638c206 from 2d8636f (Pool monitoring API keeps track of channel's stable_hashrate property)
0d282da from c09661e (JDC monitoring API keeps track of channel's stable_hashrate property)
42814e5 from 09d0242 (tProxy monitoring API keeps track of channel's stable_hashrate property)

1:1 custom/analogous for #496:
7f113aa (backport: tProxy vardiff keeps track of stable hashrate)
ddaa78a (backport: pool stable_hashrate tracking compatibility)
21f0ef6 (backport: jd-client stable_hashrate tracking compatibility)

cherry-picked from #497 (with conflict resolution where needed):
0ae6ec9 from d8ff249 (add shared payout helpers in stratum-apps)
61d9a72 from 5457fd3 (move Pool to use shared payout mode)
c494571 from af7374b (add payout checks in tProxy when doing SOLO mining)
4a7694e from dcaa401 (add IT for tProxy checks and fallbacks on payout distributions)

final version-bump commit:
1f8b2f4 (release: bump patch versions for v0.3.6 backports see #505)

I'm running integration tests locally

[GitGab19]

I would wait to trigger any release there though, until we're almost wrapping up the v0.5.0 milestone.

[plebhash]

actually, please disregard the message above

the backports were not sane, I'm deleting release/v0.3.6 for the time being

I'm afraid #496 will not be very straightforward to backport, mainly because of the companion stratum-mining/stratum#2152

I have to think more deeply about this

[plebhash]

as mentioned above, evaluating all the variables for backporting PRs to past release cycles turns out to be non-trivial

leaving it entirely for human planning/execution ends up being highly laborious, time consuming, and most importantly: EXTREMELY error-prone

so I came up with a prompt template so we can leverage coding agents to do this in a more sustainable way.

warning: it might take a long time (and a lot of tokens) for this prompt to fully plan and execute... the agent must also be carefully watched

[plebhash]

one important takeaway from this investigation:

moving forward, every time we do a MAJOR or MINOR global release on stratum repository, we MUST NOT bump PATCH version of stratum-core like we did here:

sv2-apps global release	stratum global release	stratum-core
v0.2.0	v1.7.0	v0.2.0
v0.3.0	v1.8.0	v0.2.1

in order to understand the rationale behind this, let's take e.g.: channels_sv2 into consideration:

sv2-apps global release	stratum global release	stratum-core	channels_sv2
v0.2.0	v1.7.0	v0.2.0	v3.0.0
v0.3.0	v1.8.0	v0.2.1	v4.0.0

now imagine we need to backport some feature into sv2-apps v0.2.x, while also having to backport things into channels_sv2:

sv2-apps global release	stratum global release	stratum-core	channels_sv2
v0.2.0	v1.7.0	v0.2.0	v3.0.0
v0.2.1	v1.7.1	v0.2.?	v3.0.1
v0.3.0	v1.8.0	v0.2.1	v4.0.0

which version should we use for stratum-core? v0.2.1 is already taken!

using v0.2.2 doesn't seem like the right choice, since channels_sv2 v4.0.0 was already used for stratum-core v0.2.1, and we would break the natural progression by associating channels_sv2 v3.0.1 with stratum-core v0.2.2

therefore, the conclusion we arrive is that the following rule must be followed:

PATCH version bumps of stratum-core crate must be reserved to PATCH global releases of stratum repo

gladly, I don't think we will ever need to backport anything to v0.2.0/v1.7.0, so we will not face this blocker due to this past violation

here, v0.2.0/v1.7.0 serves merely as an example to illustrate how things would go bad

but moving forward, we must follow this rule stricly, otherwise we could find ourselves in very tricky situations with regards to backports of HTTP API features in future releases

PR stratum-mining/stratum#2158 is adding this rule to CONTRIBUTING.md of stratum repo

---

does that mean that every time we backport, we create a new PATCH release on stratum?

not necessarily.

as a first attempt, it makes sense to simply try to use the upcoming release of stratum on the PATCH release of sv2-apps.

but if we face deeper incompatibilities (e.g.: upcoming stratum-core uses incompatible codec_sv2 in a way that's completely orthogonal to the HTTP API changes), we will have to fallback to creating a PATCH release on stratum as well

the prompt template frames this as (with replaced prompt template variables for clarity):

in summary, while choosing which stratum-core version to use on release/v0.3.6, we we will have two options:

• A. use the same stratum-core version that was used on the previous release under v0.3.x
• B. create a new stratum release branch on v1.8.x and backport changes from stratum companion PRs with new PATCH bumps on crates (including stratum-core)

option A. should be preferred, but if any PR under the sv2-apps PRs to be backported has stratum companions , this option is not available

for us to always have option B available, we must start following the rule described above.

[plebhash]

I'm continuing the agentic backporting but it's taking a lot of time (as expected) and it's getting late

I'll continue tomorrow and report back here