X-List-Received-Date: Mon, 17 Aug 2015 09:44:56 -0000 --001a1137949e612dbb051d7ea764 Content-Type: text/plain; charset=UTF-8 I have tried to solve the maximum block size debate, depending on the previous block size calculation. Requesting for comment - http://upalc.com/maxblocksize.php --001a1137949e612dbb051d7ea764 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I have tried = to solve the maximum block size debate, depending on the previous block siz= e calculation.

Requesting for comment -=C2=A0http:/= /upalc.com/maxblocksize.php

--001a1137949e612dbb051d7ea764-- 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 8693874 for ; Mon, 17 Aug 2015 09:54:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3AA95AB for ; Mon, 17 Aug 2015 09:54:11 +0000 (UTC) Received: by lbcbn3 with SMTP id bn3so78211282lbc.2 for ; Mon, 17 Aug 2015 02:54:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=dVV4EwLuy5Ny0KSAjwZ4VJSCdpKVzPuOc+NBhzn1SwI=; b=C933dyP6mU8pwKMNuyj4lrOkvwq2oVn3kdwOik4nx+UF/7T3xHlwUaE03FaFzsTZ53 TJyc5v469YCQOslDBmAuhOiF9uNbeuj6ct7WbPOT0XPSf1r7UTxVNI6OJAWfOKWrZ0in 6WtcVIu7ofRXPkEQjqxIZh8AxG0DnjgjRQlOvN6/xfBd1hZ59jmv+JQbn5F7X63Svpfa nNWgqjrUe5M15ikXhchcq58qE3Oy9bRtN1MopXqBLFz8qTEvRxerIqEMCbzjxQIOX9lw NXwiSk7MDq71eOA+aqDEIk4cn5fKX1mG2/GEBXpVPyR0KSMQYQnee5thWpx9UVt4wbQR 1yTg== X-Gm-Message-State: ALoCoQmU7k4Rk83JYEDenzqq/rFnkGmG4gZBBF8/3pv7D3zTOodipB4n4OyP6BCht7PQoWV/5ria X-Received: by 10.112.147.201 with SMTP id tm9mr484546lbb.40.1439805249690; Mon, 17 Aug 2015 02:54:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Levin Keller Date: Mon, 17 Aug 2015 09:54:00 +0000 Message-ID: To: Upal Chakraborty , bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=047d7b34391a743aec051d7ec8e0 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, 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] Dynamically Controlled Bitcoin Block Size Max Cap 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: Mon, 17 Aug 2015 09:54:12 -0000 --047d7b34391a743aec051d7ec8e0 Content-Type: text/plain; charset=UTF-8 Interesting. I am writing down something similar. Will share soon. Upal Chakraborty via bitcoin-dev schrieb am Mo., 17. Aug. 2015 um 11:45 Uhr: > I have tried to solve the maximum block size debate, depending on the > previous block size calculation. > > Requesting for comment - http://upalc.com/maxblocksize.php > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --047d7b34391a743aec051d7ec8e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Interesting. I am writing down something similar. Will sha= re soon.

Upal Chakrabo= rty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> schrieb am Mo., 17. Aug= . 2015 um 11:45=C2=A0Uhr:

I have tried to solve= the maximum block size debate, depending on the previous block size calcul= ation.

Reques= ting for comment -=C2=A0http://upalc.com= /maxblocksize.php
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--047d7b34391a743aec051d7ec8e0-- 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 A565774 for ; Mon, 17 Aug 2015 09:59:22 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9DDDCE8 for ; Mon, 17 Aug 2015 09:59:21 +0000 (UTC) Received: by pacgr6 with SMTP id gr6so105461568pac.2 for ; Mon, 17 Aug 2015 02:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type; bh=RZtsQOb4adRXGNxeTbWqcP64qm8ZmhrsHSQHsFkE8fw=; b=iefST+8uVeowIfF6EURVG9m8ZvLzglvgZ7FMqJFXOrLELNJpsCOMBZGjDzzzO060LG OUfsGgRh44uf7It08trtb3DaELwXM8S3hi05D+gAx+1nULn1WzsSuTTgojGCPll7Ict0 gKIsbVtg9nw+Ns/L6WGD6w8XrgZBNYtlB7IzOMdtM43E3QY/f37z7XJyjoVpHWRaaLnu +61PwwtWlEyVbFz3hz4EiY5PWQPhp8Dg9ugsPQyUGCKXK0yJvmA6OQcrTlAFqR9XRs6s Y0IKLJzkSRc4/jNFRyp9mM7y3gDdqEGZJWkkOioAHeqLF/inZQnLQwdQhm09GffNI33U 009w== X-Received: by 10.66.253.229 with SMTP id ad5mr1085278pad.101.1439805561177; Mon, 17 Aug 2015 02:59:21 -0700 (PDT) Received: from [10.45.134.112] (c-67-188-9-126.hsd1.ca.comcast.net. [67.188.9.126]) by smtp.googlemail.com with ESMTPSA id pf10sm14164862pac.43.2015.08.17.02.59.20 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2015 02:59:20 -0700 (PDT) Message-ID: <55D1B077.6070208@gmail.com> Date: Mon, 17 Aug 2015 02:59:19 -0700 From: Patrick Strateman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: bitcoin-dev@lists.linuxfoundation.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030605060509050902020905" X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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] Dynamically Controlled Bitcoin Block Size Max Cap 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: Mon, 17 Aug 2015 09:59:22 -0000 This is a multi-part message in MIME format. --------------030605060509050902020905 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Nobody is going to click that... On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote: > I have tried to solve the maximum block size debate, depending on the > previous block size calculation. > > Requesting for comment - http://upalc.com/maxblocksize.php > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --------------030605060509050902020905 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Nobody is going to click that...

On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote:

I have tried to solve the maximum block size debate, depending on the previous block size calculation.

Requesting for comment - http://upalc.com/maxblocksize.php
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--------------030605060509050902020905-- 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 6EF0E259 for ; Mon, 17 Aug 2015 10:51:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yk0-f176.google.com (mail-yk0-f176.google.com [209.85.160.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A8976E8 for ; Mon, 17 Aug 2015 10:51:46 +0000 (UTC) Received: by ykdt205 with SMTP id t205so122418067ykd.1 for ; Mon, 17 Aug 2015 03:51:46 -0700 (PDT) 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:content-type; bh=tKTE0LSQoFuFbdXmrnY10wrpWPMvPoJubWAetibu0A8=; b=ifcqggvRB8fK8/khkEOi/Ra117B2zXUHjR7S1QhiRh/7cVDTUN4xNRqMShlJHyzCJd lbJ4s7mML4BrgdnkDDYEuP0nNRgJpqTakvyjJAfvqDBQZ8EHVofMyf3bwNQbuhOCqzIu HJvrPWGpC6WIVE/Ec0HAugUAyY+iShF6oHqcGn8kEiMDZm9AKa1aTPdNv+5Cq5+QCKXj AYarflnGiTDDSdQeMpio4E9RoJvnQhgbt1PugoJdxWI+kH7p5sMK8Rerb5P+65rk6Q/g fScJ0t9xlr8EZTxHB4/fmgjW37ppMcYSP1nLVg293BYsdVcH+IjqA2XsKX/F8H53H5BC /5PA== X-Received: by 10.13.254.1 with SMTP id o1mr682569ywf.88.1439808705871; Mon, 17 Aug 2015 03:51:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.94.132 with HTTP; Mon, 17 Aug 2015 03:51:26 -0700 (PDT) In-Reply-To: <55D1B077.6070208@gmail.com> References: <55D1B077.6070208@gmail.com> From: Btc Drak Date: Mon, 17 Aug 2015 11:51:26 +0100 Message-ID: To: Patrick Strateman Content-Type: multipart/alternative; boundary=94eb2c0809f4754534051d7f96b4 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, HK_RANDOM_FROM, HTML_MESSAGE, HTML_OBFUSCATE_05_10, RCVD_IN_DNSWL_LOW autolearn=no 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] Dynamically Controlled Bitcoin Block Size Max Cap 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: Mon, 17 Aug 2015 10:51:48 -0000 --94eb2c0809f4754534051d7f96b4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Nobody is going to click that... I guess I am nobody. Here's a copy of the text:- *Dynamically Controlled Bitcoin Block Size Max Cap * *Assumption*: This article is for those, who already understand the bitcoin protocol and aware of the block size controversy. Details of the problem statement can be found in BIP 100 . Satoshi's opinion regarding block size can be found here . I will = be directly going into the solution without explaining the problem in details. *Solution*: Difficulty changes at every 2016 block, i.e. at every 2016 block each full node does a calculation to find the next target. We will do just another calculation here. Nodes will also calculate what % of blocks in the last difficulty period is higher than 90% of the maximum block size, which is 1 MB for now. If it is found that more than 90% blocks in the last difficulty period is higher than 90% of the maximum block size, then double the maximum block size. If not, then calculate what % of blocks in the last difficulty period is less than 50% of the maximum block size. If it is higher than 90%, then half the maximum block size. If none of the above condition satisfies, keep the maximum block size as it is. Please note that, while calculating the % of blocks, it is better to take into account the first 2000 of the 2016, than the whole of 2016. This helps to avoid the calculation mistake if some of the last few blocks get orphaned. *Reasoning*: This solution is derived directly from the indication of the problem. If transaction volume increases, then we will naturally see bigger blocks. On the contrary, if there are not enough transaction volume, but maximum block size is high, then only few blocks may sweep the mempool. Hence, if block size is itself taken into consideration, then maximum block size can most rationally be derived. Moreover, this solution not only increases, but also decreases the maximum block size, just like difficulty. *Other Solutions of this Problem*:- Making Decentralized Economic Policy - by Jeff Garzik Elastic block cap with rollover penalties =E2=80=93 by Meni Rosen= feld Increase maximum block size - by Gavin Andresen Block size following technological growth - by Pieter Wuille The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments - by Joseph Poon & Thaddeus Dryja Please share your opinion regarding this solution below. For mail communication, feel free to write me at bitcoin [at] upalc.com. > On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote: > > I have tried to solve the maximum block size debate, depending on the > previous block size calculation. > > Requesting for comment - http://upalc.com/maxblocksize.php > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --94eb2c0809f4754534051d7f96b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bi= tcoin-dev <bitc= oin-dev@lists.linuxfoundation.org> wrote:
> Nobody is going to= click that...

I guess I am nobody. Here's a copy of the text:-<= br>

Dynamically Controlled Bitcoin Block Size M= ax Cap=C2=A0

Assumption: This article is f= or those, who already understand the bitcoin protocol and aware of the bloc= k size controversy. Details of the problem statement can be found in=C2=A0<= a href=3D"http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf"= target=3D"_blank">BIP 100. Satoshi's opinion regarding block size = can be found=C2=A0here. I will be directly going in= to the solution without explaining the problem in details.

So= lution: Difficulty changes at every 2016 block, i.e. at every 2016 bloc= k each full node does a calculation to find the next target. We will do jus= t another calculation here. Nodes will also calculate what % of blocks in t= he last difficulty period is higher than 90% of the maximum block size, whi= ch is 1 MB for now. If it is found that more than 90% blocks in the last di= fficulty period is higher than 90% of the maximum block size, then double t= he maximum block size. If not, then calculate what % of blocks in the last = difficulty period is less than 50% of the maximum block size. If it is high= er than 90%, then half the maximum block size. If none of the above conditi= on satisfies, keep the maximum block size as it is.

Please note that= , while calculating the % of blocks, it is better to take into account the = first 2000 of the 2016, than the whole of 2016. This helps to avoid the cal= culation mistake if some of the last few blocks get orphaned.

Reasoning: This solution is derived directly from the indication of th= e problem. If transaction volume increases, then we will naturally see bigg= er blocks. On the contrary, if there are not enough transaction volume, but= maximum block size is high, then only few blocks may sweep the mempool. He= nce, if block size is itself taken into consideration, then maximum block s= ize can most rationally be derived. Moreover, this solution not only increa= ses, but also decreases the maximum block size, just like difficulty.

Other Solutions of this Problem:-

M= aking Decentralized Economic Policy=C2=A0- by Jeff Garzik

E= lastic block cap with rollover penalties=C2=A0=E2=80=93 by Meni Rosenfe= ld

Increase maximum block size=C2=A0- by Gavin= Andresen

Block size following technological growth=C2=A0- = by Pieter Wuille=C2=A0

The Bitcoin Lightning Network: Scala= ble Off-Chain Instant Payments=C2=A0- by Joseph Poon & Thaddeus Dry= ja=C2=A0

Please share your opinion regarding this solution below= . For mail communication, feel free to write me at bitcoin [at] upalc.com.

> = On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote:
>
= > I have tried to solve the maximum block size debate, depending on the<= br>> previous block size calculation.
>
> Requesting for com= ment - http://upalc.com/maxbl= ocksize.php
>
>
> ___________________________________= ____________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> ________________________________________= _______
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>

--94eb2c0809f4754534051d7f96b4-- 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 817D29C for ; Mon, 17 Aug 2015 11:57:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8B85117F for ; Mon, 17 Aug 2015 11:57:48 +0000 (UTC) Received: by igxp17 with SMTP id p17so53720604igx.1 for ; Mon, 17 Aug 2015 04:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gq0+4hcY5NFNGvxQE8RLDHH5IDeJV6bXC51yKXy/P6k=; b=lfus97CIbtygvZmJqj7Wc2rDk+9E0JNvsthkQzU/NXIpcJfI+BNPbnsTHFWCrVV9H6 76whCyZDZrs/x5dnsu8aTBLxIaDNdZ23m3aaEHPluI5HFaUz0zkF87ikLwxyVGFvR+mU 4DBTfhuSoLfxO0/MGZbupNzA88TcqsKlLLPXwrjsCGUKIsBw6Fp6+lGiEFG3Nuy66Zvt TlWDvngsdq3G6IT0X6PkX/+tYfTNgH+jR47CFGb0ovPNztHoWeVaVub/gZ76J6KVVXbu QuwI+xTsh+9xCW7tShDwdGxmJS5ELLdOErxyoXoAIb4xZxh5MkZ5CEnOl5jZZvOGuVEK GjzQ== MIME-Version: 1.0 X-Received: by 10.50.7.35 with SMTP id g3mr15557781iga.39.1439812667943; Mon, 17 Aug 2015 04:57:47 -0700 (PDT) Received: by 10.79.22.198 with HTTP; Mon, 17 Aug 2015 04:57:47 -0700 (PDT) Date: Mon, 17 Aug 2015 21:57:47 +1000 Message-ID: From: Rodney Morris To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=089e0122eda89db35a051d8082c6 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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] Dynamically Controlled Bitcoin Block Size Max Cap 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: Mon, 17 Aug 2015 11:57:49 -0000 --089e0122eda89db35a051d8082c6 Content-Type: text/plain; charset=UTF-8 Words cannot capture how much I wish Satoshi had put logic like this (or even just a simple block size doubling every reward halving) in place when he put in the "temporary" 1MB anti-spam block size limit... I see problems to this approach. The biggest one I see is that a miner with 11% of hash power could sabotage block size increases by only ever mining empty blocks. I haven't run any statistics or simulations, but I'm concerned that the interplay between the random distribution of transaction arrival and the random distribution of block times may lead to false signals. A 90% full block 1 minute after the previous block is a more "serious" problem than a 90% full block 30 minutes after the previous block. A 90% full block after a 90% full block is a more "serious" problem than a 90% full block after an empty block. I would expect a robust approach in this manner to look at block sizes weighted by block times, but this is an interesting proposal regardless. But I think you'll run up against one of the great schisms in this debate - those that believe blocks should always be full (or close to it), to encourage a "fee market" and to encourage off-chain transactions, and those that think that the blockchain should be useable by almost anyone for almost anything, implying there should always be spare space in blocks, with off-chain transactions reserved for microtransactions and zero-conf (and possibly low-fee transactions). At least, that's my take on it. Rodney > > > Date: Mon, 17 Aug 2015 11:51:26 +0100 > From: Btc Drak > To: Patrick Strateman > Cc: Bitcoin Dev > Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size > Max Cap > Message-ID: > vVyw@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Nobody is going to click that... > > I guess I am nobody. Here's a copy of the text:- > > *Dynamically Controlled Bitcoin Block Size Max Cap > * > > *Assumption*: This article is for those, who already understand the bitcoin > protocol and aware of the block size controversy. Details of the problem > statement can be found in BIP 100 > . > Satoshi's opinion regarding block size can be found here > . I will > be > directly going into the solution without explaining the problem in details. > > > *Solution*: Difficulty changes at every 2016 block, i.e. at every 2016 > block each full node does a calculation to find the next target. We will do > just another calculation here. Nodes will also calculate what % of blocks > in the last difficulty period is higher than 90% of the maximum block size, > which is 1 MB for now. If it is found that more than 90% blocks in the last > difficulty period is higher than 90% of the maximum block size, then double > the maximum block size. If not, then calculate what % of blocks in the last > difficulty period is less than 50% of the maximum block size. If it is > higher than 90%, then half the maximum block size. If none of the above > condition satisfies, keep the maximum block size as it is. > > Please note that, while calculating the % of blocks, it is better to take > into account the first 2000 of the 2016, than the whole of 2016. This helps > to avoid the calculation mistake if some of the last few blocks get > orphaned. > > > *Reasoning*: This solution is derived directly from the indication of the > problem. If transaction volume increases, then we will naturally see bigger > blocks. On the contrary, if there are not enough transaction volume, but > maximum block size is high, then only few blocks may sweep the mempool. > Hence, if block size is itself taken into consideration, then maximum block > size can most rationally be derived. Moreover, this solution not only > increases, but also decreases the maximum block size, just like difficulty. > > > *Other Solutions of this Problem*:- > > Making Decentralized Economic Policy > - by > Jeff Garzik > > Elastic block cap with rollover penalties > ? by Meni Rosenfeld > > Increase maximum block size > - by > Gavin > Andresen > > Block size following technological growth > - by Pieter Wuille > > The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments > - by Joseph Poon & > Thaddeus Dryja > > > Please share your opinion regarding this solution below. For mail > communication, feel free to write me at bitcoin [at] upalc.com. > > --089e0122eda89db35a051d8082c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Words cannot capture how much I wish Satoshi had put logic like this (or e= ven just a simple block size doubling every reward halving) in place when h= e put in the "temporary" 1MB anti-spam block size limit...

