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 641E583D for ; Fri, 14 Aug 2015 15:03:51 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E9D60149 for ; Fri, 14 Aug 2015 15:03:50 +0000 (UTC) Received: from mail-io0-f178.google.com ([209.85.223.178]) by mrelay.perfora.net (mreueus001) with ESMTPSA (Nemesis) id 0M1HiQ-1YXU4r3trk-00tEgJ for ; Fri, 14 Aug 2015 17:03:49 +0200 Received: by iodt126 with SMTP id t126so87726379iod.2 for ; Fri, 14 Aug 2015 08:03:49 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.148.8 with SMTP id w8mr52772152iod.116.1439564629278; Fri, 14 Aug 2015 08:03:49 -0700 (PDT) Received: by 10.50.104.198 with HTTP; Fri, 14 Aug 2015 08:03:49 -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 16:03:49 +0100 Message-ID: From: Adam Back To: =?UTF-8?B?SmFrb2IgUsO2bm5iw6Rjaw==?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:PTFg8t8dKDnYPJyxa/xbJMSuNKmuSijAvSZ/mA2CX4becr1oxYD Y8iKTq5t91odXaYYNnCAcZJ/ilhAIAK3dFq6pp+LY5MCdugyP0lH7ubSelizRhsKt/J86JO /heIlF9vHRmfWEpXlj7xjdSbjIPYgh78dov9afZTaVkCCv94FbHY90cWRiA2V0DzdAGbVHa UMg3XW1CQGNCFexpb7vpQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:bwsaf9NlZK0=:gnZkJOtKKihOn6TAU4tTCn Thdz5PfjvM79hkUYYpY0VWqMHnwySRplDaRmLKFpJroM/UqzGbFEOj4EppONpghAHqYiuW/rH ttmeIAa0RRRwa+VehKPqkQrm+ApahLFmxGxoMWiOs/pfYbnKGks/QPlFqyC1dJIJ4nno168NW XWzae+t0d+XhNHhRxPNwTCJtbkTaoKwu/GLZ8eTIhnBzf1aPFkku7NzEzmLVxQcS/X1T/EICv y6vo3FrVjepiu4P78VIyck1/lnUvy6DJX2pWR9WFsxS7x9Nu5kjiegO90zr3HHFXdBVvD5SmQ NKDS6x+FJA4u0YDwUEmzBdMWgNRyzQomtRrLa/Wy+Rnd5geaRyKTahevN4rud3feD/vSK8otm D0u7gnHA9UmEAbnunxnzB5uy1TBBQixDNNWct0XNQ9C5hOqRprPKeQK83uM3ejfZgwxCeDIIW Kp+z7BPxley1V2NAYJFUketP3fWRfXgluG3zyCctpjeiMgTXMGVGhLQYI5cIqD2KW0Cpto53E VHAiybsD+F/Dwl5saBD1WKzoq+hd/pj2HGTYVQwSQprskMLlrv7GNBJ1lInZ/D8ml4j/+dWfK uyqIBJYPn1jUK6MM1OdWdkt1ElkNHtPr62Fwwuj3nFVMVANmMII+sKfNkgbKTuBzsYEtqcoka ozipLZCo4sbdOKbhWTENWmIcqKimfjs5+7h7+ceItsHOugiYQ8Jb2skMxrM/aoGx0PWgSS0hb Trql0Mo4JmDvH1jW 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 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:03:51 -0000 There is a proposal that relates to this, see the flexcap proposal by Greg Maxwell & Mark Friedenbach, it was discussed on the list back in May: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008017.html and http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008038.= html Adam On 14 August 2015 at 15:48, Jakob R=C3=B6nnb=C3=A4ck wrote: > > 14 aug 2015 kl. 16:20 skrev Anthony Towns : > > On 14 August 2015 at 11:59, Jakob R=C3=B6nnb=C3=A4ck > 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) > > > That would mean that as usage grew, blocksize could increase, but > 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 same? = That would > argue against the change if not for the fact that the blocks will be bigg= er > for the next difficulty period. > > 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 adj= ust > 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 investmen= t 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 > > > Very good feedback though, thanks a lot :) > > /jakob > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >