-
Notifications
You must be signed in to change notification settings - Fork 29
feat(mergedmining): support dummy mining on coordinator #966
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #966 +/- ##
==========================================
- Coverage 85.08% 84.99% -0.10%
==========================================
Files 314 314
Lines 23919 23939 +20
Branches 3614 3621 +7
==========================================
- Hits 20351 20346 -5
- Misses 2863 2880 +17
- Partials 705 713 +8 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm just wondering if this couldn't be simpler, for example, couldn't we just have a way to create a merge mined block and resolve it with the CPU miner? I mean, instead of having to start the coordinator, create a job, etc
9a3a1e4
to
e48581d
Compare
e48581d
to
07d2a63
Compare
It definitely can be made simpler mining on CPU, however it's hard to make it in real-time to mine an actual block what will be accepted and used by the rest of the network. Which there wouldn't be anything wrong with a block that is voided for being old, but it'd be better if we have a more realistic test where blocks are accepted. Also doing it in the coordinator makes stratum clients mine blocks with the extended merkle path, which is good to confirm it works with no special changes. |
07d2a63
to
1a0c9db
Compare
1a0c9db
to
1f7facd
Compare
1f7facd
to
f1b24cd
Compare
f1b24cd
to
47473dd
Compare
|
Report | Wed, August 14, 2024 at 15:47:04 UTC |
Project | hathor-core |
Branch | feat/mm-coordinator-dummy |
Testbed | ubuntu-22.04 |
Click to view all benchmark results
Benchmark | Latency | Latency Results nanoseconds (ns) | (Δ%) | Latency Lower Boundary nanoseconds (ns) | (%) | Latency Upper Boundary nanoseconds (ns) | (%) |
---|---|---|---|---|
sync-v2 (up to 20000 blocks) | ✅ (view plot) | 104,176,275,883.32 (-12.98%) | 95,769,881,797.87 (91.93%) | 143,654,822,696.81 (72.52%) |
Bencher - Continuous Benchmarking
View Public Perf Page
Docs | Repo | Chat | Help
Motivation
On the mainnet miners mostly use pools with custom integrations, but on the testnet the whole stack is in our control. For testing the newly activated (on the testnet) extended merkle_path len, we benefit from having the merged mining coordinator be able to do it seamlessly with some injected dummy merkle path.
Acceptance Criteria
--x-dummy-merged-mining
and--x-dummy-merkle-len
torun_merged_mining
subcommand, for running a coordinator with a dummy chain (instead of BTC), and with a dummy merkle path with the specified length;Checklist
master
, confirm this code is production-ready and can be included in future releases as soon as it gets merged