<= div>

I see problems to this approach.=C2=A0 The biggest one I= see is that a miner with 11% of hash power could sabotage block size incre= ases by only ever mining empty blocks.

I haven'= ;t run any statistics or simulations, but I'm concerned that the interp= lay between the random distribution of transaction arrival and the random d= istribution of block times may lead to false signals.

<= div>A 90% full block 1 minute after the previous block is a more "seri= ous" problem than a 90% full block 30 minutes after the previous block= .=C2=A0 A 90% full block after a 90% full block is a more "serious&quo= t; problem than a 90% full block after an empty block.

I would expect a robust approach in this manner to look at block sizes= weighted by block times, but this is an interesting proposal regardless.

But I think you'll run up against one of the gr= eat schisms in this debate - those that believe blocks should always be ful= l (or close to it), to encourage a "fee market" and to encourage = off-chain transactions, and those that think that the blockchain should be = useable by almost anyone for almost anything, implying there should always = be spare space in blocks, with off-chain transactions reserved for microtra= nsactions and zero-conf (and possibly low-fee transactions).=C2=A0 At least= , that's my take on it.

Rodney

<= /div>

=C2=A0

Date: Mon, 17 Aug 2015 11:51:26 +0100
From: Btc Drak <btcdrak@gmail.com>
To: Patrick Strateman <pa= trick.strateman@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Max Cap
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CADJgMzvV7cSW9aBnAf5zX7FDxN5E=3DAW=3DrET2i9= EnysLao=3DvVyw@mail.gmail.com>= ;
Content-Type: text/plain; charset=3D"utf-8"

On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev < bitcoin-dev@lists.= linuxfoundation.org> wrote:
> Nobody is going to click that...

I guess I am nobody. Here's a copy of the text:-

*Dynamically Controlled Bitcoin Block Size Max Cap
<http://upalc.com/maxblocksize.php>*

*Assumption*: This article is for those, who already understand the bitcoin=
protocol and aware of the block size controversy. Details of the problem statement can be found in BIP 100
<http://gtf.org/garzik/bitcoin/BI= P100-blocksizechangeproposal.pdf>.
Satoshi's opinion regarding block size can be found here
<https://bitcointalk.org/index.ph= p?topic=3D1347.msg15366#msg15366>. I will be
directly going into the solution without explaining the problem in details.=

*Solution*: Difficulty changes at every 2016 block, i.e. at every 2016
block each full node does a calculation to find the next target. We will do=
just another calculation here. Nodes will also calculate what % of blocks in the last difficulty period is higher than 90% of the maximum block size,=
which is 1 MB for now. If it is found that more than 90% blocks in the last=
difficulty period is higher than 90% of the maximum block size, then double=
the maximum block size. If not, then calculate what % of blocks in the last=
difficulty period is less than 50% of the maximum block size. If it is
higher than 90%, then half the maximum block size. If none of the above
condition satisfies, keep the maximum block size as it is.

Please note that, while calculating the % of blocks, it is better to take into account the first 2000 of the 2016, than the whole of 2016. This helps=
to avoid the calculation mistake if some of the last few blocks get
orphaned.

*Reasoning*: This solution is derived directly from the indication of the problem. If transaction volume increases, then we will naturally see bigger=
blocks. On the contrary, if there are not enough transaction volume, but maximum block size is high, then only few blocks may sweep the mempool.
Hence, if block size is itself taken into consideration, then maximum block=
size can most rationally be derived. Moreover, this solution not only
increases, but also decreases the maximum block size, just like difficulty.=

*Other Solutions of this Problem*:-

Making Decentralized Economic Policy
<http://gtf.org/garzik/bitcoin/BI= P100-blocksizechangeproposal.pdf> - by
Jeff Garzik

Elastic block cap with rollover penalties
<https://bitcointalk.org/index.php?topic=3D10785= 21> ? by Meni Rosenfeld

Increase maximum block size
<https://github.com/bitcoin/bips/bl= ob/master/bip-0101.mediawiki> - by Gavin
Andresen

Block size following technological growth
<https://gist.github.com/sipa/c65665fc360ca7a176= a6> - by Pieter Wuille

The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments
<https://lightning.network/lightning-netwo= rk-paper.pdf> - by Joseph Poon &
Thaddeus Dryja

Please share your opinion regarding this solution below. For mail
communication, feel free to write me at bitcoin [at] upalc.com.

--089e0122eda89db35a051d8082c6-- 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 46D0E7AE for ; Mon, 17 Aug 2015 12:38:27 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2407E63 for ; Mon, 17 Aug 2015 12:38:26 +0000 (UTC) Received: by igxp17 with SMTP id p17so54498923igx.1 for ; Mon, 17 Aug 2015 05:38:25 -0700 (PDT) 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:content-type; bh=GPfg9ikBCaWS9FitScm8p3rkunpSuvKS+1+HbYoQGFE=; b=tLciiBJmI1kHsDi1Zs9wm9n9GmF1u1RFD4AQaGgRc9N/oU2tx4O4qsPb5J97I7YNQg 63NyWCcbP8OKeTA1WyPb6ECTfD3gr1NxflzHBeMUv5wzokE6RGFDYAGExMRlx+RFyWHx ex0HzQhSFzx0sBPGnIgZgdqYFGFwpNPueC2iBHkfJCgpTBt0mrnmaKaANqj3f/qWBHC1 Ewr4Smrn3+ijJtfQbJ+kviOXLW0qrI8NCjNLJkt14soq/HZ4uBDich7ALjoVN7SZsdYJ ayRmcyJqfu2ESrFK9EG2q1SaD05gmfRw++atmeYsJt53mgtUzm2IRWH+9Exo23/8vf3L ELGA== X-Received: by 10.50.109.233 with SMTP id hv9mr17094519igb.92.1439815105523; Mon, 17 Aug 2015 05:38:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.122.144 with HTTP; Mon, 17 Aug 2015 05:38:06 -0700 (PDT) In-Reply-To: References: From: Angel Leon Date: Mon, 17 Aug 2015 08:38:06 -0400 Message-ID: To: Rodney Morris Content-Type: multipart/alternative; boundary=089e0122e6bce838c1051d81138a X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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] Dynamically Controlled Bitcoin Block Size Max Cap 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: Mon, 17 Aug 2015 12:38:27 -0000 --089e0122e6bce838c1051d81138a Content-Type: text/plain; charset=UTF-8 I've been sharing a similar solution for the past 2 weeks. I think 2016 blocks is too much of a wait, I think we should look at the mean block size during the last 60-120 minutes instead and avert any crisis caused by transactional spikes that could well be caused by organic use of the network (Madonna sells her next tour tickets on Bitcoin, OpenBazaar network starts working as imagined, XYZ startup really kicks ass and succeeds in a couple of major cities with major PR push) Pseudo code in Python https://gist.github.com/gubatron/143e431ee01158f27db4 My idea stems from a simple scalability metric that affects real users and the desire to use Bitcoin: Waiting times to get your transactions confirmed on the blockchain. Anything past 45mins-1 hour should be unnacceptable. Initially I wanted to measure the mean time for the transactions in blocks to go from being sent by the user (initial broadcast into mempools) until the transaction was effectively confirmed on the blockchain, say for 2 blocks (acceptable 15~20mins) When blocks get full, people start waiting unnaceptable times for their transactions to come through if they don't adjust their fees. The idea is to avoid that situation at all costs and keep the network churning to the extent of its capabilities, without pretending a certain size will be right at some point in time, nobody can predict the future, nobody can predict real organic usage peaks on an open financial network, not all sustained spikes will come from spammers, they will come from real world use as more and more people think of great uses for Bitcoin. I presented this idea to measure the mean wait time for transactions and I was told there's no way to reliably meassure such a number, there's no consensus when transactions are still in the mempool and wait times could be manipulated. Such an idea would have to include new timestamp fields on the transactions, or include the median wait time on the blockheader (too complex, additional storage costs) This is an iteration on the next thing I believe we can all agree is 100% accurately measured, blocksize. Full blocks are the cause why many transactions would have to be waiting in the mempool, so we should be able to also use the mean size of the blocks to determine if there's a legitimate need to increase or reduce the maximum blocksize. The idea is simple, If blocks are starting to get full past a certain threshold then we double the blocksize limit starting the next block, if blocks remain within a healthy bound, transaction wait times should be as expected for everyone on the network, if blocks are not getting that full and the mean goes below a certain threshold then we half the maximum block size allowed until we reach the level we need. Similar to what we do with hashing difficulty, it's something you can't predict, therefore no fixed limits, or predicted limits should be established. --089e0122e6bce838c1051d81138a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I= 9;ve been sharing a similar solution for the past 2 weeks. I think 2016 blo= cks is too much of a wait, I think we should look at the mean block size du= ring the last 60-120 minutes instead and avert any crisis caused by transac= tional spikes that could well be caused by organic use of the network (Mado= nna sells her next tour tickets on Bitcoin, OpenBazaar network starts worki= ng as imagined, XYZ startup really kicks ass and succeeds in a couple of ma= jor cities with major PR push)

Pseudo code in Python
https://gist.github.c= om/gubatron/143e431ee01158f27db4

My idea stems from a simple sca= lability metric that affects real users and the desire to use Bitcoin:

Waiting times to get your transactions confirme= d on the blockchain.=C2=A0

Anything past 45= mins-1 hour should be unnacceptable.

Initially I wanted to measure the mean time = for the transactions in blocks to go from being sent by the user

(initial broadcast into mempools) until the transacti= on was effectively=C2=A0

confirmed on the b= lockchain, say for 2 blocks (acceptable 15~20mins)

When blocks get full, people s= tart waiting unnaceptable times for their transactions to come through=C2= =A0

if they don't adjust their fees. Th= e idea is to avoid that situation at all costs and keep the network

churning to the extent of its capabilities, withou= t pretending a certain size will be right at some=C2=A0

point in time, nobody can predict the future, nobody can predi= ct real organic usage peaks=C2=A0

on an ope= n financial network, not all sustained spikes will come from spammers,=C2= =A0

they will come from real world use as m= ore and more people think of great uses for Bitcoin.

I presented this idea to mea= sure the mean wait time for transactions and I was told=C2=A0

there's no way to reliably meassure such a number, t= here's no consensus when transactions are still=C2=A0

in the mempool and wait times could be manipulated. Such a= n idea would have to include new timestamp fields=C2=A0

on the transactions, or include the median wait time on the bl= ockheader (too complex, additional storage costs)

This is an iteration on the nex= t thing I believe we can all agree is 100% accurately measured, blocksize.<= /div>

Full blocks are the cause why many transact= ions would have to be waiting in the mempool, so we should be able

to also use the mean size of the blocks to determin= e if there's a legitimate need to increase or reduce the=C2=A0

maximum blocksize.

The idea is simple, If blocks are star= ting to get full past a certain threshold then we double the blocksize=C2= =A0

limit starting the next block, if block= s remain within a healthy bound, transaction wait times should be as=C2=A0<= /div>

expected for everyone on the network, if bl= ocks are not getting that full and the mean goes below a certain=C2=A0

threshold then we half the maximum block size a= llowed until we reach the level we need.

Si= milar to what we do with hashing difficulty, it's something you can'= ;t predict, therefore no fixed limits,=C2=A0

or predicted limits should be established.

--089e0122e6bce838c1051d81138a-- 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 AF9E5409 for ; Mon, 17 Aug 2015 12:43:47 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com [209.85.220.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5679663 for ; Mon, 17 Aug 2015 12:43:47 +0000 (UTC) Received: by qkcs67 with SMTP id s67so45899873qkc.1 for ; Mon, 17 Aug 2015 05:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=AUXFvkDnttwV9mK9Pj2D3nEZtzgEh6NR1P3gaPW8oKc=; b=J73YRqlEnIfinjUkbKYUlmUMeDyo/0zTu4LAmNMGmiFK85TesDrwVs1bm4xUlmLieP 9CT0xgDO4pqN05JyqKvYM/pN7G+A14Wr5mqGW+ZFTrNeFzXsnPGGYK353oa2ZpQnBqdX RmSpTwW925FGafN/YMd910K1VhR4x5kfZOMNLlZ7CI/Lkt5bxRPlEo1Csr+6SaEoumjO WmSKc8wX9fCjDjWErCgw+lvGl8P2hrhoZXFKHpiGPCLXKZUHvM2CindI5fd+ivgozuCD m8MC2uyDISs8TIRBBT5tw+mNYzThL77Z2ndBxky7al4H8V2abckOh0qNjDB2YjOfowmf 5nsA== MIME-Version: 1.0 X-Received: by 10.55.215.144 with SMTP id t16mr1995171qkt.107.1439815426724; Mon, 17 Aug 2015 05:43:46 -0700 (PDT) Received: by 10.140.31.181 with HTTP; Mon, 17 Aug 2015 05:43:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 Aug 2015 13:43:46 +0100 Message-ID: From: Tier Nolan Cc: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a114661980d6033051d812788 X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, MALFORMED_FREEMAIL, MISSING_HEADERS,RCVD_IN_DNSWL_LOW 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] Dynamically Controlled Bitcoin Block Size Max Cap 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: Mon, 17 Aug 2015 12:43:47 -0000 --001a114661980d6033051d812788 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 17, 2015 at 12:57 PM, Rodney Morris via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I haven't run any statistics or simulations, but I'm concerned that the > interplay between the random distribution of transaction arrival and the > random distribution of block times may lead to false signals. > You could just take the average of all the block sizes for the last 2016 window. If average of last 2016 > 50% of the limit, then increase by 6.25% Otherwise, decrease by 6.25% This means that the average would be around 50% of the limit. This gives margin to create larger blocks when blocks are happening slowly. A majority of miners could force the limit upwards by creating spam but full blocks. It could be coupled with a hard limit that grows at whatever is seen as the maximum reasonable. This would be both a maximum and a minimum. All of these schemes add state to the system. If the schedule is predictable, then you can check determine the maximum block size purely from the header and coinbase. --001a114661980d6033051d812788 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On M= on, Aug 17, 2015 at 12:57 PM, Rodney Morris via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

I haven't run any statistics or simulations,= but I'm concerned that the interplay between the random distribution o= f transaction arrival and the random distribution of block times may lead t= o false signals.

Yo= u could just take the average of all the block sizes for the last 2016 wind= ow.

If average of last 2016 > 50% of the limit, then i= ncrease by 6.25%

Otherwise, decrease by 6.25%

This means that the average would be around 50% of the limit.=C2=A0 This= gives margin to create larger blocks when blocks are happening slowly.
=

A majority of miners could force the limit upwards by creati= ng spam but full blocks.

It could be coupled with a= hard limit that grows at whatever is seen as the maximum reasonable.=C2=A0= This would be both a maximum and a minimum.

All of these schemes add state to the system.=C2=A0 If the schedu= le is predictable, then you can check determine the maximum block size pure= ly from the header and coinbase.

