Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2013-04-05 📝 Original message:51% isn't a magic number - ...
📅 Original date posted:2013-04-05
📝 Original message: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.
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.
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.
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/2deb655b/attachment.html>
📝 Original message: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.
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.
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.
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/2deb655b/attachment.html>