📅 Original date posted:2013-04-05
📝 Original message:On 5 April 2013 11:48, Mike Hearn <mike at plan99.net> wrote:
> 51% isn't a magic number - it's possible to do double spends against
> confirmed transactions before that. If Michael wanted to do so, with the
> current setup he could, and that's obviously rather different to how
> Satoshi envisioned mining working.
>
Thanks for pointing this out. I guess 51% is mainly of psychological
significance.
>
> However, you're somewhat right in the sense that it's a self-defeating
> attack. If the pool owner went bad, he could pull it off once, but the act
> of doing so would leave a permanent record and many of the people mining on
> his pool would leave. As he doesn't own the actual mining hardware, he then
> wouldn't be able to do it again.
>
Totally see the logic of this, and it makes sense. But I dont think the
only risk is in terms of double spend, but rather
1) vandalize the block chain which may be difficult to unwind?
2) use an attack to manipulate the price downwards, then rebuy lower
As bitcoin's market cap grows, incentives to move the market will grow
>
> There are also other mining protocols that allow people to pool together,
> without p2pool and without the pool operator being able to centrally pick
> which transactions go into the block. However I'm not sure they're widely
> deployed at the moment. It'd be better if people didn't cluster around big
> mining pools, but I think p2pool still has a lot of problems dealing with
> FPGA/ASIC hardware and it hasn't been growing for a long time.
>
I guess the market will decide which algorithm is used, but as a community
we can perhaps review the different mining protocols and order them in
terms of risk ...
>
>
> On Fri, Apr 5, 2013 at 11:30 AM, Melvin Carvalho <melvincarvalho at gmail.com
> > wrote:
>
>> There was some chat on IRC about a mining pool reaching 46%
>>
>> http://blockchain.info/pools
>>
>> What's the risk of a 51% attack.
>>
>> I suggested that the pool itself is decentralized so you could not launch
>> one
>>
>> On IRC people were saying that the pool owner gets to choose what goes in
>> the block
>>
>> Surely with random non colliding nonces, it would be almost impossible to
>> coordinate a 51% even by the owner
>>
>> Someone came back and said that creating random numbers on a GPU is
>> hard. But what about just creating ONE random number and incrementing from
>> there ...
>>
>> It would be great to know if this is a threat or a non issue
>>
>>
>> ------------------------------------------------------------------------------
>> Minimize network downtime and maximize team effectiveness.
>> Reduce network management and security costs.Learn how to hire
>> the most talented Cisco Certified professionals. Visit the
>> Employer Resources Portal
>> http://www.cisco.com/web/learning/employer_resources/index.html
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130405/93891a93/attachment.html>;
Melvin Carvalho [ARCHIVE] /
npub1uv…saxrt
2023-06-07 11:43:32
in reply to nevent1q…8ud5
Author Public Key
npub1uvtfvcegcn9kds68r8he57emc480vqtx8t22kpsctxgjxae44gvsksaxrtPublished at
2023-06-07 11:43:32Event JSON
{
"id": "89f188418819dca93deb1597c9f1c90a2b897a891364b7e53dafd66579dcb486",
"pubkey": "e316966328c4cb66c34719ef9a7b3bc54ef601663ad4ab06185991237735aa19",
"created_at": 1686138212,
"kind": 1,
"tags": [
[
"e",
"6fb578e911dca94b45942e0389b5d912f7dd77b06d2b79ad6f70d972966cf14a",
"",
"root"
],
[
"e",
"b2c2f53955c9fc44d70394a22140a779785612cc0eee4ac791fc62c93626be4a",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2013-04-05\n📝 Original message:On 5 April 2013 11:48, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\n\u003e 51% isn't a magic number - it's possible to do double spends against\n\u003e confirmed transactions before that. If Michael wanted to do so, with the\n\u003e current setup he could, and that's obviously rather different to how\n\u003e Satoshi envisioned mining working.\n\u003e\n\nThanks for pointing this out. I guess 51% is mainly of psychological\nsignificance.\n\n\n\u003e\n\u003e However, you're somewhat right in the sense that it's a self-defeating\n\u003e attack. If the pool owner went bad, he could pull it off once, but the act\n\u003e of doing so would leave a permanent record and many of the people mining on\n\u003e his pool would leave. As he doesn't own the actual mining hardware, he then\n\u003e wouldn't be able to do it again.\n\u003e\n\nTotally see the logic of this, and it makes sense. But I dont think the\nonly risk is in terms of double spend, but rather\n\n1) vandalize the block chain which may be difficult to unwind?\n2) use an attack to manipulate the price downwards, then rebuy lower\n\nAs bitcoin's market cap grows, incentives to move the market will grow\n\n\n\u003e\n\u003e There are also other mining protocols that allow people to pool together,\n\u003e without p2pool and without the pool operator being able to centrally pick\n\u003e which transactions go into the block. However I'm not sure they're widely\n\u003e deployed at the moment. It'd be better if people didn't cluster around big\n\u003e mining pools, but I think p2pool still has a lot of problems dealing with\n\u003e FPGA/ASIC hardware and it hasn't been growing for a long time.\n\u003e\n\nI guess the market will decide which algorithm is used, but as a community\nwe can perhaps review the different mining protocols and order them in\nterms of risk ...\n\n\n\u003e\n\u003e\n\u003e On Fri, Apr 5, 2013 at 11:30 AM, Melvin Carvalho \u003cmelvincarvalho at gmail.com\n\u003e \u003e wrote:\n\u003e\n\u003e\u003e There was some chat on IRC about a mining pool reaching 46%\n\u003e\u003e\n\u003e\u003e http://blockchain.info/pools\n\u003e\u003e\n\u003e\u003e What's the risk of a 51% attack.\n\u003e\u003e\n\u003e\u003e I suggested that the pool itself is decentralized so you could not launch\n\u003e\u003e one\n\u003e\u003e\n\u003e\u003e On IRC people were saying that the pool owner gets to choose what goes in\n\u003e\u003e the block\n\u003e\u003e\n\u003e\u003e Surely with random non colliding nonces, it would be almost impossible to\n\u003e\u003e coordinate a 51% even by the owner\n\u003e\u003e\n\u003e\u003e Someone came back and said that creating random numbers on a GPU is\n\u003e\u003e hard. But what about just creating ONE random number and incrementing from\n\u003e\u003e there ...\n\u003e\u003e\n\u003e\u003e It would be great to know if this is a threat or a non issue\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e Minimize network downtime and maximize team effectiveness.\n\u003e\u003e Reduce network management and security costs.Learn how to hire\n\u003e\u003e the most talented Cisco Certified professionals. Visit the\n\u003e\u003e Employer Resources Portal\n\u003e\u003e http://www.cisco.com/web/learning/employer_resources/index.html\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130405/93891a93/attachment.html\u003e",
"sig": "da7abe0516daae669db7bfd383e14a734158c704d3ab4ff569c46754264d649a3dc41d4ba1a19f8cc7cb15684f31e339572c2d56fd3ab5288a99c5a3e2a7ff6b"
}