--001a114661980d6033051d812788-- 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 D47587AA for ; Tue, 18 Aug 2015 12:13:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3621819A for ; Tue, 18 Aug 2015 12:13:49 +0000 (UTC) Received: by igui7 with SMTP id i7so77976116igu.0 for ; Tue, 18 Aug 2015 05:13:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=q8vHawa9zkylTkYO17U8B9vdf4nB4dZF0vG4OeZAhEY=; b=N2A4id6dxnxO0Y83zMOCnphlYoPLQMDZxAXDHByc9l++c+YWwv32CnLWIFUjHOWL+Z uVL38NSTFf2x8ieT4J6/TgFA0qViByn8gZ68/iF10OBt2z1/jFuLOJSMukovFFQU7SFV 4RSdbTg4gT6HhzWj7gWt0MeH2g2ft8igGDfueYQ5agAqwfBLx/mtY0YuIEfoEiDalV7m e6GN0VlBxtjswKknOIFlnEK5ezLBP/QcAcIxyLvpQUomf7ACNjXAT01Hg04QnVPPIF9P /oOoVQ5KDCn8s/L7W78Zi3ZMnrSzIiFRbU4LlhV9LrpcAcxdzp/pX0nw7boV2djp0nQU v8aA== X-Gm-Message-State: ALoCoQkCL4QHv/7WAOmlH2NQezI7Q8ohmBHSD/GpxEaOnQA1/mxAsupGkBYMOqkbIVAbDFkVwDyL MIME-Version: 1.0 X-Received: by 10.50.79.202 with SMTP id l10mr20670247igx.7.1439900028572; Tue, 18 Aug 2015 05:13:48 -0700 (PDT) Received: by 10.107.18.155 with HTTP; Tue, 18 Aug 2015 05:13:48 -0700 (PDT) X-Originating-IP: [203.171.245.240] Date: Tue, 18 Aug 2015 17:43:48 +0530 Message-ID: From: Upal Chakraborty To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=089e0122aaeeb73789051d94d92d X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, 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: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap 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: Tue, 18 Aug 2015 12:13:49 -0000 --089e0122aaeeb73789051d94d92d Content-Type: text/plain; charset=UTF-8 Regarding: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html I am arguing with the following statement here... *I see problems to this approach. The biggest one I see is that a miner > with 11% of hash power could sabotage block size increases by only ever > mining empty blocks.* First, I would like to argue from economics' point of view. If someone wants to hold back the block size increase with 11% hash power by mining empty blocks, he has to sacrifice Tx fees, which is not economical. 11% hash power will most likely be a pool and pool miners will find out soon that they are losing Tx fees because of pool owner's intention. Hence, they'll switch pool and pool owner will lose out. This is the same reason why 51% attack will never happen, even if a pool gets more than 51% hash power. Next, I would like to propose a slightly modified technical solution to this problem in algorithmic format... If more than 50% of block's size, found in the first 2000 of the last difficulty period, is more than 90% MaxBlockSize Double MaxBlockSize Else if more than 90% of block's size, found in the first 2000 of the last difficulty period, is less than 50% MaxBlockSize Half MaxBlockSize Else Keep the same MaxBlockSize This is how, those who want to stop increase, need to have more than 50% hash power. Those who want to stop decrease, need to have more than 10% hash power, but must mine more than 50% of MaxBlockSize in all blocks. In this approach, not only miners, but also the end user have their say. Because, end users will fill up the mempool, from where miners will take Tx to fill up the blocks. Please note that, taking first 2000 of the last 2016 blocks is important to avoid data discrepancy among different nodes due to orphan blocks. It is assumed that a chain can not be orphaned after having 16 confirmation. Looking for comments. --089e0122aaeeb73789051d94d92d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Regarding:=C2=A0http://lists.linuxfoundati= on.org/pipermail/bitcoin-dev/2015-August/010295.html

<= /div>

I am arguing with the following statement here...

<= /div>

I see problems to this approach. The biggest = one I see is that a miner with 11% of hash power could sabotage block size = increases by only ever mining empty blocks.

First, I would like to argue from economics' point = of view. If someone wants to hold back the block size increase with 11% has= h power by mining empty blocks, he has to sacrifice Tx fees, which is not e= conomical. 11% hash power will most likely be a pool and pool miners will f= ind out soon that they are losing Tx fees because of pool owner's inten= tion. Hence, they'll switch pool and pool owner will lose out. This is = the same reason why 51% attack will never happen, even if a pool gets more = than 51% hash power.

Ne= xt, I would like to propose a slightly modified technical solution to this = problem in algorithmic format...

If more than 50% = of block's size, found in the first 2000 of the last difficulty period,= is more than 90% MaxBlockSize

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Double MaxBlockSize

Else if more than 90% of block's siz= e, found in the first 2000 of the last difficulty period, is less than 50% = MaxBlockSize

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Half MaxBlockSize<= /div>

Else

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Keep the s= ame MaxBlockSize

This is how, those who want to st= op increase, need to have more than 50% hash power. Those who want to stop = decrease, need to have more than 10% hash power, but must mine more than 50= % of MaxBlockSize in all blocks. In this approach, not only miners, but als= o the end user have their say. Because, end users will fill up the mempool,= from where miners will take Tx to fill up the blocks. Please note that, ta= king first 2000 of the last 2016 blocks is important to avoid data discrepa= ncy among different nodes due to orphan blocks. It is assumed that a chain = can not be orphaned after having 16 confirmation.

= Looking for comments.

