The traffic between the pool server and individual hashers is far busier
than 50kB/30s. If their bandwidth is so limited, hashers would have
switched to other pools already.
All these data may prove is they have very bad mining codes. For
example, their hashers may not be required to update the transaction
list regularly. I don't think they are struggling. They are just too
lazy or think that's too risky to improve their code. After all, they
are generating half million USD per day and a few seconds of downtime
would hurt.
By the way, vast majority of the full blocks (>0.99MB) on the blockchain
are generated by Chinese pools.
Luv Khemani via bitcoin-dev 於 2015-08-17 04:42 寫到:
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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
