From: Luke Dashjr <luke@dashjr.org>
To: Hampus =?utf-8?q?Sj=C3=B6berg?= <hampus.sjoberg@gmail.com>
Date: Mon, 11 Nov 2019 19:56:15 +0000
User-Agent: KMail/1.9.10
References: <CAN+Of7A9pmrhEma49cQ0eP7vn50WxFemAEvztFxhgX2om_8Dpw@mail.gmail.com>
	<201911111647.06200.luke@dashjr.org>
	<CAFMkqK8fuB0BSpVsSnzgBv1WkZx_8Wqi4BQ6dL95PeGExM1nHQ@mail.gmail.com>
In-Reply-To: <CAFMkqK8fuB0BSpVsSnzgBv1WkZx_8Wqi4BQ6dL95PeGExM1nHQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <201911111956.16782.luke@dashjr.org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Dynamic MaxBlockSize - 3 Byte Solution
Precedence: list

On Monday 11 November 2019 17:10:16 Hampus Sj=C3=B6berg wrote:
> > 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.

Not likely, so long as spam continues to pad blocks full.

> > 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.

Softforks leave old nodes *working*, so yes, maintaining the correct UTXO=20
state.

Simply "following" is meaningless, as even soft-hardforks are "followed".

> 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.

If there isn't consensus, then it shouldn't be done, period.

Luke