--089e0122aaeeb73789051d94d92d-- 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 5829A89D for ; Tue, 18 Aug 2015 17:26:47 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yk0-f175.google.com (mail-yk0-f175.google.com [209.85.160.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9B79515D for ; Tue, 18 Aug 2015 17:26:46 +0000 (UTC) Received: by ykfw73 with SMTP id w73so111922647ykf.3 for ; Tue, 18 Aug 2015 10:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=7UOABCS7Alw+a/Z5rLbot+V06+kJJ4SqeChfscQv0XI=; b=usXXQn/RqXnzSzl/ILSLElors6c0gq22Zy0p+puJoCMqs/B6eJ9rkSPr0+GzVuIuVn bUzALrCL1wHf1CNxvCllQEXW4MBLEQyuOmrMG4moLzh4wAZCZEaVyjA8Jxfkl3+1AUZo SB/wc/kr9S7Ei+Wg4l9MJhF8NvVzyHYeT2FvLzORlgC2hzv1nvo8DcJ9lTYvXAhUmNa4 rw6sc+HF3vVdSJE8QwuzSDuVoT2Ia4Pe2EYud8Eecy3Md6VgC19SPLrdW9z7ab/JcZlH ENjUcB3S1fTsolyhgbe2C/xcPAp7zIf8i5yXNhMAtwzO5R0ruZWDqGnIyvF7jCObChSK wtyg== MIME-Version: 1.0 X-Received: by 10.129.81.194 with SMTP id f185mr8566209ywb.41.1439918805914; Tue, 18 Aug 2015 10:26:45 -0700 (PDT) Received: by 10.37.2.69 with HTTP; Tue, 18 Aug 2015 10:26:45 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Aug 2015 13:26:45 -0400 Message-ID: From: Chris Wardell To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a11456cbcee9a35051d9938e6 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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] Dynamically Controlled Bitcoin Block Size Max Cap 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: Tue, 18 Aug 2015 17:26:47 -0000 --001a11456cbcee9a35051d9938e6 Content-Type: text/plain; charset=UTF-8 I'm no authority on the subject, but I don't understand why there is a max block-size, other than anti-spam measures. The only other reason I have heard for a max-block-size is to force people into paying higher fees. This seems like the wrong way to force fees. If you want to force fees, then do exactly that - make fees required, and set a minimum... don't force people to pay fees by limiting transactions per second. That's like shooting yourself in the foot to get free surgery.... On Tue, Aug 18, 2015 at 8:13 AM, Upal Chakraborty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Regarding: > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html > > > I am arguing with the following statement here... > > *I see problems to this approach. The biggest one I see is that a miner >> with 11% of hash power could sabotage block size increases by only ever >> mining empty blocks.* > > > > First, I would like to argue from economics' point of view. If someone > wants to hold back the block size increase with 11% hash power by mining > empty blocks, he has to sacrifice Tx fees, which is not economical. 11% > hash power will most likely be a pool and pool miners will find out soon > that they are losing Tx fees because of pool owner's intention. Hence, > they'll switch pool and pool owner will lose out. This is the same reason > why 51% attack will never happen, even if a pool gets more than 51% hash > power. > > > Next, I would like to propose a slightly modified technical solution to > this problem in algorithmic format... > > If more than 50% of block's size, found in the first 2000 of the last > difficulty period, is more than 90% MaxBlockSize > Double MaxBlockSize > Else if more than 90% of block's size, found in the first 2000 of the last > difficulty period, is less than 50% MaxBlockSize > Half MaxBlockSize > Else > Keep the same MaxBlockSize > > This is how, those who want to stop increase, need to have more than 50% > hash power. Those who want to stop decrease, need to have more than 10% > hash power, but must mine more than 50% of MaxBlockSize in all blocks. In > this approach, not only miners, but also the end user have their say. > Because, end users will fill up the mempool, from where miners will take Tx > to fill up the blocks. Please note that, taking first 2000 of the last 2016 > blocks is important to avoid data discrepancy among different nodes due to > orphan blocks. It is assumed that a chain can not be orphaned after having > 16 confirmation. > > Looking for comments. > > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a11456cbcee9a35051d9938e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'm no authority on the subject, but I don't = understand why there is a max block-size, other than anti-spam measures.

The only other reason I have heard for a max-block-size is = to force people into paying higher fees.

This seems like the wrong w= ay to force fees.=C2=A0 If you want to force fees, then do exactly that - m= ake fees required, and set a minimum... don't force people to pay fees = by limiting transactions per second.=C2=A0 That's like shooting yoursel= f in the foot to get free surgery....

On Tue, Aug 18, 2015 at 8:13 AM= , Upal Chakraborty via bitcoin-dev <bitcoin-dev@lists.= linuxfoundation.org> wrote:

Regarding:=C2=A0http://= lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html=

I am arguing with the following statement here= ...

I see problems to this app= roach. The biggest one I see is that a miner with 11% of hash power could s= abotage block size increases by only ever mining empty blocks.

First, I would like to argue from ec= onomics' point of view. If someone wants to hold back the block size in= crease with 11% hash power by mining empty blocks, he has to sacrifice Tx f= ees, which is not economical. 11% hash power will most likely be a pool and= pool miners will find out soon that they are losing Tx fees because of poo= l owner's intention. Hence, they'll switch pool and pool owner will= lose out. This is the same reason why 51% attack will never happen, even i= f a pool gets more than 51% hash power.

Next, I would like to propose a slightly modified technica= l solution to this problem in algorithmic format...

If more than 50% of block's size, found in the first 2000 of the last= difficulty period, is more than 90% MaxBlockSize

=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Double MaxBlockSize

Else if more than 90= % of block's size, found in the first 2000 of the last difficulty perio= d, is less than 50% MaxBlockSize

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Half MaxBlockSize

Else

=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Keep the same MaxBlockSize

This is ho= w, those who want to stop increase, need to have more than 50% hash power. = Those who want to stop decrease, need to have more than 10% hash power, but= must mine more than 50% of MaxBlockSize in all blocks. In this approach, n= ot only miners, but also the end user have their say. Because, end users wi= ll fill up the mempool, from where miners will take Tx to fill up the block= s. Please note that, taking first 2000 of the last 2016 blocks is important= to avoid data discrepancy among different nodes due to orphan blocks. It i= s assumed that a chain can not be orphaned after having 16 confirmation.

Looking for comments.

<= /div>

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--001a11456cbcee9a35051d9938e6-- 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 EB93F8A6 for ; Tue, 18 Aug 2015 20:27:06 +0000 (UTC) X-Greylist: delayed 00:42:31 by SQLgrey-1.7.6 Received: from moe.ows.fr (smtp.ows.fr [194.116.202.39]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 10B121C3 for ; Tue, 18 Aug 2015 20:27:05 +0000 (UTC) Received: from 93-103-156-51.dynamic.t-2.net ([93.103.156.51] helo=[192.168.1.239]) by moe.ows.fr with esmtpa (Exim 4.80) (envelope-from ) id 1ZRmo9-0000hA-Qc for bitcoin-dev@lists.linuxfoundation.org; Tue, 18 Aug 2015 21:44:30 +0200 Message-ID: <55D38B19.2090609@ows.fr> Date: Tue, 18 Aug 2015 21:44:25 +0200 From: cedric perronnet User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: bitcoin-dev@lists.linuxfoundation.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010804030508030306040108" X-SA-Exim-Connect-IP: 93.103.156.51 X-SA-Exim-Mail-From: cp@ows.fr X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,HTML_MESSAGE, RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:57:07 +0000) X-SA-Exim-Scanned: Yes (on moe.ows.fr) Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap 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: Tue, 18 Aug 2015 20:27:07 -0000 This is a multi-part message in MIME format. --------------010804030508030306040108 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sounds like a much better approach than arbitrary deciding what the block size should be BR Le 18/08/2015 14:13, Upal Chakraborty via bitcoin-dev a écrit : > Regarding: > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html > > > > I am arguing with the following statement here... > > /I see problems to this approach. The biggest one I see is that a > miner with 11% of hash power could sabotage block size increases > by only ever mining empty blocks./ > > > > First, I would like to argue from economics' point of view. If someone > wants to hold back the block size increase with 11% hash power by > mining empty blocks, he has to sacrifice Tx fees, which is not > economical. 11% hash power will most likely be a pool and pool miners > will find out soon that they are losing Tx fees because of pool > owner's intention. Hence, they'll switch pool and pool owner will lose > out. This is the same reason why 51% attack will never happen, even if > a pool gets more than 51% hash power. > > > Next, I would like to propose a slightly modified technical solution > to this problem in algorithmic format... > > If more than 50% of block's size, found in the first 2000 of the last > difficulty period, is more than 90% MaxBlockSize > Double MaxBlockSize > Else if more than 90% of block's size, found in the first 2000 of the > last difficulty period, is less than 50% MaxBlockSize > Half MaxBlockSize > Else > Keep the same MaxBlockSize > > This is how, those who want to stop increase, need to have more than > 50% hash power. Those who want to stop decrease, need to have more > than 10% hash power, but must mine more than 50% of MaxBlockSize in > all blocks. In this approach, not only miners, but also the end user > have their say. Because, end users will fill up the mempool, from > where miners will take Tx to fill up the blocks. Please note that, > taking first 2000 of the last 2016 blocks is important to avoid data > discrepancy among different nodes due to orphan blocks. It is assumed > that a chain can not be orphaned after having 16 confirmation. > > Looking for comments. > > > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --------------010804030508030306040108 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Sounds like a much better approach than arbitrary deciding what the block size should be
BR

Le 18/08/2015 14:13, Upal Chakraborty via bitcoin-dev a écrit :

Regarding: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html

I am arguing with the following statement here...

I see problems to this approach. The biggest one I see is that a miner with 11% of hash power could sabotage block size increases by only ever mining empty blocks.

First, I would like to argue from economics' point of view. If someone wants to hold back the block size increase with 11% hash power by mining empty blocks, he has to sacrifice Tx fees, which is not economical. 11% hash power will most likely be a pool and pool miners will find out soon that they are losing Tx fees because of pool owner's intention. Hence, they'll switch pool and pool owner will lose out. This is the same reason why 51% attack will never happen, even if a pool gets more than 51% hash power.

Next, I would like to propose a slightly modified technical solution to this problem in algorithmic format...

If more than 50% of block's size, found in the first 2000 of the last difficulty period, is more than 90% MaxBlockSize

Double MaxBlockSize

Else if more than 90% of block's size, found in the first 2000 of the last difficulty period, is less than 50% MaxBlockSize

Half MaxBlockSize

Else

Keep the same MaxBlockSize

This is how, those who want to stop increase, need to have more than 50% hash power. Those who want to stop decrease, need to have more than 10% hash power, but must mine more than 50% of MaxBlockSize in all blocks. In this approach, not only miners, but also the end user have their say. Because, end users will fill up the mempool, from where miners will take Tx to fill up the blocks. Please note that, taking first 2000 of the last 2016 blocks is important to avoid data discrepancy among different nodes due to orphan blocks. It is assumed that a chain can not be orphaned after having 16 confirmation.

Looking for comments.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--------------010804030508030306040108-- 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 DE44D895 for ; Tue, 18 Aug 2015 20:58:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 482C71B7 for ; Tue, 18 Aug 2015 20:58:51 +0000 (UTC) Received: by obbhe7 with SMTP id he7so151940415obb.0 for ; Tue, 18 Aug 2015 13:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=flP4rxSRzKh6fw2oFSroyt443OV004brdqfnSmnKq2k=; b=wBhhVeBkTTlUsjldDk/M3KVOqdXLN6ndTrmHx559hnQ7BRF+WFvQ5v5KlWoiZd7la4 0pOCMaBlDdRBXcU4Sqqo2K02ZjY+/3jl0qxKJAjtz3drFno3/v5TzQTXz8qjksY4U2IQ hj6sfY7WCIkLYFYkWRq60tNlqv2IW5Dqoniq+YFyZFT1AQ9TeFcFNf+6X8VL3lRdb26E yloOVL2P0hTJZDU+AtfzhbluZqFkRVs11FheGTK9x2PiTnOdxKLjdeVwdfrZZz2ucI1M RvbestlYnPzkYI3pTaO+rRRAOcMfLPr/avWoonO33mUQU9MJhoO6BKGh16OHJyW5usec 54OA== MIME-Version: 1.0 X-Received: by 10.182.250.137 with SMTP id zc9mr7492498obc.79.1439931530633; Tue, 18 Aug 2015 13:58:50 -0700 (PDT) Received: by 10.202.134.78 with HTTP; Tue, 18 Aug 2015 13:58:50 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Aug 2015 13:58:50 -0700 Message-ID: From: Danny Thorpe To: Upal Chakraborty Content-Type: multipart/alternative; boundary=089e01537b22626ae8051d9c2f9f X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap 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: Tue, 18 Aug 2015 20:58:52 -0000 --089e01537b22626ae8051d9c2f9f Content-Type: text/plain; charset=UTF-8 I like the simplicity of this approach. Demand driven response. Is there really a need to reduce the max block size at all? It is just a maximum limit, not a required size for every block. If a seasonal transaction surge bumps the max block size limit up a notch, what harm is there in leaving the max block size limit at the "high water mark" indefinitely, even though periods of decreased transaction volume? I'd argue to remove the reduction step, making the max block size calculation a monotonic increasing function. Cut the complexity in half. -Danny On Tue, Aug 18, 2015 at 5:13 AM, Upal Chakraborty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Regarding: > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html > > > I am arguing with the following statement here... > > *I see problems to this approach. The biggest one I see is that a miner >> with 11% of hash power could sabotage block size increases by only ever >> mining empty blocks.* > > > > First, I would like to argue from economics' point of view. If someone > wants to hold back the block size increase with 11% hash power by mining > empty blocks, he has to sacrifice Tx fees, which is not economical. 11% > hash power will most likely be a pool and pool miners will find out soon > that they are losing Tx fees because of pool owner's intention. Hence, > they'll switch pool and pool owner will lose out. This is the same reason > why 51% attack will never happen, even if a pool gets more than 51% hash > power. > > > Next, I would like to propose a slightly modified technical solution to > this problem in algorithmic format... > > If more than 50% of block's size, found in the first 2000 of the last > difficulty period, is more than 90% MaxBlockSize > Double MaxBlockSize > Else if more than 90% of block's size, found in the first 2000 of the last > difficulty period, is less than 50% MaxBlockSize > Half MaxBlockSize > Else > Keep the same MaxBlockSize > > This is how, those who want to stop increase, need to have more than 50% > hash power. Those who want to stop decrease, need to have more than 10% > hash power, but must mine more than 50% of MaxBlockSize in all blocks. In > this approach, not only miners, but also the end user have their say. > Because, end users will fill up the mempool, from where miners will take Tx > to fill up the blocks. Please note that, taking first 2000 of the last 2016 > blocks is important to avoid data discrepancy among different nodes due to > orphan blocks. It is assumed that a chain can not be orphaned after having > 16 confirmation. > > Looking for comments. > > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --089e01537b22626ae8051d9c2f9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I like the simplicity of this approach.=C2=A0 Demand drive= n response.

Is there really a need to reduce the max blo= ck size at all?=C2=A0 It is just a maximum limit, not a required size for e= very block.=C2=A0 If a seasonal transaction surge bumps the max block size = limit up a notch, what harm is there in leaving the max block size limit at= the "high water mark" indefinitely, even though periods of decre= ased transaction volume?

I'd argue to remove t= he reduction step, making the max block size calculation a monotonic increa= sing function. Cut the complexity in half.

-Danny<= /div>

On Tue= , Aug 18, 2015 at 5:13 AM, Upal Chakraborty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

Regarding:=C2=A0http://lists.linuxfoundation.org/pipermail/bitcoin-dev/20= 15-August/010295.html

I am arguing with the= following statement here...

I= see problems to this approach. The biggest one I see is that a miner with = 11% of hash power could sabotage block size increases by only ever mining e= mpty blocks.

First, I wo= uld like to argue from economics' point of view. If someone wants to ho= ld back the block size increase with 11% hash power by mining empty blocks,= he has to sacrifice Tx fees, which is not economical. 11% hash power will = most likely be a pool and pool miners will find out soon that they are losi= ng Tx fees because of pool owner's intention. Hence, they'll switch= pool and pool owner will lose out. This is the same reason why 51% attack = will never happen, even if a pool gets more than 51% hash power.

Next, I would like to propose a s= lightly modified technical solution to this problem in algorithmic format..= .

If more than 50% of block's size, found in t= he first 2000 of the last difficulty period, is more than 90% MaxBlockSize<= /div>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Double MaxBlockSize

<= div>Else if more than 90% of block's size, found in the first 2000 of t= he last difficulty period, is less than 50% MaxBlockSize

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Half MaxBlockSize

Else

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Keep the same MaxBlockSize

This is how, those who want to stop increase, need to have more= than 50% hash power. Those who want to stop decrease, need to have more th= an 10% hash power, but must mine more than 50% of MaxBlockSize in all block= s. In this approach, not only miners, but also the end user have their say.= Because, end users will fill up the mempool, from where miners will take T= x to fill up the blocks. Please note that, taking first 2000 of the last 20= 16 blocks is important to avoid data discrepancy among different nodes due = to orphan blocks. It is assumed that a chain can not be orphaned after havi= ng 16 confirmation.

Looking for comments.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--089e01537b22626ae8051d9c2f9f-- 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 862B97AA for ; Tue, 18 Aug 2015 21:17:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yk0-f179.google.com (mail-yk0-f179.google.com [209.85.160.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6AA83191 for ; Tue, 18 Aug 2015 21:17:07 +0000 (UTC) Received: by ykfw73 with SMTP id w73so118640536ykf.3 for ; Tue, 18 Aug 2015 14:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6e0Lnu3NmkmsMOjQWswu0v50kjN9RQMvSjIFn9MCgjw=; b=hsip53gl7/I94xnKno1EOl1HU3DLt0y1s/+IysonYU5IuoasG+Z07jB0vZ+OoqJeCF fv8WfqYdeOv24+rnWunr1ljmCCyLS0B5529RJqTg61nqd2SyWUkaa9FW540Z9NLzoZq8 cL0aXCSl2EPkBRZksUxp4KjoK0XGdVug38Nn31jKBxlXY9goRiHv7aW4iAi+xqUnRVBz VYRtVtKALWtr6Yu2j2Esr06CQIxunjKf7OUeAYTTTUcIRUqyDLjA3bmV/HekWURbBrQ6 o6X1t5iZBp+sUQhaYr6jn087rL9aGVm2tBpZDBQ+BykkeajHBCmQikHdz97f/5CQaY3W s6XQ== MIME-Version: 1.0 X-Received: by 10.13.225.66 with SMTP id k63mr10224837ywe.148.1439932626653; Tue, 18 Aug 2015 14:17:06 -0700 (PDT) Received: by 10.37.2.69 with HTTP; Tue, 18 Aug 2015 14:17:06 -0700 (PDT) In-Reply-To: References:

Date: Tue, 18 Aug 2015 17:17:06 -0400 Message-ID: From: Chris Wardell To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=94eb2c076e8eb66172051d9c7049 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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] Dynamically Controlled Bitcoin Block Size Max Cap 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: Tue, 18 Aug 2015 21:17:08 -0000 --94eb2c076e8eb66172051d9c7049 Content-Type: text/plain; charset=UTF-8 I agree with the simplicity of this approach and with removing the reduction step... it's unlikely the block size would ever need to be reduced, only increased with demand? I like this solution better than either kicking the can, or raising the block size based on chain height (another dynamic solution). -Chris On Tue, Aug 18, 2015 at 4:58 PM, Danny Thorpe via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I like the simplicity of this approach. Demand driven response. > > Is there really a need to reduce the max block size at all? It is just a > maximum limit, not a required size for every block. If a seasonal > transaction surge bumps the max block size limit up a notch, what harm is > there in leaving the max block size limit at the "high water mark" > indefinitely, even though periods of decreased transaction volume? > > I'd argue to remove the reduction step, making the max block size > calculation a monotonic increasing function. Cut the complexity in half. > > -Danny > > On Tue, Aug 18, 2015 at 5:13 AM, Upal Chakraborty via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Regarding: >> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html >> >> >> I am arguing with the following statement here... >> >> *I see problems to this approach. The biggest one I see is that a miner >>> with 11% of hash power could sabotage block size increases by only ever >>> mining empty blocks.* >> >> >> >> First, I would like to argue from economics' point of view. If someone >> wants to hold back the block size increase with 11% hash power by mining >> empty blocks, he has to sacrifice Tx fees, which is not economical. 11% >> hash power will most likely be a pool and pool miners will find out soon >> that they are losing Tx fees because of pool owner's intention. Hence, >> they'll switch pool and pool owner will lose out. This is the same reason >> why 51% attack will never happen, even if a pool gets more than 51% hash >> power. >> >> >> Next, I would like to propose a slightly modified technical solution to >> this problem in algorithmic format... >> >> If more than 50% of block's size, found in the first 2000 of the last >> difficulty period, is more than 90% MaxBlockSize >> Double MaxBlockSize >> Else if more than 90% of block's size, found in the first 2000 of the >> last difficulty period, is less than 50% MaxBlockSize >> Half MaxBlockSize >> Else >> Keep the same MaxBlockSize >> >> This is how, those who want to stop increase, need to have more than 50% >> hash power. Those who want to stop decrease, need to have more than 10% >> hash power, but must mine more than 50% of MaxBlockSize in all blocks. In >> this approach, not only miners, but also the end user have their say. >> Because, end users will fill up the mempool, from where miners will take Tx >> to fill up the blocks. Please note that, taking first 2000 of the last 2016 >> blocks is important to avoid data discrepancy among different nodes due to >> orphan blocks. It is assumed that a chain can not be orphaned after having >> 16 confirmation. >> >> Looking for comments. >> >> >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --94eb2c076e8eb66172051d9c7049 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I agree with the simplicity of this approach and with= removing the reduction step... it's unlikely the block size would ever= need to be reduced, only increased with demand?

I like this s= olution better than either kicking the can, or raising the block size based= on chain height (another dynamic solution).

-C= hris

On Tue, Aug 18, 2015 at 4:58 PM, Danny Thorpe via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wr= ote:

I like the simplici= ty of this approach.=C2=A0 Demand driven response.

Is th= ere really a need to reduce the max block size at all?=C2=A0 It is just a m= aximum limit, not a required size for every block.=C2=A0 If a seasonal tran= saction surge bumps the max block size limit up a notch, what harm is there= in leaving the max block size limit at the "high water mark" ind= efinitely, even though periods of decreased transaction volume?
<= br>
I'd argue to remove the reduction step, making the max bl= ock size calculation a monotonic increasing function. Cut the complexity in= half.

-Danny

On Tue, Aug 18, 201= 5 at 5:13 AM, Upal Chakraborty via bitcoin-dev <bitcoi= n-dev@lists.linuxfoundation.org> wrote:
Regarding:= =C2=A0http://lists.linuxfoundation.org/pi= permail/bitcoin-dev/2015-August/010295.html

I am arguing with the following statement here...

I see problems to this approach. The biggest one I see= is that a miner with 11% of hash power could sabotage block size increases= by only ever mining empty blocks.

=
First, I would like to argue from economics' point of view. = If someone wants to hold back the block size increase with 11% hash power b= y mining empty blocks, he has to sacrifice Tx fees, which is not economical= . 11% hash power will most likely be a pool and pool miners will find out s= oon that they are losing Tx fees because of pool owner's intention. Hen= ce, they'll switch pool and pool owner will lose out. This is the same = reason why 51% attack will never happen, even if a pool gets more than 51% = hash power.

Next, I wou= ld like to propose a slightly modified technical solution to this problem i= n algorithmic format...

If more than 50% of block&= #39;s size, found in the first 2000 of the last difficulty period, is more = than 90% MaxBlockSize
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Double Ma= xBlockSize
Else if more than 90% of block's size, found = in the first 2000 of the last difficulty period, is less than 50% MaxBlockS= ize
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Half MaxBlockSize
Else
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Keep the same MaxBl= ockSize

This is how, those who want to stop increa= se, need to have more than 50% hash power. Those who want to stop decrease,= need to have more than 10% hash power, but must mine more than 50% of MaxB= lockSize in all blocks. In this approach, not only miners, but also the end= user have their say. Because, end users will fill up the mempool, from whe= re miners will take Tx to fill up the blocks. Please note that, taking firs= t 2000 of the last 2016 blocks is important to avoid data discrepancy among= different nodes due to orphan blocks. It is assumed that a chain can not b= e orphaned after having 16 confirmation.

Looking f= or comments.

__________________________________________= _____
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--94eb2c076e8eb66172051d9c7049-- 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 DEA9994F for ; Wed, 19 Aug 2015 17:21:53 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B2BF611D for ; Wed, 19 Aug 2015 17:21:52 +0000 (UTC) Received: by igui7 with SMTP id i7so113217702igu.1 for ; Wed, 19 Aug 2015 10:21:52 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=KZ+VSeXCDdvTteURfYM5vxbg8l3mRusA4Rnvh9AwJqQ=; b=VU2KTG+GwUfPlNRTIbgXTb5icH+lDfPbhF5Sdo/h1RTlSlJDYuo6orJO51rrp0j7Zv SDr3dTxpJgBC9+04rr9rkV/gdcoSFM/7ZpYdVu543N7mN4lXkd8TKHfAdkOpQO/+ujiE mD+dHkXWjeM0kg8meCurouCzenJO5IKbNmQCAfoFFo70tbMNTPDh26nWt/WJvVawpPxr SEojlGndqIuVw/Os6CIPpm2P7pbXkoXy0VmWJNn8I+od6JQiALsjKDZWDvo9/XshRTRP XOLXC4FMMXN/4W3DaQ+eRWrrBF5jAy1gPoZPAsypM6deB9MM8BcgEdtjTeW3KCpu8G9E iSPA== X-Gm-Message-State: ALoCoQmLo8RQUmXPshT2Zzs7fGQAzPM2yM35i3OHSgTxHgsZa1zb0gu+p0hya8+27PmnhfeA5kAg MIME-Version: 1.0 X-Received: by 10.50.66.129 with SMTP id f1mr27593878igt.7.1440004912118; Wed, 19 Aug 2015 10:21:52 -0700 (PDT) Received: by 10.107.18.155 with HTTP; Wed, 19 Aug 2015 10:21:52 -0700 (PDT) X-Originating-IP: [115.187.37.206] In-Reply-To: References:

Date: Wed, 19 Aug 2015 22:51:52 +0530 Message-ID: From: Upal Chakraborty To: Danny Thorpe Content-Type: multipart/alternative; boundary=047d7bdc0cf4432167051dad45cc X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap 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: Wed, 19 Aug 2015 17:21:54 -0000 --047d7bdc0cf4432167051dad45cc Content-Type: text/plain; charset=UTF-8 I think, keeping the reduction part is necessary to have it demand driven. Otherwise, we could just increase it to a fixed size. If the max cap is high, but there is not enough Tx in the mempool, then after one big block many will go small. This will not be good when block reward become small and mining revenue become dependent on Tx fee. But, if reduction is there, max cap will come down soon and all miners will see revenue from Tx fee again. Proposal details: http://upalc.com/maxblocksize.php On Wed, Aug 19, 2015 at 2:28 AM, Danny Thorpe wrote: > I like the simplicity of this approach. Demand driven response. > > Is there really a need to reduce the max block size at all? It is just a > maximum limit, not a required size for every block. If a seasonal > transaction surge bumps the max block size limit up a notch, what harm is > there in leaving the max block size limit at the "high water mark" > indefinitely, even though periods of decreased transaction volume? > > I'd argue to remove the reduction step, making the max block size > calculation a monotonic increasing function. Cut the complexity in half. > > -Danny > > On Tue, Aug 18, 2015 at 5:13 AM, Upal Chakraborty via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Regarding: >> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html >> >> >> I am arguing with the following statement here... >> >> *I see problems to this approach. The biggest one I see is that a miner >>> with 11% of hash power could sabotage block size increases by only ever >>> mining empty blocks.* >> >> >> >> First, I would like to argue from economics' point of view. If someone >> wants to hold back the block size increase with 11% hash power by mining >> empty blocks, he has to sacrifice Tx fees, which is not economical. 11% >> hash power will most likely be a pool and pool miners will find out soon >> that they are losing Tx fees because of pool owner's intention. Hence, >> they'll switch pool and pool owner will lose out. This is the same reason >> why 51% attack will never happen, even if a pool gets more than 51% hash >> power. >> >> >> Next, I would like to propose a slightly modified technical solution to >> this problem in algorithmic format... >> >> If more than 50% of block's size, found in the first 2000 of the last >> difficulty period, is more than 90% MaxBlockSize >> Double MaxBlockSize >> Else if more than 90% of block's size, found in the first 2000 of the >> last difficulty period, is less than 50% MaxBlockSize >> Half MaxBlockSize >> Else >> Keep the same MaxBlockSize >> >> This is how, those who want to stop increase, need to have more than 50% >> hash power. Those who want to stop decrease, need to have more than 10% >> hash power, but must mine more than 50% of MaxBlockSize in all blocks. In >> this approach, not only miners, but also the end user have their say. >> Because, end users will fill up the mempool, from where miners will take Tx >> to fill up the blocks. Please note that, taking first 2000 of the last 2016 >> blocks is important to avoid data discrepancy among different nodes due to >> orphan blocks. It is assumed that a chain can not be orphaned after having >> 16 confirmation. >> >> Looking for comments. >> >> >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > --047d7bdc0cf4432167051dad45cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think, keeping the reduction part is necessary to have i= t demand driven. Otherwise, we could just increase it to a fixed size. If t= he max cap is high, but there is not enough Tx in the mempool, then after o= ne big block many will go small. This will not be good when block reward be= come small and mining revenue become dependent on Tx fee. But, if reduction= is there, max cap will come down soon and all miners will see revenue from= Tx fee again.

Proposal details:=C2=A0http://upalc.com/maxblocksize.php

On Wed, Aug 19, 2015 = at 2:28 AM, Danny Thorpe <danny.thorpe@gmail.com> wrote= :

I like the simplicity = of this approach.=C2=A0 Demand driven response.

Is there= really a need to reduce the max block size at all?=C2=A0 It is just a maxi= mum limit, not a required size for every block.=C2=A0 If a seasonal transac= tion surge bumps the max block size limit up a notch, what harm is there in= leaving the max block size limit at the "high water mark" indefi= nitely, even though periods of decreased transaction volume?

=
I'd argue to remove the reduction step, making the max block= size calculation a monotonic increasing function. Cut the complexity in ha= lf.

-Danny
<= br>
On Tue, Aug 18, 2015 a= t 5:13 AM, Upal Chakraborty via bitcoin-dev <bitcoin= -dev@lists.linuxfoundation.org> wrote:
Regarding:= =C2=A0http://lists.linuxfoundation.org/pi= permail/bitcoin-dev/2015-August/010295.html

I am arguing with the following statement here...

I see problems to this approach. The biggest one I see= is that a miner with 11% of hash power could sabotage block size increases= by only ever mining empty blocks.

=
First, I would like to argue from economics' point of view. = If someone wants to hold back the block size increase with 11% hash power b= y mining empty blocks, he has to sacrifice Tx fees, which is not economical= . 11% hash power will most likely be a pool and pool miners will find out s= oon that they are losing Tx fees because of pool owner's intention. Hen= ce, they'll switch pool and pool owner will lose out. This is the same = reason why 51% attack will never happen, even if a pool gets more than 51% = hash power.

Next, I wou= ld like to propose a slightly modified technical solution to this problem i= n algorithmic format...

If more than 50% of block&= #39;s size, found in the first 2000 of the last difficulty period, is more = than 90% MaxBlockSize
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Double Ma= xBlockSize
Else if more than 90% of block's size, found = in the first 2000 of the last difficulty period, is less than 50% MaxBlockS= ize
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Half MaxBlockSize
Else
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Keep the same MaxBl= ockSize

This is how, those who want to stop increa= se, need to have more than 50% hash power. Those who want to stop decrease,= need to have more than 10% hash power, but must mine more than 50% of MaxB= lockSize in all blocks. In this approach, not only miners, but also the end= user have their say. Because, end users will fill up the mempool, from whe= re miners will take Tx to fill up the blocks. Please note that, taking firs= t 2000 of the last 2016 blocks is important to avoid data discrepancy among= different nodes due to orphan blocks. It is assumed that a chain can not b= e orphaned after having 16 confirmation.

Looking f= or comments.

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--047d7bdc0cf4432167051dad45cc-- 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 766FE25A for ; Thu, 20 Aug 2015 07:31:22 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E0F29115 for ; Thu, 20 Aug 2015 07:31:21 +0000 (UTC) Received: by lbbpu9 with SMTP id pu9so18229254lbb.3 for ; Thu, 20 Aug 2015 00:31:20 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=uTVLaKCzJEOUZhdW9QL1FqkA+Xmh25Ddh8FmmyMOQTo=; b=JtOzT26vaRpzswtSHUNbV8XlIZQlvNL0I9MH19cnUjW5bF25hV8JXc1CPKK/cJTyKd rX1pl8wLRmbwY5b41aBrNNF45Jjp4nKe/8t3yoRIE99TrpqV1QEMrlHbKkRhLzUGK8uC utsWBfo8r9vs2y4dnHM4f+7y1o9YwYmnP/2v7kM9fWGbDihTSusgnTKCUirccs5TywR3 ERwpBkFRBmmQjCb+2ObDODFXVDm8vL3BgobB4l9cameFV82mgc+PDSdshLXTQLpM81jv G+8Xr+sR29wdux63TGyL26b6wYd69ejwVj8jPd0RVVo4md2ygwRi7wqQaxudsiUnB9Fc Ju+Q== X-Gm-Message-State: ALoCoQk96376hpcF4YYW9/HipgCvmmPWrdJcarjjiCWgKWM4qapmPUlTkMEuWsLunAzzLjF3rd4T MIME-Version: 1.0 X-Received: by 10.112.146.106 with SMTP id tb10mr1636882lbb.22.1440055880407; Thu, 20 Aug 2015 00:31:20 -0700 (PDT) Received: by 10.25.15.22 with HTTP; Thu, 20 Aug 2015 00:31:20 -0700 (PDT) In-Reply-To: References:

Date: Thu, 20 Aug 2015 09:31:20 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Chris Wardell Content-Type: text/plain; charset=UTF-8 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] Dynamically Controlled Bitcoin Block Size Max Cap 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, 20 Aug 2015 07:31:22 -0000 On Tue, Aug 18, 2015 at 7:26 PM, Chris Wardell via bitcoin-dev wrote: > I'm no authority on the subject, but I don't understand why there is a max > block-size, other than anti-spam measures. > > The only other reason I have heard for a max-block-size is to force people > into paying higher fees. For the 73th time or so this month on this list: The maximum block size consensus rule limits mining centralization (which is currently pretty bad). But don't worry about not being an authority on the subject: Gavin (who has written extensively on the subject) doesn't seem to understand this either. He thinks it only limits full node centralization (by limiting how expensive it can be to run a full node). I thought the later would be quite obvious for everyone, but this month I've discovered that I've been extremely optimistic about people's understanding of the effects of the consensus rule they want to change. For the later reason (the one Gavin and I agree on) there's an old but very clear video explaining it: https://www.youtube.com/watch?v=cZp7UGgBR0I 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 CB17B9A for ; Thu, 20 Aug 2015 10:23:20 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.help.org (mail.help.org [70.90.2.18]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5A118E5 for ; Thu, 20 Aug 2015 10:23:19 +0000 (UTC) Received: from [10.1.10.25] (B [10.1.10.25]) by mail.help.org with ESMTPA ; Thu, 20 Aug 2015 06:23:16 -0400 To: bitcoin-dev@lists.linuxfoundation.org References:

From: Milly Bitcoin Message-ID: <55D5AA8E.7070403@bitcoins.info> Date: Thu, 20 Aug 2015 06:23:10 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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] Dynamically Controlled Bitcoin Block Size Max Cap 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, 20 Aug 2015 10:23:20 -0000 > For the 73th time or so this month on this list: > > The maximum block size consensus rule limits mining centralization > (which is currently pretty bad). Instead of posting all these messages with bald claims why don't you work on a decentralization metric which you can point to? (instead of trying to claim people don't understand things which is clearly not the case, You are just attacking people you don't agree with). Russ 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 BA5A48E8 for ; Thu, 20 Aug 2015 15:02:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 45093110 for ; Thu, 20 Aug 2015 15:02:08 +0000 (UTC) Received: by iodv127 with SMTP id v127so48964165iod.3 for ; Thu, 20 Aug 2015 08:02:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=LhtTGRyWd7/yvCyKUddnY+/pCDYFF7ha0m9Pg4IzDI8=; b=bVk2gf2vQoLt2/M0IWNa72GEU/hhJI3MU9CAH4aeysRUhjU1lOJ79TG6VT+t3sE5fr YoEGytg82a3RHmKbkQsSFuC5t4a8JmwUUqo1LP4SDbpvPcIpeTMozl5OBmki8bonS7zx ztKnJAGUZzvS4WVTfNVRWa5vRKyii+FTw72nWoTLIkEVeIImTND3xFdbQEEkzDlFdZRD WVdwWa45oKoscPJcd3nblw55RA6JHr13ZnO2heymG2XCBDILrFDnIXuY6O+qsBH1gfpC 6bDU1+Kbw5DteRkKHN87D3woEVxVS/c+5DyO3Ifei4bqG1fYSXKadkak5YcQBv/Hh0Mm Lgyg== X-Gm-Message-State: ALoCoQn04lIKSxmERDAPKn7jTGrZmMLt9dYHu/D12yuZ4eQh9AxjWe2KgBWQ/VdUAta0vXQk6K2b MIME-Version: 1.0 X-Received: by 10.107.46.86 with SMTP id i83mr2858835ioo.121.1440082927232; Thu, 20 Aug 2015 08:02:07 -0700 (PDT) Received: by 10.107.18.155 with HTTP; Thu, 20 Aug 2015 08:02:07 -0700 (PDT) X-Originating-IP: [115.187.38.4] Date: Thu, 20 Aug 2015 20:32:07 +0530 Message-ID: From: Upal Chakraborty To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a1137949e5363b7051dbf6fde X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_WEB autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap 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, 20 Aug 2015 15:02:08 -0000 --001a1137949e5363b7051dbf6fde Content-Type: text/plain; charset=UTF-8 Regarding... i. http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010493.html ii. http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010499.html Could we please keep the conversation specific to the proposal presented at http://upalc.com/maxblocksize.php ? If you find any demerits to this, please point them out. Otherwise, I'll ask for a BIP. The proposal in algorithmic format is as follows... If more than 50% of block's size, found in the first 2000 of the last difficulty period, is more than 90% MaxBlockSize Double MaxBlockSize Else if more than 90% of block's size, found in the first 2000 of the last difficulty period, is less than 50% MaxBlockSize Half MaxBlockSize Else Keep the same MaxBlockSize --001a1137949e5363b7051dbf6fde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Regarding...

i.=C2=A0http://lists.linu= xfoundation.org/pipermail/bitcoin-dev/2015-August/010493.html

ii.=C2=A0http://lists.linuxfoundation.org/pipermail/bitcoi= n-dev/2015-August/010499.html

Could we please = keep the conversation specific to the proposal presented at=C2=A0http://upalc.com/maxblocksize.php ?= If you find any demerits to this, please point them out. Otherwise, I'= ll ask for a BIP. The proposal in algorithmic format is as follows...

If=
 more than 50% of block's size, found in the first 2000 of the last dif=
ficulty period, is more than 90% MaxBlockSize
         Double MaxBlockSize
Else if more than 90% of block's size, found in the first 2000 of the l=
ast difficulty period, is less than 50% MaxBlockSize
         Half MaxBlockSize
Else
         Keep the same MaxBlockSize

--001a1137949e5363b7051dbf6fde-- 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 C23A8273 for ; Fri, 21 Aug 2015 00:26:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5BD8689 for ; Fri, 21 Aug 2015 00:26:30 +0000 (UTC) Received: by padfo6 with SMTP id fo6so33392203pad.0 for ; Thu, 20 Aug 2015 17:26:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=o5zsptqafqSZ02xIkeIKI85z6YJ9dXGYgoFilzictcY=; b=nMDPQXPjUd9YJje1XJ7Dbi7A4dG3XKLzi3EVNnmcG5eN/V3/lWwKipdsBhC/hiipD+ 2LGv2qpGA/AK+3Gowrj+q60bxuhiKLCMNiUC4SSDusROkMwVtaoacrcZW9O5juHyzrwn uHYZk8bdhXEO7fwV8Gy24qzhRJoztkh59u91UtKwpyZ5vgYfwfoG+5IpZgjiQIN0+QUg wKry/iKf7Fr5KLkybef8yYmPOg1IIxIDo3m+WcMOZVA0duYwsQQdStXAniDzRaUejVvv vlLlbrPUHboqUd/SHIMpLarYmMPlK7a6ACKRSXDXW8oqX8xnDdmhfzd1J1gjb7OenpPH Vk1g== X-Gm-Message-State: ALoCoQn7zqby8bd03UNT9J0vFKL0E2bOUP+EVnsPl1tmWMDTi4V8F7Ww5kXvPyMMAKnxOIga91vB X-Received: by 10.68.114.196 with SMTP id ji4mr11688126pbb.46.1440116790093; Thu, 20 Aug 2015 17:26:30 -0700 (PDT) Received: from [10.100.1.239] ([204.58.254.99]) by smtp.googlemail.com with ESMTPSA id uv5sm5620612pbc.12.2015.08.20.17.26.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Aug 2015 17:26:28 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References:

<55D5AA8E.7070403@bitcoins.info> From: Tom Harding Message-ID: <55D67017.9000106@thinlink.com> Date: Thu, 20 Aug 2015 17:25:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55D5AA8E.7070403@bitcoins.info> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_WEB 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] Dynamically Controlled Bitcoin Block Size Max Cap 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, 21 Aug 2015 00:26:30 -0000 On 8/20/2015 3:23 AM, Milly Bitcoin via bitcoin-dev wrote: >> For the 73th time or so this month on this list: >> >> The maximum block size consensus rule limits mining centralization >> (which is currently pretty bad). > > Instead of posting all these messages with bald claims why don't you > work on a decentralization metric which you can point to? (instead of > trying to claim people don't understand things which is clearly not > the case, You are just attacking people you don't agree with). Pieter built a nice simulation tool and posted some results. I tweaked the parameters and ran the tool in a way that tested ONLY for hashrate centralization effects, and did not conflate these with network partitioning effects. I found that small miners were not at all disadvantaged by large blocks. The only person who commented on this result agreed with me. He also complimented Pieter's insight (which is entirely appropriate since Pieter did the hard work of creating the tool). http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008820.html 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 89226279 for ; Fri, 21 Aug 2015 00:38:02 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148096.authsmtp.net (outmail148096.authsmtp.net [62.13.148.96]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id B21C0102 for ; Fri, 21 Aug 2015 00:38:01 +0000 (UTC) Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7L0c0ff056696; Fri, 21 Aug 2015 01:38:00 +0100 (BST) Received: from muck (s75-157-242-51.bc.hsia.telus.net [75.157.242.51]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7L0bqFl093951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 21 Aug 2015 01:37:57 +0100 (BST) Date: Thu, 20 Aug 2015 17:37:51 -0700 From: Peter Todd To: Tom Harding Message-ID: <20150821003751.GA19230@muck> References:

<55D5AA8E.7070403@bitcoins.info> <55D67017.9000106@thinlink.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <55D67017.9000106@thinlink.com> X-Server-Quench: df6f1a78-479c-11e5-b398-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAMUGUATAgsB AmMbW1VeU1p7XGo7 bA9PbABafEhKXRtv UVdMSlVNFUssBmAB VF9oDhl7dAxDeTB3 ZE5qECQNWhJ7JEF1 X0pTHD4bZGY1bX1N U0lQagNUcgZDfk5E bwQuUz1vNG8XDSg5 AwQ0PjZ0MThBHWx5 UwcEKFMZSEIPD3YX QBYeBzIrGUAJDw8y MxchK1hUNkIWOUZ6 ClozVBo9Og9aIQRG dwAA X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.157.242.51/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap 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, 21 Aug 2015 00:38:02 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 20, 2015 at 05:25:59PM -0700, Tom Harding via bitcoin-dev wrote: > On 8/20/2015 3:23 AM, Milly Bitcoin via bitcoin-dev wrote: > >>For the 73th time or so this month on this list: > >> > >>The maximum block size consensus rule limits mining centralization > >>(which is currently pretty bad). > > > >Instead of posting all these messages with bald claims why don't > >you work on a decentralization metric which you can point to? > >(instead of trying to claim people don't understand things which > >is clearly not the case, You are just attacking people you don't > >agree with). >=20 >=20 > Pieter built a nice simulation tool and posted some results. >=20 > I tweaked the parameters and ran the tool in a way that tested ONLY > for hashrate centralization effects, and did not conflate these with > network partitioning effects. >=20 > I found that small miners were not at all disadvantaged by large blocks. >=20 > The only person who commented on this result agreed with me. He > also complimented Pieter's insight (which is entirely appropriate > since Pieter did the hard work of creating the tool). >=20 > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008820.h= tml You used 20% as the size of the large miner, with all the small miners having good connectivity with each other. That is *not* the scenario we're worried about. The math behind the issue is that the a miner needs to get their blocks to at least 33% of hashing power, but more than that is unnecessary and only helps their competition; you simulated 20%, which is under that threshold. Equally, why are you assuming the small miner group is well connected to each other? You probably didn't get any replies because your experiment is obviously wrong and misguided, and we're all busy. --=20 'peter'[:-1]@petertodd.org 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJV1nLcXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwNDAyZmU2ZmI5YWQ2MTNjOTNlMTJiZGRmYzZlYzAyYTJi ZDkyZjAwMjA1MDU5NGQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udzkdwf/U1pW1uXaVNxkCnz3h1+MtdFH AUSP26OpLZszf+einkRMI4HwyRHjsb1jlmDTRurSTPRKNvDBFl1nC6zw/z+gC1JL 4D3wk0iiMBhCissenmuaoO0GuY9/AZw4dTAdxdIynOC49n72gdHjkkr0XTppsmCl y6w6ZFgbnmH1YlAJ+UIdZ0BDvvcBSBe7/huaSbVdRbBH3S41qvUIJLfwQuaD/8SR g1lUWnKRcCqa1Td0dzDg0g0ZO1qgZWTwa2fsXFvHfLivnbBF9r1a1KxuLsGYbR2z +mHAj6yrQkTQp6jRbXXwFB1PfXKbiBh/OEkrGefNqLVHdAYxBLYUFeHkMJDXHg== =sNv+ -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- 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 04B554D3 for ; Fri, 21 Aug 2015 00:46:04 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.help.org (mail.help.org [70.90.2.18]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 379F2102 for ; Fri, 21 Aug 2015 00:46:03 +0000 (UTC) Received: from [10.1.10.25] (B [10.1.10.25]) by mail.help.org with ESMTPA ; Thu, 20 Aug 2015 20:45:59 -0400 To: bitcoin-dev@lists.linuxfoundation.org References:

<55D5AA8E.7070403@bitcoins.info> <55D67017.9000106@thinlink.com> From: Milly Bitcoin Message-ID: <55D674C1.6000102@bitcoins.info> Date: Thu, 20 Aug 2015 20:45:53 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55D67017.9000106@thinlink.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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] Dynamically Controlled Bitcoin Block Size Max Cap 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, 21 Aug 2015 00:46:04 -0000 The idea is to come up with some sort of standardized metric so as the tools and issues come up you are comparing similar things. The first thing you have to do is link "centralization pressure" and (pressure to merge with a big miner) to some sort of overall decentralization metric. For instance, how much do big miners reduce decentralization to begin with? That is a complicated analysis on its own. Then you can measure specif use cases with a tool like that. the idea at least is that the metrics do not "take sides" on any issue and just provide a measure of whatever it is you are measuring. most of the references have to do with measuring decentralization in political systems so a system would need to be developed to apply to software projects like Bitcoin: http://www.sscnet.ucla.edu/polisci/faculty/treisman/Papers/defin.pdf http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider_Decentralization.pdf Russ > > Pieter built a nice simulation tool and posted some results. > > I tweaked the parameters and ran the tool in a way that tested ONLY for > hashrate centralization effects, and did not conflate these with network > partitioning effects. > > I found that small miners were not at all disadvantaged by large blocks. > > The only person who commented on this result agreed with me. He also > complimented Pieter's insight (which is entirely appropriate since > Pieter did the hard work of creating the tool). > > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008820.html > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > 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 79C0574 for ; Fri, 21 Aug 2015 00:58:31 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149080.authsmtp.com (outmail149080.authsmtp.com [62.13.149.80]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 9D86E102 for ; Fri, 21 Aug 2015 00:58:30 +0000 (UTC) Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7L0wSso088858; Fri, 21 Aug 2015 01:58:28 +0100 (BST) Received: from muck (s75-157-242-51.bc.hsia.telus.net [75.157.242.51]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7L0wKeA056510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 21 Aug 2015 01:58:26 +0100 (BST) Date: Thu, 20 Aug 2015 17:58:20 -0700 From: Peter Todd To: Milly Bitcoin Message-ID: <20150821005820.GA27305@muck> References:

<55D5AA8E.7070403@bitcoins.info> <55D67017.9000106@thinlink.com> <55D674C1.6000102@bitcoins.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline In-Reply-To: <55D674C1.6000102@bitcoins.info> X-Server-Quench: bbb868a3-479f-11e5-b398-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAMUGUATAgsB AmMbW1VeVVV7W2Q7 bA9PbABafEhKXRtv UVdMSlVNFUssBmAB QWVLIxl3cQBHeDB2 YURiECIJDkx8fRd+ X0pTHDsbZGY1bX1N U0lQagNUcgZDfk5E bwQuUz1vNG8XDSg5 AwQ0PjZ0MThBHWx5 UwcEKFMZSEIPD3YX QBYeBzIrGUAJDw8y MxchK1hUNkIWOUZ6 ClozVBo9Og9aIQRG dwAA X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.157.242.51/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap 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, 21 Aug 2015 00:58:31 -0000 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 20, 2015 at 08:45:53PM -0400, Milly Bitcoin via bitcoin-dev wro= te: You know, I've noticed you've spent a tremendous amount of time and energy on this list promoting these kinds of metrics; obviously you're somewhat of an expert on this compared to the rest of us. Why don't you look into spearheading one of these analyses yourself to show us how it's done? > The idea is to come up with some sort of standardized metric so as > the tools and issues come up you are comparing similar things. >=20 > The first thing you have to do is link "centralization pressure" and > (pressure to merge with a big miner) to some sort of overall > decentralization metric. For instance, how much do big miners > reduce decentralization to begin with? That is a complicated > analysis on its own. Then you can measure specif use cases with a > tool like that. >=20 > the idea at least is that the metrics do not "take sides" on any > issue and just provide a measure of whatever it is you are > measuring. >=20 > most of the references have to do with measuring decentralization in > political systems so a system would need to be developed to apply to > software projects like Bitcoin: >=20 > http://www.sscnet.ucla.edu/polisci/faculty/treisman/Papers/defin.pdf >=20 > http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider= _Decentralization.pdf --=20 'peter'[:-1]@petertodd.org 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJV1nepXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwNDAyZmU2ZmI5YWQ2MTNjOTNlMTJiZGRmYzZlYzAyYTJi ZDkyZjAwMjA1MDU5NGQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udwjhggAgzojukqTiG00pfi60SFiP9JC 73RjErxd7vxCO4YKNuiWNcoeLANpgt1NuCi/MAA1KSt9Ckk7W7YDrZ0oRsGHJCTv /P7R4AKg/wd0WXWum4ra0Dc9yK/tcf2x876dHlGh2rR7VYGxxXlxKQqdd/bXntQT Yp7X7m5Eo0ivNzeUjwBbNScucT5hoJzCqbNIEvRJLxuLxPA7kCeFgEW8f3gyL0U4 YHaEHQKrgW4UW9nUWAhYBAn5Kv2mkcNGSSbXszMFb6PF+K6Ewy6pw2NIaYHJxqNx n+g/1766Yu0C26CV/WArBrC5G1jIxQIq45stzHkUpaQB4wxYCqZ5iG/RNqKu7g== =+cuS -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- 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 227A8847 for ; Fri, 21 Aug 2015 01:30:47 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.help.org (mail.help.org [70.90.2.18]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 956E01AC for ; Fri, 21 Aug 2015 01:30:46 +0000 (UTC) Received: from [10.1.10.25] (B [10.1.10.25]) by mail.help.org with ESMTPA ; Thu, 20 Aug 2015 21:30:43 -0400 References:

<55D5AA8E.7070403@bitcoins.info> <55D67017.9000106@thinlink.com> <55D674C1.6000102@bitcoins.info> <20150821005820.GA27305@muck> From: Milly Bitcoin To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <55D67F3D.5060101@bitcoins.info> Date: Thu, 20 Aug 2015 21:30:37 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150821005820.GA27305@muck> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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] Dynamically Controlled Bitcoin Block Size Max Cap 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, 21 Aug 2015 01:30:47 -0000 Yes, I am familiar with the process as i spent years doing it. Many here are familiar with the Bitcoin issues but they are not familiar with addressing risk in a systematic way. There are many good posts but they are dispersed among thousands of messages and the discussions are in a variety of contexts. As a result, the same things are often argued over and over and much time is wasted. Note that knowing a technical area and knowing a process to analyze metrics are two different things. I am glad you want to participate in such a process. Several developers on this list have mentioned the need for a decentralization metric so i think that is a good place to start. I suggest getting the other developers/experts together and send me the various into and tools you have and I will put it together into a useable format. The idea is to create a living document so people can discuss changes in a similar context. Russ On 8/20/2015 8:58 PM, Peter Todd wrote: > On Thu, Aug 20, 2015 at 08:45:53PM -0400, Milly Bitcoin via bitcoin-dev wrote: > > You know, I've noticed you've spent a tremendous amount of time and > energy on this list promoting these kinds of metrics; obviously you're > somewhat of an expert on this compared to the rest of us. > > Why don't you look into spearheading one of these analyses yourself to > show us how it's done? 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 CE0F2305 for ; Fri, 21 Aug 2015 12:13:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AB9741C3 for ; Fri, 21 Aug 2015 12:13:08 +0000 (UTC) Received: by pawq9 with SMTP id q9so51787155paw.3 for ; Fri, 21 Aug 2015 05:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QJB83aTy+9gemkU0dUkDDWqCw6ZU1qsphaM+HYgFmpA=; b=x8krMOmA0U5DoR0vuPfPwNOnKBD+Ro6Cg0q3gnJ5nq1e+Vr9kvmXCmDKh7pb8XSx0t /d/hu/OWKMfGMzXHX3MrFP1m3tgjuBwVz++4Iad/hWPUhhAbNvNlDHMAalVJUuCfqpFk yKZBkWF4MRFIWyZQ0mdqz6c7QD9wAmaXHKRzE0uhhrotv5/+AWKe50SFxM9zyg8PHS7/ FhS8lu/yOd09lIerC6JMyvCbOK23RjuapFrEugrrtLjIgYVLouIW/M1UByo40LJxDajS yKugQw/rpsocuPwbaQuP/t3CyUAa96d+0jxlkZPvS/ObHK/l7vn1BrqA5CpR9e2JzNOc pRUA== MIME-Version: 1.0 X-Received: by 10.66.156.196 with SMTP id wg4mr16653938pab.65.1440159188415; Fri, 21 Aug 2015 05:13:08 -0700 (PDT) Received: by 10.66.83.7 with HTTP; Fri, 21 Aug 2015 05:13:08 -0700 (PDT) In-Reply-To: References:

