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