From: =?utf-8?Q?Jakob_R=C3=B6nnb=C3=A4ck?= <jakob.ronnback@me.com>
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable
Message-id: <09C8843E-8379-404D-8357-05BDB1F749C1@me.com>
Date: Fri, 14 Aug 2015 11:59:32 +0200
To: bitcoin-dev@lists.linuxfoundation.org
MIME-version: 1.0 (Mac OS X Mail 8.2 \(2102\))
Subject: [bitcoin-dev] Adjusted difficulty depending on relative blocksize
Precedence: list

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=