There's no such thing as a trivial change to the bitcoin consensus rules, especially when that change requires everyone to upgrade their software at once on pain of financial loss. We're talking something that's never been done before in the entire history of Bitcoin.
Also, running a full Bitcoin node on a machine with a spinning rust disk and a relatively small amount of RAM is going to be hell - especially if that disk is heavily shared - because it has to do a lot of random reads from the chain state DB in order to retrieve outputs referenced by the transactions, with the number of reads scaling linearly with the block size. I think some of this may be skipped during the initial block download these days, but you can hit 1 minute plus per block easily just with the existing block size limit. It looks like the hosting provider he chose has some kind of SSD cache of unspecified size which might have helped, if everything fitted in it.
> There's no such thing as a trivial change to the bitcoin consensus rules, especially when that change requires everyone to upgrade their software at once on pain of financial loss. We're talking something that's never been done before in the entire history of Bitcoin.
No, not like that. Technically that only required a supermajority of miners to install the fixed version (and everyone to stop trading temporarily, but there wasn't much of that going on back then anyway). This would be harder because it really would require everyone to upgrade. BIP50 is probably closer; that did require everyone to upgrade over a relatively short timespan or work around the issue by changing a setting, ironically enough due to a latent bug triggered by increasing block size closer to the maximum 1MB.
> The bad transaction no longer exists for people using the longest chain. Therefore, the bitcoins created by it do not exist either. While the transaction does not exist anymore, the 0.5 BTC that was consumed by it does. It appears to have come from a faucet and has not been used since.[7]
Wait... so if you wait long enough then old transactions disappear ? I thought the whole blockchain could allow anyone to track every transactions ?
This is not true at all. On the last 10 blocks (495808-495817, ~6000 seconds) there were 22,277 txns and 49,746 txn inputs. That means a full node needs to look up on average only 8.3 inputs per second in the UTXO database. Assuming 1 I/O per lookup, that's 8 IOPS, which is a trivial workload, even on a non-SSD setup.
I am the author of this blog.zorinaq.com post and I can assure you the real-world I/O workload I see on this $5/month node is negligible.
You're assuming that you're content to always be one block behind on average, that the node never goes down and has to catch up, and that the block size never increases. The block size is already increasing, and you're suggesting an even bigger increase. Also, cheap VPSes are often pretty terrible in the IOPS department because storage is shared, worse than a normal non-SSD setup.
The node is never one block behind. Block verification is instantaneous on my VPS. You seem to be under the false impression that when a block is announced, a node has to suddenly verify 2-3k txns in a brief moment. This is not how things work. Txns are verified incrementally as they are added one at a time to the mempool.
> Also, running a full Bitcoin node on a machine with a spinning rust disk and a relatively small amount of RAM is going to be hell
Is anyone even actually doing that? Even several years ago when I last did it, the blockchain was 60+GB (now it's more than twice that) and you were never, ever going to get anything out of it other than heating the room up.
The way I thought most people were going was using something like Electrum, where you still have your own private wallet that nobody else controls, but you're not yourself a full node.
Running a 120GB DB on spinning rust to the level of a dozen tx per minute is a jokingly light load on modern hardware, and dead simple to set up in the cloud.
You don't even do anything with most of the DB once you have it.
> We're talking something that's never been done before in the entire history of Bitcoin.
That is false. There were even rollbacks in the early days. Don’t talk about a subject you haven’t personally experienced or taken the time to research.
Also, running a full Bitcoin node on a machine with a spinning rust disk and a relatively small amount of RAM is going to be hell - especially if that disk is heavily shared - because it has to do a lot of random reads from the chain state DB in order to retrieve outputs referenced by the transactions, with the number of reads scaling linearly with the block size. I think some of this may be skipped during the initial block download these days, but you can hit 1 minute plus per block easily just with the existing block size limit. It looks like the hosting provider he chose has some kind of SSD cache of unspecified size which might have helped, if everything fitted in it.