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 4B099892 for ; Fri, 14 Aug 2015 15:00:28 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 44EC01AE for ; Fri, 14 Aug 2015 15:00:27 +0000 (UTC) Received: by wicne3 with SMTP id ne3so22190997wic.1 for ; Fri, 14 Aug 2015 08:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6Rx0pQpbtMpnXQ7orDzs8glSuu1wHp4JTG+YvgdN7YE=; b=euWYXpOgNU+92gnE5fPthS4qZ+K8pvvSWfKkO/OQVy32yfhynNEN/ln9vl5coMGIE8 HfAsbJuUfaCj8yxltfSfSfecS+o6jY0KpoGFp2UQIDCe0PgrB1nL+/U0v0GkAAf2NcGx VdltYSk2s6eoNa+sPajs9P8z1DoqyGL46QZEufIM9ycetsgM+r2UE6KlU5CcU5XC2ZNP ND6SNYkNHuhc4d6dRhKE4hLF/K3uD9EhsaAYUABuveA4jPfpMs6LlcPEcNuZLkg2529o l8atpwktz0CPVrC+V32WRHeb4vOUFJ0EEkl/RiKIrwKncGWkHGhqmNVQoErxNioAQ8GD DoZA== MIME-Version: 1.0 X-Received: by 10.180.38.68 with SMTP id e4mr7912883wik.9.1439564425879; Fri, 14 Aug 2015 08:00:25 -0700 (PDT) Sender: anthony.j.towns@gmail.com Received: by 10.28.176.69 with HTTP; Fri, 14 Aug 2015 08:00:25 -0700 (PDT) In-Reply-To: <116B26BD-D8E8-4AFD-A619-2EAC348DA5E6@me.com> References: <09C8843E-8379-404D-8357-05BDB1F749C1@me.com> <116B26BD-D8E8-4AFD-A619-2EAC348DA5E6@me.com> Date: Fri, 14 Aug 2015 17:00:25 +0200 X-Google-Sender-Auth: JdYgsoSN2NpjJH4vrkeBnTGJNM8 Message-ID: From: Anthony Towns To: =?UTF-8?B?SmFrb2IgUsO2bm5iw6Rjaw==?= Content-Type: multipart/alternative; boundary=e89a8f646fcd3c6661051d46b62f X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize 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: Fri, 14 Aug 2015 15:00:28 -0000 --e89a8f646fcd3c6661051d46b62f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 14 August 2015 at 16:48, Jakob R=C3=B6nnb=C3=A4ck < bitcoin-dev@lists.linuxfoundation.org> wrote: > 14 aug 2015 kl. 16:20 skrev Anthony Towns : > > On 14 August 2015 at 11:59, Jakob R=C3=B6nnb=C3=A4ck < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> What if one were to adjust the difficulty (for individual blocks) >> depending on the relative size to the average block size of the previous >> difficulty period? (I apologize if i=E2=80=99m not using the correct ter= ms, I=E2=80=99m not >> a real programmer, and I=E2=80=99ve only recently started to subscribe t= o the >> mailing list) >> > > =E2=80=8BThat would mean that as usage grew, blocksize could increase, bu= t > confirmation times would also increase (though presumably less than > linearly). That seems like a loss? > > Would that really be the case though? If it takes 5% to find a block, but > it contains 5% more transactions would that not mean it=E2=80=99s the sam= e? That > would argue against the change if not for the fact that the blocks will b= e > bigger for the next difficulty period. > =E2=80=8BIf you're waiting for one confirmation, something like that works = -- you might from 95% chance of 10 minutes 5% chance of 20 minutes to 100% chance of 10m30s. But if you want 144 confirmations (eg) you go from 95% chance of 1 day, 5% chance of 1 day 10 minutes; to 100% chance of 1 day 72 minutes. > If you also let the increase in confirmation time (due to miners finding > harder blocks rather than a reduction in hashpower) then get reflected ba= ck > as decreased difficulty, it'd probably be simpler to just dynamically > adjust the max blocksize wouldn't it? > > I guess that could make the difficulty fluctuate a bit depending on the > amount of transactions and the fees being paid. Would it really matter in > the long run though? Since it=E2=80=99s the same amount of miners, doesn= =E2=80=99t that > just mean it=E2=80=99s just the number that is lower, not the actual inve= stment > needed to mine the blocks? Not sure if this would open up some forms of > attacks on the system for someone willing to lose money though=E2=80=A6 > Once blocksizes had normalised as much larger than 1MB with a corresponding higher average hashrate, a bad actor could easily mine a raft of valid empty/small blocks at the minimum hash rate and force a reorg (and do doublespends, etc). =E2=80=8BCheers, aj=E2=80=8B --=20 Anthony Towns --e89a8f646fcd3c6661051d46b62f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 14 August 2015 at 16:48,= Jakob R=C3=B6nnb=C3=A4ck <bitcoin-dev@lists.linuxfoundation.org> wrote:
14 aug 2015 kl. 16:20 skrev Anthony Towns <aj@erisian.com.au>:

=
On 14 August 2015 at 11:59, Jakob R=C3=B6nnb=C3=A4c= k=C2=A0<= = bitcoin-dev@lists.linuxfoundation.org>=C2=A0wrote:
What if one were to adjust t= he difficulty (for individual blocks) depending on the relative size to the= average block size of the previous difficulty period? (I apologize if i=E2= =80=99m not using the correct terms, I=E2=80=99m not a real programmer, and= I=E2=80=99ve only recently started to subscribe to the mailing list)

=E2=80= =8BThat would mean that as usage grew, blocksize could increase, but confir= mation times would also increase (though presumably less than linearly). Th= at seems like a loss?
Would= that really be the case though? If it takes 5% to find a block, but it con= tains 5% more transactions would that not mean it=E2=80=99s the same? That = would argue against the change if not for the fact that the blocks will be = bigger for the next difficulty period.

=E2=80=8BIf you're waiting for one confirmation, something = like that works -- you might from 95% chance of 10 minutes 5% chance of 20 = minutes to 100% chance of 10m30s. But if you want 144 confirmations (eg) yo= u go from 95% chance of 1 day, 5% chance of 1 day 10 minutes; to 100% chanc= e of 1 day 72 minutes.=C2=A0
If you also let the increase in confirmation time (due to= miners finding harder blocks rather than a reduction in hashpower) then ge= t reflected back as decreased difficulty, it'd probably be simpler to j= ust dynamically adjust the max blocksize wouldn't it?
=
I guess that could make the difficulty = fluctuate a bit depending on the amount of transactions and the fees being = paid. Would it really matter in the long run though? Since it=E2=80=99s the= same amount of miners, doesn=E2=80=99t that just mean it=E2=80=99s just th= e number that is lower, not the actual investment needed to mine the blocks= ? Not sure if this would open up some forms of attacks on the system for so= meone willing to lose money though=E2=80=A6

Once blocksizes had normalised as much larger than 1MB wit= h a corresponding higher average hashrate, a bad actor could easily mine a = raft of valid empty/small blocks at the minimum hash rate and force a reorg= (and do doublespends, etc).

=E2=80=8BCheers,
aj=E2=80=8B

--
Anthony Towns <aj@erisian.com.au>
--e89a8f646fcd3c6661051d46b62f--