Return-Path: <anthony.j.towns@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4B099892 for <bitcoin-dev@lists.linuxfoundation.org>; 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 <bitcoin-dev@lists.linuxfoundation.org>; Fri, 14 Aug 2015 15:00:27 +0000 (UTC) Received: by wicne3 with SMTP id ne3so22190997wic.1 for <bitcoin-dev@lists.linuxfoundation.org>; 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> <CAJS_LCWRagQ40c28SGetxeHxnk8FqY3y_X0OxfqaiLbd25dSGg@mail.gmail.com> <A6B32C22-4006-434E-9B89-D7C99B5743A8@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: <CAJS_LCVUJKUitR52AHGsJoBxt2ddOQJYpE=OQN62NzvenHLe=Q@mail.gmail.com> From: Anthony Towns <aj@erisian.com.au> To: =?UTF-8?B?SmFrb2IgUsO2bm5iw6Rjaw==?= <jakob.ronnback@me.com> 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 <bitcoin-dev@lists.linuxfoundation.org> 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 <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <aj@erisian.com.au>: > > 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 <aj@erisian.com.au> --e89a8f646fcd3c6661051d46b62f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac= e"><span style=3D"font-family:arial,sans-serif">On 14 August 2015 at 16:48,= Jakob R=C3=B6nnb=C3=A4ck </span><span dir=3D"ltr" style=3D"font-family:ari= al,sans-serif"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"= target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span><spa= n style=3D"font-family:arial,sans-serif"> wrote:</span></div><div class=3D"= gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div= ><div><div style=3D"word-wrap:break-word"><div><div><blockquote type=3D"cit= e"><div>14 aug 2015 kl. 16:20 skrev Anthony Towns <<a href=3D"mailto:aj@= erisian.com.au" target=3D"_blank">aj@erisian.com.au</a>>:</div><br><div>= <div dir=3D"ltr"><div style=3D"font-family:monospace"><span style=3D"font-f= amily:arial,sans-serif">On 14 August 2015 at 11:59, Jakob R=C3=B6nnb=C3=A4c= k=C2=A0</span><span dir=3D"ltr" style=3D"font-family:arial,sans-serif"><= <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= bitcoin-dev@lists.linuxfoundation.org</a>></span><span style=3D"font-fam= ily:arial,sans-serif">=C2=A0wrote:</span><br></div><div class=3D"gmail_extr= a"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,= 204);border-left-style:solid;padding-left:1ex">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)<br></= blockquote><div><br></div><div><div style=3D"font-family:monospace">=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?</div></div></div></div></div></div></blockquote>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.</div></div></div></div></div></block= quote><div><br></div><div><div class=3D"gmail_default" style=3D"font-family= :monospace">=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.<span style=3D"font-family:arial,sans-serif">=C2=A0</= span></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div style=3D"wor= d-wrap:break-word"><div><div><blockquote type=3D"cite"><div dir=3D"ltr"><di= v class=3D"gmail_extra"><div class=3D"gmail_quote"><div><div style=3D"font-= family:monospace">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?</div></div></div>= </div></div></blockquote></div><div>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</div></div></div></div></div></= blockquote><div><br></div><div><div class=3D"gmail_default" style=3D"font-f= amily:monospace">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).</div><br></div><div><div class=3D"gmail_defaul= t" style=3D"font-family:monospace">=E2=80=8BCheers,</div><div class=3D"gmai= l_default" style=3D"font-family:monospace">aj=E2=80=8B</div></div></div><di= v><br></div>-- <br><div>Anthony Towns <<a href=3D"mailto:aj@erisian.com.= au" target=3D"_blank">aj@erisian.com.au</a>></div> </div></div> --e89a8f646fcd3c6661051d46b62f--