Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 95235892 for ; Fri, 14 Aug 2015 14:49:06 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from st11p02im-asmtp002.me.com (st11p02im-asmtp002.me.com [17.172.220.114]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1B080E2 for ; Fri, 14 Aug 2015 14:49:06 +0000 (UTC) Received: from [10.0.1.60] (h-29-43.a159.priv.bahnhof.se [79.136.29.43]) by st11p02im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NT200P4HUHC9I30@st11p02im-asmtp002.me.com> for bitcoin-dev@lists.linuxfoundation.org; Fri, 14 Aug 2015 14:48:51 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-08-14_06:2015-08-13, 2015-08-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1508140212 From: =?utf-8?Q?Jakob_R=C3=B6nnb=C3=A4ck?= Content-type: multipart/alternative; boundary="Apple-Mail=_1CA12C5C-50FB-4153-B72A-23AC0006C25F" Message-id: <116B26BD-D8E8-4AFD-A619-2EAC348DA5E6@me.com> MIME-version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Date: Fri, 14 Aug 2015 16:48:48 +0200 References: <09C8843E-8379-404D-8357-05BDB1F749C1@me.com> To: bitcoin-dev@lists.linuxfoundation.org In-reply-to: X-Mailer: Apple Mail (2.2102) X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD 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] 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 14:49:06 -0000 --Apple-Mail=_1CA12C5C-50FB-4153-B72A-23AC0006C25F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > 14 aug 2015 kl. 16:20 skrev Anthony Towns >: >=20 > 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 = terms, I=E2=80=99m not a real programmer, and I=E2=80=99ve only recently = started to subscribe to the mailing list) >=20 > =E2=80=8BThat 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? >=20 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 bigger 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 back as decreased difficulty, it'd probably be simpler to just = dynamically adjust the max blocksize wouldn't it? >=20 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 investment 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= --Apple-Mail=_1CA12C5C-50FB-4153-B72A-23AC0006C25F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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 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 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 bigger 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 back 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=99= s 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 investment 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
= --Apple-Mail=_1CA12C5C-50FB-4153-B72A-23AC0006C25F--