rich1.0npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdhttps://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdnjumphttps://nostr.ae📅 Original date posted:2015-05-16 📝 Original message:On Sat, May 16, 2015 at 5:39 AM, Stephen <stephencalebmorse at 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"? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150516/e5dd0406/attachment.html>