Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E3CFD87A for ; Fri, 14 Aug 2015 14:20:21 +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 0BAAA89 for ; Fri, 14 Aug 2015 14:20:20 +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 <0NT200XC3T5B0W30@st11p02im-asmtp002.me.com> for bitcoin-dev@lists.linuxfoundation.org; Fri, 14 Aug 2015 14:20:02 +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=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1508140207 Content-type: multipart/alternative; boundary="Apple-Mail=_C90B9614-0E4D-4ABB-8414-3DEB6C12246E" MIME-version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: =?utf-8?Q?Jakob_R=C3=B6nnb=C3=A4ck?= In-reply-to: Date: Fri, 14 Aug 2015 16:19:58 +0200 Message-id: References: <09C8843E-8379-404D-8357-05BDB1F749C1@me.com> To: Angel Leon X-Mailer: Apple Mail (2.2102) X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, 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 Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 14:20:22 -0000 --Apple-Mail=_C90B9614-0E4D-4ABB-8414-3DEB6C12246E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hmm=E2=80=A6 well, yes and no. Mostly no :) The main idea i was trying to describe was that the actual difficulty = for the block could be adjusted according to how much the size of the = proposed block differ compared to the average size of blocks in the = previous difficulty period. Unless I=E2=80=99m being very dense atm your = gist is just about dynamically adjusting the blocksize? I=E2=80=99ll give a numeric example to clarify a bit. Assume the current difficulty was calculated to be 1000, and the average = size of the blocks in the period used to calculate the difficulty was = 500kb. Example 1: I=E2=80=99m now attempting to find a new block with a size of 450 kb, or = 450/500 =3D 10% smaller than average. The difficulty would then be 1000 = * 110% =3D 1100 Example 2: If I instead was trying to make a block sized 10000 kb, or 10000/500 =3D = 2000% bigger than average the difficulty would be adjusted to 1000*20 =3D = 20000 Why I find this interesting is in a possible future when the block = reward is insignificant compared to the transactions fees miners would = make bigger blocks as fees rise. A miner could include more transactions = into blocks as long as the fees are high enough to offset the reduced = chance of actually finding the block. However, I now realize that there = wouldn=E2=80=99t be any downward pressure below the average size if the = price shrinks (using the particular numbers i have in my examples) = though. Maybe this method is only useful on the upside of the blocks, = meaning blocks smaller than the average size doesn=E2=80=99t get = adjusted difficulty. I need to go for a walk and think this through :) > 14 aug 2015 kl. 15:32 skrev Angel Leon : >=20 > Like this? > https://gist.github.com/gubatron/143e431ee01158f27db4 = >=20 > http://twitter.com/gubatron >=20 > On Fri, Aug 14, 2015 at 5:59 AM, Jakob R=C3=B6nnb=C3=A4ck = > wrote: > Greetings, >=20 > a thought occurred to me that I would love to hear what some bitcoin = experts think about. >=20 > 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 >=20 > In practice: >=20 > 1. calculate average block size for the previous difficulty period (is = it 2016-blocks?) > 2. when trying to find a new block adjust the difficulty by adding the = relative size difference. For instance, if i=E2=80=99m trying to create = a block half (or double) the size of the average block size for the = previous difficulty period then my difficulty will be 2x the normal = one=E2=80=A6 if I=E2=80=99m trying to make one that is 30% bigger (or = smaller) then the difficulty is 1.3 times the normal one >=20 >=20 > Right now this would force miners to make blocks as close to 1mb as = possible (since the block reward >> fees). But unless I=E2=80=99m = mistaken sometime in the future the block size should be adjusted to = maximize the fees=E2=80=A6 >=20 >=20 > Could the concept be useful somehow? >=20 > I apologize if it=E2=80=99s been discussed before or if it=E2=80=99s a = stupid idea, I would have run it by some other people, but I=E2=80=99m = afraid I don=E2=80=99t know anyone that have any interest in bitcoin. >=20 > Regards > /jakob > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org = > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev = >=20 --Apple-Mail=_C90B9614-0E4D-4ABB-8414-3DEB6C12246E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hmm=E2=80=A6 well, yes and no. Mostly no :)

The main idea i was trying to describe = was that the actual difficulty for the block could be adjusted according = to how much the size of the proposed block differ compared to the = average size of blocks in the previous difficulty period. Unless I=E2=80=99= m being very dense atm your gist is just about dynamically adjusting the = blocksize?


 I=E2=80=99ll give = a numeric example to clarify a bit.

Assume the current difficulty was = calculated to be 1000, and the average size of the blocks in the period = used to calculate the difficulty was 500kb.
Example = 1:
I=E2=80=99m now attempting to find a new block = with a size of 450 kb, or 450/500 =3D 10% smaller than average. The = difficulty would then be 1000 * 110% =3D 1100
Example= 2:
If I instead was trying to make a block sized = 10000 kb, or 10000/500 =3D 2000% bigger than average the difficulty = would be adjusted to 1000*20 =3D 20000


Why = I find this interesting is in a possible future when the block reward is = insignificant compared to the transactions fees miners would make bigger = blocks as fees rise. A miner could include more transactions into blocks = as long as the fees are high enough to offset the reduced chance of = actually finding the block. However, I now realize that there wouldn=E2=80= =99t be any downward pressure below the average size if the price = shrinks (using the particular numbers i have in my examples) though. = Maybe this method is only useful on the upside of the blocks, meaning = blocks smaller than the average size doesn=E2=80=99t get adjusted = difficulty. I need to go for a walk and think this through :)


14 aug 2015 kl. 15:32 skrev Angel Leon <gubatron@gmail.com>:

Like this?
https://gist.github.com/gubatron/143e431ee01158f27db4

http://twitter.com/gubatron

On Fri, Aug 14, 2015 at 5:59 = AM, Jakob R=C3=B6nnb=C3=A4ck <bitcoin-dev@lists.linuxfoundation.org> = wrote:
Greetings,

a thought occurred to me that I would love to hear what some bitcoin = experts think about.

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)


In practice:

1. calculate average block size for the previous difficulty period (is = it 2016-blocks?)
2. when trying to find a new block adjust the difficulty by adding the = relative size difference. For instance, if i=E2=80=99m trying to create = a block half (or double) the size of the average block size for the = previous difficulty period then my difficulty will be 2x the normal = one=E2=80=A6 if I=E2=80=99m trying to make one that is 30% bigger (or = smaller) then the difficulty is 1.3 times the normal one


Right now this would force miners to make blocks as close to 1mb as = possible (since the block reward >> fees). But unless I=E2=80=99m = mistaken sometime in the future the block size should be adjusted to = maximize the fees=E2=80=A6


Could the concept be useful somehow?

I apologize if it=E2=80=99s been discussed before or if it=E2=80=99s a = stupid idea, I would have run it by some other people, but I=E2=80=99m = afraid I don=E2=80=99t know anyone that have any interest in bitcoin.

Regards
/jakob
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>


= --Apple-Mail=_C90B9614-0E4D-4ABB-8414-3DEB6C12246E--