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 4AF23B2F for ; Thu, 30 Mar 2017 07:11:26 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253080.outbound.protection.outlook.com [40.92.253.80]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B9D8FAF for ; Thu, 30 Mar 2017 07:11:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1SoTi5R7xv/tobWQEAOHVBxDb540RImq8U5eGFBIvII=; b=nh0hFJVslxdHF8DJLdNTFAxvKLLXTb653qECEK402RE5Ezqb8Xa9UoY2I1siqyMfCDyQsXmOqQfSxwJFZ717UGr+jKmvmSN/D4W6pWV+iAvk0ctlz1+vi+YAzofW+onqCUVwbNTruV/4DWXsp61W+WAhov6tm22vt4UEwxtEl5YdNJ1S/+H+ompqIUwCF+DpT90hdA8YVz+tTI//wVbn7SjuRK82LzNP+Z1vjKOHyzQmTzdOiIvHxDxNbVPJ+JuByWaJjMTiwqnRTTKuO2h0HjXQjciJn7f0BbTRgJzJotsnx+KJw2S0TN7z1VjMVSe9dqCGN5s/1NSOK4TonpYIyg== Received: from PU1APC01FT039.eop-APC01.prod.protection.outlook.com (10.152.252.58) by PU1APC01HT185.eop-APC01.prod.protection.outlook.com (10.152.252.189) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.7; Thu, 30 Mar 2017 07:11:21 +0000 Received: from SINPR04MB1949.apcprd04.prod.outlook.com (10.152.252.60) by PU1APC01FT039.mail.protection.outlook.com (10.152.253.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1005.5 via Frontend Transport; Thu, 30 Mar 2017 07:11:21 +0000 Received: from SINPR04MB1949.apcprd04.prod.outlook.com ([10.141.116.153]) by SINPR04MB1949.apcprd04.prod.outlook.com ([10.141.116.153]) with mapi id 15.01.0991.022; Thu, 30 Mar 2017 07:11:21 +0000 From: Luv Khemani To: David Vorick , Jared Lee Richardson , Bitcoin Protocol Discussion Thread-Topic: [bitcoin-dev] Hard fork proposal from last week's meeting Thread-Index: AQHSqMNonQ4DjsxFiU+7a8C6k6bCq6GsRI2AgAAb7oCAAGkzLQ== Date: Thu, 30 Mar 2017 07:11:21 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; gmail.com; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:8ED8A085A3E967CC7496685A4320639FBD811C323B1D3B081ABA379CA44F8700; UpperCasedChecksum:5D5E927E1F3AC40C2F57F9C39D8B4D17D7345C8AC841F3645FBEF82476A51936; SizeAsReceived:8404; Count:42 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [it9R7jlWksJ44+trxL+8n5EVA8f8IFwO] x-microsoft-exchange-diagnostics: 1; PU1APC01HT185; 5:Ro00q3UWAp7XDON/KAnt3lNwHEocoRWPHacMhLQil6ikdTrTjE0SB90ucBbSUK76hnLS6nNfE/WCvxkfeajNm5fd1I2S5UTwdrBftllEdPWbMmJPomU8ZGqPHyCWhJeAWxGnPKntX7o9rUWWct/Uzg==; 24:ojehugImnFQWaJdhshY8fiAVDWUWPFI/i3fkWSpbC9X7urn1XR3iJdwB5z4ay9oCivZ/AsO8K6tHhPLmdQRtF+4KUC+Xb2orqIqFgSHGYn4=; 7:3pKg5UAh1iCsQAHKwEPCEysIT9qB5CkjKU64OvWdScvbn0RJp0ybVoeKop7pctIfIscLvkB849IB87aFccEK4Fsmj04fGfF/r3aQwqGc5aiimC57qP7R8llSfHibcnRchHoWX8RFMHpKb3xC29u70bb+BEpgskdU0tgiJUKQY2M/cIi+/VidpRCYrBWpVt+PafH9iXTbO1nTfZDRhyYwRnyk8ccJZBiMcFKTcQB/Rp8GD+UYkXqepeme+EXARE8EeaO5CloG3RpaC68adOqSqD7yTvgGX0TAsOXU3sd5jHuoEQushnc+2uE9uMn/6p4u x-incomingheadercount: 42 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:PU1APC01HT185; H:SINPR04MB1949.apcprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: e894460f-91a0-4ae9-2749-08d4773bf826 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322274)(1603101448)(1601125374)(1701031045); SRVR:PU1APC01HT185; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:PU1APC01HT185; BCL:0; PCL:0; RULEID:; SRVR:PU1APC01HT185; x-forefront-prvs: 02622CEF0A spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SINPR04MB1949AB581C6870184445E0C4C2340SINPR04MB1949apcp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2017 07:11:21.4727 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT185 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 X-Mailman-Approved-At: Thu, 30 Mar 2017 10:58:27 +0000 Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting 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: Thu, 30 Mar 2017 07:11:26 -0000 --_000_SINPR04MB1949AB581C6870184445E0C4C2340SINPR04MB1949apcp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >> If home users are not running their own full nodes, then home users have= to trust and rely on other, more powerful nodes to represent them. Of cour= se, the more powerful nodes, simply by nature of having more power, are goi= ng to have different opinions and objectives from the users. >I think you're conflating mining with node operation here. Node users onl= y power is to block the propagation of certain things. Since miners also h= ave a node endpoint, they can cut the node users out of the equation by lin= king with eachother directly - something they already do out of practicalit= y for propagation. Node users do not have the power to arbitrate consensus= , that is why we have blocks and PoW. You are only looking at technical aspects and missing the political aspect. Node users decide what a Bitcoin is. It matters not how much hash power is = behind a inflationary supply chain fork, full nodes protect the user from t= he change of any properties of Bitcoin which they do not agree with. The ab= ility to retain this power for users is of prime importance and is arguably= what gives Bitcoin most of it's value. Any increase in the cost to run a f= ull node is an increase in cost to maintain monetary sovereignty. The abili= ty for a user to run a node is what keeps the miners honest and prevents th= em from rewriting any of Bitcoin's rules. If it's still difficult to grasp the above paragraph, ask yourself the foll= owing questions, - What makes Bitcoin uncensorable - What gives confidence that the 21 million limit will be upheld - What makes transactions irreversible - If hashpower was king as you make it to be, why havn't miners making up m= ajority hashrate who want bigger blocks been able to change the blocksize? The market is not storing 10s of billions of dollars in Bitcoin despite all= it's risks because it is useful for everyday transactions, that is a solve= d problem in every part of the world (Cash/Visa/etc..). Having said that, i fully empathise with your view that increasing transact= ion fees might allow competitors to gain marketshare for low value use case= s. By all means, we should look into ways of solving the problem. But all t= hese debates around blocksize is a total waste of time. Even if we fork to = 2MB, 5MB, 10MB. It is irrelevant in the larger picture, transaction capacit= y will still be too low for global usage in the medium-long term. The addit= ional capacity from blocksize increases are linear improvements with very l= arge systemic costs compared with the userbase and usage which is growing e= xponentially. Lightning potentially offers a couple or orders of magnitude = of scaling and will make blocksize a non-issue for years to come. Even if i= t fails to live up to the hype, you should not discount the market innovati= ng solutions when there is money to be made. --_000_SINPR04MB1949AB581C6870184445E0C4C2340SINPR04MB1949apcp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


