📅 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>;
Tier Nolan [ARCHIVE] /
npub1g6…sl5wd
2023-06-07 15:33:42
in reply to nevent1q…7ps7
Author Public Key
npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdPublished at
2023-06-07 15:33:42Event JSON
{
"id": "97a59d716eef47921836776ed1b6814b26b06232e3530eea37d44657256b50d2",
"pubkey": "46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e",
"created_at": 1686152022,
"kind": 1,
"tags": [
[
"e",
"f8b5d67799444b0b408a010416662bfec521761783201657452331c18514fd28",
"",
"root"
],
[
"e",
"4755db99840fd23ffcd6333304ce53075a685217837576e7f655badebb9db104",
"",
"reply"
],
[
"p",
"46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e"
]
],
"content": "📅 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",
"sig": "caf6d8844519570f8447e14456e3fa21fcda413d668e7e7889f3c108ddcb456328839f35323e7adbef3d732ab6ad8567720a693550112daf541f1aadb8cc7227"
}