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 0C757C5F for ; 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 ; 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 In-Reply-To: Date: Wed, 9 Dec 2015 08:40:46 +0800 Message-Id: <411150E9-8811-43B9-8285-DC2EB3BD1C50@toom.im> References: <5F73C59C-7939-4937-839D-CA93880CB21F@toom.im> To: Gregory Maxwell 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > On Tue, Dec 8, 2015 at 11:48 PM, Jonathan Toomim 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--