Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1AE0F4A8 for ; Thu, 30 Jul 2015 16:48:21 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EE008F2 for ; Thu, 30 Jul 2015 16:48:19 +0000 (UTC) Received: from mail-qk0-f169.google.com ([209.85.220.169]) by mrelay.perfora.net (mreueus003) with ESMTPSA (Nemesis) id 0M3kt5-1Z3b8N4BNZ-00rGfq for ; Thu, 30 Jul 2015 18:48:19 +0200 Received: by qkfc129 with SMTP id c129so20131300qkf.1 for ; Thu, 30 Jul 2015 09:48:18 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.55.15.20 with SMTP id z20mr70615311qkg.16.1438274898215; Thu, 30 Jul 2015 09:48:18 -0700 (PDT) Received: by 10.96.226.68 with HTTP; Thu, 30 Jul 2015 09:48:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jul 2015 18:48:18 +0200 Message-ID: From: Adam Back To: Gavin Andresen Content-Type: text/plain; charset=UTF-8 X-Provags-ID: V03:K0:cSIhUvNBt8FA6ibFk0NYCa69f1QXN9TvrHPWupeW/o41J7dRGoQ 4e+2gOHLpBeBRw+ZlxtaQhyr68yLnNNXyWQXJ2jK/XatEoQrCSv+S1+vASvo3rh5fEs/02j lgxkMzbqy8vaz2QjHEtMV0Y6GY0xLwVHhdXEtE2uNf9t98mjO07x+UtWa/QmwEgxdH1NWFn GoAig8iG44dN2YYJK+b5g== X-UI-Out-Filterresults: notjunk:1;V01:K0:sjTwkGasLOg=:jJvdYS5Ir430X3gMoloOtR FIAY5hovqTTUgWe23wlfcIYeoQUfO0N4CBNEENhmZI0ZHBVOCTGkVQrOu8YPTXFmsNsZ47wOE lp1k04K4ucyrtdkkXydsDb86ULs3c+Qv59PIPZOijWWIKHkw1c683oaGJUci8b5BLAhLli79A KLVQUsNsao4HLjoXmE57lvF9j0H6zNauRkryBJ6ku66fMTAUkILOtT5g8KEdMJpW6NyTlXRup SaHAuXcZTqD1fr0sat5Aek0At8LYbI4ekKqHALMXgo5P1Oy4adpvfv0hcsZgnDiz1h2nK2WHl 2qfl0Q0pzsMwg6vBpfVDxS5b/Vz8qNV9avwba3sffLf5e+VK5XBkU++xQByO2FmU/CkR1zKRm vAcEfBhgB0ubO5pvajTOeUGGuAhpNypydTZlgPyB756uS960e46GTVXR61+GVHf299qDTnMdD 71I+rhsoZnTAxkjR+S1ekyDx4TzLJIpU9MgVr0wFLX2cbfFJvvDvZvHwobqy/xWQOkjKpHKg8 U+EKwg5qfzDFiJBM6fr60GK+LZh8JsWIXaBIBv9ie2M7IVd0ANRdJtoQA10wUVl9ySB4km6Dj +9iQFxB/dqQXGbgp3szBu7ZqdqxE6GTdg7ZoVg+277yKfnQHlgoTBdc0iENUpgLWGbj2/4fxJ mB4iJ5vUph79IOKJngH/QxongVNjMIkII/hWxS0m6mGuMbA== 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] Block size following technological growth 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: Thu, 30 Jul 2015 16:48:21 -0000 That's what is nice about proposals, they are constructive and help move the conversation forward! On 30 July 2015 at 18:20, Gavin Andresen via bitcoin-dev wrote: > Specific comments: > > So we'd get to 2MB blocks in the year 2021. I think that is much too > conservative, and the most likely effect of being that conservative is that > the main blockchain becomes a settlement network, affordable only for > large-value transactions. But, if we agree that 17%/year is consistent with network improvements, by arguing this is too conservative, does that not mean you are actually going beyond suggesting throughput increases to benefit from bandwidth improvements, and explicitly arguing to borrowing from Bitcoin's already very weak decentralisation to create more throughput? (Or arguing to subsidise transaction fees if borrowing so deeply that excess capacity pushes beyond demand). I think the logical implication of this would be that we should be first focussing on improving decentralisation, to make security room to reclaim extra throughput. (To be clear there are concrete things that can be done and actually are being done to improve decentralisation via ecosystem education and mining protocol improvements, but it's safer to wait a few months and see if those things take effect well). Secondly in this assumption are you considering that lightning will likely be online for many years by 2021 and the situation will be hugely different? I think an incremental and conservative approach is safer. People can probably get a lightning prototype running about as fast as a hard-fork could be safely rolled out. I do think it is normal to be conservative with security and with $4b of other peoples money. It's no longer an experimental system to consider fail fast experiments on. > I don't think your proposal strikes the right balance between centralization > of payments (a future where only people running payment hubs, big merchants, > exchanges, and wallet providers settle on the blockchain) and centralization > of mining. What criteria should we be using in your opinion to balance? I think throughput increases trading off decentralisation would be more reasonable if decentralisation wasnt in very bad shape. Adam