[Bitcoin-development] Block Size Increase Requirements
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
Hah, it could be called a "semi-hard fork"?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitcoin-dev