path: root/86/87decdc5a762211d07b67ca77f7fdeb737430e

Return-Path: <jakob.ronnback@me.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E3CFD87A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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?= <jakob.ronnback@me.com>
In-reply-to: <CADZB0_YvvDDq4XzfvQeeWJ2oZxPukP0oXYSrEeC3gy9_Fk0ZuA@mail.gmail.com>
Date: Fri, 14 Aug 2015 16:19:58 +0200
Message-id: <D018B1B0-B613-4C05-84BB-02CE6E2FEA3E@me.com>
References: <09C8843E-8379-404D-8357-05BDB1F749C1@me.com>
	<CADZB0_YvvDDq4XzfvQeeWJ2oZxPukP0oXYSrEeC3gy9_Fk0ZuA@mail.gmail.com>
To: Angel Leon <gubatron@gmail.com>
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 <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 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 <gubatron@gmail.com>:
>=20
> Like this?
> https://gist.github.com/gubatron/143e431ee01158f27db4 =
<https://gist.github.com/gubatron/143e431ee01158f27db4>
>=20
> http://twitter.com/gubatron <http://twitter.com/gubatron>
>=20
> On Fri, Aug 14, 2015 at 5:59 AM, Jakob R=C3=B6nnb=C3=A4ck =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> 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 =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">Hmm=E2=80=A6 well, yes and no. Mostly no :)<div class=3D""><br =
class=3D""></div><div class=3D"">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?</div><div class=3D""><br class=3D""></div><div class=3D""><div =
class=3D""><br class=3D""></div><div class=3D"">&nbsp;I=E2=80=99ll give =
a numeric example to clarify a bit.</div><div class=3D""><br =
class=3D""></div><div class=3D"">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.</div><div class=3D"">Example =
1:</div><div class=3D"">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</div><div class=3D"">Example=
 2:</div><div class=3D"">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</div><div class=3D""><br =
class=3D""></div><div class=3D""><br class=3D""></div><div class=3D"">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 :)</div><div =
class=3D""><br class=3D""></div><div class=3D""><br class=3D""></div><div =
class=3D""><div class=3D""><div class=3D""><div><blockquote type=3D"cite" =
class=3D""><div class=3D"">14 aug 2015 kl. 15:32 skrev Angel Leon &lt;<a =
href=3D"mailto:gubatron@gmail.com" =
class=3D"">gubatron@gmail.com</a>&gt;:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D"">Like this?<br class=3D""><a =
href=3D"https://gist.github.com/gubatron/143e431ee01158f27db4" =
class=3D"">https://gist.github.com/gubatron/143e431ee01158f27db4</a><br =
class=3D""></div><div class=3D"gmail_extra"><br clear=3D"all" =
class=3D""><div class=3D""><div class=3D"gmail_signature"><a =
href=3D"http://twitter.com/gubatron" target=3D"_blank" =
class=3D"">http://twitter.com/gubatron</a><br class=3D""></div></div>
<br class=3D""><div class=3D"gmail_quote">On Fri, Aug 14, 2015 at 5:59 =
AM, Jakob R=C3=B6nnb=C3=A4ck <span dir=3D"ltr" class=3D"">&lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> =
wrote:<br class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Greetings,<br =
class=3D"">
<br class=3D"">
a thought occurred to me that I would love to hear what some bitcoin =
experts think about.<br class=3D"">
<br class=3D"">
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)<br class=3D"">
<br class=3D"">
<br class=3D"">
In practice:<br class=3D"">
<br class=3D"">
1. calculate average block size for the previous difficulty period (is =
it 2016-blocks?)<br class=3D"">
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<br class=3D"">
<br class=3D"">
<br class=3D"">
Right now this would force miners to make blocks as close to 1mb as =
possible (since the block reward &gt;&gt; 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<br class=3D"">
<br class=3D"">
<br class=3D"">
Could the concept be useful somehow?<br class=3D"">
<br class=3D"">
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.<br =
class=3D"">
<br class=3D"">
Regards<br class=3D"">
/jakob<br class=3D"">
_______________________________________________<br class=3D"">
bitcoin-dev mailing list<br class=3D"">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"=
 rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a><br class=3D"">
</blockquote></div><br class=3D""></div>
</div></blockquote></div><br =
class=3D""></div></div></div></div></body></html>=

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