-
Notifications
You must be signed in to change notification settings - Fork 254
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
Add RPC call 'getblockstats' #157
Conversation
It seems that in 0.18 this call needs diff --git a/integration_test/run.sh b/integration_test/run.sh
index b40aa78..97925fd 100755
--- a/integration_test/run.sh
+++ b/integration_test/run.sh
@@ -29,6 +29,7 @@ if bitcoind -version | grep -q "v0\.2"; then
fi
bitcoind -regtest $BLOCKFILTERARG $FALLBACKFEEARG \
+ -txindex=1 \
-datadir=${TESTDIR}/2 \
-connect=127.0.0.1:12348 \
-rpcport=12349 \ |
The rest looks good to me! |
@@ -439,6 +439,10 @@ pub trait RpcApi: Sized { | |||
self.call("getblockhash", &[height.into()]) | |||
} | |||
|
|||
fn get_block_stats(&self, height: u64) -> Result<json::GetBlockStatsResult> { |
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.
This can also accept the block hash instead of the height, maybe worth supporting it?
There's also an option for selecting which fields you want statistics for. Though this would require changing all the GetBlockStatsResult
fields to be an Option<T>
, which isn't great.
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.
All of them?
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.
If we want to support getting a specific list of fields from getblockstats
, then I'm afraid yes...
Perhaps it could be a separate struct? So we have get_block_stats(height) -> GetBlockStatsResult
and get_block_stats_fields(height, fields) -> GetBlockStatsResultPartial
. Maintaining this would be annoying though, but perhaps not so bad with some macros?
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.
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.
Looks good! Commented with two small nits
json/src/lib.rs
Outdated
pub total_size: usize, | ||
pub total_weight: usize, | ||
#[serde(rename = "totalfee")] | ||
pub total_fee: u64, |
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.
This should be a bitcoin::Amount
(will also require with = "bitcoin::util::amount::serde::as_sat"
in the derive).
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.
Oh yeah, true, we're using those in this crate.
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.
As far as I understand, bitcoin::Amount should then also be used for: avg_fee
, fee_rate_percentiles
, max_fee
, median_fee
and min_fee
, right?
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.
When I try too define the fields as Option<Amount>
, the compiler throws the follwoing error at me: the trait SerdeAmount
is not implemented for std::option::Option<Amount>
Any idea how I should deal with this?
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.
Yes, and also avg_fee_rate
, max_fee_rate
, min_fee_rate
, total_fee
, subsidy
and total_out
.
Note that unlike most other RPCs in bitcoind, the feerates here are represented in sat/vB rather than BTC/KB, while amounts are in satoshis rather than BTC.
json/src/lib.rs
Outdated
#[derive(Clone, PartialEq, Debug, Deserialize, Serialize)] | ||
pub struct GetBlockStatsResult { | ||
#[serde(rename = "avgfee")] | ||
pub avg_fee: u32, |
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.
IIUC there's a preference by the folks here to use u64
over u32
/usize
. Maybe @stevenroose can explain more.
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 suppose this can also be an Amount
, right?
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.
Oh right, this could. But I was referring to all the u32
fields, not just that one
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.
Would appreciate some more info about 'using u64
over u32
/usize
for all fields'. @stevenroose ?
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.
Just that we use 64-bit numbers for amounts. But in this crate, we are mostly using the dedicated Amount
type. You can find some other usages of that type and the serde-tag you have to use with it.
client/src/client.rs
Outdated
@@ -443,6 +443,14 @@ pub trait RpcApi: Sized { | |||
self.call("getblockstats", &[height.into()]) | |||
} | |||
|
|||
fn get_block_stats_fields(&self, height: u64, fields: &Vec<bitcoincore_rpc_json::BlockStatsFields>) -> Result<json::GetBlockStatsResultPartial> { |
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.
Can use fields: &[bitcoincore_rpc_json::BlockStatsFields]
so it also accepts slices. And bitcoincore_rpc_json
is also aliased as just json
.
With commit 03b7fa9, I have now a version that works (with Amounts), but it has also added a ton of boilerplate code. Still open is the question, about whether I should use |
I'd say
|
Thanks for your input @0xB10C, I'll wait for more comments from @stevenroose and @shesek about your suggestion. |
I agree with @0xB10C 's suggestions :) |
Could you also rebase to make CI happy? |
Rebased. Travis seems to have a problem still, concerning the I've update the data type for timestamps in commit 890c211. @0xB10C Here's my rationale for why Given a maximum block size of
|
integration_test/run.sh
Outdated
@@ -9,6 +9,7 @@ mkdir -p ${TESTDIR}/1 ${TESTDIR}/2 | |||
killall -9 bitcoind | |||
|
|||
bitcoind -regtest \ | |||
-txindex=1 \ |
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.
The txindex
argument was added to the wrong bitcoind
instance imo. There's another one started a few lines below (line 32, idk why), which is used for testing apparently as the RPC_URL
env var is set to its port. That's probably why the 0.18.*
tests fail, possibly because -blockfilterindex=1
is set for all other versions and works for stats too?
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.
You are right, the one below has the flag -server=1
set, while the one above has it set to 0
.
I moved the flag in commit f7d1f3bce957be592b6f90d1f7667e2a008a1022
.
Just to get a rough idea about the field Lowest increase: Highest increase: |
Is this PR still active? Sorry for the wait. We are not good at keeping track of PRs, so pinging reviewers generally helps. |
@sgeisler Yes it is still active. I just rebased it, so it should be ready to be merged. Okay thank you for the information, will ping you guys every now and then :-) |
All looks good to me, ACK 6af032a. Thanks for the contribution! Edit: actually, one small last nit is that the |
@sgeisler @stevenroose Looks like this PR is ready to be reviewed/merged. |
How is the progress on this guys? Is there something else I could provide you with, to assist you? |
I rebased this again, so it is once again, ready to be merged. |
I rebased this again, so it is once again, ready to be merged. |
ACK d83b8fe I am going to wait some days before merging, it would be great this rebase to master and squash some commits |
a1d803b
to
14a1d36
Compare
@RCasatta thanks for the review, rebased and squashed some commits. |
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.
utACK 60b0dd7
will merge soon if there is no more feedback
Hey @RCasatta Friendly reminder that 3 weeks have passed. Could you specify |
Sorry for the delay and thanks for the contribution |
getblockstats
is available in Bitcoin Core since version0.17.0
.More info (here)[https://bitcoincore.org/en/doc/0.17.0/rpc/blockchain/getblockstats/]
I'm completely new to Rust and this is my first Rust-PR ever, so please have mercy.