Read on Twitter
another auditability thread yes, you have to add up all the outputs of every block. it's not enough to take block count * coins issued per block. also: you have to do this for every transaction type. more tx types means much more challenging auditability.
in bitcoin, the software automates this checking and we merely have to trust that those validity rules capture all the edge cases and that miners are restricted in what they can do.
this is pretty easy overall because
- running a 'full archival' node for Bitcoin is cheap and doable on commodity hardware
- Bitcoin is fairly simple and there's not that much to check
- Bitcoin only has one transactional type
- Bitcoin has no obfuscation at the protocol layer
- running a 'full archival' node for Bitcoin is cheap and doable on commodity hardware
- Bitcoin is fairly simple and there's not that much to check
- Bitcoin only has one transactional type
- Bitcoin has no obfuscation at the protocol layer
I was kind of surprised when I first learned that Bitcoin Core doesn't 'check global supply constantly' but instead makes sure that each block and transaction follows protocol rules. "what's the difference" you might say. well... here's an example:
In Bitcoin Private, the transaction validity rules, inherited from bitcoin, weren't the issue – those rules were followed. the issue was the one-time UTXO import process which was not cross-checked. more transaction types – more attack vectors. https://coinmetrics.io/bitcoin-private/
so does gettxoutsetinfo matter? hell yes it does! that's how @khannib caught the BTCP inflation! gettxoutsetinfo casts a wider dragnet than the protocol's regular validity rules do. note: no BTCP block explorer was actually performing this verification.
so more transaction types = more scope for inflation = more complex auditing. Bitcoin has the nice property whereby you can sum the entire supply on your laptop and double-check what your node is doing.
ethereum isn't as straightforward, because merely summing balances gets you in trouble when you run into the DAO state changes (many people are learning this now). these are written in node software, not in the protocol rules. they have to be manually accounted for.
Tezos actually had a similar issue, which @coinmetrics detailed on their great post on auditability of blockchains. If you look deeply enough into any blockchain with many txn types, you will often find issues like these which trip up auditors. https://coinmetrics.io/coin-metrics-state-of-the-network-issue-30/
Even the blockchain itself can be unreliable. In Stellar, there is a field in every transaction that attests to the supply. Following an inflation bug in 2017 that created 2.2b XLM, this field was wrong! If you added up all the XLM, you ended up with more.
So there are a couple factors that made auditability _very_ complex for blockchains
- Multiple transaction types, especially implicit ones
- Costly node operation (everything is slower, less accessible to regular folks, and there are fewer people checking)
- Multiple transaction types, especially implicit ones
- Costly node operation (everything is slower, less accessible to regular folks, and there are fewer people checking)
I find this supremely ironic, because blockchains are meant to be auditable. But some chains traded off auditability against complex txn types, or a high TPS, or base-layer privacy. The sad truth is that verifying supply for most blockchains is outside the reach of most people
The designers of these next gen blockchains very rarely optimize for auditability. Indeed, it doesn't seem to be a priority at all. But these are internet money systems, and they are very fragile to inflation bugs. So it really matters.
Even though @coinmetrics has made a name for itself taking an extremely rigorous approach to supply and verifying it when no one else will, I would prefer that the end users of these chains could perform the supply verification. otherwise users are totally disempowered.
In the Stellar example, the devs burned 2.2b XLM from the dev fund to "true up" the supply after the inflation bug. Only problem – they later burned 50b more from that fund (47% of total supply), and the price only increased 20%. the market didn't believe those coins were active.
so the 2.2b burned wasn't equivalent to the coins created in the inflation bug, because it came from a pool of coins the market didn't consider liquid. so there really was permanent inflation stemming from that bug.
at the time though, virtually no one knew about it. the disclosure was hidden away in a technical post to devs. but this was highly material info! any XLM holder surely would have wanted to know about it. so double checking supply really, really matters.
the big ugly secret is that for the less auditable chains, virtually no one does that work. this is one place where @coinmetrics is stepping in, but again, I would much prefer that regular individuals could hold protocol devs accountable rather than a handful of data providers.
Because there’s some questions on the steps to audit ETH supply, and I haven’t personally done it, I recommend this thread which is the best I’ve seen so far in the topic https://twitter.com/j6sp5r/status/1292574364848750592?s=21
