MIME-Version: 1.0
Sender: anthony.j.towns@gmail.com
In-Reply-To: <09C8843E-8379-404D-8357-05BDB1F749C1@me.com>
References: <09C8843E-8379-404D-8357-05BDB1F749C1@me.com>
Date: Fri, 14 Aug 2015 16:20:35 +0200
Message-ID: <CAJS_LCWRagQ40c28SGetxeHxnk8FqY3y_X0OxfqaiLbd25dSGg@mail.gmail.com>
From: Anthony Towns <aj@erisian.com.au>
To: =?UTF-8?B?SmFrb2IgUsO2bm5iw6Rjaw==?= <jakob.ronnback@me.com>
Content-Type: multipart/alternative; boundary=089e01228c70bd0a4c051d46271b
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Adjusted difficulty depending on relative
	blocksize
Precedence: list

--089e01228c70bd0a4c051d46271b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 term=
s, 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?

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?

Cheers,
aj=E2=80=8B

--=20
Anthony Towns <aj@erisian.com.au>

--089e01228c70bd0a4c051d46271b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e"><span style=3D"font-family:arial,sans-serif">On 14 August 2015 at 11:59,=
 Jakob R=C3=B6nnb=C3=A4ck </span><span dir=3D"ltr" style=3D"font-family:ari=
al,sans-serif">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
 target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span><spa=
n style=3D"font-family:arial,sans-serif"> wrote:</span><br></div><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
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=99=
m not a real programmer, and I=E2=80=99ve only recently started to subscrib=
e to the mailing list)<br></blockquote><div><br></div><div><div class=3D"gm=
ail_default" style=3D"font-family:monospace">=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?</d=
iv><div class=3D"gmail_default" style=3D"font-family:monospace"><br></div><=
div class=3D"gmail_default" style=3D"font-family:monospace">If you also let=
 the increase in confirmation time (due to miners finding harder blocks rat=
her than a reduction in hashpower) then get reflected back as decreased dif=
ficulty, it&#39;d probably be simpler to just dynamically adjust the max bl=
ocksize wouldn&#39;t it?</div><div class=3D"gmail_default" style=3D"font-fa=
mily:monospace"><br></div><div class=3D"gmail_default" style=3D"font-family=
:monospace">Cheers,</div><div class=3D"gmail_default" style=3D"font-family:=
monospace">aj=E2=80=8B</div></div></div><div><br></div>-- <br><div class=3D=
"gmail_signature">Anthony Towns &lt;<a href=3D"mailto:aj@erisian.com.au" ta=
rget=3D"_blank">aj@erisian.com.au</a>&gt;</div>
</div></div>

--089e01228c70bd0a4c051d46271b--