might have to add another RPC hook to call them with blocknotify

signature cache
UTXO cache

19:31 ~/bin/statoshi $ bitcoin-cli gettxoutsetinfo
{
}
19:40 ~/bin/statoshi $ 

Notice how it takes 9 minutes to process that request.
I got to this because the utxoset gauges were missing in my Grafana installation. Running the latest Statoshi version.

Add more psutil stats https://github.com/giampaolo/psutil

Don't know where in the source this lies, but figured you'd know...

Via next release:

$ bitcoin-cli -addrinfo
{
"addresses_known": {
"ipv4": 14406,
"ipv6": 2511,
"torv2": 5563,
"torv3": 2842,
"i2p": 8,
"total": 25330
}
}

In order to offer charts with dollars and cents: https://twitter.com/badslinky/status/694289285277622273

bitcoin#10757

Call it after each block?

Looks like the C++ statsd client supports batching for improved performance: https://github.com/talebook/statsd-client-cpp/blob/master/src/statsd_client.cpp

Requested by @Oriste: Read the IP address of the Statsd server from bitcoin.conf instead of hard-coded in the source. I would make it a whole lot more flexible.

here: https://github.com/jlopp/statoshi/blob/master/src/main.cpp#L2587

BOUNTY: Anyone who submits a working docker build for everything below will be paid $500 worth of BTC.

I want a docker container that installs:

1. Statoshi fork of Bitcoin Core
2. node.js
3. forever
4. statsd
5. graphite
6. carbon
7. whisper
8. apache / nginx
9. memcached
10. grafana 2.0
11. The system metrics daemon

Installation & config instructions are at https://jlopp.github.io/statoshi/

Additionally, it would be preferable to compile, install, and run the Statoshi fork of Bitcoin Core before anything else, wait ~24 hours so that the blockchain finishes syncing, and then install and configure the rest of the software. Otherwise the initial syncing will be much slower and will store a bunch of useless metrics. As part of this, there is no need to configure the bitcoin.conf "blocknotify" hook until after the blockchain has finished syncing.

Basically, a docker image that creates a fully functional web site backed by a statoshi instance like you see on statoshi.info with just a click of a button to deploy it will satisfy the requirements for the posted bounty.

Need to add documentation for:

Node pool connection management daemon
DisconnectPeer RPC function
System metrics daemon
Grafana installation + elasticsearch support

Add sample bitcoin.conf to note disablewallet and blocknotify=bitcoin-cli gettxoutsetinfo to populate UTXO set metrics

@reboot /usr/bin/python /opt/graphite/bin/carbon-cache.py start
@reboot /usr/local/bin/forever start /home//statsd/stats.js /home//statsd/config.js
@reboot /usr/bin/python /home//logSystemMetrics.py &
@reboot /usr/bin/bitcoind -daemon

Add documentation with upstart jobs for bitcoind and for carbon-cache.py

Message:
Cannot read property 'length' of undefined

Stack trace:
TypeError: Cannot read property 'length' of undefined
at h.convertDataPointsToMs (http://statoshi.info/app/app.a7d02220.js:36:22995)
at i (http://statoshi.info/app/app.a7d02220.js:12:3146)
at http://statoshi.info/app/app.a7d02220.js:12:3318
at n.$eval (http://statoshi.info/app/app.a7d02220.js:12:10922)
at n.$digest (http://statoshi.info/app/app.a7d02220.js:12:9353)
at n.$apply (http://statoshi.info/app/app.a7d02220.js:12:11189)
at f (http://statoshi.info/app/app.a7d02220.js:11:17908)
at r (http://statoshi.info/app/app.a7d02220.js:11:19705)
at XMLHttpRequest.v.onload (http://statoshi.info/app/app.a7d02220.js:11:20245)

Support partitioning each metric by the name of the host running the Statoshi instance.

Why isn't the fee recommended for next block confirmation increase when, for example, there is no block for 1.3 hours and the following happen ?

https://i.imgur.com/NhwoNJq.png

Merge upstream

See https://en.bitcoin.it/wiki/OP_CHECKSIG

on ubuntu 16.04 64-Bit

I did:

./autogen.sh && ./configure && make

But I gor error:

  CXX      wallet/libbitcoin_wallet_a-walletdb.o
  CXX      wallet/libbitcoin_wallet_a-walletutil.o
wallet/walletutil.cpp: In function ‘std::vector<boost::filesystem::path> ListWalletDir()’:
wallet/walletutil.cpp:60:32: error: ‘relative’ is not a member of ‘fs’
             paths.emplace_back(fs::relative(it->path(), wallet_dir));
                                ^
wallet/walletutil.cpp:71:36: error: ‘relative’ is not a member of ‘fs’
                 paths.emplace_back(fs::relative(it->path(), wallet_dir));
                                    ^
Makefile:6912: recipe for target 'wallet/libbitcoin_wallet_a-walletutil.o' failed
make[2]: *** [wallet/libbitcoin_wallet_a-walletutil.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/home/ak/git/SUGAR/TOOLS/statoshi/src'
Makefile:10250: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/ak/git/SUGAR/TOOLS/statoshi/src'
Makefile:774: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

Any idea?

After 0.21 release, pass the "none" flag to speed up RPC return by skipping utxo set hashing

There are benchmarking log print statements throughout the codebase; it would be great to add statsd timers that mirror all of the log statements.

I love statoshi.info.

I'm viewing the mining page a lot to track the hashrate after the halving.

I'm wondering if it's possible to add more panels with estimations of the hashrate using more blocks in the calculation. Currently we can only see an estimation based on 120 blocks (20 hours). It would be nice to also be able to see for example 50 and 100 hours.

I would create a pull request for this myself but I'm too bad at cpp to be able to figure out how. I see that we need to change request in this line to not use the default 120 in getnetworkhashps but instead 300 and 600.

statsClient.gauge("network.exahashesPerSecond", getnetworkhashps(request).get_real() / 1e18);

BR,
Fridokus

this could make adding future metrics far less painful

Would be really useful. Not sure how to do it, though.

Jonas Schnelli asked to add requested block heights distribution to statoshi (similar to http://bitcoin.sipa.be/depths.png ).

Is your feature request related to a problem? Please describe.

Missing lightning network (layer 2) insides.

Describe the solution you'd like

Gathering lightning network stats and also leverage StatsD daemon to aggregate them towards a database/dashboard.

Describe alternatives you've considered

https://1ml.com/statistics (but meh, Grafana would be much cooler)

Investigate feasibility of realtime stats similar to http://opreturn.org/

This stat is displaying as negative now, likely due to overflow. Should switch to exahashesPerSecond and divide the output by 10^18

smart fee & smart priority estimates

Like nVersion, here: https://github.com/jlopp/statoshi/blob/master/src/net.cpp#L1105

ActivateBestChain (ms)
ConnectTip

Add orphan block gauge in processblock function
track tx fees & tx size - check
gauge # inputs & outputs per tx - check

track tx types / OP_
track timestamp metrics for blocks
gauge block size in KB, # of tx in block

from peer version msg:
gauge block heights of peers
gauge version of peers
gauge nTimeOffset

From the new RPC endpoint https://github.com/bitcoin/bitcoin/pull/9733/files

There are currently several separate instances of the client to prevent compiler linking errors; figure out how to reduce this to preferably a single instance.

Current install guide only goes as far as Graphite installation. Need to add the rest of the instructions for adding Grafana on top.

Also: instructions for running "forever" scripts to auto-restart crashed daemons.
Also: templates for default Grafana charts.

RPC getnetworkhashps

Here: https://github.com/jlopp/statoshi/blob/master/src/main.cpp#L573