I'm not afraid of the markets nor do I think it's actually possible to achieve super cheap transactions with Bitcoin regardless of how this is handled. The problem is deeper and has to do with proof of work. The security that is achieved with proof of work does not come without a price. In the very long term proof of work proof of stake hybrids will most likely be able to handle more transactions with less hashing power and less cost, and still be reliable enough.

I have long since accepted that Bitcoin transactions will cost more in the future than they do now. That is basically inevitable. The question is how much should they cost. The block limit is essentially an entirely artificial limit that's quite unintuitive. In my opinion the only truly valid reason to retain scarcity with the block limit is to keep miners incentivized in general. There needs to be scarcity, but not too much scarcity.

The solution in my mind for now would be to only increase the block limit when the current limit has truly reached its limits. We're not there yet so there is no immediate problem. The ideal solution would be to create a not-easily-rigged method of automatically adjusting the block limit. That can be implemented later, though.

Huh? It's the arguments that the pools (note: miners are not even invoked here, the idea that the authority is handed over to a couple pools is already so easily accepted) will reject "too large" blocks that demands a conspiracy.  Peter Todd's point is that a single miner can push off all the smaller ones, all on their own— unless there is a conspiracy to stop them from including these otherwise valid blocks.  As you argue such a conspiracy "will result in abuse of current rules", and I agree.  Worse, if we as a community can't figure out a criteria to conspire on and put it into the system— where there is no risk of defection— how can we expect a pool-conspiracy to do better when they have less powerful tools to enforce conformance?  Also, while the network is choking on blocks which will be rejected users are left around waiting longer times for confirmation because its not obvious when a chain is going to get orphaned because it violated the invisible cartel rules.  Finally, even if the cartel is successful at preventing single miners from breaking the system, its in each member's individual best interest to mine the largest possible blocks, so we should expect a slow evaporation which has the same conclusion: a single primary miner/validator.

Think merged-mining. Don't think of it as alternate currencies, just alternate chains. They are not competing with bitcoin, they are more chains that are all part of the same family, bitcoin providing high value high security international settlements and the basic security shared by all the merged chains, other chains providing space for smaller value transactions, whatever stuff the primary chain becomes too expensive to be economical to do. The same miners mining all the chains or however many of them they choose to.

It is not competition, it is co-operation.

Floating the blocksize would maybe lead to more centralisation in chains too, detracting from miners' motivation to merge more chains, instead leading to them ignoring more of the merged chains than they otherwise would do when the primary chain starts to be full-to-overflowing with high-fee transactions.

-MarkM-

You aren't paying attention to the debate.  This is about miners with slower internet bandwidth.  Try again with a 1200 baud dial-up connection and see how long it takes you to receive the next 1MB block when it is added to the blockchain.

As long as paying a few cents suffices to get you into a block within an hour or so there probably is no big need to increase block size.

Heck right now people are still able to get free transactions into blocks, until that is no longer possible there seems time yet. Should free transactions ever get in, really? Even after many days? Or would a free transaction getting in within a week or so indicate there is still not full paid utilisation of the already available space?

-MarkM-

I'd say that if a free transaction gets stuck for over a day (144 blocks), then it is already time to start planning the change.

How, I'm asking again? The proof of work will naturally favor smaller blocks that can be spread faster to majority of the network (and thus support decentralization). Yes, worst connected nodes will be left behind, but as long as there are plenty of "middle class" nodes that will naturally favor blocks less than certain size and slow propagation of oversized blocks making them into orphans more likely, I don't see a problem.

You seriously insist on making mining or running full node possible through 1200 baud dialup? Please don't be ridiculous. 10mbit-like satellite connection is affordable in most of the world now.

Now the transactions themselves aren't a problem, 1MiB/10minutes is just 1.8KiB/second average. However, what happens when someone finds a block?

So Alice finds one, and with her 1MiB/second connection she simultaneously transfers her new found block to her three peers. She has enough bandwidth that she can do all three at once, so Bob has it in 1 second, Charlie 4 seconds, and finally David in 20 seconds. The thing is, David has effectively spent that 20 seconds doing nothing. Even if he found a new block in that time he wouldn't be able to upload it to his other peers fast enough to beat Alice's block. In addition, there was also a probabilistic time window before Alice found her block, where even if David found a block, he couldn't get it to the majority of hashing power fast enough to matter. Basically we can say David spent about 30 seconds doing nothing, and thus his effective hash power is now down by 5%


However, it gets worse. Lets say a rolling average mechanism to determine maximum block sizes has been implemented, and since demand is high enough that every block is at the maximum, the rolling average lets the blocks get bigger. Lets say we're now at 10MiB blocks. Average transaction volume is now 18KiB/second, so David just has 32KiB/second left, and a 1MiB block takes 5.3 minutes to download. Including the time window when David finds a new block but can't upload it he's down to doing useful mining a bit over 3 minutes/block on average.

Alice on the other hand now has 15% less competition, so she's actually clearly benefited from the fact that her blocks can't propagate quickly to 100% of the installed hashing power.


Now I know you are going to complain that this is BS because obviously we don't need to actually transmit the full block; everyone already has the transactions so you just need to transfer the tx hashes, roughly a 10x  reduction in bandwidth. But it doesn't change the fundamental principle: instead of David being pushed off-line at 10MiB blocks, he'll be pushed off-line at 100MiB blocks. Either way, the incentives are to create blocks so large that they only reliably propagate to a bit over 50% of the hashing power, *not* 100%

This raises the issue of exchange rates between chains.  A user might see their "bitcoin" total vary over time if it has stored some of the coins as bitcoin-chain7 and bitcoin-chain12 coins.