📅 Original date posted:2015-08-20
📝 Original message:That's not a valid conclusion. Just because you observe a miner producing
empty blocks doesn't mean he is SPV mining.
There can be many reasons for mining on an empty block even after having
fully verified the previous block. And therefore these reasons would be
completely independent of block size. You cannot conclude that miners are
struggling with a certain block size.
For example, there are reasons rooted in the mining hardware and mining
software itself, which have nothing to do with the node software, in
particular not with block propagation, verification or transaction
selection. See also https://github.com/BlockheaderNonce2/bitcoin/wiki where
this was warned about. The effect can be expected to become more pronounced
in the future.
Timo
On Mon, Aug 17, 2015 at 10:42 AM, Luv Khemani via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> I previously mentioned in a post that i believe that technically nodes
> are capable of handling blocks an order of magnitude larger than the
> current blocksize limit, the only missing thing was an incentive to run
> them. I have been monitoring the blockchain for the past couple of weeks
> and am seeing that even miners who have all the incentives are for whatever
> reason struggling to download and validate much smaller blocks.
>
> The data actually paints a very grim picture of the current
> bandwidth/validating capacity of the global mining network.
>
> See the following empty blocks mined despite a non-trivial elapsed time
> from the previous block just from the past couple of days alone (Data from
> insight.bitpay.com):
>
> EmptyBlock /Time since previous block/ Size of previous block(bytes)/Mined
> by
> ====================================================
> 370165 29s 720784 Antpool
> 370160 31s 50129 BTCChinaPool
> 370076 49s 469988 F2Pool
> 370059 34s 110994 Antpool
> 370057 73s 131603 Antpool
>
> We have preceding blocks as small as 50KB with 30s passing and the miner
> continues to mine empty blocks via SPV mining.
> The most glaring case is Block 370057 where despite 73s elapsing and the
> preceding block being a mere 131KB, the miner is unable to
> download/validate fast enough to include transactions in his block. Unless
> ofcourse the miner is mining empty blocks on purpose, which does not make
> sense as all of these pools do mine blocks with transactions when the
> elapsed time is greater.
>
> This is a cause for great concern, because if miners are SPV mining for a
> whole minute for <750KB blocks, at 8MB blocks, the network will just fall
> apart as a significant portion of the hashing power SPV mines throughout.
> All a single malicious miner has to do is mine an invalid block on purpose,
> let these pools SPV mine on top of them while it mines a valid block free
> of their competition. Yes, these pools deserve to lose money in that event,
> but the impact of reorgs and many block orphans for anyone not running a
> full node could be disastrous, especially more so in the XT world where
> Mike wants everyone to be running SPV nodes. I simply don't see the XT fork
> having any chance of surviving if SPV nodes are unreliable.
>
> And if these pools go out of business, it will lead to even more mining
> centralization which is already too centralized today.
>
> Can anyone representing these pools comment on why this is happening? Are
> these pools on Matt's relay network?
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/530bd96e/attachment.html>;
Timo Hanke [ARCHIVE] /
npub1dd…pgp9a
2023-06-07 17:36:16
in reply to nevent1q…m4ln
Author Public Key
npub1ddqaln8xsfmy6sxqplt9sz5ev99kh052sveqsh02q7hmc3a6n68shpgp9aPublished at
2023-06-07 17:36:16Event JSON
{
"id": "e94e38d33f50443ea5464b84233e54f552ab6ae70d9cef6545845b651144d372",
"pubkey": "6b41dfcce682764d40c00fd6580a99614b6bbe8a8332085dea07afbc47ba9e8f",
"created_at": 1686159376,
"kind": 1,
"tags": [
[
"e",
"93be86f57a7c4e04ac56389b03d609c67c4a2367e4745a95416e81e74ffcd6f5",
"",
"root"
],
[
"e",
"592a0bb79be6abbe1b659dd8bd03831e94a2e45b63b296e205f28f672280b003",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2015-08-20\n📝 Original message:That's not a valid conclusion. Just because you observe a miner producing\nempty blocks doesn't mean he is SPV mining.\n\nThere can be many reasons for mining on an empty block even after having\nfully verified the previous block. And therefore these reasons would be\ncompletely independent of block size. You cannot conclude that miners are\nstruggling with a certain block size.\n\nFor example, there are reasons rooted in the mining hardware and mining\nsoftware itself, which have nothing to do with the node software, in\nparticular not with block propagation, verification or transaction\nselection. See also https://github.com/BlockheaderNonce2/bitcoin/wiki where\nthis was warned about. The effect can be expected to become more pronounced\nin the future.\n\nTimo\n\n\nOn Mon, Aug 17, 2015 at 10:42 AM, Luv Khemani via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hi all,\n\u003e\n\u003e I previously mentioned in a post that i believe that technically nodes\n\u003e are capable of handling blocks an order of magnitude larger than the\n\u003e current blocksize limit, the only missing thing was an incentive to run\n\u003e them. I have been monitoring the blockchain for the past couple of weeks\n\u003e and am seeing that even miners who have all the incentives are for whatever\n\u003e reason struggling to download and validate much smaller blocks.\n\u003e\n\u003e The data actually paints a very grim picture of the current\n\u003e bandwidth/validating capacity of the global mining network.\n\u003e\n\u003e See the following empty blocks mined despite a non-trivial elapsed time\n\u003e from the previous block just from the past couple of days alone (Data from\n\u003e insight.bitpay.com):\n\u003e\n\u003e EmptyBlock /Time since previous block/ Size of previous block(bytes)/Mined\n\u003e by\n\u003e ====================================================\n\u003e 370165 29s 720784 Antpool\n\u003e 370160 31s 50129 BTCChinaPool\n\u003e 370076 49s 469988 F2Pool\n\u003e 370059 34s 110994 Antpool\n\u003e 370057 73s 131603 Antpool\n\u003e\n\u003e We have preceding blocks as small as 50KB with 30s passing and the miner\n\u003e continues to mine empty blocks via SPV mining.\n\u003e The most glaring case is Block 370057 where despite 73s elapsing and the\n\u003e preceding block being a mere 131KB, the miner is unable to\n\u003e download/validate fast enough to include transactions in his block. Unless\n\u003e ofcourse the miner is mining empty blocks on purpose, which does not make\n\u003e sense as all of these pools do mine blocks with transactions when the\n\u003e elapsed time is greater.\n\u003e\n\u003e This is a cause for great concern, because if miners are SPV mining for a\n\u003e whole minute for \u003c750KB blocks, at 8MB blocks, the network will just fall\n\u003e apart as a significant portion of the hashing power SPV mines throughout.\n\u003e All a single malicious miner has to do is mine an invalid block on purpose,\n\u003e let these pools SPV mine on top of them while it mines a valid block free\n\u003e of their competition. Yes, these pools deserve to lose money in that event,\n\u003e but the impact of reorgs and many block orphans for anyone not running a\n\u003e full node could be disastrous, especially more so in the XT world where\n\u003e Mike wants everyone to be running SPV nodes. I simply don't see the XT fork\n\u003e having any chance of surviving if SPV nodes are unreliable.\n\u003e\n\u003e And if these pools go out of business, it will lead to even more mining\n\u003e centralization which is already too centralized today.\n\u003e\n\u003e Can anyone representing these pools comment on why this is happening? Are\n\u003e these pools on Matt's relay network?\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/530bd96e/attachment.html\u003e",
"sig": "3658c493e3d0488440896b7cac2f009314522c0a1f2e2987a2a3fb6c0965fcc31b9feeb545595e2c3ec3473caa2b6fca5422103380d22eddc9a7679b1f4c147c"
}