Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Sb1gO-00085K-9r for bitcoin-development@lists.sourceforge.net; Sun, 03 Jun 2012 03:40:48 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.160.47 as permitted sender) client-ip=209.85.160.47; envelope-from=watsonbladd@gmail.com; helo=mail-pb0-f47.google.com; Received: from mail-pb0-f47.google.com ([209.85.160.47]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) id 1Sb1gN-0004fV-EH for bitcoin-development@lists.sourceforge.net; Sun, 03 Jun 2012 03:40:48 +0000 Received: by pbbrq2 with SMTP id rq2so4443265pbb.34 for ; Sat, 02 Jun 2012 20:40:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.129.167 with SMTP id nx7mr5280920pbb.80.1338694841635; Sat, 02 Jun 2012 20:40:41 -0700 (PDT) Sender: watsonbladd@gmail.com Received: by 10.142.174.10 with HTTP; Sat, 2 Jun 2012 20:40:41 -0700 (PDT) In-Reply-To: References: <201206030052.17128.luke@dashjr.org> Date: Sat, 2 Jun 2012 22:40:41 -0500 X-Google-Sender-Auth: cFj9yNQtq3Zeqb4RplkKwU7B8vU Message-ID: From: Watson Ladd To: Bitcoin Dev Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (watsonbladd[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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: 1Sb1gN-0004fV-EH Subject: [Bitcoin-development] Fwd: Defeating the block withholding attack 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: Sun, 03 Jun 2012 03:40:48 -0000 On Sat, Jun 2, 2012 at 7:52 PM, Luke-Jr wrote: > Analysis, comments, constructive criticism, etc welcome for the following= : > > =3D=3DBackground=3D=3D > At present, an attacker can harm a pool by intentionally NOT submitting s= hares > that are also valid blocks. All pools are vulnerable to this attack, whet= her > centralized or decentralized and regardless of reward system used. The > attack's effectiveness is proportional to ratio of the attacker's hashrat= e to > the rest of the pool. This attack has an obvious signature: getting outworked on the same block as the pool was trying to verify, and always by the same person. > > There are obvious solutions that can be used to defeat this attack on > centralized pools. For example, including a secret in the coinbase transa= ction > that is accepted by the network as a partial preimage proof-of-work. All = these > solutions require changes to Bitcoin's proof-of-work acceptance terms, an= d > since centralized pools can be harmful to the network's security, these r= ule > changes are not likely to gain enough acceptance among the greater Bitcoi= n > community. > > =3D=3DProposed Solution=3D=3D > Please comment on the viability of this new proof-of-work algorithm, whic= h I > think should be viable for even decentralized pools: > > Blocks are accepted at a lower difficulty N (choosable by the pool; eg, t= he > share difficulty) iff they are submitted with a candidate for the next bl= ock > and SHA256(SHA256(NewBlockHash + NextBlockCandidateHash)) meets difficult= y M. > The relationship between M and N must be comparable to the normal network > difficulty; details on the specifics of this can be figured out later, id= eally > by someone more qualified than me. M and N must be chosen prior to search= ing > for the block: it should be safe to steal some always-zero bytes from the > prevblock header for this. So the goal is to prevent the attacker double-dipping by submitting cycles to the pool, which if he found a correct answer he could submit himself. I don't see how this does that: if he finds a valid block he finds a valid block. Only if the operator has a secret is this prevented. > > This algorithm should guarantee that every share has an equal chance of b= eing > a valid block at the time it is found, and that which ones are actually b= locks > cannot be known until the subsequent block is found. Thus, attackers have= no > way to identify which shares to withhold even while they have full knowle= dge > of the shares/blocks themselves. This further delays the finalization of a transaction. That's not a good th= ing. > > =3D=3DBackward Compatibility=3D=3D > Obviously, this change creates a hard-fork in the blockchain. I propose t= hat > if it solves the block withholding risk, the gain is sufficient that the > community may approve a hard-fork to take place 1-2 years from consensus. > > Since mining continues to use a double-SHA256 on a fixed 80 byte header, > existing miners, FPGAs, etc should work unmodified. Poolservers will need= to > adapt significantly. > > -------------------------------------------------------------------------= ----- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither=C2=A0 Liberty nor Safety." -- Benjamin Franklin --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither=C2=A0 Liberty nor Safety." -- Benjamin Franklin