Because there's no consensus on the contents of the mempool, this approach is unsafe and will lead to forks. It also opens a new attack vector where people can time the flood of new transactions with the discovery of a block by a competitor, to orphan the block and to fork the chain.
The technical defense against an attacking majority of miners is to change the PoW, effectively moving the community off into a new altcoin where the attackers, hopefully, don't have majority hash power. - egs Sent from my phone, please compensate for autocorrect errors. On Mar 24, 2017 9:06 AM, "CANNON via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > When the original white paper was written the idea was that nodes > would be miners at same time. That the distribution of mining power > being mostly on par with the distribution of nodes if I understand > correctly. The problem we face now I fear, is the mining power > becoming centralized. Even if every bitcoin node invested a $1000 > into mining power and mined at a loss, it still would not even > make a dent in hash distribution. Currently there are around 6000 > known nodes. If each node invested $1000 for say 10 ths of hashing > power. At current hashrate of around 3,674,473,142 GH/s this would > only make up %16 of hash power. This is out of balance as while > nodes are distributed mining power is becoming very centralized > due to the creation of monopolization of ASICs. The problem we > are facing is a small group of a couple people whom control a > large amount and growing of hash power. At time of this writing > it has quickly risen to 39% and at current rate will soon become > 50% of hashing power that is controlled by a small group of a few > people. Their intentions are too hijack the bitcoin network to a > cryptocurrency that suits their dangerous agenda. Dangerous because > their plan would centralize power of consensus as I understand it, > to themselves the miners. Dangerous also because the code base of > the attempting subverters is buggy, insecure, and reckless from a > technological standpoint. Even though they only have very minute > amount of nodes compared to legitimate bitcion nodes, the danger > is that they are very quickly taking over in mining power. While > it is true that nodes will not accept invalid blocks that would be > attempted to be pushed by the conspirators, they are threatening to > attack the valid (or in their words, "minority chain") by dedicating > some mining power soley to attacking the valid chain by mining empty > blocks and orphaning the valid chain. So even though the majority > of nodes would be enforcing what blocks are valid and as a result > block the non-compliant longer chain, the conspiring miner can simply > (as they are currently threatening to) make the valid chain unuseable > by mining empty blocks. > > If a malicious miner with half or majority control passes invalid > blocks, the worst case scenario is a hardfork coin split in which > the non-compliant chain becomes an alt. However the problem is that > this malicious miner is very recently threatening to not just simply > fork, but to kill the valid chain to force economic activity to the > adversary controlled chain. If we can simply defend against attacks > to the valid chain, we can prevent the valid chain from dying. > > While empty or near empty blocks would generally be protected by > the incentive of miners to make money. The threat is there if the > malicious miner with majority control is willing to lose out on > these transaction fees and block reward if their intention is to > suppress it to force the majority onto their chain. > > Proposal for potential solution Update nodes to ignore empty blocks, > so this way mined empty blocks cannot be used to DOS attack the > blockchain. But what about defense from say, blocks that are > not empty but intentionally only have a couple transactions > in it? Possible to have nodes not only ignore empty blocks, > but also blocks that are abnormally small compared to number of > valid transactions in mempool? > > For example would be something like this: > If block = (empty OR <%75 of mempool) THEN discard > This threshold just an example. > > What would be any potentials risks > and attacks resulting from both having such new rulesets and not > doing anything? > > Lets assume that the first problem of blocking empty or near empty > blocks has been mitigated with the above proposed solution. How > likely and possible would it be for a malicious miner with lots of > mining power to orphan the chain after so many blocks even with > non empty blocks? Is there a need to mitigate this? > If so is it possible? > > Time is running short I fear. There needs to be discussion on various > attacks and how they can be guarded against along with various > other contingency plans. > > - -- > Cannon > PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832 > Email: can...@cannon-ciota.info > > NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD > BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE. > If this matters to you, use PGP. > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCgAGBQJY1UH/AAoJEAYDai9lH2mw2QYQALDLBxjdO5WTG7VXfuAE476p > D3o1MMGw23tb+DFUO5WV6aFqfy3VSxbVXz6UuWbj6kHgp3ys6qxg5TX0Dy8tKSZM > V28kovuS/pfen4gTxw1FCNff7YVW1R8QX+cSYxSD5EoEaTbpIPgi8zMusDxUVZk2 > WG3ItoyvkLvoNIYGDcU3gR3UkjDS5lOPiHu5BKSj1dEiibOXhr8JEBCznfUSyxCG > TjVRJaUPlwCU06nad8jAZiDrsW3l866iNkBKaMzMavYuMLvCGIdRkbf54B2ZlIT/ > S/owusxqeIdQpydi/3ydnrqyeWo3znMnn+oOvdvfYEHKLts6gar3Zv8cZ40yYSIE > z7C7GQFIo5TYDUNOk+2VE7NNtdX39Wj3gJql/305miaIt0qMsf1D30ODjePwyxUQ > LQ96ZeF1K/0RSTN5TFvLjV9ZmaaN/tFm3kx0PunptJaZT8d9EgMeHREjCF4di04A > 6Dp3Qeug41X/zdIc2AM387QnPwmGB1TpfrY9qgvcrIe26T6An2V5LHwVmslCX3ui > DYAl0o5ODQqnnakF1FIrr1blMVqm7FqDPQc1I5TfzQuxX2+x+5zdrciPC2HUMCMQ > jMujge5IdGL3kjEwjt+M6kqLu0/T0fhdUetb2DWrRJUcEVoIaiUL7qLJC+4KMR3d > Gu3oWoE1ld+BC6At28AD > =SSuj > -----END PGP SIGNATURE----- > _______________________________________________ > 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