Date: Fri, 21 Aug 2015 17:43:08 +0530 Message-ID: From: Sriram Karra To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary=047d7b86f120d87d81051dd130aa X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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] Dynamically Controlled Bitcoin Block Size Max Cap 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, 21 Aug 2015 12:13:09 -0000 --047d7b86f120d87d81051dd130aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 20, 2015 at 1:01 PM, Jorge Tim=C3=B3n < bitcoin-dev@lists.linuxfoundation.org> wrote: > > For the 73th time or so this month on this list: > > The maximum block size consensus rule limits mining centralization > (which is currently pretty bad). > > But don't worry about not being an authority on the subject: Gavin > (who has written extensively on the subject) doesn't seem to > understand this either. > If your goal is to get the Miners (who are highly centralised today) to implement a change in consensus rule that will limit mining centralisation, guess what public position you will be taking? --047d7b86f120d87d81051dd130aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Aug 20, 2015 at 1:01 PM, Jorge Tim=C3=B3n <bitcoin-dev@lists.linuxfoundation.org> wrote:

For the 73th time or so this month on this list:

The maximum block size consensus rule limits mining centralization
(which is currently pretty bad).

But don't worry about not being an authority on the subject: Gavin
(who has written extensively on the subject) doesn't seem to
understand this either.

