From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UO3GW-00031S-4w for bitcoin-development@lists.sourceforge.net; Fri, 05 Apr 2013 09:49:00 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.175 as permitted sender) client-ip=209.85.214.175; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f175.google.com; Received: from mail-ob0-f175.google.com ([209.85.214.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UO3GS-000413-ME for bitcoin-development@lists.sourceforge.net; Fri, 05 Apr 2013 09:49:00 +0000 Received: by mail-ob0-f175.google.com with SMTP id va7so3456567obc.20 for ; Fri, 05 Apr 2013 02:48:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.112.202 with SMTP id is10mr7019788obb.8.1365155331231; Fri, 05 Apr 2013 02:48:51 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.162.198 with HTTP; Fri, 5 Apr 2013 02:48:51 -0700 (PDT) In-Reply-To: References: Date: Fri, 5 Apr 2013 11:48:51 +0200 X-Google-Sender-Auth: mPoyg6MkQSZHanZyFfFxBQNue4g Message-ID: From: Mike Hearn To: Melvin Carvalho Content-Type: multipart/alternative; boundary=089e015369be94d9e504d999fe0b X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UO3GS-000413-ME Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] A mining pool at 46% X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 09:49:00 -0000 --089e015369be94d9e504d999fe0b Content-Type: text/plain; charset=UTF-8 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 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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --089e015369be94d9e504d999fe0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
51% isn't a magic number - it's possible to do dou= ble spends against confirmed transactions before that. If Michael wanted to= do so, with the current setup he could, and that's obviously rather di= fferent to how Satoshi envisioned mining working.

However, you're somewhat right in the sense that i= t'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 man= y of the people mining on his pool would leave. As he doesn't own the a= ctual 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 be= tter if people didn't cluster around big mining pools, but I think p2po= ol still has a lot of problems dealing with FPGA/ASIC hardware and it hasn&= #39;t been growing for a long time.


On Fri,= Apr 5, 2013 at 11:30 AM, Melvin Carvalho <melvincarvalho@gmail.com= > wrote:
Th= ere was some chat on IRC about a mining pool reaching 46%

http://blockchain.info/poo= ls

What's the risk of a 51% attack.

I suggested that the pool itself is decentralized so you could no= t launch one

On IRC people were saying that the pool owner gets to c= hoose 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.=C2=A0 But what about just creating ONE random number and increment= ing 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/ind= ex.html
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--089e015369be94d9e504d999fe0b--