Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 832F4BBC for ; Sat, 27 Jun 2015 17:35:00 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148107.authsmtp.com (outmail148107.authsmtp.com [62.13.148.107]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id BD980198 for ; Sat, 27 Jun 2015 17:34:59 +0000 (UTC) Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5RHYtSR092071; Sat, 27 Jun 2015 18:34:55 +0100 (BST) Received: from muck (cpe-74-66-142-58.nyc.res.rr.com [74.66.142.58]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5RHYqNe039521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 27 Jun 2015 18:34:54 +0100 (BST) Date: Sat, 27 Jun 2015 13:34:51 -0400 From: Peter Todd To: Michael Naber Message-ID: <20150627173451.GA28181@muck> References: <20150627163731.GA12820@muck> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: X-Server-Quench: d2d6ddfd-1cf2-11e5-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR bgdMdAUUEkAaAgsB AmMbWlxeU1l7XGc7 bA5PawNDY05MQQBi T01BRU1TWkFtY2Ro R2BLUhp7cgdHNn93 bU5iECRZCEIuIRAp X08HQ28bZGY1bX1N U0leagNUcgZDfk5E bwQuUz1vNG8XDSg5 AwQ0PjZ0MThBHWx8 CjkXKkoVWksHVhU7 QggYGjAuBkBNWyJ7 MxwrYnQYG00Sen4z I1ZpfVMdMgN6 X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 74.66.142.58/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit 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: Sat, 27 Jun 2015 17:35:00 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 27, 2015 at 01:25:14PM -0400, Michael Naber wrote: > Global network consensus means that there is global network recognition > that a particular transaction has occurred and is irreversible. The > off-chain solutions you describe, while probably useful for other purpose= s, > do not exhibit this characteristic and so they are not global network > consensus networks. Hub-and-spoke payment channels and the Lightning network are not off-chain solutions, they are ways to more efficiently use on-chain transactions to achive the goal of moving assets from point a to point b, resulting in more economic transactions being done with fewer - but not zero! - blockchain transactions. Off-chain transaction systems such as Changetip allow economic transactions to happen with no blockchain transactions at all. > Bitcoin Core scales as O(N), where N is the number of transactions. Can we > do better than this while still achieving global consensus? No, Bitcoin the network scales with O(n^2) with your above criteria, as each node creates k transactions, thus each node has to verify k*n transactions, resulting in O(n^2) total work. For Bitcoin to have O(n) scaling you have to assume that the number of validation nodes doesn't scale with the number of users, thus resulting in a system where users trust others to do validation for them. That is not a global consensus system; that's a trust-based system. There's nothing inherently wrong with that, but why change Bitcoin itself into a trust-based system, when you can preserve the global consensus functionality, and built a trust-based system on top of it? --=20 'peter'[:-1]@petertodd.org 0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24 --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJVjt64XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwMDdmYzEzY2UwMjA3MmQ5Y2IyYTZkNTFmYWU0MWZlZmNk ZTdiM2IyODM4MDNkMjQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udy9Jgf/dtetQbJqUsfgeAGE8bzBn03H 1HlG6AhfgBiZNGytFB1hzPiWr1TOlXk+5l3cpTfdqKTS7BlorHCc5qVmiomVMlN6 1nUFhyK2kpjP7cKUfv10SVukMfl4NIa2DQDWcSQLpQ6NnlNIaJk07Fge0ayWo+gL mr8Rg3kQ+ePFFlUbiB0gWLGLU168mmhzPsWXiFsRw0wB0h7QngeFRvemWFG3e4yS 5aRTIGK15z9m1srElBHgEAP+gonLtZx7ucJCxCQVvShR4mBYK5t3bQw75eZribMJ zkKxZPPMJVV6MTh3zzWJtI8XwErLCJgcCXAFok3UnuNPqNjvq3wPXoWpyu41wg== =TXJW -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J--