If your goal is= to get the Miners (who are highly centralised today) to implement a change= in consensus rule that will limit mining centralisation, guess what public= position you will be taking?

--047d7b86f120d87d81051dd130aa-- 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 A7EAF9C for ; Fri, 21 Aug 2015 16:52:46 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 53820AB for ; Fri, 21 Aug 2015 16:52:46 +0000 (UTC) Received: by pawq9 with SMTP id q9so56327188paw.3 for ; Fri, 21 Aug 2015 09:52:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=R/Gm46cZhiyRWuNSiJOGPghxcz5zvvHIfrreiN2LjZc=; b=dN3/uTml6rlKEIpfyFdWbDhI+r+vAKFIG5UmFjF0PpHK9MjJiZ9+VSGIsdWUL0Q26p Gnh0gGjqkVDn1qtzus+23zK9uayUX8oy6Lc46fQlZ8tAbMiShWHuq7UsLzXe5m7Iu96K 2Ibj4DUVfwDEvwg38//8reoDxIF/w4s7AvPGbMSGv7Li3E/3v1xdtrljW6Dh7L7hwmO2 37S34jT5PjCS+00bfyG4wSky2DZoeRjdlM54z68EBcGyo+t0E26enZtTNevjp1CdJpaT ausf7JchFaHyJHj99ofNzfIA2STIoaW8drV76rlj6xdDExyPBdA4kjo4tHbAUjK8CgSn JfaA== X-Gm-Message-State: ALoCoQlACc0OGg3iaDEna4+VSnWIbjjl7kCnTgLNMKpJHPR2OEVLTIfQEn3nQGUZO5F36hz8S11R X-Received: by 10.68.117.142 with SMTP id ke14mr19149245pbb.93.1440175965849; Fri, 21 Aug 2015 09:52:45 -0700 (PDT) Received: from [192.168.1.89] (99-8-65-117.lightspeed.davlca.sbcglobal.net. [99.8.65.117]) by smtp.googlemail.com with ESMTPSA id ew13sm8428299pac.25.2015.08.21.09.52.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Aug 2015 09:52:44 -0700 (PDT) To: Peter Todd References:

<55D5AA8E.7070403@bitcoins.info> <55D67017.9000106@thinlink.com> <20150821003751.GA19230@muck> From: Tom Harding X-Enigmail-Draft-Status: N1110 Message-ID: <55D7575B.6030505@thinlink.com> Date: Fri, 21 Aug 2015 09:52:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150821003751.GA19230@muck> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap 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, 21 Aug 2015 16:52:46 -0000 On 8/20/2015 5:37 PM, Peter Todd wrote: > On Thu, Aug 20, 2015 at 05:25:59PM -0700, Tom Harding via bitcoin-dev wrote: >> I found that small miners were not at all disadvantaged by large blocks. >> > > You used 20% as the size of the large miner, with all the small miners > having good connectivity with each other. > > That is *not* the scenario we're worried about. The math behind the > issue is that the a miner needs to get their blocks to at least 33% of > hashing power, but more than that is unnecessary and only helps their > competition; you simulated 20%, which is under that threshold. Equally, > why are you assuming the small miner group is well connected to each > other? > > You probably didn't get any replies because your experiment is obviously > wrong and misguided, and we're all busy. > I gave the small miners collectively the same hashrate as the large miners in the original test. I made them well-connected because everyone was well-connected intra-partition in the original test. I just varied one thing: the size of the miners. This is a principle of experiment design, in science. Next you'll probably claim that second-order and cross-term effects dominate. Maybe you can find the time to prove it. 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 764D5847 for ; Fri, 21 Aug 2015 20:09:36 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1B86711E for ; Fri, 21 Aug 2015 20:09:35 +0000 (UTC) Received: by lbbsx3 with SMTP id sx3so50258997lbb.0 for ; Fri, 21 Aug 2015 13:09:33 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CxKoKkG+lP9ZJ3fFbAkNT/ONOcGUxCOC3VLbYSLg1K0=; b=I0l97ZGQX+pM8t2uofORGJyiUxdDEETARiwgy/VL32z2IEGYAa30FMbX17HKjfdqn0 dScGNVFR1sYiX26VIFpqi0BBpCEpJooZYKdocMsenXeXxv2GitOsAShVq41yJ7uIntaQ CBNITGCOJCUXGQWFoCxFG4OIWcZy2RgxPulHbu4lXqlBwhR1eBTduhk1L3DjElFuljOb S+Jp0spwg8a/5HFkve2p++APNSUaVdbQY9JIUdEZWtZvwGZBQLFfLflmK1byThyXWV+o F/bd+Y27SC4+1Oe7Ye/Uq1OI2B+uQbD8/ZAuLgsLVpQce/6GX2N3ay13nuC3DZak4RnN vUQw== X-Gm-Message-State: ALoCoQkSFbomAb2QA57JnyU8oMAvZWG8QGqS74fhaboOCkv6ytrrZqAeRKejLRi4yrFzC2Q60TMv MIME-Version: 1.0 X-Received: by 10.152.42.170 with SMTP id p10mr9138066lal.39.1440187773535; Fri, 21 Aug 2015 13:09:33 -0700 (PDT) Received: by 10.25.15.22 with HTTP; Fri, 21 Aug 2015 13:09:33 -0700 (PDT) In-Reply-To: References:

Date: Fri, 21 Aug 2015 22:09:33 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Sriram Karra Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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] Dynamically Controlled Bitcoin Block Size Max Cap 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, 21 Aug 2015 20:09:36 -0000 On Fri, Aug 21, 2015 at 2:13 PM, Sriram Karra wrote: > On Thu, Aug 20, 2015 at 1:01 PM, Jorge Tim=C3=B3n > wrote: >> >> >> For the 73th time or so this month on this list: >> >> The maximum block size consensus rule limits mining centralization >> (which is currently pretty bad). >> >> But don't worry about not being an authority on the subject: Gavin >> (who has written extensively on the subject) doesn't seem to >> understand this either. > > > If your goal is to get the Miners (who are highly centralised today) to > implement a change in consensus rule that will limit mining centralisatio= n, > guess what public position you will be taking? The rule is already there. My goal is to make sure we understand the potential consequences of changing that rule in the "less limitation to mining centralization" better before changing it. 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 D660A259 for ; Fri, 21 Aug 2015 20:28:33 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0BF8B14C for ; Fri, 21 Aug 2015 20:28:32 +0000 (UTC) Received: by lbcbn3 with SMTP id bn3so50342649lbc.2 for ; Fri, 21 Aug 2015 13:28:31 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=5d71H0vAas0qwCEOnvNsLvSFNFEbQbJLHynYSPXTLzA=; b=Lu8zS/8uOwnFE6j7XHugy5L5CktaKOhcTKU8AmYKovWhIp/3CZaBIfGa7IXuWNcwPt qkXxX/GH7+KJ+hO+YrNULv5U2vOMVVfIl+fFKvKfxP8uwYHpkBz1cxYIe0/q6TV+vZEM 0OA8rJBiLZuW++9E/6GgZiCi4QlN5nUCuyWrK0C/AuOfD/LZWakTnG4X0SUch5ctMVKe n5t6uI4JGszGPZuCJfySrUk8e7vCjkXWFUy5QrM9d4r3VI1LncpgVG3iy1zPI9JwP1MW 7vp8ma5f0uyeVQD11YnDylhVmbX7mmz1qkuh95ZoSSNxN1TNBfi6p8VY3HDgYOqMqQXh XMLA== X-Gm-Message-State: ALoCoQlqGpc/733b3qUa1RrNNucXi2zinN/gblZk6AHW3/d8AH9LYDHFkVQMP2nkBZ8JulydwXJF MIME-Version: 1.0 X-Received: by 10.152.219.3 with SMTP id pk3mr9476684lac.114.1440188911180; Fri, 21 Aug 2015 13:28:31 -0700 (PDT) Received: by 10.25.15.22 with HTTP; Fri, 21 Aug 2015 13:28:31 -0700 (PDT) In-Reply-To: <55D5AA8E.7070403@bitcoins.info> References:

