> For example would be something like this: > If block = (empty OR <%75 of mempool) THEN discard > This threshold just an example I don't think this is a good idea, mempool is different from node to node and is not a part of the consensus. Hampus 2017-03-24 18:29 GMT+01:00 Nick ODell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org>: > Two concerns: > > 1) This makes block validity depend on things that aren't in the > blockchain. If you and I have different minrelaytxfee's, we will have > different mempool sizes. Your node will discard a block, but my node will > think it is valid, and our nodes will not come to consensus. > > 2) This is trivially bypassed. A miner can take some coins they own > already, and create a zero-value transaction that has a scriptPubKey of > OP_1. (i.e. anyone-can-spend.) Then, they create another transaction > spending the first transaction, with an empty scriptSig, and the same > scriptPubKey. They do this over and over until they fill up the block. > > The last OP_1 output can be left for the next miner. Since the above > algorithm is deterministic, a merkle tree containing every transaction > except the coinbase can be precomputed. The 'malicious' miners do not need > to store this fake block. > > On Fri, Mar 24, 2017 at 10:03 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: cannon@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 > >