>> If home users a= re not running their own full nodes, then home users have to trust and rely= on other, more powerful nodes to represent them. Of course, the more powerful nodes, simply by nature of having more power, ar= e going to have different opinions and objectives from the users.

>I think you're conflating mining with node operation here.  Node u= sers only power is to block the propagation of certain things.  Since = miners also have a node endpoint, they can cut the node users out of the eq= uation by linking with eachother directly - something they already do out of practicality for propagation.  Node users do n= ot have the power to arbitrate consensus, that is why we have blocks and Po= W.

You are onl= y looking at technical aspects and missing the political aspect.

Node users = decide what a Bitcoin is. It matters not how much hash power is behind= a inflationary supply chain fork, full nodes protect the user from the change of any properties of Bitcoin which they do not ag= ree with. The ability to retain this power for users is of prime importance= and is arguably what gives Bitcoin most of it's value. Any increase in the= cost to run a full node is an increase in cost to maintain monetary sovereignty. The ability for a user to run a = node is what keeps the miners honest and prevents them from rewriting any o= f Bitcoin's rules.

If it's sti= ll difficult to grasp the above paragraph, ask yourself the following quest= ions,
- What make= s Bitcoin uncensorable
- What give= s confidence that the 21 million limit will be upheld
- What make= s transactions irreversible
- If hashpower was king as you make it to be, why havn't miners making up majority hashrate who want bigger bl= ocks been able to change the blocksize?

The market is not= storing 10s of billions of dollars in Bitcoin despite all it's risks = because it is useful for everyday transactions, that is a solved problem in every part of the world (Cash/Visa/etc..).&nbs= p;

Having said that,= i fully empathise with your view that increasing transaction fees might al= low competitors to gain marketshare for low value use cases. By all means, we should look into ways of solvin= g the problem. But all these debates around blocksize is a total waste= of time. Even if we fork to 2MB, 5MB, 10MB. It is irrelevant in the larger= picture, transaction capacity will still be too low for global usage in the medium-long term. The additional capaci= ty from blocksize increases are linear improvements with very large systemi= c costs compared with the userbase and usage which is growing exponent= ially. Lightning potentially offers a couple or orders of magnitude of scaling and will make blocksize a non-iss= ue for years to come. Even if it fails to live up to the hype, you should n= ot discount the market innovating solutions when there is money to be made.=

--_000_SINPR04MB1949AB581C6870184445E0C4C2340SINPR04MB1949apcp_--