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 EC61510F0 for ; Sat, 26 Dec 2015 16:09:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5F3D9EC for ; Sat, 26 Dec 2015 16:09:19 +0000 (UTC) Received: by mail-io0-f169.google.com with SMTP id e126so276314894ioa.1 for ; Sat, 26 Dec 2015 08:09:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=lJL4NZXSMUBoKCPqpXb1PtlROM0/LVQDp2/2owNxGZA=; b=Awo33pwoyNKrd5twUMbHOL3SFliuuJKL3hCeaFXz9T9MgOTG7x5A8i0jNdtFYRiwbL a5DgGS9RAUZ6TXPjC6U6ylJdw+EDiKzEnev5YoOP1LNU67/xMCB3tlugyED3gmCYrRtE SVFEOrV9qD6GLhZxkPu8iBwHmMc1PtbfRWOJ3Qg9T4o7yuSxt8EvC62dYztZaPMYU8xW 8mKoY+jC5dDox9XzkmSpMS8yW2D2eBcgNA+d6W7Oc/bjkKd/lOO/v5ZJ1gMwWbgE7lGb PZUQSoi9Or4iytTgZoQozATRm7Y9Y4N8y7yUgFR90Cv5DdY3Xo883ak6vUuzIFbk09cO /ZMA== MIME-Version: 1.0 X-Received: by 10.107.17.144 with SMTP id 16mr10257099ior.109.1451146158814; Sat, 26 Dec 2015 08:09:18 -0800 (PST) Received: by 10.79.77.75 with HTTP; Sat, 26 Dec 2015 08:09:18 -0800 (PST) In-Reply-To: References: <20151220132842.GA25481@muck> Date: Sat, 26 Dec 2015 16:09:18 +0000 Message-ID: From: Tier Nolan To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a113ff202503ab70527cf4bf4 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 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, 26 Dec 2015 16:09:20 -0000 --001a113ff202503ab70527cf4bf4 Content-Type: text/plain; charset=UTF-8 On Sat, Dec 26, 2015 at 8:23 AM, Eric Lombrozo via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Unfortunately, this also means longer confirmation times, lower > throughput, and lower miner revenue. Note, however, that confirmations > would (on average) represent more PoW, so fewer confirmations would be > required to achieve the same level of security. > No, the re-target compensates so that the number of blocks in the last two weeks is 2016. If a soft fork forces miners to throw away 25% of their blocks, then the difficulty will drop by 75% to keep things balanced. Throwing away 75% of blocks has the same effect on difficulty as destroying 75% of mining hardware. The block interval will only increase until the next re-target. Slowly increasing the fraction of blocks which are thrown away gives the re-target algorithm time to adjust, so it is another advantage. If the rule was instantly changed so that 95% of blocks were thrown away, then there could be up to 40 weeks until the next retarget and that would give 200 minute block times until the adjustment. --001a113ff202503ab70527cf4bf4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Dec 26, 2015 at 8:23 AM, Eric Lombrozo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Unfortunately, this also means longer confirmation times, lower throug= hput, and lower miner revenue. Note, however, that confirmations would (on = average) represent more PoW, so fewer confirmations would be required to ac= hieve the same level of security.


No, the re-ta= rget compensates so that the number of blocks in the last two weeks is 2016= .=C2=A0 If a soft fork forces miners to throw away 25% of their blocks, the= n the difficulty will drop by 75% to keep things balanced.=C2=A0 Throwing a= way 75% of blocks has the same effect on difficulty as destroying 75% of mi= ning hardware.

The block interval will only increase unti= l the next re-target.

Slowly increasing the fraction of blocks which= are thrown away gives the re-target algorithm time to adjust, so it is ano= ther advantage.=C2=A0

If the rule was instantly changed so that 95%= of blocks were thrown away, then there could be up to 40 weeks until the n= ext retarget and that would give 200 minute block times until the adjustmen= t.
--001a113ff202503ab70527cf4bf4--