[Bitcoin-development] Block Size Increase Requirements

Tier Nolan tier.nolan at gmail.com
Sat May 16 11:29:14 UTC 2015

On Sat, May 16, 2015 at 5:39 AM, Stephen <stephencalebmorse at gmail.com>

> I think this could be mitigated by counting confirmations differently. We
> should think of confirmations as only coming from blocks following the
> miners' more strict rule set. So if a merchant were to see payment for the
> first time in a block that met their own size restrictions but not the
> miners', then they would simply count it as unconfirmed.

In effect, there is a confirm penalty for less strict blocks.  Confirms =
max(miner_confirms, merchant_confirms - 3, 0)

Merchants who don't upgrade end up having to wait longer to hit

If they get deep enough in the chain, though, the client should probably
> count them as being confirmed anyway, even if they don't meet the client
> nodes' expectation of the miners' block size limit. This happening probably
> just means that the client has not updated their software (or
> -minermaxblocksize configuration, depending on how it is implemented) in a
> long time.

That is a good idea.  Any parameters that have miner/merchant differences
should be modifiable (but only upwards) in the command line.

"Why are my transactions taking longer to confirm?"

"There was a soft fork to make the block size larger and your client is
being careful.  You need to add "minermaxblocksize=4MB" to your
bitcoin.conf file."

Hah, it could be called a "semi-hard fork"?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150516/e5dd0406/attachment.html>

More information about the bitcoin-dev mailing list