📅 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>;
Tier Nolan [ARCHIVE] /
npub1g6…sl5wd
2023-06-07 15:33:42
in reply to nevent1q…aym4
Author Public Key
npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdPublished at
2023-06-07 15:33:42Event JSON
{
"id": "4755db99840fd23ffcd6333304ce53075a685217837576e7f655badebb9db104",
"pubkey": "46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e",
"created_at": 1686152022,
"kind": 1,
"tags": [
[
"e",
"f8b5d67799444b0b408a010416662bfec521761783201657452331c18514fd28",
"",
"root"
],
[
"e",
"f0c0ada1d60a7c48848688643a845721ac8e07baa387e47f026e250e717c2262",
"",
"reply"
],
[
"p",
"10238a6d0c6848c1acb963573a9db5f379583e293364361bd86476b496370490"
]
],
"content": "📅 Original date posted:2015-05-16\n📝 Original message:On Sat, May 16, 2015 at 5:39 AM, Stephen \u003cstephencalebmorse at gmail.com\u003e\nwrote:\n\n\u003e I think this could be mitigated by counting confirmations differently. We\n\u003e should think of confirmations as only coming from blocks following the\n\u003e miners' more strict rule set. So if a merchant were to see payment for the\n\u003e first time in a block that met their own size restrictions but not the\n\u003e miners', then they would simply count it as unconfirmed.\n\u003e\n\nIn effect, there is a confirm penalty for less strict blocks. Confirms =\nmax(miner_confirms, merchant_confirms - 3, 0)\n\nMerchants who don't upgrade end up having to wait longer to hit\nconfirmations.\n\nIf they get deep enough in the chain, though, the client should probably\n\u003e count them as being confirmed anyway, even if they don't meet the client\n\u003e nodes' expectation of the miners' block size limit. This happening probably\n\u003e just means that the client has not updated their software (or\n\u003e -minermaxblocksize configuration, depending on how it is implemented) in a\n\u003e long time.\n\u003e\n\nThat is a good idea. Any parameters that have miner/merchant differences\nshould be modifiable (but only upwards) in the command line.\n\n\"Why are my transactions taking longer to confirm?\"\n\n\"There was a soft fork to make the block size larger and your client is\nbeing careful. You need to add \"minermaxblocksize=4MB\" to your\nbitcoin.conf file.\"\n\nHah, it could be called a \"semi-hard fork\"?\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150516/e5dd0406/attachment.html\u003e",
"sig": "189cb549caa4f6c1065a2b4acf4f64cc90509f94b23bf7d711f922bc62beb905e7ebe8583dc4060c8f2a3b4341967218cd05b275e2829ef73897f8b952ee5e3e"
}