-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
the limitations have been researched extensively outside of the echo chamber of bitcoin development. It is possible to scale a utxo system like bitcoins to hundreds of millions of txs per day. Xthinner[1] can compress blocksizes by 99%, but bitcoin devs have ignored this with handywavy arguments.
[1]https://github.com/jtoomim/xthinner-spec
It really sucks that people are so easily bamboozled by dishonest scammers.
In the original bitcoin software a node would receive every transaction made while it was online twice: once when the transaction was first relayed, once when it was placed into blocks. This was obviously wasteful, so we created and deployed a reconciliation scheme that exploits the fact that normally all, or almost all the included transactions are already known. https://github.com/bitcoin/bips/blob/master/bip-0152.mediawi...
But because Bitcoin developers are not dishonest scammers they didn't run around putting out press releases claiming "98.6% compression"-- though that's what you get if you compare size size of the BIP152 message to the size of the block. In reality, since it depends on the transaction being known in advance the unachievable limit for this class of approaches is a 50% bandwidth reduction for a node. BIP152 achieves 49.3% out of that 50%, as measured on the latest block.
Even before compact blocks was created back in December 2015, we knew even smaller could be achieved. E.g. we published a scheme that requires asymptotically 0 bytes per transaction, only requiring data proportional to size of the difference between the block and the recipients guess at the next block. But what we found is that the simpler scheme actually propagated blocks much faster because once the block is down to just a few thousand bytes other factors (like CPU time) dominate. Expending a lot of additional code and cpu time to take 49.3% closer to 50% isn't a win in actual usage.
It's also the case that some of these dishonestly hyped supposed improvements are actually totally brain damaged and wouldn't work in practice because they're not robust against attack-- but there isn't much reason to dive into technical minutia because what they claim to achieve, once you strip off the dishonest marketing, isn't all that interesting.