From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A2C7CD88 for ; Mon, 11 Nov 2019 17:10:29 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com [209.85.167.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6FCE05E4 for ; Mon, 11 Nov 2019 17:10:28 +0000 (UTC) Received: by mail-oi1-f173.google.com with SMTP id j7so12139949oib.3 for ; Mon, 11 Nov 2019 09:10:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QHc0oym6Jl3FVJ63O18O9VaL7ZWCnGpn9hREQAQX/Vs=; b=Ns0SN92TX3nRMcle5bPjqw25GbDWgpzS1pz1xcWC0G/1oIl1Yf/XjPV+PA/Odbphxa f2IBlZgpIMDZRnTp6yOJY2acCmcSnyCJxO+TX+6RX15OjD9e20zK81sL/laWkOttB1SG O2b8G9y67Dadbk37Erwr5L5I6bEUYC4oLu5R9uq0Dmv1GsGySxlze2dqUp+EU0M31nSQ dpMWRfTe+lUmYcIBrMfEuAwM1G1zaBnAvzpkT7vZSZI/tZwcBQDpUHGx3ngsoJdoDdJZ jIZkxZR5F+Rx387whTTfqbAxE0O3nUDTImjwnO2qQgewxO53ze5jDPSU2UnWmqXiU7kv wcxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QHc0oym6Jl3FVJ63O18O9VaL7ZWCnGpn9hREQAQX/Vs=; b=uJDduoTjW/xYUjbtOI7Q34dbboyHWtGDrsMlYGBQVKzHDzhRw9Pltom94Kw29OBSfL EuqB2XYo8rk4jXrb2c+yOigTzylVR4+ITKJLNpP7L0lzycbvViyU09NE1GSrvTGt3qSy nRAcWyTZ3aR+0LNY4dZ8yv71116vuO/RID3N4/L58SxHPLhRZDUyEOuKIOYmytguCDNF jTFyW6KSeOEEPJmC9+9GvLixr7L+kK245IluGygdT/3cGDciZ4k1PWTc3CVOzPccBZw0 dHRI0irMRevCa+LFETdm0mg0vx5U6+9C3ECTnAFqTfDERbEY9+4LFh5I9BTw+KbBrsmn kPXA== X-Gm-Message-State: APjAAAUjKB9GrYW7AxLUzfAKxM952Dz67iRVQhFKPF/Zy+5XBIhZ+fnN IVxq1bWR8LcQOj3PXRq5afnCFtFrbRp3cSTTUWM= X-Google-Smtp-Source: APXvYqy4VNrs3L67H28yUPKGd51I33K+Y75jnFN+hqKeWzUSEZF6t4FcMIXaaT5aNyekUiGJKzEZSEiOvjtOfUywy1M= X-Received: by 2002:aca:f141:: with SMTP id p62mr22408oih.3.1573492227540; Mon, 11 Nov 2019 09:10:27 -0800 (PST) MIME-Version: 1.0 References: <201911111647.06200.luke@dashjr.org> In-Reply-To: <201911111647.06200.luke@dashjr.org> From: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= Date: Mon, 11 Nov 2019 18:10:16 +0100 Message-ID: To: Luke Dashjr Content-Type: multipart/alternative; boundary="000000000000478a51059715352e" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Dynamic MaxBlockSize - 3 Byte Solution X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 17:10:29 -0000 --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 : > 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
> 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;
hopeful= ly when exchanges start using Lightning or Liquid, avg blocksize will go do= wn.

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

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

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

Hampus

Den m=C3=A5n 11 nov. 2019 kl 17:47 skrev L= uke Dashjr <luke@dashjr.org>:<= br>
On Monday 11 Nov= ember 2019 16:08:43 Hampus Sj=C3=B6berg via bitcoin-dev wrote:
> 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 = via
> an extension block (softfork).

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

Luke
--000000000000478a51059715352e--