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 D13BD407 for ; Fri, 24 Jul 2015 14:09:15 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C7EA61DF for ; Fri, 24 Jul 2015 14:09:14 +0000 (UTC) Received: from mail-qg0-f54.google.com ([209.85.192.54]) by mrelay.perfora.net (mreueus001) with ESMTPSA (Nemesis) id 0MAvmU-1ZAyAH40U0-009xtU for ; Fri, 24 Jul 2015 16:09:14 +0200 Received: by qged69 with SMTP id d69so11095688qge.0 for ; Fri, 24 Jul 2015 07:09:13 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.96.80 with SMTP id j74mr1708807qge.43.1437746953341; Fri, 24 Jul 2015 07:09:13 -0700 (PDT) Received: by 10.96.226.68 with HTTP; Fri, 24 Jul 2015 07:09:13 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Jul 2015 07:09:13 -0700 Message-ID: From: Adam Back To: bitcoin-dev@lists.linuxfoundation.org Content-Type: text/plain; charset=UTF-8 X-Provags-ID: V03:K0:yKrAO5+0WbUw4f6ofK/eis8raVL9h8oyD1LHesXDyNHDIObyn7G qn+fhzj+Sro5/0PaCN9b0bQA8hPZy4b13CegqP5D768ubZZ10Mcz81bVcPfQIqJwlP77t65 oaoGgiulXqDebMT3x9UeSyZwHHqSlZEfzamvosOIo+rTHQnZG7tvDDrTfyFsIYf1FxnBYdW u7EULlykdSGvZxZNnLHwg== X-UI-Out-Filterresults: notjunk:1;V01:K0:Z9+5JMrNPIo=:PT76fviYmE2E001yIKe7Hf 98+CK9tdL886m1HGrCC26FXzrBXfAK7EysRi7rK6W1Sw9M7szVwDV8LuM57z0wvurwCTH13DZ Ff+mLsWM74UdGH/NFSi8e00X3W0UDIZNTMl8HxLfRdQmUF+d2mOcVaH+wGZI+1tBoe4V1z7hS /9R1BWgshDkghFIYwQXigiDhzrYNKUOd3tz8/XdJUIJh6e6x1XDxt05BVLzVAAqNDY+XnUlPv V8AxohIGdwaPZkZIrgQS4PsLQ7a9Z+aJTwao+Mfa4FzyzxeRuvsLEUlDWtbGG2zTnfJHlTsS3 hpfZeGvqj3VeezdtOPczKeaQmYmRHAMLK7MTgb3drrWL0mWGMJ12ZwzJ4qsZWOX/7dHdmg44X Bf2ZFc7Z2zPe0NpXlxUOqDOIlIkasG1DHKNBWkKgn+Mp5sh6ft1L7MYNotXYEZFzocKXNyQ1F yw1ZUc/6y1mO7eb7QAY7NwL8rEL5LAS/x4Hrb8r/ClEzBz+wjXPRO3hNOgk72pwlHo6xMKClI 4hyK4RmrTENSlQPrcPnf41aaAF52q5BZDFdff+5qRGUPEqi2Z44cguFDrKDvUpwA2NKQHmMER Hh5bcYq/zAOAzZjFiy5EkE+QA9TY2BIEuxgLtPMqaqZjJhqEKVVk0HaDYY2Q2YMxtzQ73d+eu zlbhAgEJ7jC7CUbkUYost6B/nBZ62tffrKt1j/bgseUDipg== X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_20,LOTS_OF_MONEY, 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 Subject: Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis 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: Fri, 24 Jul 2015 14:09:16 -0000 (Claim of large bitcoin ecosystem companies without full nodes) this says to me rather we have a need for education: I run a full node myself (intermittently), just for my puny collection of bitcoins. If I ran a business with custody of client funds I'd wake up in a cold sweat at night about the security and integrity of the companies full nodes, and reconciliation of client funds against them. However I'm not sure the claim is accurate ($30m funding and no full node) but to take the hypothetical that this pattern exists, security people and architects at such companies must insist on the company running their own full node to depend on and cross check from otherwise they would be needlessly putting their client's funds at risk. The crypto currency security standards document probably covers requirement for fullnode somewhere https://cryptoconsortium.github.io/CCSS/ - we need some kind of basic minimum bar standard for companies to aim for and this seems like a reasonable start! Reducing custody in my opinion should also be an aim eg 2 of 2 multisig + timelock seems like a more prudent approach, transaction throughput permitting. Right now exchange volume wouldnt fit on chain, once bitcoin scaling has improved, perhaps it can. I am optimistic that within a year Bitcoin scaling and decentralisation will look much better with current active work on decentralisation, layer 2 scaling solutions. As part of that I could see a modest blocksize increase to smooth out the transition to layer 2. In terms of a constructive discussion, I think it's interesting to talk about the root cause and solutions: decentralisation (more economically dependent full nodes, lower miner policy centralisation), more layer 2 work. People interested in scaling, if they havent, should go read the lightning paper, look at the github and participate in protocol or code work. I think realistically we can have this running inside of a year. That significantly changes the dynamic. Similarly a significant part of mining centralisation is artificial and work is underway that will improve that. What I mean about decentralisation is if decentralisation simple metrics were in a healthy place, it would be a simple conversation to make use of bandwidth improvements (in the range of 15%/year per Cisco numbers) to get more throughput. I do think flexcap is interesting as a way to add one more control variable such that we can have economically validated scaling. Pushing fees to zero and increasing centralisation to levels that weaken security with economically weak payments is probably not desirable. Without flexcap it seems the next best thing we can do is rely on miners to balance user utility against mining revenue, and it seems plausible that they would in extremis but to my mind there are factors suggesting this could be problematic incrementally: miners have not often been responsive to editing defaults, or reacting to security or soft-fork upgrades; miners may have some conflict of interest of users, eg they could use switching cost economics to optimise for miner profit at the expense of user utility, or attack each other in selfish-miner or other variants as miners are also pitted against each other while being held honest by economically dependent full nodes. Adam