On Sat, May 16, 2015 at 5:39 AM, Stephen <stephencalebmorse@gmail.com> wrote:
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 confirmations.

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"?