Measuring Shielded Adoption

How many total coinbase outputs were generated in August, to compare to the 24 shielded ones?

1 Like

There were 35,513 transparent coinbase tx in August.

3 Likes

Thanks! Much appreciated.

1 Like

So shielded adoption clearly needs massive improvement. But I donā€™t think it makes sense to focus on shielded coinbase separately.

Shielded coinbase was hyped a bit too much. In and of it self, it has nothing to do with privacy: the source, amount, and recipient of a ā€œshieldedā€ coinbase are, iā€™m told, public. Which is the same level of privacy you get from a transparent coinbase. So why bother? Well, now the money is in the shielded pool and as a mining pool operator you can distribute your payouts privately without extra work.

Mining pools clearly arenā€™t doing this but this shouldnā€™t be surprisingly :

  1. Their pool management software needs to be updated. That takes time and there needs to be demand to do it.
  2. Well, there needs to be demand for shielded.

So, weā€™re back to shielded usage needing to go up. Which it does. But shielded coinbase is a sideshow.

5 Likes

Shielded coinbase is a necessary prerequisite to moving to a fully shielded protocol. Might as well have done that part early.

9 Likes

BTW, I see this currently for the dashboard link:

Whoops, we couldnā€™t load the dashboard

The dashboard does not exist, or you donā€™t have permission to view it

See my earlier message. I removed based on feedback and just publishing monthly reports.

1 Like

Updated for September. 18,716 fully shielded transactions - thatā€™s a new high and 11% of all transactions :smile:

For those measuring shielded coinbase adoption, there were 128 shielded out of 34,399 total coinbase transactions. There were also 7 migration transactions.

17 Likes

this is awesome

1 Like

tested ACK. :nerd_face:

1 Like

Also posted in a separate thread, but I wanted to follow up here as well: Iā€™ve just launched (with Garethā€™s advice and assistance) zdash.info - a metrics dashboard that now offers live feeds for much of the shielded adoption data covered in these reports. Updated hourly, and offers interactive charts by the day, week, month and year:

13 Likes

Oh man, that screenshot looks cool. zdash.info appears to not be up any more?

Whatā€™s the latest on measuring shielded adoption?

1 Like

ECC metrics page is the only thatā€™s up and running I think. Their data is updated monthly. Itā€™s sad for me to look at the graphs though, more and more $ZEC leaves the shielded pool.

Thanks, yeah; Iā€™m familiar with that page. I would really like to be able to drill down to months, weeks, days, hours. Is the code behind these graphs open source in a repo somewhere? Itā€™s early; but, I think of shielded adoption as a sort of KPI for https://free2z.cash which only barely went live in early March.

Donā€™t despair! Transparent liquidity on exchanges and low prices in this phase can still be good in the long run as it gives more people the ability to get in. I think cases like ZDA/UDA, free2z and general increased interest in privacy could easily converge to turn around this dip in the shielded pool.

I havenā€™t read this thread throughly; but, are there any prevailing hypotheses on the two big spikes (and then dips) in 2020 and 2021?

EDIT (Also + ~10,000 ZEC between Feb and March isnā€™t too bad if Iā€™m reading this right zcash-metrics - Google Sheets)

3 Likes

Hello,

For now we have been using blocksci. The initial setup takes quite some time and is not straight forward. Other folks have just used big query depending on their requirements.

Below is a fairly standard approach/configs you will need:

  1. Building Blocksci:
sudo add-apt-repository ppa:ubuntu-toolchain-r/test -y
sudo apt-get update
sudo apt install cmake libtool autoconf libboost-filesystem-dev libboost-iostreams-dev \
libboost-serialization-dev libboost-thread-dev libboost-test-dev  libssl-dev libjsoncpp-dev \
libcurl4-openssl-dev libjsoncpp-dev libjsonrpccpp-dev libsnappy-dev zlib1g-dev libbz2-dev \
liblz4-dev libzstd-dev libjemalloc-dev libsparsehash-dev python3-dev python3-pip
git clone git@github.com:cryptolu/BlockSci.git
cd BlockSci
mkdir release
cd release
CC=gcc-7 CXX=g++-7 cmake -DCMAKE_BUILD_TYPE=Release ..
make
sudo make install
cd ..
CC=gcc-7 CXX=g++-7 sudo -H pip3 install -e blockscipy

This setup will likely vary depending on your system. This was tested on Ubuntu 18.04 and 20.04.

  1. Ensure the given zcash.conf has atleast these two params:
txindex=1
insightexplorer=1

Important note: this will increase the expected chain size on disk compared to a default zcash.conf and this chain needs to be ran with nodes matching the above config only to avoid reindexing.

  1. Start zcashd and ensure the node is on current height of the given chain
  2. While zcashd is still running, issue the following in another terminal to use values in your zcash.conf
blocksci_parser --output-directory zcash-data update --max-block -100 rpc --username your-rpc-username --password your-rpc-password --address 127.0.0.1 --port 8232

This will take a long time (8+hours) to create the folder called zcash-data, but once you have that archive for the chain you can re run blocksci_parser as needed to quickly update zcash-data

  1. Code examples above using blocksci module can query the zcash-data as needed to get metrics
    Outputs aggregated metrics from the Zcash blockchain Ā· GitHub

Depending on your requirements, this tool can be ideal for off-chain metrics rather than on-chain metrics.

6 Likes

Forgot to explain a couple important details in the above blocksci_parser command
update --max-block -100.

This is updating the newly created zcash-data dir containing metrics, not creating a new metrics dir each time the command is issued. It( --output-directory zcash-data) will likely be located from the path you issue the command. It is NOT the standard zcashdatadir used on command line to operate a full node (e.g src/zcash-cli -datadir=~/.zcash/zcash/).

Ive used max-block -100 as a safe window to pull metrics on a running node. This will gather metrics 100 blocks from current height. In my experience this helps not corrupt the --output-directory zcash-data metrics dir and avoids dealing with certain file locks or chains that often reorg like testnet. If you are gathering metrics on a chain that has different confirmation windows or consensus rules, it should be much easier to lower 100 to something closer to current height.

3 Likes