On Sat, May 16, 2015 at 5:39 AM, Stephen <stephencalebmo...@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"?
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
