Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CAA9971F for ; Sun, 11 Dec 2016 20:31:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A85D214B for ; Sun, 11 Dec 2016 20:31:07 +0000 (UTC) Received: by mail-oi0-f50.google.com with SMTP id y198so69808256oia.1 for ; Sun, 11 Dec 2016 12:31:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LpTighJAs8JsyxJhaR9P9JeWMfn3erNAPPruF2DIK6I=; b=WVrQLPqFMF34eaZzjY6PaIfdD2zLWoSCuVSCJ1f8U+pUEdtsWDOQz6orJVIdSh4J2W BRSGg9UM8McPcaHjfsDC05uSNtxX5/EBsbkgFZaRIilK30X2XjQMCt/w/+NBJZG/DIb2 YarsIocFP3xKPq/EDWFrWx6BjcZE9SZ71PGoRFwehR2xZMUmaKHs5uux9ZWBIXMNGvb2 2tzdg55QGa2HXCFWjlxi0ejH8pSsc2J+WKWZE2aeTIU0FPEcWuX7GVBxTlIF9SPf/aRj B/wHxwecfGsxazgheq+upSe9xzU2MbQwev8gqnWNrokMBpS7KTf2D2DJNOIytIiK04K0 94+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LpTighJAs8JsyxJhaR9P9JeWMfn3erNAPPruF2DIK6I=; b=as6dXtfUdx15afjNKQxWMIsbVh5JcPCKWLub0Mu9ph+9TmTCHXHm5bMVnGQ6t3ejFh Q0Wfr1VL65k/iWsRyrRUFqsWcJ19E+4xkBLog5JoPXXt+QIzNPdTvaL27w21A5HVWC59 dK/vtC1wOGhohHUYM+yxyp5sLy1b9GFmZzrTXTt44+9Onvo2Fb+RWRTzxK+NCrkHVygA jvig/WHa5TgbaDWVOfnMvuZtiXiVfFZ6nRQ7Y5xnpcCROpyKjYslkdRJtc1Uijh9QRWt 4nhZvPA86v5AWtdvKsXM7slJcNGMlD4uLJe3UGidgsP8CaZlpQliE51OnDIjJ9j+hfa3 Yjhg== X-Gm-Message-State: AKaTC033Hp3ARjRA5q//AyybfkdM3hgEve2QusdyG+qiADM+zVluZw9dZkO/Tq8Yiv9luNrbW+PeU8vY79cNwQ== X-Received: by 10.202.8.205 with SMTP id 196mr46970742oii.13.1481488266422; Sun, 11 Dec 2016 12:31:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.77.130 with HTTP; Sun, 11 Dec 2016 12:31:05 -0800 (PST) In-Reply-To: References: From: James Hilliard Date: Sun, 11 Dec 2016 14:31:05 -0600 Message-ID: To: "t. khan" , Bitcoin Protocol Discussion Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,URIBL_BLACK autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Managing block size the same way we do difficulty (aka Block75) 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: Sun, 11 Dec 2016 20:31:12 -0000 What's most likely to happen is miners will max out the blocks they mine simply to try and get as many transaction fees as possible like they are doing right now(there will be a backlog of transactions at any block size). Having the block size double every year would likely cause major problems and this proposal allows over a 7x increase it seems. The main problem with this proposal I think is that users effectively have no way to stop the miners from increasing block size continuously. On Sun, Dec 11, 2016 at 1:55 PM, t. khan via bitcoin-dev wrote: > > On Sun, Dec 11, 2016 at 12:11 PM, s7r wrote: >> >> >> This is an incentive, if few miners agree to create a large conglomerate >> that will ultimately control the network. >> >> You miss something obvious that makes this attack actually free of cost. >> Nothing will "cost them more in transaction fees". A miner can create >> thousands of transactions paying to himself, and not broadcast them to >> the network, but hold them and include them in the blocks he mines. The >> fees are collected by him because transactions are included in a block >> that he mined and the left amount is in another wallet of the same >> person. Repeat this continuously to fill blocks. > > > No, that wasn't overlooked. Miners could indeed stuff their own blocks for > free, but they can't stuff blocks mined by others for free. > > In the hypothetical scenario where there is a single mining pool which mines > most (if not all) of the blocks, we would have much larger problems than > their ability to raise the max block size gradually. Even if they were able > to fill 100% of the blocks for an entire year, the max block size for that > 2016 block period would be 7.25MB (not accounting for SegWit). After the > whole year they would have made no extra profit vs doing nothing. And as > soon as they stopped this scheme, block size would spring back to it's > natural level. > > The good news is, this scenario has never happened and even when we've come > remotely close (when ASICs first shipped), the situation was temporary. The > odds of this happening in the future and persisting long enough to have any > major effect with Block75 are very close to zero. > >> >> Topology and bandwidth speed / hash rate of the network cannot be >> controlled - if we make assumptions about these it might have terrible >> consequences. >> >> Even if we take in consideration that bandwidth will only grow and disk >> space will only cost less (which is not something we can safely assume, >> by the way) the hard limit max. block size cannot grow to unlimited >> value (even if the growth happens over time). There is also a validation >> cost in time for each block, for the health of the network any node >> should be able to download _and_ validate a block, before next block >> gets mined. >> >> You said in another post that a permanent solution is preferred, rather >> than kicking the can down the road. I fully agree, as well as many >> others reading this list, but the permanent solution doesn't necessarily >> have to be increasing the max block size dynamically. > > > Increasing *and* decreasing max block size dynamically. Block75 is > self-correcting, whereas any solution with hardcoded limits can't correct > without human intervention and would rely on our ability to predict the > future (which as you pointed out, we can't do). Therefore, any solution > that's not dynamic cannot be permanent. > > Additionally, the frequent and gradual changes in max block size would allow > us to see any consequences well in advance (years probably). > >> >> If you think about it the other way around, dynamically growing the max >> block size is also kicking the can down the road ... just without having >> to touch it and get dust on the boot ;) > > > Not having to touch it again = permanent solution. ;) > > It would be helpful if some others would run the numbers on how Block75 > would adjust the block size over time: > > new max block size = 1000kb + (average block size over last 2016 blocks - > 750kb) > > -t.k. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >