An important thing to consider is that, while there probably is an ideal block size for the current set of conditions (risk of centralization, average Bitcoin network latency, rate of transactions), there's no a priori reason that it should be 1 MB. It may well be less than 1 MB, or it may well be more. 1 MB is arbitrary. My best guess is that the optimal current block size is somewhat larger than 1 MB.
> My best guess is that the optimal current block size is somewhat larger than 1 MB.
I disagree. There's good reason to believe the ideal block size is now smaller than 1 MB because large pools have been caught red-handed not validating blocks. (Which is like their ONE job and the the thing they get paid the big bucks for!)
Presumably, the only reason they're doing this is because orphan rates are too high, which in turn suggests block sizes are too high.
Classic tragedy of the commons: for everyone as a whole, it's better to process transactions as fast as possible. But with the way incentives are currently structured, it's better for any individual miner to produce an empty block that propagates faster. Or in other words, to process transactions as slowly as possible.
There's two ways you can fix the incentives. One would be to kill the block reward. You don't process transactions, you don't get any fees. This would likely cause a massive increase in transaction fees if the network were to retain its current hashrate (and thus level of security).
The other way is to make a law, basically. You'd need a hardfork that refuses to recognize any block that isn't at least 75% full, but you keep the block reward and thus avoid blowing up transaction costs. This has the problem that the network could "stall out" under the right conditions (no incoming transactions, gigabyte blocksize, etc).
Or instead of messing with incentives you can change the protocol itself - if everyone works on the same transaction set then all you really need is a fixed-size structure to propagate the winning hash, and there are no empty blocks unless there's no incoming transactions. Again, you're talking a hardfork and this one would involve core changes to the Bitcoin protocol.
You're absolutely right on that, but you have the issue backwards.
Each individual miner has an incentive to build a block which pays the most in fees.
That means that as long as the transaction rate is less than the absolute limit, fees will tend towards zero. (Any fee is marginally better than nothing).
The size of the block and propagation time are no longer strongly correlated thanks to the hard work of Matt Corallo on the relay network ( http://bitcoinrelaynetwork.org/ ).
Separate of the blocksize issue - fundamentally I don't think the network should run on the back of transaction fees. The benefit of a high hashrate (a secure network) isn't limited only to those actively transferring money. Anyone who holds Bitcoin has a stake in the network.
Everyone also benefits from high scalability of transaction processing, so ideally transaction fees should stay low or zero. I don't accept the idea of meta-currency (alt-currencies and sidechains) to rectify this situation - too much risk when you have a known quantity that works pretty OK. It also decreases security by splitting processing power. If the problem is that it doesn't scale well, fix it, don't replace it. Joel on Programming's #1 Thing You Should Never Do: start over from scratch.
It's impossible to maintain the massive amount of processing power spent on this solely through transaction fees. Block rewards effectively socialize this collective interest in network security though a very low level of inflation, which hits the right population (Bitcoin holders as a whole). To me transaction fees should be nothing more than spam prevention, to prevent a DOS attack from clogging up the transaction blocks.
Really there's no reason you couldn't have an arbitrarily-large transaction block as long as the bandwidth is reasonable. You still have the problem of the chain becoming too great in size, but that's a problem with some pretty obvious answers.
$1.63 per transaction rules out the possibility of microtransactions. I personally don't think that anyone has the moral authority to deem a use-case "wrong" for a currency. You need to support transactions involving pocket change just as well as you support transactions in benjamins to see wide acceptance.
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.
Why does the penny transaction have to confirm in 10 mins? Currently, and for at least a couple of years, you will likely still be able to send 0 fee transactions. The time for them to appear in a block will increase however.
I don't like this 75% full idea because the miners would virtually be REQUIRED to pad out blocks with trivial transactions if they don't have enough on their own. To not do so would leave hashing power idle.
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.
I don't think there would be reason to, except in protest perhaps. 750Kb size block is 750Kb no matter what transactions make up the block; whos transactions go into a block wouldn't change propagation time. Miners would rather take other peoples' transactions if forced to take transactions at all. That way they get the fees.
I suppose that's true. Trying to fix that would basically put you in the third case - you need everyone to be working on the same transactions, which are the most significant (greatest transaction fees).
Do you really think that the number of full nodes has been dropping because of the 1 MB block limit though? Not for other reasons? Is it really so onerous to run a full node now that the average computer cannot handle it?
The optimal block size is obviously 0, as these blocks will propagate through the network the fastest, thus lowering the orphan rate to nearly 0, and will require the least resource usage (bandwidth, hard disk space, CPU cycles) for full node operators.
