From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 24775F00 for ; Sat, 19 Dec 2015 20:03:30 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 576AC191 for ; Sat, 19 Dec 2015 20:03:29 +0000 (UTC) Received: from localhost ([::1]:54362 helo=server47.web-hosting.com) by server47.web-hosting.com with esmtpa (Exim 4.85) (envelope-from ) id 1aANiy-002GWu-5g; Sat, 19 Dec 2015 15:03:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sat, 19 Dec 2015 15:03:28 -0500 From: jl2012 To: Peter Todd In-Reply-To: <20151219184240.GB12893@muck> References: <20151219184240.GB12893@muck> Message-ID: <1e6039b8cc5db77ed0a75dfff7863f6d@xbt.hk> X-Sender: jl2012@xbt.hk User-Agent: Roundcube Webmail/1.0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server47.web-hosting.com X-AntiAbuse: Original Domain - lists.linuxfoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - xbt.hk X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id: jl2012@xbt.hk X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 19 Dec 2015 20:07:07 +0000 Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] We need to fix the block withholding attack X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2015 20:03:30 -0000 After the meeting I find a softfork solution. It is very inefficient and I am leaving it here just for record. 1. In the first output of the second transaction of a block, mining pool will commit a random nonce with an OP_RETURN. 2. Mine as normal. When a block is found, the hash is concatenated with the committed random nonce and hashed. 3. The resulting hash must be smaller than 2 ^ (256 - 1/64) or the block is invalid. That means about 1% of blocks are discarded. 4. For each difficulty retarget, the secondary target is decreased by 2 ^ 1/64. 5. After 546096 blocks or 10 years, the secondary target becomes 2 ^ 252. Therefore only 1 in 16 hash returned by hasher is really valid. This should make the detection of block withholding attack much easier. All miners have to sacrifice 1% reward for 10 years. Confirmation will also be 1% slower than it should be. If a node (full or SPV) is not updated, it becomes more vulnerable as an attacker could mine a chain much faster without following the new rules. But this is still a softfork, by definition. --------------- ok, back to topic. Do you mean this? http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2012-June/001506.html Peter Todd via bitcoin-dev 於 2015-12-19 13:42 寫到: > At the recent Scaling Bitcoin conference in Hong Kong we had a chatham > house rules workshop session attending by representitives of a super > majority of the Bitcoin hashing power. > > One of the issues raised by the pools present was block withholding > attacks, which they said are a real issue for them. In particular, > pools > are receiving legitimate threats by bad actors threatening to use block > withholding attacks against them. Pools offering their services to the > general public without anti-privacy Know-Your-Customer have little > defense against such attacks, which in turn is a threat to the > decentralization of hashing power: without pools only fairly large > hashing power installations are profitable as variance is a very real > business expense. P2Pool is often brought up as a replacement for > pools, > but it itself is still relatively vulnerable to block withholding, and > in any case has many other vulnerabilities and technical issues that > has > prevented widespread adoption of P2Pool. > > Fixing block withholding is relatively simple, but (so far) requires a > SPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We should > do this hard-fork in conjunction with any blocksize increase, which > will > have the desirable side effect of clearly show consent by the entire > ecosystem, SPV clients included. > > > Note that Ittay Eyal and Emin Gun Sirer have argued(1) that block > witholding attacks are a good thing, as in their model they can be used > by small pools against larger pools, disincentivising large pools. > However this argument is academic and not applicable to the real world, > as a much simpler defense against block withholding attacks is to use > anti-privacy KYC and the legal system combined with the variety of > withholding detection mechanisms only practical for large pools. > Equally, large hashing power installations - a dangerous thing for > decentralization - have no block withholding attack vulnerabilities. > > 1) http://hackingdistributed.com/2014/12/03/the-miners-dilemma/ > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev