An alternative to spamming the Blockchain

[johoe]

If we want to test how Bitcoin behaves if the blocks are nearly full under realistic conditions, there is an alternative to spamming the Blockchain.  We could try to convince the top miners to decrease their soft limit on the block size.  For example if most miners limit themselves to produce only 300 KB blocks we should see what happens if the blocks get full and the memory pools grow in size.

I'm not sure how easy it is to get most miners to participate in this experiment.  They should not have any disadvantages by doing this (following the logic of some people they should even gain something due to fee pressure) Anyways, the fee is about 2-3% of the block reward and the lower orphan rate should easily make up for the missed transaction fees.  If the transaction congestion has negative effects it is easy for them to revert the block size limitation.  And every miner can choose to participate or not immediately without the need for consensus (of course we only see an effect if most do).

The 300 KB limit is just a suggestion, considering that the current average block size is above 300kb; I expect that many miners are not participating.  Of course, every miner can adjust the limit arbitrarily to add or release some pressure.

I fear there is no way to do this experiment on TestNet since what we really want to test are economic choices.  E.g., it should show if users pay more transaction fees, or if they send fewer transactions.  This experiment may actually have bad effects, e.g. making Bitcoin transactions unreliable and leading to increased 0-confirmation double spends, but at least it is easy to revert the soft block limit if there are serious problems.

[unamis76]

Although this a pretty interesting idea, I think it would definitely cause chaos in the production network in just a few blocks after adapting the change...

Is it worth it for merchants and people sending transactions to have this experiment going when we have almost full blocks happening? It would definitely be interesting to hear devs/experts about this.

[johoe]

Although this a pretty interesting idea, I think it would definitely cause chaos in the production network in just a few blocks after adapting the change...

Only if almost all miner implemented this change at the same time.  I expect that initially there are still enough miners that clean up the queued up transactions regularly. So it would have first only minor effect -- maybe some larger delays -- until enough miners adopt this change.

If you are afraid of this, the miners could also set the soft limit to 500 kb and wait until we reach this soft limit.  If something bad happen some miners can easily adapt within a few hours by setting a higher limit.  It is much better than if we wait until we reach the hard limit and then need two months to deploy an emergency hard fork if something bad happens.

[Newar]

[...] and then need two months to deploy an emergency hard fork if something bad happens.

Where do you get two months from? The last time there was an "emergency hard fork" situation the matter was resolved in ~ two days, IIRC.

[johoe]

[...] and then need two months to deploy an emergency hard fork if something bad happens.

Where do you get two months from? The last time there was an "emergency hard fork" situation the matter was resolved in ~ two days, IIRC.

From BIP-50:

Immediately

Release a version 0.8.1, forked directly from 0.8.0, that, for the next two months has the following new rules:

Reject blocks that could cause more than 10,000 locks to be taken.
Limit the maximum block-size created to 500,000 bytes
...
Over the next 2 months, send a series of alerts to users of older versions, pointing to the web page [that urged them to upgrade].

In other words the new version 0.8.1 was as restrictive as pre-0.8 versions for two months (i.e. an emergency soft fork against 0.8 to go back to the old rules) and the hard forking rule (allow larger blocks and more locks to be taken) was automatically deployed two months later (the first block that broke the old rules came five months later).

And in March 2013 when the accidental hard fork happened, 0.8 had already 60 % hash power on its side, so they only had to convince 40 % to upgrade.

A hard fork can only be successful if most miners and almost all merchants update.  There is no chance you can get them to update in two days.