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 E1B95305 for ; Sun, 28 Jun 2015 10:07:42 +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 420407C for ; Sun, 28 Jun 2015 10:07:42 +0000 (UTC) Received: from mail-qk0-f171.google.com ([209.85.220.171]) by mrelay.perfora.net (mreueus003) with ESMTPSA (Nemesis) id 0M56jI-1Yrutf1UtS-00zGuJ for ; Sun, 28 Jun 2015 12:07:41 +0200 Received: by qkbp125 with SMTP id p125so79741138qkb.2 for ; Sun, 28 Jun 2015 03:07:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.97.230 with SMTP id m93mr12793210qge.32.1435486060688; Sun, 28 Jun 2015 03:07:40 -0700 (PDT) Received: by 10.96.28.39 with HTTP; Sun, 28 Jun 2015 03:07:40 -0700 (PDT) In-Reply-To: References: Date: Sun, 28 Jun 2015 12:07:40 +0200 Message-ID: From: Adam Back To: Raystonn Content-Type: text/plain; charset=UTF-8 X-Provags-ID: V03:K0:q5OyrEI3PUQZwchtM68m9p+UjvNkd3O3QfXE9XuNafGQqWISDy8 OhrJPFd9/7dfr3mAuIre5p93PLcAb1SIuPQ8XGsmIGbLy5NvD0+7POWn7C1MnuXKSE74jhF h2UL2zj1Xr6bz6k6OzRIKXF6j1f8ZZMYRFfaC7tDrcXYsrS/GfxKHX+ymy0fdBTyRHKgygs /Wjkyk6Ejk4PYXHdoNt4A== X-UI-Out-Filterresults: notjunk:1;V01:K0:URop/dzh4R4=:bySirfa8+v0huxtIQWAHTH K6mOokrA/lO3f1GZFMLoBk5iyKsO0344G1o6rKovjUCa2clJ6Y3/3sqxkP+i4feA4pdCpfdDV bbWYYmmodIjmvCCjBa6ohPHxKVW6WtyiDtx3zmh4BAbjImwUCd4qXdoU0KoepDfcV+rAy1IGf NYNPaV8jYbtKyXP6Gd3EgoY/CVdxn8Soq2F4RqeT7ysvnNSBu7wCo6GiOhW3L6jM/3PMxYGsJ 9y57xewwIWkNwsArzHnAGAaMvFS9hirgo1dtScUFzUJzHUGGiw6KI56PSU4px96mYPx8SF/d0 MSkUCwFwVq5UVQzeIBn+WFqzUFchMsbgN6ZcUt7FbaZ4gxUSNrvCo8ntA6bIDGNT5Q5Iply+7 qAGbxMC58v4XNKbjVmJQaE/ea1pa6tG2wvA2wn1eixd/zOkfjXCC4exGk99QMeKUwNbPubPwb wjNdZ2Y8iONpHx7MVdxaQCnVJ9g73Nm/XbbZ7S7R+Q/+WceHhiwdwRsURN4+P2B36TMXutN7f oiLAMoN69Vq8jHdsUyi019thsU/XCziWa/kpnbQN+KBNTrIFNz98ti5h+O6I2ay6ZjleWS0RM 6gdiNopF3vKS77Dg/TGDril0hjnz7WtXiMbrJghIkz6CUEire3pqcURE0NG0ecH5fWInL4FEQ EUt78sj+Ov15rEH/4YWX18UpWSB/KCGqSZ6h6ApFsO0BPUQ== X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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 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: Sun, 28 Jun 2015 10:07:43 -0000 On 28 June 2015 at 07:34, Raystonn wrote: > nodes are limited to 133 connections. This is 8 outgoing connections and > 125 incoming connections. [...] Once your full node reaches 133 connections, > it will see no further increase in load [...] Only transaction rate will affect the > load on your node. The total system cost is more relevant, or total cost per user. I think you are stuck on the O( t * m ) t = tx, m = nodes thinking. Total cost per user is increasing. That better scaling algorithms need to be found. That's why people are working on lightning-like systems. > fear larger blocks based on an assumption of exponential growth of work, which just > isn't the case. People have been explaining quadratic system level increase, which is not exponential, wrong assumption. > Decentralisation is planned to scale down once the 133 connection limit is > hit. Like it or not, this is the current state of the code. No people are not assuming decentralisation would decrease. They are assuming the number of economically dependent full nodes would increase, that's where the O( n^2 ) comes from! If we assume say c= 0.1% of users will run full nodes, and users make some small-world assumed number of transactions that doesnt increase greatly as more users are added to the network, then O( t * m ) => O( n^2 ). Seeing decentralisation failing isn't a useful direction as Bitcoin depends on decentralisation for most of it's useful security properties. People running around saying great lets centralise Bitcoin and scale it, are not working on Bitcoin. They may more usefully go work on competing systems without proof of work as that's where this line of reasoning ends up. There are companies working on such things. Some of them support Bitcoin IOUs. Some of them have job openings. We can improve decentralisation, and use bandwidth and relay improvements to get some increase in throughput. But starting a direction of simplistic thinking about an ever increasing block-size mode of thinking is destructive and not Bitcoin. If you want to do that, you need to do it in an offchain system. You cant build on sand so your offchain system wont be useful if Bitcoin doesnt have reasonable decentralisation to retain useful meaning. Hence lightning. There are existing layer 2 things that have on-chain netting. Go work on one of those. But people need to understand the constraints and stop arguing to break Bitcoin to "scale". It's too simplistic. Even Gavin's proposal is not trying to do that, hence reference to Nielsen's law. His parameters are too high for too long for basic safety or prudence, but the general idea to reclaim some throughput from network advances, is reasonable. Also decentralisation is key, and that is something we can improve with pooling protocols to phase out the artificial centralisation. We can also educate people to use fullnode they economically depend on to keep the full to SPV ratio reasonable which is also needed for security. Adam