4 ms·

> Also cannot scale this way infinitely (you need to keep all the transactions on a disk forever). The whitepaper itself mentions that the Merkle tree can be p

> Also cannot scale this way infinitely (you need to keep all the transactions on a disk forever). The whitepaper itself mentions that the Merkle tree can be pruned so that doesn't need to be the case. Do you know why there hasn't been more effort towards implementing that yet?

erikpukinskis 9y ago
The leaves still grow with the square root of the tree size, which is certainly better than linear, but doesn't really solve the problem. It buys you one less order of magnitude you have to scale to, but only one. If you're growing by an order of magnitude every few years, it's just buying you an extra few years lead time.
- placeybordeaux 9y ago
  If we only wanted to track the current unspent outputs we're sitting at 54M which interestingly has been holding relatively constant since June. Where as the total number of transactions (size of blockchain in general) is at 240M and is strictly monotonically increasing. See UTXO here: https://blockchain.info/charts/utxo-count https://blockchain.info/charts/utxo-count See total TX here: https://blockchain.info/charts/n-transactions-total https://blockchain.info/charts/n-transactions-total Every block for the near future will include one new UTXO, but it can increase, decrease or keep the total number of UTXO the same.
runeks 9y ago
It would appear the Bitcoin network has a hard time agreeing on breaking changes :)
fpgaminer 9y ago
AFAIK the paper is referring to thin clients, right? You can already run those with the stock Bitcoin Core client. There's a command line argument that tells it to prune any blocks older than X. The disk space required by such clients is X times the maximum size of blocks + the size of the UTXO. But you still need full nodes who maintain all historical data. Because, AFAIK, there's no way other way to trustlessly establish a UTXO without rescanning the whole blockchain. Maybe there are ways; I'm not that deep into Bitcoin's internal at the moment.
- rocqua 9y ago
  I think perhaps a soft-fork is possible where you store a hash of the UTXO pool in e.g. the coinbase transaction. This way you can verify a given UTXO pool by just checking the hash.
monort 9y ago
It is implemented, the command line option is a -prune=<n>

erikpukinskis 9y ago

The leaves still grow with the square root of the tree size, which is certainly better than linear, but doesn't really solve the problem. It buys you one less order of magnitude you have to scale to, but only one. If you're growing by an order of magnitude every few years, it's just buying you an extra few years lead time.

placeybordeaux 9y ago
If we only wanted to track the current unspent outputs we're sitting at 54M which interestingly has been holding relatively constant since June. Where as the total number of transactions (size of blockchain in general) is at 240M and is strictly monotonically increasing. See UTXO here: https://blockchain.info/charts/utxo-count https://blockchain.info/charts/utxo-count See total TX here: https://blockchain.info/charts/n-transactions-total https://blockchain.info/charts/n-transactions-total Every block for the near future will include one new UTXO, but it can increase, decrease or keep the total number of UTXO the same.

runeks 9y ago

It would appear the Bitcoin network has a hard time agreeing on breaking changes :)

fpgaminer 9y ago

AFAIK the paper is referring to thin clients, right? You can already run those with the stock Bitcoin Core client. There's a command line argument that tells it to prune any blocks older than X. The disk space required by such clients is X times the maximum size of blocks + the size of the UTXO. But you still need full nodes who maintain all historical data. Because, AFAIK, there's no way other way to trustlessly establish a UTXO without rescanning the whole blockchain. Maybe there are ways; I'm not that deep into Bitcoin's internal at the moment.

rocqua 9y ago
I think perhaps a soft-fork is possible where you store a hash of the UTXO pool in e.g. the coinbase transaction. This way you can verify a given UTXO pool by just checking the hash.

monort 9y ago

It is implemented, the command line option is a -prune=<n>