<55D5AA8E.7070403@bitcoins.info> Date: Fri, 21 Aug 2015 22:28:31 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Milly Bitcoin Content-Type: text/plain; charset=UTF-8 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] Dynamically Controlled Bitcoin Block Size Max Cap 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, 21 Aug 2015 20:28:34 -0000 On Thu, Aug 20, 2015 at 12:23 PM, Milly Bitcoin via bitcoin-dev wrote: >> For the 73th time or so this month on this list: >> >> The maximum block size consensus rule limits mining centralization >> (which is currently pretty bad). > > > Instead of posting all these messages with bald claims why don't you work on > a decentralization metric which you can point to? Please start with the centralization metrics we both agree are necessary instead of keeping insulting me publicly and privately. > (instead of trying to > claim people don't understand things which is clearly not the case, You are > just attacking people you don't agree with). I'm not inventing this, he recently said so himself publicly on this mailing list: "I don't believe that the maximum block size has much at all to do with mining centralization" http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/009960.html It is therefore not surprising that non-developers and developers with less experience in Bitcoin than Gavin have similar misunderstandings. That claim seems in contradiction with his earlier analysis: http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners "I ran some simulations, and if blocks take 20 seconds to propagate, a network with a miner that has 30% of the hashing power will get 30.3% of the blocks." That's why I was surprised when he denied the relation between the consensus maximum size and mining centralization, but hey, people change their minds and that's completely fine. I change my mind about many things quite often myself. For example, I will change my mind about not touching the maximum blocksize consensus rule as soon as I see some data that convinces that the proposed sizes are not very risky. 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 D917F847 for ; Fri, 21 Aug 2015 21:45:38 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3CC42E2 for ; Fri, 21 Aug 2015 21:45:38 +0000 (UTC) Received: by iodb91 with SMTP id b91so95644442iod.1 for ; Fri, 21 Aug 2015 14:45:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=FjD+3+V8C+oTPXxRo73eThSftGSzJJ4NAkqF4JBfjl8=; b=cFsYc4EolD7LIGlkWOL6oIPhHvSmCcWV1MxALxWji+VYUa/W/0PxsYiETaum2WNN04 Hq/eItF96nhXkmEC5MgrHdvTgqVvQD1Kn0vMQ/WTBn36T1YgFKPw0uW0BAixB4G5FBIE jcqv4jaLoU/b0TikT6u6unm45bVpCIyLeGAWRbNmPkcT5IMpHyVrBVlyp0PWSCsjFThH YVeZiYquglhG/cM71cBelEWF/pPJdCVxwV7A2Q404ewAcftInHvtBeNQcTqfd3zdZOfU Bp5Rz8P/yDteiC17sa5/GHtY/j3Cl3jls2Ja7v1p5FA+MdNOVhYOeD0DYP0l27+i2dPB GIXQ== X-Gm-Message-State: ALoCoQkt4m0h/EmiiGE/eBlC7CeOYpYHvpqB/ersYTAICLauQ9dLMRhsb0DXfDLKEIIY+hdXi71W MIME-Version: 1.0 X-Received: by 10.107.19.94 with SMTP id b91mr8583481ioj.144.1440193537355; Fri, 21 Aug 2015 14:45:37 -0700 (PDT) Received: by 10.107.18.155 with HTTP; Fri, 21 Aug 2015 14:45:37 -0700 (PDT) X-Originating-IP: [115.187.53.147] Date: Sat, 22 Aug 2015 03:15:37 +0530 Message-ID: From: Upal Chakraborty To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a113f3c7033d746051dd930c8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, 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: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap 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, 21 Aug 2015 21:45:39 -0000 --001a113f3c7033d746051dd930c8 Content-Type: text/plain; charset=UTF-8 I have tried to solve the maximum block size debate in two different proposal. i. Depending only on previous block size calculation. ii. Depending on previous block size calculation and previous Tx fee collected by miners. Proposal 1: Depending only on previous block size calculation If more than 50% of block's size, found in the first 2000 of the last difficulty period, is more than 90% MaxBlockSize Double MaxBlockSize Else if more than 90% of block's size, found in the first 2000 of the last difficulty period, is less than 50% MaxBlockSize Half MaxBlockSize Else Keep the same MaxBlockSize Proposal 2: Depending on previous block size calculation and previous Tx fee collected by miners TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008 blocks in last 2 difficulty period TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty) If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 > 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty > TotalTxFeeInLastButOneDifficulty) ) MaxBlockSize = TotalTxFeeInLastDifficulty * MaxBlockSize / TotalTxFeeInLastButOneDifficulty Else If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty < TotalTxFeeInLastButOneDifficulty) ) MaxBlockSize = TotalTxFeeInLastDifficulty * MaxBlockSize / TotalTxFeeInLastButOneDifficulty Else Keep the same MaxBlockSize Details: http://upalc.com/maxblocksize.php Requesting for comment. --001a113f3c7033d746051dd930c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I have tried to solve the maximum block size debate i= n two different proposal.

i. Depending only on pre= vious block size calculation.

ii. Depending on pre= vious block size calculation and previous Tx fee collected by miners.

Proposal 1: Depending only on previous b= lock size calculation

If more than 50% of block= 9;s size, found in the first 2000 of the last difficulty period, is more th= an 90% MaxBlockSize

=C2=A0 =C2=A0 Double MaxBlockSize

E= lse if more than 90% of block's size, found in the first 2000 of the la= st difficulty period, is less than 50% MaxBlockSize

=C2=A0 =C2=A0= Half MaxBlockSize

Else

=C2=A0 =C2=A0 Keep the same Max= BlockSize

Proposal 2: Depending on previous block size calculat= ion and previous Tx fee collected by miners

TotalT= xFeeInLastButOneDifficulty =3D Sum of all Tx fees of first 2008 blocks in l= ast 2 difficulty period

TotalTxFeeInLastDifficulty =3D Sum of all= Tx fees of second 2008 blocks in last 2 difficulty period (This actually i= ncludes 8 blocks from last but one difficulty)

If = ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 > 50= % MaxBlockSize) AND (TotalTxFeeInLastDifficulty > TotalTxFeeInLastButOne= Difficulty) )

=C2=A0 =C2=A0 MaxBlockSize =3D TotalTxFeeInLastDiff= iculty * MaxBlockSize / TotalTxFeeInLastButOneDifficulty

Else If = ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 < 50= % MaxBlockSize) AND (TotalTxFeeInLastDifficulty < TotalTxFeeInLastButOne= Difficulty) )

=C2=A0 =C2=A0 MaxBlockSize =3D TotalTxFeeInLastDiff= iculty * MaxBlockSize / TotalTxFeeInLastButOneDifficulty

Else

=C2=A0 =C2=A0 Keep the same MaxBlockSize

Details: http://upalc.com/maxblocksize.php

Requesting for comment.

