MIME-Version: 1.0
References: <CAN+Of7A9pmrhEma49cQ0eP7vn50WxFemAEvztFxhgX2om_8Dpw@mail.gmail.com>
	<CAL6iL8VwYVpFkZuExpk=7LKGTLxVdQODtZmHnaK4MR0J9McdVQ@mail.gmail.com>
	<CAFMkqK9-8GRJWXgYOUHrQtApCQ0WW0beD1xr7+mbAQS6YXY65A@mail.gmail.com>
	<201911111647.06200.luke@dashjr.org>
In-Reply-To: <201911111647.06200.luke@dashjr.org>
From: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= <hampus.sjoberg@gmail.com>
Date: Mon, 11 Nov 2019 18:10:16 +0100
Message-ID: <CAFMkqK8fuB0BSpVsSnzgBv1WkZx_8Wqi4BQ6dL95PeGExM1nHQ@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary="000000000000478a51059715352e"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Dynamic MaxBlockSize - 3 Byte Solution
Precedence: list

--000000000000478a51059715352e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> It ISN'T low right now...

I agree, but I don't think it's a good idea to softfork it to lower than 4M
WU though, and I don't think we need to;
hopefully when exchanges start using Lightning or Liquid, avg blocksize
will go down.

> Extension blocks are not softforks, and are unreasonably convoluted for
no
real gain. When the time comes, the block size should be increased only
using
a hardfork.

It depends on how you define soft and hardforks, I suspect you don't see
extension blocks as a softforks because old nodes won't maintain a correct
UTXO set.
I think an extension block is a softfork because old nodes will still be
able to follow the mainchain.

I don't know if a blocksize increase hardfork will get consensus as the
idea has been ruined by all malicious hijack attempts we've seen over the
years.

Hampus

Den m=C3=A5n 11 nov. 2019 kl 17:47 skrev Luke Dashjr <luke@dashjr.org>:

> On Monday 11 November 2019 16:08:43 Hampus Sj=C3=B6berg via bitcoin-dev w=
rote:
> > I am advocating to keep the blocksize low right now,
>
> It ISN'T low right now...
>
> > but I don't leave out
> > in increasing it in the future when we have a need for it, preferably v=
ia
> > an extension block (softfork).
>
> Extension blocks are not softforks, and are unreasonably convoluted for n=
o
> real gain. When the time comes, the block size should be increased only
> using
> a hardfork.
>
> Luke
>

--000000000000478a51059715352e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><span class=3D"gmail-im">&gt; </span>It ISN&#39;T low=
 right now...<span class=3D"gmail-im"><br></span></div><div><br></div><div>=
I agree, but I don&#39;t think it&#39;s a good idea to softfork it to lower=
 than 4M WU though, and I don&#39;t think we need to;<br></div><div>hopeful=
ly when exchanges start using Lightning or Liquid, avg blocksize will go do=
wn.<br></div><div><br></div><div>&gt; Extension blocks are not softforks, a=
nd are unreasonably convoluted for no <br>
real gain. When the time comes, the block size should be increased only usi=
ng <br>
a hardfork.</div><div><br></div><div>It depends on how you define soft and =
hardforks, I suspect you don&#39;t see extension blocks as a softforks beca=
use old nodes won&#39;t maintain a correct UTXO set.</div><div>I think an e=
xtension block is a softfork because old nodes will still be able to follow=
 the mainchain.</div><div><br></div><div>I don&#39;t know if a blocksize in=
crease hardfork will get consensus as the idea has been ruined by all malic=
ious hijack attempts we&#39;ve seen over the years.<br></div><div><br></div=
><div>Hampus<br></div><div><span class=3D"gmail-im"></span></div><div><span=
 class=3D"gmail-im"></span></div></div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">Den m=C3=A5n 11 nov. 2019 kl 17:47 skrev L=
uke Dashjr &lt;<a href=3D"mailto:luke@dashjr.org">luke@dashjr.org</a>&gt;:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Monday 11 Nov=
ember 2019 16:08:43 Hampus Sj=C3=B6berg via bitcoin-dev wrote:<br>
&gt; I am advocating to keep the blocksize low right now, <br>
<br>
It ISN&#39;T low right now...<br>
<br>
&gt; but I don&#39;t leave out <br>
&gt; in increasing it in the future when we have a need for it, preferably =
via<br>
&gt; an extension block (softfork).<br>
<br>
Extension blocks are not softforks, and are unreasonably convoluted for no =
<br>
real gain. When the time comes, the block size should be increased only usi=
ng <br>
a hardfork.<br>
<br>
Luke<br>
</blockquote></div>

--000000000000478a51059715352e--