{"type":"rich","version":"1.0","author_name":"npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","author_url":"https://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-16\n📝 Original message:On Sat, May 9, 2015 at 4:08 AM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e \u003e I wonder if having a \"miner\" flag would be good for the network.\n\u003e\n\u003e Makes it trivial to find miners and DoS attack them - a huge risk to the\n\u003e network as a whole, as well as the miners.\n\u003e\n\nTo mitigate against this, two chaintips could be tracked.  The miner tip\nand the client tip.\n\nMiners would build on the miner tip.  When performing client services, like\nwallets, they would use the client tip.\n\nThe client would act exactly the same as any node, the only change would be\nthat it gives miner work based on the mining tip.\n\nIf the two tips end up significantly forking, there would be a warning to\nthe miner and perhaps eventually refuse to give out new work.\n\nThat would happen when there was a miner level hard-fork.\n\n\n\u003e That'd be an excellent way to double-spend merchants, significantly\n\u003e increasing the chance that the double-spend would succeed as you only\n\u003e have to get sufficient hashing power to get the lucky blocks; you don't\n\u003e need enough hashing power to *also* ensure those blocks don't become the\n\u003e longest chain, removing the need to sybil attack your target.\n\u003e\n\nTo launch that attack, you need to produce fake blocks.  That is\nexpensive.\n\nStephen Cale's suggestion to wait more than one block before counting a\ntransaction as confirmed would also help mitigate.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150516/ef7854ef/attachment.html\u003e"}
