Return-Path: <j@toom.im>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 0C757C5F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  9 Dec 2015 00:40:54 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 81058165
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  9 Dec 2015 00:40:53 +0000 (UTC)
Received: from [192.168.0.136] (1-64-179-042.static.netvigator.com
	[1.64.179.42]) (authenticated bits=0)
	by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id tB90el63008150
	(version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
	Tue, 8 Dec 2015 16:40:49 -0800
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_1F7DEAD5-247D-46DA-AAC3-9EEC34D67150";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.2
From: Jonathan Toomim <j@toom.im>
In-Reply-To: <CAAS2fgRP8bLWZoKR9-iJS-2RKTGQQ9NG-LpAfa2BOdcR=GuB_A@mail.gmail.com>
Date: Wed, 9 Dec 2015 08:40:46 +0800
Message-Id: <411150E9-8811-43B9-8285-DC2EB3BD1C50@toom.im>
References: <CAAS2fgQyVs1fAEj+vqp8E2=FRnqsgs7VUKqALNBHNxRMDsHdVg@mail.gmail.com>
	<5F73C59C-7939-4937-839D-CA93880CB21F@toom.im>
	<CAAS2fgRP8bLWZoKR9-iJS-2RKTGQQ9NG-LpAfa2BOdcR=GuB_A@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
X-Sonic-CAuth: UmFuZG9tSVbt16s7lgt+o/pFzZV2+rIP+x5kjmzaRac9E8llnh3fZ7068k6OkCuxcPV6q8r6vO3fZDO3klwnfb8N5sg/DOX4
X-Sonic-ID: C;+i7vfA2e5RGRwf8vZz0oYQ== M;Mg5efg2e5RGRwf8vZz0oYQ==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
	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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
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: Wed, 09 Dec 2015 00:40:54 -0000


--Apple-Mail=_1F7DEAD5-247D-46DA-AAC3-9EEC34D67150
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Dec 9, 2015, at 8:09 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> On Tue, Dec 8, 2015 at 11:48 PM, Jonathan Toomim <j@toom.im> wrote:
>=20
> By contrast it does not reduce the safety factor for the UTXO set at
> all; which most hold as a much greater concern in general;

I don't agree that "most" hold UTXO as a much greater concern in =
general. I think that it's a concern that has been addressed less, which =
means it is a more unsolved concern. But it is not currently a =
bottleneck on block size. Miners can afford way more RAM than 1 GB, and =
non-mining full nodes don't need to store the UTXO in memory.I think =
that at the moment, block propagation time is the bottleneck, not UTXO =
size. It confuses me that SigWit is being pushed as a short-term fix to =
the capacity issue when it does not address the short-term bottleneck at =
all.

> and that
> isn't something you can say for a block size increase.

True.

I'd really like to see a grand unified cost metric that includes UTXO =
expansion. In the mean time, I think miners can use a bit more RAM.

> With respect to witness safety factor; it's only needed in the case of
> strategic or malicious behavior by miners-- both concerns which
> several people promoting large block size increases have not only
> disregarded but portrayed as unrealistic fear-mongering. Are you
> concerned about it?

Some. Much less than e.g. Peter Todd, for example, but when other people =
see something as a concern that I don't, I try to pay attention to it. I =
expect Peter wouldn't like the safety factor issue, and I'm surprised he =
didn't bring it up.

Even if I didn't care about adversarial conditions, it would still =
interest me to pay attention to the safety factor for political reasons, =
as it would make subsequent blocksize increases much more difficult. =
Conspiracy theorists might have a field day with that one...

> In any case-- the other improvements described in
> my post give me reason to believe that risks created by that
> possibility will be addressable.

I'll take a look and try to see which of the worst-case concerns can and =
cannot be addressed by those improvements.

--Apple-Mail=_1F7DEAD5-247D-46DA-AAC3-9EEC34D67150
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJWZ3iOAAoJEIEuMk4MG0P1g5QH/1uTzOINv+70CFXOGc0nKmAN
o78A78umVdtvovG946LulCeC3pvqr7iPjQHTBHOIJQbAfE21rhl6gzUk8vgmCXlY
uUGpoRVQzqIqpSE6OgXVIQ0orBrMrShC+Nd5n+Mt5MJ61ptcNZNSWVz3r2R/Xr1y
Pl6jz2nn1DFNbVrlwrQp1yxIpidQ7kQGPnBcrKSp/bsqd9oNH7eAcNLt8D0lDngV
eLkqjvZ6tK0EmliU3PFnj8oNJbUATueZPkHUpVVIigv5LY7busPS3bt8R5rkYChn
WQW+eyvtf9KV8FjIfmHpNNIHroDa247LdAMA6yNkFT8DwcB3mDwNo3dnDVgMrNI=
=W3Ds
-----END PGP SIGNATURE-----

--Apple-Mail=_1F7DEAD5-247D-46DA-AAC3-9EEC34D67150--