WIP: speculative templates #54
Open
Conversation
This file contains 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
Co-Authored-By: Christopher Coverdale <[email protected]>
This commit adds the simplest stratum v2 message. The remaining messages are introduced in later commits. Co-Authored-By: Christopher Coverdale <[email protected]>
This allows us to subclass Transport.
Implemented starting from a copy of V2Transport and the V2TransportTester, modifying it to fit Stratum v2 and Noise Protocol requirements. Co-Authored-By: Christopher Coverdale <[email protected]> Co-Authored-By: Fi3
Co-Authored-By: Christopher Coverdale <[email protected]>
…lass This allows reusing them in other mocked implementations. Also move the implementation (method definitions) to `test/util/net.cpp` to make the header `test/util/net.h` easier to follow.
…o it And also allows gradually providing the data to be returned by `Recv()` and sending and receiving net messages (`CNetMessage`).
Co-authored-by: Vasil Dimov <[email protected]>
Co-authored-by: Christopher Coverdale <[email protected]>
The template provider will listen for a Job Declarator client. It can establish a connection and detect various protocol errors. Co-Authored-By: Christopher Coverdale <[email protected]> Co-Authored-By: Fi3
An external program that uses the Mining interface may need quick access to some information in the block template, while it can wait a bit longer for the full raw transaction data. This would be the case for a Stratum v2 Template Provider which needs to send a NewTemplate message (which doesn't include transactions) as quickly as possible.
Co-authored-by: Vasil Dimov <[email protected]>
Similar to the previous commit, however the behavior isn't opt-in with NO_BRANCH, because Github CI lacks custom variables.
Have the Template Provider create speculative templates for the next block. Either empty or full of transactions (optimistic, if our current template wins)
|
cc @TheBlueMatt & @Fi3 thoughts? |
24 tasks
|
I would add a third template with very low fee txs if another miner/pool found the block while we are building the new template we very fast compare the inputs of all the txs in the new block with the one in the template if no input are the same we send SNPH for that template otherwise we send it for the empty one. Didn't think too much about it but I guess that is enough to have valid templates? More generally I think that if there is a way to avoid empty template that is still several time faster then create a new template we should use it. |
|
Indeed it would be nice to have a non-empty template that we can very quickly verify, and only fall back to the empty template if needed. |
Sjors
force-pushed
the
sv2
branch
2 times, most recently
from
58a98ea to
e250789
Compare
Sjors
force-pushed
the
sv2
branch
2 times, most recently
from
40f2533 to
216354f
Compare
Sjors
force-pushed
the
sv2
branch
3 times, most recently
from
4f58e3f to
9442af5
Compare
Sjors
force-pushed
the
sv2
branch
2 times, most recently
from
9dc6622 to
72b8f59
Compare
Sjors
force-pushed
the
sv2
branch
4 times, most recently
from
8cf7578 to
a1c1bd9
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
After reading @0xB10C's blog post on mining pool behaviour during forks, I felt motivated to implement Stratum v2's future block template functionality.
Well, this is just a very rough sketch which doesn't compile.
There's two relevant protocol messages (for the Template Provider in bitcoin#29432):
Whenever the tip updates, the current working implementation first sends a
NewTemplatemessage withfuture_templateset totrue, immediately followed bySetNewPrevHashfor the new tip.This PR tries to improve upon that for two different scenarios:
So prepare for either out, after we've send out the current work as described above, we send two additional templates. Both have
future_template = trueand both build for the block on top of the last template. The first is empty, the second has all the transactions that didn't fit in the original block.Especially this last bit will require an overhaul of
BlockAssembler::CreateNewBlock, but it would be a nice selling point for stratum v2.So now the following things can happen:
We receive a block via p2p, this means we didn't* win. The Template Provider needs to look though the template cache and send the connected client(s) a
SetNewPrevHashmessage referring to the match.We receive a block via
SubmitSolution. That means we found the block. The message handling code already finds the matching template. All we need to do is reply to the client with aNewPrevHashmessage.For both (1) and (2) we then proceed as normal, creating and sending a template with non-empty block.
* =actually it's possible that the Job Declarator server reconstructed the block and broadcast it for us, so I need to add detection for this case (maybe by comparing the coinbase merkle path).