--001a113f3c7033d746051dd930c8-- 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 B41918EA for ; Fri, 21 Aug 2015 22:21:59 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148108.authsmtp.net (outmail148108.authsmtp.net [62.13.148.108]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id E821C11D for ; Fri, 21 Aug 2015 22:21:58 +0000 (UTC) Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7LMLvmw013578; Fri, 21 Aug 2015 23:21:57 +0100 (BST) Received: from muck (S0106e091f5827ad2.ok.shawcable.net [24.71.232.17]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7LMLrJ6050215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 21 Aug 2015 23:21:56 +0100 (BST) Date: Fri, 21 Aug 2015 15:21:53 -0700 From: Peter Todd To: Tom Harding Message-ID: <20150821222153.GD7450@muck> References:

<55D5AA8E.7070403@bitcoins.info> <55D67017.9000106@thinlink.com> <20150821003751.GA19230@muck> <55D7575B.6030505@thinlink.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="H4SyuGOnfnj3aJqJ" Content-Disposition: inline In-Reply-To: <55D7575B.6030505@thinlink.com> X-Server-Quench: 08ff232f-4853-11e5-b398-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAMUGUATAgsB AmMbWVdeUlx7XGQ7 aQ5PagRDYElMQQRt T01BRU1TWkFvfWF9 RGQYUhxydQRDNnl3 Y0AsXngNCkZ5dxBg RkZRFnAHZDJldTIc WUhFdwNWdQpKLx5A PgF4GhFYa3VsNCMk FAgyOXU9MCtqYAhE RAgILFkbRUIaVhU7 QQwYGjErEEFNbSQv JBsnLBY2GEEaMQ0J MEksEXcRI1c5AxU2 X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 24.71.232.17/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap 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, 21 Aug 2015 22:21:59 -0000 --H4SyuGOnfnj3aJqJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 21, 2015 at 09:52:43AM -0700, Tom Harding wrote: > On 8/20/2015 5:37 PM, Peter Todd wrote: > > On Thu, Aug 20, 2015 at 05:25:59PM -0700, Tom Harding via bitcoin-dev w= rote: >> I found that small miners were not at all disadvantaged by large > blocks. >> > > You used 20% as the size of the large miner, with all the > small miners > having good connectivity with each other. > > That is > *not* the scenario we're worried about. The math behind the > issue is > that the a miner needs to get their blocks to at least 33% of > hashing > power, but more than that is unnecessary and only helps their > > competition; you simulated 20%, which is under that threshold. Equally, > > why are you assuming the small miner group is well connected to each > > other? > > You probably didn't get any replies because your experiment > is obviously > wrong and misguided, and we're all busy. > >=20 > I gave the small miners collectively the same hashrate as the large > miners in the original test. I made them well-connected because > everyone was well-connected intra-partition in the original test. >=20 > I just varied one thing: the size of the miners. This is a principle of > experiment design, in science. >=20 > Next you'll probably claim that second-order and cross-term effects > dominate. Maybe you can find the time to prove it. This is a security issue: if you can find a likely scenario where the system fails, that's a problem and we need to fix it. You've taken the scenario where the system fails, and changed the conditions to create a scenario where it works. That's not particularly interesting or noteworthy. To use a car analogy, Pieter Wuille has shown that the brake cylinders have a fatigue problem, and if used in stop-and-go traffic regularly they'll fail during heavy braking, potentially killing someone. You've countered with a study of highway driving, showing that if the car is only used on the highway the brakes have no issues, claiming that the car design is perfectly safe. --=20 'peter'[:-1]@petertodd.org 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d --H4SyuGOnfnj3aJqJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJV16R+XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwNDAyZmU2ZmI5YWQ2MTNjOTNlMTJiZGRmYzZlYzAyYTJi ZDkyZjAwMjA1MDU5NGQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udwlaAf9FmXKLlG5dvBtoBIbiPhnbsQ1 ruJ6opUCV4MWqBs9NNA5cW/zsUOdHIe3F6hvYBy0wkiahok+JjNqqWdGrN1vAEqc 71ks3B9gRoRmhl4SO2D7osZ//vntvyhEbPSEjMQorcMsco8wizdCJr2MmvCaFQma 0MA3xxxT9lBlomc6ullfN1ZVdoATnAyPKwm7rTBrFPKHnKs2iViOLAx840mFqN93 VdvPLfgrgyY0T35a5pE7U2sxIdJydFZnIw4QshgCvasbbXbcDbvdxV9EMJORfq3M YC/Q+8E1H4VsJ7vXZ9NP6ukLKTcvJDQyTnJe4IwQ1GlwbuEmxoUOmbE0Z32j7A== =L+a2 -----END PGP SIGNATURE----- --H4SyuGOnfnj3aJqJ-- 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 BCA9B8EA for ; Fri, 21 Aug 2015 23:16:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 704C3115 for ; Fri, 21 Aug 2015 23:16:39 +0000 (UTC) Received: by padfo6 with SMTP id fo6so16393617pad.1 for ; Fri, 21 Aug 2015 16:16:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=u9Np8NVzH/apEbXJkkhjQeFXTwHOFiVDUkCkiAIQuRM=; b=jRvBndFi9I8KWzOPyB7WmYoKqtdmOY1ALUGJDU2QJ39f6nrITaeUucQ35vmwM12Rq0 Z5uIkMcNEgLUnqlgSTrtkajwFaU0gwRlUif4MCK2NbxCpqUDIlWkFcLKi9ZaNwPpJqto VQEMfnORa0bI9gmBw8urgTuhYLFGKV0SMg9ZhUUAJHuDqwXGygpUrTy7i0d/c9qLH/uJ I79+KGxjVYtfBGNppFivlSlqt7wU9FgsdvQw70jY49/xLdfpm0rWIGbFwmHoD5fMRPMF +bbXKUNy1R53R2vWTUhueq0ZcnR9B7T+j1KbsiqUD0XB1fyJNcR947zncYGydCxShQFS AEwA== X-Gm-Message-State: ALoCoQkBDvy8MUAgLAR2yHFfj6LBQjAJ73KmLkcRlja+gZOu+2Cddn1+OnCaP8ilufAiyjfd5Ytp X-Received: by 10.66.161.232 with SMTP id xv8mr21705082pab.137.1440198999179; Fri, 21 Aug 2015 16:16:39 -0700 (PDT) Received: from [192.168.1.89] (99-8-65-117.lightspeed.davlca.sbcglobal.net. [99.8.65.117]) by smtp.googlemail.com with ESMTPSA id hh3sm9003066pbc.8.2015.08.21.16.16.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Aug 2015 16:16:37 -0700 (PDT) To: Peter Todd References:

<55D5AA8E.7070403@bitcoins.info> <55D67017.9000106@thinlink.com> <20150821003751.GA19230@muck> <55D7575B.6030505@thinlink.com> <20150821222153.GD7450@muck> From: Tom Harding X-Enigmail-Draft-Status: N1010 Message-ID: <55D7B157.904@thinlink.com> Date: Fri, 21 Aug 2015 16:16:39 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150821222153.GD7450@muck> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap 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, 21 Aug 2015 23:16:39 -0000 On 8/21/2015 3:21 PM, Peter Todd wrote: > To use a car analogy, Pieter Wuille has shown that the brake cylinders > have a fatigue problem, and if used in stop-and-go traffic regularly > they'll fail during heavy braking, potentially killing someone. You've > countered with a study of highway driving, showing that if the car is > only used on the highway the brakes have no issues, claiming that the > car design is perfectly safe. No. If we must play the analogy game, it was found that the car crashes when the brakes are bad (minority hash power partitioned) the radio is on (partitioned miners had small individual hashrate). I checked the scenario where only the radio is on, and found the car does not crash. 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 3B92991A for ; Sat, 22 Aug 2015 00:01:35 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149055.authsmtp.co.uk (outmail149055.authsmtp.co.uk [62.13.149.55]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 76822FE for ; Sat, 22 Aug 2015 00:01:34 +0000 (UTC) Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7M01XMx065442; Sat, 22 Aug 2015 01:01:33 +0100 (BST) Received: from muck (S0106e03f49079160.ok.shawcable.net [174.4.1.120]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7M01Sn7049195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 22 Aug 2015 01:01:31 +0100 (BST) Date: Fri, 21 Aug 2015 17:01:27 -0700 From: Peter Todd To: Tom Harding Message-ID: <20150822000127.GA5679@muck> References:

<55D5AA8E.7070403@bitcoins.info> <55D67017.9000106@thinlink.com> <20150821003751.GA19230@muck> <55D7575B.6030505@thinlink.com> <20150821222153.GD7450@muck> <55D7B157.904@thinlink.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <55D7B157.904@thinlink.com> X-Server-Quench: f25065a0-4860-11e5-b398-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAAUGUATAgsB AmMbW1VeUFx7WmE7 ag1VcwFDY1RPXQV1 VUBOXVMcUAIVAR1i WBkeVhBzfgAIfnp5 Ywg0XHVbWkErdVt5 SkhUCGwHMGJ9OmMW WF1YdwFReQMbfxoR O1cxNiYHcQ5VPz4z GA41ejw8IwAXBDVT SwQMJlsWRVdDNTk6 WwoFGTEiEQUvRjk4 KB0gYnQYG00Sen4z I1ZpfFsIezQbEmUA X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 174.4.1.120/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap 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: Sat, 22 Aug 2015 00:01:35 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 21, 2015 at 04:16:39PM -0700, Tom Harding wrote: > On 8/21/2015 3:21 PM, Peter Todd wrote: > > To use a car analogy, Pieter Wuille has shown that the brake cylinders > > have a fatigue problem, and if used in stop-and-go traffic regularly > > they'll fail during heavy braking, potentially killing someone. You've > > countered with a study of highway driving, showing that if the car is > > only used on the highway the brakes have no issues, claiming that the > > car design is perfectly safe.=20 >=20 > No. If we must play the analogy game, it was found that the car crashes > when the brakes are bad (minority hash power partitioned) the radio is > on (partitioned miners had small individual hashrate). >=20 > I checked the scenario where only the radio is on, and found the car > does not crash. Incidentally, what's your acceptable revenue difference between a small (1% hashing power) and large (%30 hashing power) miner, all else being equal? (remember that we shouldn't preclude variance reduction techniques such as p2pool and pooled-solo mode) Equally, what kind of attacks on miners do you think we need to be able to resist? E.g. DoS attacks, hacking, etc. That would let me know if you're definition of "the brakes are bad" corresponds to normal usage, or something that's not reasonable to design for. --=20 'peter'[:-1]@petertodd.org 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGqBAEBCACVBQJV17vUXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwNDAyZmU2ZmI5YWQ2MTNjOTNlMTJiZGRmYzZlYzAyYTJi ZDkyZjAwMjA1MDU5NGQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udxNPwf1GmKP0EQJiEqJA+4OMyYv0eoG FcuyUL55hxuIaT20ccPqAYM3AWPfkhMdWbUqoX2uNVFLzdAOh6NVqY5Fmjo0sXuB uceLdO1HeBO1V//OwejV4eJ3jzvQvZLgkL7agDbwnc4PDcD5JKAG6oumFLe8utoe vcPqIyuj2H7XjTCSngLZq9APeF1u3s/J6/wQ76pl6vuVxw9pGXhjkY/v8MWXe/Pf OAOQakwMij/G476qhXFuP+3rQSNK2tJSD2gx5ZCavBwSYcBB+qtBAwETKAlRFRdS KRxC3Qm+6EIprYj0OBoZLUiCSnPUYuxsQpSUiXEaPpdpsQspKYu0icoIM8nW =+CC1 -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- 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 BFF2E898 for ; Sat, 22 Aug 2015 03:21:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DF3AA89 for ; Sat, 22 Aug 2015 03:21:24 +0000 (UTC) Received: by lbcbn3 with SMTP id bn3so53665750lbc.2 for ; Fri, 21 Aug 2015 20:21:23 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=IS0Iz3yDGAg3LHHnSusRNatA4ZzPJ8gNdeQ/BDYYi14=; b=ECt4fMw4XMuIweG98IvGRpjsOBN8/rx26MvLX1BKfv/7eL+cQbina9paNPgLG0kUff 7XpZXnVytfRhJODP+xXMG/eAN7xKAH5I6jg9eHzLjfHnshU+XyDXFfW0pIWlUTjDK14B lG9GlS6gDXiI6s+LPNGe+7nuS3c13Mr8G//yluOO5dECCfi1+ammhhZfvCA4i9MSM9n3 e/zu6mVvf+63BJqNBBmi95rGcvfmuKZFYsmR/yIeVxgPRU4dK8dwFlDXfXOFoKybneKQ wCU0RjN4X9Wh4OKT6MjwkBGUZFWT6eyqLZUAiYKLL3LfklWk2pj1g6mnEtWGEEZ4JHly 3uJA== X-Gm-Message-State: ALoCoQlx3xbMepG858pPNlzuMEVXbUkUKgs3z2jG/WpjKcehuXqdKg3Hm4dE3KjB0EhF7i4zPbO5 MIME-Version: 1.0 X-Received: by 10.112.172.201 with SMTP id be9mr10484342lbc.39.1440213683021; Fri, 21 Aug 2015 20:21:23 -0700 (PDT) Received: by 10.25.15.22 with HTTP; Fri, 21 Aug 2015 20:21:22 -0700 (PDT) Received: by 10.25.15.22 with HTTP; Fri, 21 Aug 2015 20:21:22 -0700 (PDT) In-Reply-To: <20150822000127.GA5679@muck> References:

<55D5AA8E.7070403@bitcoins.info> <55D67017.9000106@thinlink.com> <20150821003751.GA19230@muck> <55D7575B.6030505@thinlink.com> <20150821222153.GD7450@muck> <55D7B157.904@thinlink.com> <20150822000127.GA5679@muck> Date: Sat, 22 Aug 2015 05:21:22 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Peter Todd Content-Type: multipart/alternative; boundary=001a11c3888efa3eae051ddde006 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, 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] Dynamically Controlled Bitcoin Block Size Max Cap 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: Sat, 22 Aug 2015 03:21:25 -0000 --001a11c3888efa3eae051ddde006 Content-Type: text/plain; charset=UTF-8 Don't you mean profits instead of revenue? On Aug 21, 2015 5:01 PM, "Peter Todd via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Fri, Aug 21, 2015 at 04:16:39PM -0700, Tom Harding wrote: > > On 8/21/2015 3:21 PM, Peter Todd wrote: > > > To use a car analogy, Pieter Wuille has shown that the brake cylinders > > > have a fatigue problem, and if used in stop-and-go traffic regularly > > > they'll fail during heavy braking, potentially killing someone. You've > > > countered with a study of highway driving, showing that if the car is > > > only used on the highway the brakes have no issues, claiming that the > > > car design is perfectly safe. > > > > No. If we must play the analogy game, it was found that the car crashes > > when the brakes are bad (minority hash power partitioned) the radio is > > on (partitioned miners had small individual hashrate). > > > > I checked the scenario where only the radio is on, and found the car > > does not crash. > > Incidentally, what's your acceptable revenue difference between a small > (1% hashing power) and large (%30 hashing power) miner, all else being > equal? (remember that we shouldn't preclude variance reduction > techniques such as p2pool and pooled-solo mode) > > Equally, what kind of attacks on miners do you think we need to be able to > resist? E.g. DoS attacks, hacking, etc. > > That would let me know if you're definition of "the brakes are bad" > corresponds to normal usage, or something that's not reasonable to > design for. > > -- > 'peter'[:-1]@petertodd.org > 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a11c3888efa3eae051ddde006 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Don't you mean profits instead of revenue?

On Aug 21, 2015 5:01 PM, "Peter Todd via bitcoin-dev&qu= ot; <bitcoin-de= v@lists.linuxfoundation.org> wrote:
>
> On Fri, Aug 21, 2015 at 04:16:39PM -0700, Tom Harding wrote:
> > On 8/21/2015 3:21 PM, Peter Todd wrote:
> > > To use a car analogy, Pieter Wuille has shown that the brake= cylinders
> > > have a fatigue problem, and if used in stop-and-go traffic r= egularly
> > > they'll fail during heavy braking, potentially killing s= omeone. You've
> > > countered with a study of highway driving, showing that if t= he car is
> > > only used on the highway the brakes have no issues, claiming= that the
> > > car design is perfectly safe.
> >
> > No.=C2=A0 If we must play the analogy game, it was found that the= car crashes
> > when the brakes are bad (minority hash power partitioned) the rad= io is
> > on (partitioned miners had small individual hashrate).
> >
> > I checked the scenario where only the radio is on, and found the = car
> > does not crash.
>
> Incidentally, what's your acceptable revenue difference between a = small
> (1% hashing power) and large (%30 hashing power) miner, all else being=
> equal? (remember that we shouldn't preclude variance reduction
> techniques such as p2pool and pooled-solo mode)
>
> Equally, what kind of attacks on miners do you think we need to be abl= e to
> resist? E.g. DoS attacks, hacking, etc.
>
> That would let me know if you're definition of "the brakes ar= e bad"
> corresponds to normal usage, or something that's not reasonable to=
> design for.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--001a11c3888efa3eae051ddde006-- 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 CB859847 for ; Sat, 22 Aug 2015 06:26:48 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149082.authsmtp.co.uk (outmail149082.authsmtp.co.uk [62.13.149.82]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 05D4A106 for ; Sat, 22 Aug 2015 06:26:47 +0000 (UTC) Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt16.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7M6Qj3L016407; Sat, 22 Aug 2015 07:26:45 +0100 (BST) Received: from [25.83.116.0] ([24.114.26.110]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7M6Qcl0041548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Aug 2015 07:26:41 +0100 (BST) In-Reply-To: References:

<55D5AA8E.7070403@bitcoins.info> <55D67017.9000106@thinlink.com> <20150821003751.GA19230@muck> <55D7575B.6030505@thinlink.com> <20150821222153.GD7450@muck> <55D7B157.904@thinlink.com> <20150822000127.GA5679@muck> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Peter Todd Date: Sat, 22 Aug 2015 06:26:32 +0000 To: =?ISO-8859-1?Q?Jorge_Tim=F3n?= Message-ID: X-Server-Quench: c21bb52c-4896-11e5-b398-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdAAUGUATAgsB AmMbW1NeUlt7XWc7 aQ5PbARZfEhIQQRr UFdNRFdNFUssBmEH Z01CUhl2dgBCcDB1 YkZhECNZXRYocEQu X0pcHGsbZGY1bX1N U0lQagNUcgZDfk5E bwQuUz1vNG8XDSg5 AwQ0PjZ0MThBHWx5 UwcEKFMZSEIPD3YX QBYeBzIrGUAJDw8y MxchK1hUNkIWOUZ6 ClozVBo9Og9aIQRG dwAA X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 24.114.26.110/465 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, URIBL_BLACK autolearn=no 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] Dynamically Controlled Bitcoin Block Size Max Cap 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: Sat, 22 Aug 2015 06:26:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 21 August 2015 20:21:22 GMT-07:00, "Jorge TimÃ³n" wrote: >Don't you mean profits instead of revenue? Actually no. I thought revenue would be a less subjective question to ask, with more focus on the underlying orphan rate question; part of the answer might include an assumed profit margin. -----BEGIN PGP SIGNATURE----- iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV2BYO AAoJEMCF8hzn9Lncz4MH/3Z+n1sWPIBSjRebDdZdiFZvJhOYknpE9fzHo2zv6euY qDkQS5uAXbFroF2jrm41H3hjtDXcy0mBIgxhhYMesia8ck9jXb2mXuUlnltBNzgK XeNEWgie1Y2kvXkeq1pXgPLtWWi9W54kQQ9IrpoMpasBMmP8UHh5WuzSqrWFP8Ha HD8smRbByhc6ydEHbVE8FaYxg9ijBIM1e0sh3W+QPgRG8ATAaH6UVJu01YkKHtwS V7PLW0m8WAEH+DAMV54Wgzm6prreQGy3KmldHDF58iMLzescdDIc0Pvotw613rvz 06KgQkQ20ba75XeJQOqXBygGoYS3qHOa9XwVyYq1S7g= =elAX -----END PGP SIGNATURE----- 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 B843987A for ; Sun, 23 Aug 2015 23:41:15 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6D3ED28F for ; Sun, 23 Aug 2015 23:41:15 +0000 (UTC) Received: by pacti10 with SMTP id ti10so9233673pac.0 for ; Sun, 23 Aug 2015 16:41:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=KbyNd4mSYkKpgwWJYVEDONej3ZCyLLizc6BE1hkL5wg=; b=PdxJNd4N+JlSWUwh9aJcNXAf+WFEuWsm2glrcpJMK38zjDqSYza0SuWRWK08Mxhofw 7lyQrbUeARrScbqwyl+WSsbLmpprDJNkDxNi+udt5OK0N9ZB3ZUkzhgM70/O3rF/BrLi 786N/I8j12M+CXoxSCjnfpZlIo9j25JwYp6fBry8vC2bSK7Zjouuxug361t7TP9XOuk5 r7EB4FRN0f85k6x+sHzdLLgF6jJgDCvEh8ATXFkYVuQvv2wQW542/oTcj+vNVRd6X5hw bHiw4SMY8lCm/4mYsPhnVqLtnNbQAhbyspKtveS5/p4mc1kXJdmpumZTvc55svFO438V oE/g== X-Gm-Message-State: ALoCoQn25jUeHp7E7KeYchiE7AiaSLgZhA+SFC5YkhqNQKUoEhqnFIG9cWg3kQuKdUY8htI1McPc X-Received: by 10.66.233.164 with SMTP id tx4mr13358651pac.21.1440373275065; Sun, 23 Aug 2015 16:41:15 -0700 (PDT) Received: from [192.168.1.89] (99-8-65-117.lightspeed.davlca.sbcglobal.net. [99.8.65.117]) by smtp.googlemail.com with ESMTPSA id fm5sm15027538pbb.60.2015.08.23.16.41.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Aug 2015 16:41:13 -0700 (PDT) To: Peter Todd References:

<55D5AA8E.7070403@bitcoins.info> <55D67017.9000106@thinlink.com> <20150821003751.GA19230@muck> <55D7575B.6030505@thinlink.com> <20150821222153.GD7450@muck> <55D7B157.904@thinlink.com> <20150822000127.GA5679@muck> From: Tom Harding X-Enigmail-Draft-Status: N1010 Message-ID: <55DA5A1C.8080105@thinlink.com> Date: Sun, 23 Aug 2015 16:41:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150822000127.GA5679@muck> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap 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, 23 Aug 2015 23:41:15 -0000 On 8/21/2015 5:01 PM, Peter Todd wrote: > >> I checked the scenario where only the radio is on, and found the car >> does not crash. > Incidentally, what's your acceptable revenue difference between a small > (1% hashing power) and large (%30 hashing power) miner, all else being > equal? (remember that we shouldn't preclude variance reduction > techniques such as p2pool and pooled-solo mode) > > Equally, what kind of attacks on miners do you think we need to be able to > resist? E.g. DoS attacks, hacking, etc. > None of this is in the scope of Pieter's simulation. If you think that casts doubt on my conclusions, then it casts doubt on his original conclusions as well. 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 6824FFF for ; Mon, 24 Aug 2015 02:27:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B2EF0106 for ; Mon, 24 Aug 2015 02:27:04 +0000 (UTC) Received: by labgv11 with SMTP id gv11so854007lab.2 for ; Sun, 23 Aug 2015 19:27:03 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=Wny4wzqkX4Nv9XDRrKgaOMBujtojEAny6/hbbV5WrB8=; b=WFHCPimaI8Y0U1JqfxBmJIO9qTOIAisVXZCCthaVgV+3a4RmctqgPcMIUBihEnf+fF zoEpEkwQuOLT40sJV4x4MKyiG8wrxq/Oa51UPJYIIe+kBIxgEmzxwEWOmZZeierRrS1F IF5T6LXaivtmg5HVFl7aNR2ywwUP7ZVeNpDJcUNWkMcgi5CupgsfZcGpw7njBPMhnBzI bFO2dNWphMtsv7Le3bjJR/sbnDKJfcHJCgw/LluGOXpyMz0E7jL7Bcp5gBbWpiMw/0wp hjBlKHdYOlmdLkxZG8abTWRGU7w6GkSKRGz4sAbL7edTcphhSOe6MCcmUR6LUXWxiT9k OfQQ== X-Gm-Message-State: ALoCoQmxBQz/zgyE9TQ6Str+koCtQ3nbOYSAMfO0Q7waocfqBO3zfEDt2gGiNS13rv6nVFdxkIUY MIME-Version: 1.0 X-Received: by 10.112.156.168 with SMTP id wf8mr18108164lbb.114.1440383223091; Sun, 23 Aug 2015 19:27:03 -0700 (PDT) Received: by 10.25.15.22 with HTTP; Sun, 23 Aug 2015 19:27:02 -0700 (PDT) In-Reply-To: <55DA5A1C.8080105@thinlink.com> References:

<55D5AA8E.7070403@bitcoins.info> <55D67017.9000106@thinlink.com> <20150821003751.GA19230@muck> <55D7575B.6030505@thinlink.com> <20150821222153.GD7450@muck> <55D7B157.904@thinlink.com> <20150822000127.GA5679@muck> <55DA5A1C.8080105@thinlink.com> Date: Mon, 24 Aug 2015 04:27:02 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Tom Harding Content-Type: text/plain; charset=UTF-8 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] Dynamically Controlled Bitcoin Block Size Max Cap 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: Mon, 24 Aug 2015 02:27:05 -0000 On Mon, Aug 24, 2015 at 1:41 AM, Tom Harding via bitcoin-dev wrote: > On 8/21/2015 5:01 PM, Peter Todd wrote: >> >>> I checked the scenario where only the radio is on, and found the car >>> does not crash. >> Incidentally, what's your acceptable revenue difference between a small >> (1% hashing power) and large (%30 hashing power) miner, all else being >> equal? (remember that we shouldn't preclude variance reduction >> techniques such as p2pool and pooled-solo mode) >> >> Equally, what kind of attacks on miners do you think we need to be able to >> resist? E.g. DoS attacks, hacking, etc. >> > > None of this is in the scope of Pieter's simulation. > > If you think that casts doubt on my conclusions, then it casts doubt on > his original conclusions as well. As far as I know, "his conclusions" were that there was an effect, while suspending judgement on whether that effect was high enough to be important for a given size or not.