Merged mining#263
Open
Fi3 wants to merge 3 commits into
Open
Conversation
Queue a zero-value OP_RETURN output from the API and apply it when the next JD template arrives so the modified coinbase is part of the declared custom job flow instead of being mutated after declaration. This keeps the pool-side declaration, token generation, and downstream work on the same coinbase while reusing the existing API server and gating access with a shared secret.
Contributor
Author
|
need #264 |
Contributor
Author
|
need automatic testing on JD part before beeing merged. Test must mesure JDS rejection rate under high latency, and hight troughput. DO NOT MERGE WITHOUT TESTING |
added 2 commits
May 13, 2026 11:23
… submit exact found blocks The proxy reuses the existing API server behind a shared secret to accept the desired RSK OP_RETURN payload and target, and to let the sibling bridge poll complete found-job data without depending on raw block lookups from bitcoind. The desired merge-mining payload stays active across templates, but the source of truth for a found job is the exact payload and target that were actually applied to that template. Found jobs are exported only when the solved coinbase still proves that template-scoped RSK data, and they carry the witness-stripped coinbase, rebuilt Bitcoin header and block hash, block transaction count, and the RSKIP92 sibling-only merkle proof expected for multi-transaction Rootstock submissions. Single-transaction jobs still remain on the coinbase-only path. Job and chain-state tracking are also kept aligned with JD job rotation so delayed or stale shares are matched to the correct template instead of the latest refresh, which prevents duplicate or false found jobs and stops stale custom-job submissions from being turned into invalid Bitcoin block candidates.
… stay bound to the right template Keep the current clean-job family separate from same-tip template refreshes so a new non-future job does not make the previous still-valid job look stale before normal channel validation runs. Capture coinbase prefix and suffix per template instead of reading them from a mutable singleton later, so a newer template cannot overwrite the coinbase parts that belong to an earlier declaration while it is still in flight. Treat the applied RSK payload as valid only when it is the last RSKBLOCK tag in the coinbase path. This keeps template injection, found-job validation, and the bridge contract aligned and avoids exporting proofs built from a payload that is already shadowed by a later tag.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.