The Bitcoin Blocksize: A Summary

I have not wanted to fork Bitcoin for years. I still don't - I have many better things to do, like working on Lighthouse or oh .... really anything else. Screwing about with gitian and gcc all day is right at the bottom of my list of "fun things to do on a sunny day".

But the fact that Bitcoin Core was heading for disaster was obvious for a long time now. It has been progressively abandoning things that the user community finds important: SPV wallets, unconfirmed transactions, now even the notion of growing the platform at all have all become "controversial" and therefore untouchable. Anyone who suggests that maybe these things are useful is immediately branded an idiot. Combine with a maintainer who hides any time a decision is needed and you have a recipe for deadlock.

You seem to think I hate Tor. I am actually the maintainer of a full blown Tor implementation (Orchid). I've done a lot of work on integrating it into bitcoinj and I'm basically the only guy who can actually move the needle on Tor/Bitcoin usage, by enabling the use of it by default in consumer wallets that have hundreds of thousands of installs. We're not there yet (it's still too slow) but we're a lot closer than before.

This doesn't change the fact that Tor is heavily abused. It can be useful but it's a frequent source of attacks of all kinds. So finding ways to get the good without the bad involves some tricky coding.

Below, you say "anyone can jam the network with just two IP addresses". Yes, that's unfortunate isn't it. I've been sounding the alarm about Bitcoin Core's poor DoS protection for years. Nobody listened, that's why I have now written a new anti-DoS system that can handle this sort of thing. It starts by clustering and deprioritising Tor because we've seen actual jamming attacks that came through Tor, and because using it is a lot safer and more convenient for an attacker than using your own IP addresses or using a botnet. But it absolutely should be extended to have more advanced heuristics. Instead of whinging that (gasp) loading a file from a web server is "insane", maybe you should be writing code instead.

Such high transaction fees effectively make the currency indivisible to a substantial degree. Sure you can send someone a penny, but if it costs $1.63 most people won't. So that sets a very high minimum floor before people will consider using it in a transaction. Note that this is different from transaction service fees - yes, some places have minimums for CCs, but it doesn't cost me anything to hand you a penny, or even to send you a check for a penny.

The answer to blockchain size is - sidechains, actually. What I have a problem with is meta-currency - the idea that you must necessarily transfer to a separate currency or trust a third party to perform day-to-day transactions. That creates independent currencies with their own security risks, and divides the hashrate into individual pools which are more easily attacked.

Instead what I want are sidechains that compress a series of transactions. You never actually trade on a sidechain, but at some trigger event or time interval a series of transactions is brought onto a sidechain and reduced to a net-sum of inputs and outputs, then instantly reattached to the main blockchain as a single net transaction. You can call this checkpointing or whatever you like, but it doesn't need to be (and shouldn't be) all of the transactions on the blockchain, or even the most recent transactions that are sidechained. In fact I think it makes the most sense for it to be the oldest, say the oldest week of transactions (targeted) within a rolling 28 day window. Long enough to make attacks difficult, short enough it's not too large on disk.

You essentially rebase the blockchain onto a new squashed changeset. This transaction also includes the original hash of the transaction that used to be there, so the chain still validates properly, and the hash of the last confirmed regular block, so it can be strictly sequenced. Everyone validates the squashblock to be sure that it tallies properly and hashes correctly, and if it doesn't reach consensus it's not accepted. If accepted, the next regular/squashblock must include the hash of the squashblock to indicate acceptance.

Still doesn't solve the problem of dust taking up space, but it solves most of the problem. Or maybe sweeping dust is part of the reward for the squashblock somehow. I do like the idea that if you don't sweep your ha'pennies they fall into the couch cushion. Maybe you'd implement that like "any dust that hasn't moved in a block before the squashblock is confirmed may be arbitrarily moved", so dust older than a month (average) is swept.

A simpler solution would be to require that blocks are always 1 MB (or whatever) in size, and that they must be padded out with 0xDEADBEEF or whatever if the block can't be filled with transactions. This way all blocks will take the same amount of time to transmit, and there's no incentive not to include a transaction of any fee if what it's replacing would just be bad data.

I'm not saying I'm in favor of this proposal necessarily, but it works better.

Not all his ideas are good, but he's earned the right to be listened to in the bitcoin space.