rpc: implement getdifficulty by Micah-Shallom · Pull Request #973 · getfloresta/Floresta

Micah-Shallom · 2026-04-21T00:19:26Z

Description and Notes

This PR implements getdifficulty, which returns the proof-of-work difficulty at the chain tip as a multiple of the minimum difficulty.

Uses the underlying implementations of using chain.get_best_block() and chain.get_block_header() to get the difficulty_float() from headers.
It returns an f64 difficulty which matches Bitcoin Core's output shape

Test plan

Functional test getdifficulty.py - spins up florestad + bitcoind on regtest, asserts both report a positive difficulty and match within rel_tol=1e-9 (a small drift between rust-bitcoin and Bitcoin Core's C++ arithmetic)
Manually tested on local regtest node against bitcoin-cli getdifficulty for parity
Clippy clean, fmt clean, build passes

Davidson-Souza

ACK 66c1fb3

jaoleal · 2026-04-22T11:18:07Z

    // getchaintxstats
    // getdeploymentinfo
+
    // getdifficulty


You can remove the comment now

okay though looking at the other rpc methods, there are oneline comments for each methods // <rpcname>

so i followed the same pattern for getdifficulty and shifted the remaining TODO method markers to the TODO block further down

Ok but would be nice if you did this formatting only in a single commit, its easier to review.

done @jaoleal ...moved to its own commit c41cbd7

jaoleal · 2026-04-22T11:19:22Z

+    def run_test(self):
+        # Start florestad and bitcoind; both should start on the regtest
+        # genesis block and report a positive difficulty value.
+        self.run_node(self.florestad)
+        self.run_node(self.bitcoind)
+
+        floresta_difficulty = self.florestad.rpc.get_difficulty()
+        bitcoind_difficulty = self.bitcoind.rpc.get_difficulty()
+        self.log(f"florestad={floresta_difficulty}, bitcoind={bitcoind_difficulty}")
+
+        self.assertIsSome(floresta_difficulty)
+        self.assertTrue(floresta_difficulty > 0)
+        self.assertTrue(
+            math.isclose(
+                floresta_difficulty, bitcoind_difficulty, rel_tol=self.tolerance
+            )
+        )


Extend this with a difficulty increase cenario

Thanks @jaoleal.....i did a little search and saw that regtest sets fPowNoRetargeting = true, so nBits never changes no matter how many blocks we mine ....a true difficulty increase isn't reachable on that network as discussed here

https://bitcointalk.org/index.php?topic=5293244.0

this means REGTEST difficulty remains constant...
to confirm i extended the test to mine past the 2016 boundary and checked the difficulty at each step

and got

is this a necessary assertion to keep though??

note: 2016 was used cus of

Okay, i went to search on how to do this with signet and it would need some more tooling on python side so perhaps it could be in a follow up ? I think its important to have that case being exercised.

sounds good @jaoleal ....i will open a follow-up PR to track the signet network scenerio so it doesn't get lost

ughmm should i strip the regtest mining assertions i added since they dont really excercise a real increase or maybe just keep it as a check to show that RPC always tracks the tip

jaoleal · 2026-04-22T11:19:28Z

+
+### Ok response
+
+- `difficulty` - (numeric) The proof-of-work difficulty as a multiple of the minimum difficulty.


I think its good to add notes for this doc that we have an acceptable difficulty difference compared to core.

Micah-Shallom · 2026-04-24T13:22:36Z

CI build for this got stuck after 6hrs

Micah-Shallom · 2026-04-27T18:03:31Z

friendly ping @jaoleal

jaoleal · 2026-04-27T18:22:47Z

Goddamit

Davidson-Souza · 2026-04-30T17:26:17Z

Needs rebase.

Micah-Shallom · 2026-04-30T23:12:44Z

rebased .... modified the testcase to make use of the new pytest convention @Davidson-Souza

moisesPompilio · 2026-05-01T13:42:08Z

+    baseline = bitcoind_difficulty
+    for target_height in RETARGET_HEIGHTS:
+        current = bitcoind.rpc.get_block_count()
+        to_mine = target_height - current
+        if to_mine > 0:
+            bitcoind.rpc.generate_block(to_mine)
+        difficulty = bitcoind.rpc.get_difficulty()
+        assert math.isclose(difficulty, baseline, rel_tol=TOLERANCE)


This is wrong. You’re not testing anything related to Floresta here. Basically, you’re just calling bitcoind.

yea i was actually going to strip that off as seen here #973 (comment) ...
@jaoleal asked for a difficulty increase..that block of code was to show that even on bitcoind difficulty doesnt not increase......i was just using bitcoind as a reference

will take it out now

Hmm, he mentioned trying to vary the difficulty, and I agree with him; if that’s possible, it would be very welcome.

From what I looked at in the code, you extract the difficulty from the best block header. I think we could do the following: mine a block with a higher difficulty, take that hexadecimal value, hardcode it, and then just submit that block to bitcoind via submitblock.

I think that should work because the regtest genesis is static, so we can probably use a hardcoded block as long as it points to genesis as the previous block.

thanks for ur review @moisesPompilio........ i tried this locally...generated a python script that mined 1 block with generatetoaddress, then fetched the raw block hex...mutated the bits a bit so that nBits differs from the regtest's default so we can see if bitcoind will accept it, remined the new nonce, cleared the chain tip and submitted the modified block but
Bitcoind responded:

Original nBits: 0x207fffff
Modified nBits: 0x207ffffe
submitblock response: {"jsonrpc":"2.0","result":"bad-diffbits","id":1}

the different nBits approach is rejected at the consensus level on regtest...

actual bitcoind regtest logs:

it looks like the only way this will be successful is on a network that retargets its difficulty value just as......signet/testnet

WYT?? ion think we even have that test environment to begin with

ping on this @moisesPompilio thanks

jaoleal

ACK 2c0cc4e

Regarding the tests, i think what we have here is enough for now... We still dont have a doable way to vary difficulty without odds workaround that possibly would loose the point of the test or to be out-of-scope to implement the pumbling for it... Perhaps we write a issue for that ?

Davidson-Souza assigned Micah-Shallom Apr 21, 2026

Davidson-Souza added new rpc This issue/PR implements a new json-rpc endpoint RPC Changes something with our JSON-RPC interface labels Apr 21, 2026

Davidson-Souza added this to Floresta Apr 21, 2026

github-project-automation Bot moved this to Backlog in Floresta Apr 21, 2026

Davidson-Souza moved this from Backlog to Needs review in Floresta Apr 21, 2026

Davidson-Souza approved these changes Apr 21, 2026

View reviewed changes

jaoleal reviewed Apr 22, 2026

View reviewed changes

Micah-Shallom force-pushed the feat/rpc-getdifficulty branch from 66c1fb3 to 4133e75 Compare April 22, 2026 13:35

Micah-Shallom requested a review from jaoleal April 22, 2026 13:37

jaoleal mentioned this pull request Apr 27, 2026

Assume a way to reproduce CI locally. #1005

Open

Micah-Shallom force-pushed the feat/rpc-getdifficulty branch from 4133e75 to cad67da Compare April 28, 2026 01:29

Micah-Shallom added 4 commits April 30, 2026 19:19

chore(rpc): reorganize TODO method markers

ff85b9d

feat(rpc): add getdifficulty to server-side handler

5da8029

feat(rpc): add rpc client command and CLI binding for getdifficulty

d4d34a5

docs(rpc): add getdifficulty RPC documentation

3614de4

Micah-Shallom force-pushed the feat/rpc-getdifficulty branch from cad67da to ce29a41 Compare April 30, 2026 21:30

moisesPompilio reviewed May 1, 2026

View reviewed changes

test(rpc): add getdifficulty integration test and test framework method

2c0cc4e

Micah-Shallom force-pushed the feat/rpc-getdifficulty branch from ce29a41 to 2c0cc4e Compare May 1, 2026 14:34

Davidson-Souza requested a review from moisesPompilio May 4, 2026 18:23

csgui added reliability Related to runtime reliability, stability and production readiness and removed new rpc This issue/PR implements a new json-rpc endpoint labels May 8, 2026

csgui added this to the Q2/2026 milestone May 8, 2026

jaoleal approved these changes May 15, 2026

View reviewed changes


		### Ok response

		- `difficulty` - (numeric) The proof-of-work difficulty as a multiple of the minimum difficulty.

Conversation

Micah-Shallom commented Apr 21, 2026

Description and Notes

Test plan

Uh oh!

Davidson-Souza left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jaoleal Apr 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Micah-Shallom Apr 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jaoleal Apr 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Micah-Shallom commented Apr 24, 2026

Uh oh!

Micah-Shallom commented Apr 27, 2026

Uh oh!

jaoleal commented Apr 27, 2026

Uh oh!

Davidson-Souza commented Apr 30, 2026

Uh oh!

Micah-Shallom commented Apr 30, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Micah-Shallom May 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Micah-Shallom May 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jaoleal left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

jaoleal Apr 22, 2026 •

edited

Loading

Micah-Shallom Apr 22, 2026 •

edited

Loading

jaoleal Apr 22, 2026 •

edited

Loading

Micah-Shallom May 2, 2026 •

edited

Loading

Micah-Shallom May 2, 2026 •

edited

Loading