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
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>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
Precedence: list


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