Hacker News Reader

Comment by eblume | Hacker News Reader

This seems to be further confirmation that the ONLY safe way to use bitcoin is to use a full blockchain wallet such as Bitcoin Core. Any software which attempts to 'fake' it by not keeping the full blockchain has issues, exactly like this one being announced today.

This is a serious problem for Bitcoin, because right now it takes 2-3 days to download and verify the full block chain, and is fast approaching 10^H^H40 gigabytes in size.

There's going to need to be some sort of mitigation for this at some point but I don't see how that's possible.

View on HN

The unpruned blockchain is about 30GB. Of course, the slowest way to download it is through the P2P network using a standard client. There are torrents which let you bootstrap the full blockchain up to some recent date, then let the P2P client continue from that point, so it doesn't have to take "days" to download, you can pull most of that 30GB at full line rate.

But more importantly, even to run as a "full node" all you need is the UTXO (unspent transactions) and you can throw away the rest. Bitcoin Core can be flagged to prune the blockchain as you go. Pruning just discards transactions after they are spent, keeping track of just enough headers to still provide "full node" validation strength. Basically all you need to know is what available "outputs" there are, aka the unspent outputs, because that is the universe of "coins" which can be used as inputs in new transactions.

I think the only thing that may be missing from all this is a way to download a proven pre-pruned blockchain to get started. That is possible, and it would bring startup costs of a full node down to about 1GB.

The trickier challenge is if you have a historical wallet and you want to download the full transaction history of the wallet, without any meta-data you are left to downloading the whole blockchain in order to discover them. But you would still be able to get your current wallet balance even with pruning.

https://www.reddit.com/r/Bitcoin/comments/33qv3a/pruning_sup...

Correct me if I'm wrong, but how would having just access to the UTXO helped here?

This fork could have still been prevented even if only UTXO were stored.

The problem behind the fork here is that 950 out of the last 1000 blocks had the block version set to 3, but didn't follow through with their promise. By setting the block version to 3, they were voting to transition to BIP66, meaning that once 950 of the last 1000 blocks vote for version 3, then no more nonstandard DER signatures will be allowed in blocks.

Even if you prune spent transactions (so only keep UTXO) you still keep the block version, so you can still measure if 950/1000 blocks vote for version 3. And you are still able to verify that new blocks don't have nonstandard DER signatures.

" As of Bitcoin Core version 0.10.0 or later, this torrent is slower than a direct download using the bitcoin P2P protocol & client. This torrent is now only maintained for research and development purposes as a secondary option. Please use Bitcoin Core directly to download the blockchain."

https://bitcointalk.org/index.php?topic=145386.0

Ever since headers-first sync was merged (https://github.com/bitcoin/bitcoin/pull/4468), the entire blockchain download & verification process can take as little as 3-4 hours.

In regards to the size of the blockchain, you might be interested in the recently merged Autoprune functionality (https://github.com/bitcoin/bitcoin/pull/5863), which deletes block and undo files to keep the total space used by those files below a certain threshold.

Last time I looked you could only use autoprune if you completely disabled the wallet functionality, so it was useless to anyone that wanted to use Bitcoin Core as a wallet (and it probably couldn't act as a backend to any of the lightweight wallets either). I think it's basically only of use to miners in its current state.

Wallet functionality has been re-enabled to work with autoprune, but it won't make it into the 0.11 release. https://github.com/bitcoin/bitcoin/pull/6057

If the bug I reported a couple of years ago hadn't been fixed, then even running a full node wouldn't have been safe. Basically, some older versions of Bitcoin Core didn't validate signatures in blocks older than 24 hours in order to speed up the initial blockchain sync, so they could be tricked into accepting an invalid chain where someone spent bitcoins that weren't theirs if it was far enough back. This wasn't considered a major issue at the time because you'd have to do a 51% attack for 24 hours to exploit it. If a large proportion of mining nodes are no longer validating blocks, that assumption is no longer true - you'd just need to mine one block, plus enough to push the non-validating nodes over the 51% line if they weren't already, and wait. (Oh, and I think Bitcoin Core may still skip full validation of older blocks during initial sync even with the fix.)

The idea that all these miners aren't validating blocks before building on top of them now is scary. Everything's designed around the assumption that they will unless they're trying to actively attack Bitcoin.

These are valid blocks under the old consensus rule. AFAIK, there is no mining of fully invalid blocks going on here.

That's probably because no-one's produced a fully invalid block with sufficient proof of work, but supposedly the pools involved would quite happily have built on top of one because they're skipping block validation almost entirely.

BIP 66 changed the definition of validity. These blocks are fully invalid.

No, any block building on a invalid block is automatically invalid.

> This seems to be further confirmation that the ONLY safe way to use bitcoin is to use a full blockchain wallet such as Bitcoin Core

This statement is false. Not all lightweight wallets (wallets that function without needing to download the blockchain) are SPV wallets. Some lightweight wallets use blockchain APIs (and therefore are immune to this problem)

Downloading the full blockhain is not the only way to secure bitcoin.

> blockchain APIs

What doest that even mean?

You mean blockchain.info API? Well Blockchain.info is not immune to this problem, they were running an old bitcoin core version.

There is an interesting graph on how the block chain size has progressed over the years since Jan 2009 [1].

[1] https://blockchain.info/charts/blocks-size?timespan=all&show...

It seems like there should be cheaper ways to detect and mitigate these kind of fork event (than doing full block chain verification). It shouldn't be too hard 'just' to detect that there are multiple chains being actively extended, and mitigate based on this fact (e.g. big warning to user, disallow transactions temporarily, or whatever)..

It's 36GiB

If it was really that unsafe to use a SPV wallet, the announcement would have said so.

It did say that pools need to run a full node to not lose money, but the 36GiB burden should be a lot less of a problem for them.

Reply on news.ycombinator.com