rich1.0npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdhttps://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdnjumphttps://nostr.ae📅 Original date posted:2015-05-16 📝 Original message:On Sat, May 9, 2015 at 4:08 AM, Peter Todd <pete at petertodd.org> wrote: > > I wonder if having a "miner" flag would be good for the network. > > Makes it trivial to find miners and DoS attack them - a huge risk to the > network as a whole, as well as the miners. > To mitigate against this, two chaintips could be tracked. The miner tip and the client tip. Miners would build on the miner tip. When performing client services, like wallets, they would use the client tip. The client would act exactly the same as any node, the only change would be that it gives miner work based on the mining tip. If the two tips end up significantly forking, there would be a warning to the miner and perhaps eventually refuse to give out new work. That would happen when there was a miner level hard-fork. > That'd be an excellent way to double-spend merchants, significantly > increasing the chance that the double-spend would succeed as you only > have to get sufficient hashing power to get the lucky blocks; you don't > need enough hashing power to *also* ensure those blocks don't become the > longest chain, removing the need to sybil attack your target. > To launch that attack, you need to produce fake blocks. That is expensive. Stephen Cale's suggestion to wait more than one block before counting a transaction as confirmed would also help mitigate. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150516/ef7854ef/attachment.html>