From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UO2yt-0001r7-35 for bitcoin-development@lists.sourceforge.net; Fri, 05 Apr 2013 09:30:47 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.181 as permitted sender) client-ip=209.85.217.181; envelope-from=melvincarvalho@gmail.com; helo=mail-lb0-f181.google.com; Received: from mail-lb0-f181.google.com ([209.85.217.181]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UO2yr-0001PO-9z for bitcoin-development@lists.sourceforge.net; Fri, 05 Apr 2013 09:30:47 +0000 Received: by mail-lb0-f181.google.com with SMTP id r11so3538931lbv.40 for ; Fri, 05 Apr 2013 02:30:38 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.125.198 with SMTP id ms6mr5598564lbb.48.1365154238526; Fri, 05 Apr 2013 02:30:38 -0700 (PDT) Received: by 10.112.143.38 with HTTP; Fri, 5 Apr 2013 02:30:38 -0700 (PDT) Date: Fri, 5 Apr 2013 11:30:38 +0200 Message-ID: From: Melvin Carvalho To: Bitcoin Dev Content-Type: multipart/alternative; boundary=089e01161a94737c2804d999bdf8 X-Spam-Score: -0.6 (/) 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 (melvincarvalho[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1UO2yr-0001PO-9z Subject: [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:30:47 -0000 --089e01161a94737c2804d999bdf8 Content-Type: text/plain; charset=ISO-8859-1 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 --089e01161a94737c2804d999bdf8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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 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.=A0 But what about just creating ONE random number and incrementing= from there ...

It would be great to know if this is a th= reat or a non issue
--089e01161a94737c2804d999bdf8-- 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-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UO3Jr-00084g-2H for bitcoin-development@lists.sourceforge.net; Fri, 05 Apr 2013 09:52:27 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.172 as permitted sender) client-ip=209.85.217.172; envelope-from=gmaxwell@gmail.com; helo=mail-lb0-f172.google.com; Received: from mail-lb0-f172.google.com ([209.85.217.172]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UO3Jl-0008SZ-5m for bitcoin-development@lists.sourceforge.net; Fri, 05 Apr 2013 09:52:27 +0000 Received: by mail-lb0-f172.google.com with SMTP id u10so3587351lbi.31 for ; Fri, 05 Apr 2013 02:52:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.155.233 with SMTP id vz9mr5430831lbb.63.1365155534209; Fri, 05 Apr 2013 02:52:14 -0700 (PDT) Received: by 10.112.134.164 with HTTP; Fri, 5 Apr 2013 02:52:14 -0700 (PDT) In-Reply-To: References: Date: Fri, 5 Apr 2013 02:52:14 -0700 Message-ID: From: Gregory Maxwell To: Melvin Carvalho Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.6 (-) 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 (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1UO3Jl-0008SZ-5m 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:52:27 -0000 On Fri, Apr 5, 2013 at 2:30 AM, Melvin Carvalho wrote: > There was some chat on IRC about a mining pool reaching 46% > http://blockchain.info/pools The estimates on there may be a bit lossy. > What's the risk of a 51% attack. The whole fixation on "51" as a magic number is a bit confused=E2=80=94 I'l= l say more below. > I suggested that the pool itself is decentralized so you could not launch > one None of the pools listed there are meaningfully decentralized=E2=80=94 bef= ore Luke whines, in theory the ones supporting GBT could be if used in a way that no one actually uses them. P2Pool is decentralized based on the same technology as Bitcoin itself, but it's certainly not as point and click easy as a centralized pool. > On IRC people were saying that the pool owner gets to choose what goes in > the block That is correct. Though I'd point out=E2=80=94 the major pool ops all seem to be great folks who care about the future of Bitcoin=E2=80=94 and the continued success of their very profitable businesses: a 50% mining pool with a 3% fee rakes in 54 BTC per _day_. The more likely threat isn't that pool owners do something bad: It's that their stuff gets hacked (again) or that they're subjected to coercion. ... and the attacker either wants to watch the (Bitcoin) world burn, or after raiding the pool wallet can't exploit it further except via blockchain attacks. > Surely with random non colliding nonces, it would be almost impossible to > coordinate a 51% even by the owner That makes no sense. A centralized pool is the miner, the remote workers are just doing whatever computation it tells them to do. Certainly these remote workers might switch to another pool if they knew something bad was happening... but evidence suggests that this takes days even when the pool is overtly losing money. Miners have freely dumped all their hashpower on questionable parties (like the infamous pirate40) with nary a question as to what it would be used for when they were paid a premium for doing so. It seems even those with large hardware investments are not aware of or thinking carefully about the risks. > It would be great to know if this is a threat or a non issue It's important to know exactly what kind of threat you're talking about=E2=80=94 someone with a large amount of hash-power can replace confirmed blocks with an alternative chain that contains different transactions. This allows them to effectively reverse and respend their own transactions=E2=80=94 clawing back funds that perhaps had already triggered irreversible actions. This doesn't require some magic "51%"=E2=80=94 its just that when a miner h= as >50% the attack would always be successful if they kept it up long enough (long enough might be years if you're talking really close to 50% and he gets unlucky). Likewise, someone with a sustained supermajority could deny all other blocks=E2=80=94 but that attack's damage stops when they lose the supermajority or go away. More interesting is this: An attacker with only 40% of the hashpower can reverse six confirmations with a success rate of ~50%. There is source for computing this at the end of the Bitcoin paper. I did a quick and really lame conversion of his code JS so you can play with it in a browser: https://people.xiph.org/~greg/attack_success.html 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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UO3TP-0000Bk-Jx for bitcoin-development@lists.sourceforge.net; Fri, 05 Apr 2013 10:02:19 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.53 as permitted sender) client-ip=209.85.215.53; envelope-from=gmaxwell@gmail.com; helo=mail-la0-f53.google.com; Received: from mail-la0-f53.google.com ([209.85.215.53]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UO3TO-0004sa-MH for bitcoin-development@lists.sourceforge.net; Fri, 05 Apr 2013 10:02:19 +0000 Received: by mail-la0-f53.google.com with SMTP id fp12so435469lab.40 for ; Fri, 05 Apr 2013 03:02:12 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.161.97 with SMTP id xr1mr2705434lbb.15.1365156131908; Fri, 05 Apr 2013 03:02:11 -0700 (PDT) Received: by 10.112.134.164 with HTTP; Fri, 5 Apr 2013 03:02:11 -0700 (PDT) In-Reply-To: References: Date: Fri, 5 Apr 2013 03:02:11 -0700 Message-ID: From: Gregory Maxwell To: Mike Hearn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.6 (-) 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 (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1UO3TO-0004sa-MH 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 10:02:19 -0000 On Fri, Apr 5, 2013 at 2:48 AM, Mike Hearn wrote: > 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. As an aside and a clarification=E2=80=94 P2pool works great with FPGAs, and one of the largest FPGA farms I've heard of uses it. But it doesn't work well the old BFL FPGA miners=E2=80=94 because they have insane latency= . Likewise it doesn't currently work well with Avalon, again because of insane latency. P2pool uses a 10 second sharechain in order to give miners low variance but that means that if you have a several second miner you'll end up subsidizing all the faster p2pool users somewhat. It was basically stable with the network until ASICminer came online mining on BTCguild mostly and the first avalons started to ship, and then the network went up 10TH in a couple weeks (and now 15TH) while P2Pool stayed mostly constant. ForrestV (the author and maintainer of the P2pool software) would love to work on making Avalon and other higher latency devices first class supported on P2Pool, but he doesn't have one=E2=80=94 and frankly, all the people who have them aren't super eager to fuss around with a 5BTC/day revenue stream, especially since the avalon firmware (and its internal copy of cgminer) itself has a bunch of quirks and bugs that are still getting worked out... and I do believe that p2pool helps reduce concerns around mining pool centralization. ... but I think as a community we don't always do a great job at supporting people who work on infrastructure=E2=80=94 even just making sure to get them what they need= to keep giving us free stuff=E2=80=94, we just assume they're super rich Bitco= in old hands, but that often isn't true. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UO3eF-0005e7-Pc for bitcoin-development@lists.sourceforge.net; Fri, 05 Apr 2013 10:13:31 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.49 as permitted sender) client-ip=209.85.215.49; envelope-from=melvincarvalho@gmail.com; helo=mail-la0-f49.google.com; Received: from mail-la0-f49.google.com ([209.85.215.49]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UO3eE-0001aC-21 for bitcoin-development@lists.sourceforge.net; Fri, 05 Apr 2013 10:13:31 +0000 Received: by mail-la0-f49.google.com with SMTP id fs13so3319690lab.36 for ; Fri, 05 Apr 2013 03:13:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.146.199 with SMTP id te7mr5625799lab.23.1365156803238; Fri, 05 Apr 2013 03:13:23 -0700 (PDT) Received: by 10.112.143.38 with HTTP; Fri, 5 Apr 2013 03:13:23 -0700 (PDT) In-Reply-To: References: Date: Fri, 5 Apr 2013 12:13:23 +0200 Message-ID: From: Melvin Carvalho To: Mike Hearn Content-Type: multipart/alternative; boundary=e89a8f22c55551e2b704d99a569c X-Spam-Score: -0.6 (/) 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 (melvincarvalho[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1UO3eE-0001aC-21 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 10:13:31 -0000 --e89a8f22c55551e2b704d99a569c Content-Type: text/plain; charset=ISO-8859-1 On 5 April 2013 11:48, Mike Hearn 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 > 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 >> >> > --e89a8f22c55551e2b704d99a569c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 5 April 2013 11:48, Mike Hearn <mike@plan99.net> wr= ote:
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.

Thanks for pointing this out.=A0 I guess 5= 1% is mainly of psychological significance.=A0
=A0

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 t= he 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 i= t makes sense.=A0 But I dont think the only risk is in terms of double spen= d, but rather

1) vandalize the block chain which may be d= ifficult to unwind?
2) use an attack to manipulate the price downwards, then rebuy l= ower

As bitcoin's market cap grows, incentives to mov= e the market will grow
=A0

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 peop= le 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 g= rowing 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 ...
=A0


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

http://block= chain.info/pools

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.=A0 But what about just creating ONE random number and incrementing= from there ...

It would be great to know if this is a th= reat 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-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment



--e89a8f22c55551e2b704d99a569c-- 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-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UO4Z1-0000En-Sd for bitcoin-development@lists.sourceforge.net; Fri, 05 Apr 2013 11:12:13 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of mckay.com designates 37.1.88.131 as permitted sender) client-ip=37.1.88.131; envelope-from=robert@mckay.com; helo=mail.mckay.com; Received: from mail.mckay.com ([37.1.88.131]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1UO4Z0-0001LK-6a for bitcoin-development@lists.sourceforge.net; Fri, 05 Apr 2013 11:12:11 +0000 Received: from www-data by mail.mckay.com with local (Exim 4.76) (envelope-from ) id 1UO4De-0003Q7-Vw; Fri, 05 Apr 2013 11:50:07 +0100 To: Mike Hearn X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 05 Apr 2013 11:50:06 +0100 From: Robert McKay In-Reply-To: References: Message-ID: X-Sender: robert@mckay.com User-Agent: Roundcube Webmail/0.5.3 X-Spam-Score: -4.0 (----) 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 SPF_PASS SPF: sender matches SPF record -2.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1UO4Z0-0001LK-6a 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 11:12:13 -0000 On Fri, 5 Apr 2013 11:48:51 +0200, Mike Hearn wrote: > However, youre somewhat right in the sense that its 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 doesnt own the actual mining > hardware, he then wouldnt be able to do it again. Unless all the miners are monitoring the work they do for their pools and the actual miners that found the blocks noticed (unlikely) - the only way anyone knows which pool did anything is the source IP that first disseminates the new block. Also since it's unlikely that both of the doublespend blocks would be found by the same end miner, neither of them would know that the pool operator was responsible even if they were monitoring their work. There's nothing stopping the pool owner from channeling the doublespend blocks through some other previously unknown IP, so I don't think they would suffer any reputational damage from doing this repeatidly. Robert From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UO5Vx-0005PR-89 for bitcoin-development@lists.sourceforge.net; Fri, 05 Apr 2013 12:13:05 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.100 as permitted sender) client-ip=62.13.148.100; envelope-from=pete@petertodd.org; helo=outmail148100.authsmtp.co.uk; Received: from outmail148100.authsmtp.co.uk ([62.13.148.100]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UO5Vv-0002Ok-Eo for bitcoin-development@lists.sourceforge.net; Fri, 05 Apr 2013 12:13:05 +0000 Received: from mail-c233.authsmtp.com (mail-c233.authsmtp.com [62.13.128.233]) by punt5.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r35CCtCM058293; Fri, 5 Apr 2013 13:12:55 +0100 (BST) Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r35CCpe3065538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 5 Apr 2013 13:12:54 +0100 (BST) Date: Fri, 5 Apr 2013 08:12:51 -0400 From: Peter Todd To: Melvin Carvalho Message-ID: <20130405121251.GA18254@savin> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 25447145-9dea-11e2-a49c-0025907707a1 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdgcUGUUGAgsB AmUbWldeUV97XGc7 bAxPbAVDY01GQQRq WVdMSlVNFUsqAhly dV5LURl0cgBFcDB5 ZkdgEHJeWEB9dEJ4 X0cAQDwbZGY1an1O VEkLagNUcgZDfhhC alcuVT1vNG8XDQg5 AwQ0PjZ0MThBJSBS WgQAK04nCW9DGz86 RhYNVS0oGklNTjl7 c0JrQmv9 X-Authentic-SMTP: 61633532353630.1021:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.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 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1UO5Vv-0002Ok-Eo 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 12:13:05 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 05, 2013 at 12:13:23PM +0200, Melvin Carvalho wrote: > 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 >=20 > 1) vandalize the block chain which may be difficult to unwind? Vandalize the chain how? By delibrately triggering bugs? (like the old OP_CHECKSIG abuse problem) Regardless of whether or not the vulnerability requires multiple blocks in a row, the underlying problem should be fixed. By putting illegal data into it? Fundementally we have no way to prevent people from doing that other than by making it expensive. An attacker having a lot of hashing power just means they can do so faster and a bit cheaper. --=20 'peter'[:-1]@petertodd.org --AhhlLboLdkugWU4S Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRXr/CAAoJEH+rEUJn5PoE1MsH/i6wLt5C1OSCWsfDK4ppVk6u M5MIbdbwIgPB5mKrirt36i69isQ/7UlulLffU3mvG/ZoKgHZwFqu5X8Q+dKup0v/ XkoLjAazBulNo9no56KmgR20O9SpnIfJitv2W7/w7HJsrlDvQiclM+yt4NnZN7Ef tybddiCgSd7T9sYwJBJISOH6iBB3zP/UY0jWYvnT/EiY1cGjda2kfZsmu5SEJZsG I06GnXMrAgykpH44NUP6r3vcOzL2sqmsSn7Re3FufEeZXZZg7mYXECQtyXoOwTwq 7LZpMv+ufe/SZ1TPOlsjQy2vSRaDIJlDW9h5xVRP4VGe8KGd6BWOwb4n6vXJ3WM= =1hMd -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UPBWn-0003Zc-NR for bitcoin-development@lists.sourceforge.net; Mon, 08 Apr 2013 12:50:29 +0000 X-ACL-Warn: Received: from 50-56-76-114.static.cloud-ips.com ([50.56.76.114] helo=neoretro.net) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1UPBWj-0000Tm-3q for bitcoin-development@lists.sourceforge.net; Mon, 08 Apr 2013 12:50:29 +0000 Received: from [10.1.1.115] (ip98-162-173-107.pn.at.cox.net [98.162.173.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by neoretro.net (Postfix) with ESMTPSA id 314E28585F for ; Mon, 8 Apr 2013 07:32:33 -0500 (CDT) Message-ID: <5162B8DE.2030708@daryltucker.com> Date: Mon, 08 Apr 2013 07:32:30 -0500 From: Daryl Tucker User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <20130405121251.GA18254@savin> In-Reply-To: <20130405121251.GA18254@savin> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 TVD_RCVD_IP TVD_RCVD_IP X-Headers-End: 1UPBWj-0000Tm-3q 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: Mon, 08 Apr 2013 12:50:30 -0000 BTC Guild's response: 51% Mitigation Plan I want to start by thanking all users, new and old, for making BTC Guild become what it is today. I never expected a service that originally started on a mining PC in my dining room in April 2011 to go this far. However, recently BTC Guild has started to become "too big". Users of Bitcoin are becoming scared that BTC Guild, either directly or through hacking/coercion, could be used to attack the network as it gets closer to 51% of the network. If this were to happen, it is likely many people would lose confidence in Bitcoin, as a single entity could control the network if it wanted to do so. I have put forward a proposal of my plans on how to mitigate this threat, but unfortunately nothing can be done without users taking some initiative as well. The following are the actions that will be taken if certain thresholds are crossed: More than 40% of the Network [last 2016 blocks] PPS fee will be raised from 5% to 7% on all new accounts. Old accounts will also be increased (PPS ONLY) to 7% after a difficulty change. If the pool eventually drops back under 40% for more than 72 hours, these fees will be turned back down to 5% after the next difficulty change. More than 45% of the Network [last 2016 blocks] Getwork based pools will be completely removed within 24 hours. All users on getwork have been warned in the past that it is a unsupported and not advised method of connecting. This should remove ~15% of BTC Guild's hash rate immediately. More than 40% of the Network again [last 2016 blocks] PPLNS fee will be raised from 3% to 4% after a 72 hour warning. This fee will be reduced back to 3% once the pool drops back under 40% for more than 72 hours. If you have questions or comments, please leave them on the forum thread related to this issue: https://bitcointalk.org/index.php?topic=168108.0 https://www.btcguild.com/index.php?page=home On 04/05/2013 07:12 AM, Peter Todd wrote: > On Fri, Apr 05, 2013 at 12:13:23PM +0200, Melvin Carvalho wrote: >> 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? > > Vandalize the chain how? By delibrately triggering bugs? (like the > old OP_CHECKSIG abuse problem) Regardless of whether or not the > vulnerability requires multiple blocks in a row, the underlying > problem should be fixed. > > By putting illegal data into it? Fundementally we have no way to > prevent people from doing that other than by making it expensive. > An attacker having a lot of hashing power just means they can do so > faster and a bit cheaper. > > > > ------------------------------------------------------------------------------ > > 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 > -- Daryl Tucker daryl@daryltucker.com