X-List-Received-Date: Thu, 30 Jul 2015 14:25:04 -0000 --089e0160b63e14acff051c1878a9 Content-Type: text/plain; charset=UTF-8 Hello all, here is a proposal for long-term scalability I've been working on: https://gist.github.com/sipa/c65665fc360ca7a176a6 Some things are not included yet, such as a testnet whose size runs ahead of the main chain, and the inclusion of Gavin's more accurate sigop checking after the hard fork. Comments? -- Pieter --089e0160b63e14acff051c1878a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello all,

here is a prop= osal for long-term scalability I've been working on: https://gist.github.com/sipa/c6= 5665fc360ca7a176a6

Some things are not included yet, such = as a testnet whose size runs ahead of the main chain, and the inclusion of = Gavin's more accurate sigop checking after the hard fork.

= Comments?

--

Pieter

--089e0160b63e14acff051c1878a9-- 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 77DD4482 for ; Thu, 30 Jul 2015 15:05:16 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F35291F0 for ; Thu, 30 Jul 2015 15:05:07 +0000 (UTC) Received: by igbpg9 with SMTP id pg9so12800401igb.0 for ; Thu, 30 Jul 2015 08:05:07 -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=2RE+wRwfkI3oc8vLBuWVo2FjwI0vd3kD86e31QqIjYk=; b=QSeXF74BDURc7nQyACmejewEN9fMkOieo5AfrCvjAzKQspQ8eIn6rmWH7vyqJPuTmX iLZQaVqRQoD2gagila4YqnpFO6QheUgtFzz5vXom4VWHjYGpczWGv4Kgm5pFQPKnrNS/ xiA8HrCCawpDztWiF6dYbc+U+sK3K1c2QKQCMqAz6ZC0ZW95AsupQdOH/NBYGKb9vnw4 IfcFF7M1WDz1Alc48V9SDP/Hl3kjqPUrl8aptDQ9d9FssMvozoAnEOczcvj1y2DdLrjP kXZA1zsgLXf8e4dqN+MDrZilgRWbRGf9cX3NaP6xboF2aVQFGXmM2Zd146bIsWNFHZCx PKHQ== X-Received: by 10.50.13.34 with SMTP id e2mr5775273igc.23.1438268707534; Thu, 30 Jul 2015 08:05:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.15.164 with HTTP; Thu, 30 Jul 2015 08:04:47 -0700 (PDT) In-Reply-To: References: From: Greg Sanders Date: Thu, 30 Jul 2015 11:04:47 -0400 Message-ID: To: Pieter Wuille Content-Type: multipart/alternative; boundary=089e01182d04677ea6051c1907a1 X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,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] Block size following technological growth X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 15:05:16 -0000 --089e01182d04677ea6051c1907a1 Content-Type: text/plain; charset=UTF-8 What, if any, methods would be used for miners to communicate their upgrade? Greg On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello all, > > here is a proposal for long-term scalability I've been working on: > https://gist.github.com/sipa/c65665fc360ca7a176a6 > > Some things are not included yet, such as a testnet whose size runs ahead > of the main chain, and the inclusion of Gavin's more accurate sigop > checking after the hard fork. > > Comments? > > -- > Pieter > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --089e01182d04677ea6051c1907a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

What, if any, methods would be used for miners to communic= ate their upgrade?=C2=A0

Greg

On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wui= lle via bitcoin-dev <bitcoin-dev@lists.linuxfoundation= .org> wrote:

Hello all,

here is a proposal for long-= term scalability I've been working on: https://gist.github.com/sip= a/c65665fc360ca7a176a6

Some things are not included yet, s= uch as a testnet whose size runs ahead of the main chain, and the inclusion= of Gavin's more accurate sigop checking after the hard fork.

Comments?

--
=
Pieter

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

--089e01182d04677ea6051c1907a1-- 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 BD1D0481 for ; Thu, 30 Jul 2015 15:12:21 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0FF1D1F7 for ; Thu, 30 Jul 2015 15:12:20 +0000 (UTC) Received: by wibud3 with SMTP id ud3so25222640wib.1 for ; Thu, 30 Jul 2015 08:12:19 -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=/Lzeb8/HeANtyUyBoNph4U7cnXJ2g3LjmWS5NnJ7IyY=; b=W220nMIgNpgUzpPhCdawlx1ggAlv2QF9jLt7V/26z+OSDtocWSeE6wfX5hbu6dMB82 M81qMm91yRqovMIWhcuIWrkgAz25FqqEzshr55eojtMyRh+zTN71ZrTMw0we1TKPWzPI plc7m01y6r0LIPDrg5L9oE2c9DG20xB2vwdiik4QyjLvkxQtg+8Ge36sDRPJll8y/Qup HNdKUhWzxeaD7df4H1cpwmtg2uXfbPFw2UXhTpJxv0VnNbm4HzQsm4u6BJY/YTJus0Te TH7ymJLIfMf+6TuoKT5QGUDq7ngmEfZKidx//TuFsY4wuNiyN4RSb+fEgcfm1nP3He2Z Oz4w== X-Gm-Message-State: ALoCoQme4aCjeSczfCZl+qfRQjYmroopqvxYSkXqKw+XEt+pGMxeNg16naTlirlLN+zNRwlmpVNP MIME-Version: 1.0 X-Received: by 10.180.37.74 with SMTP id w10mr6938485wij.92.1438269139497; Thu, 30 Jul 2015 08:12:19 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Thu, 30 Jul 2015 08:12:19 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jul 2015 17:12:19 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Pieter Wuille 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] Block size following technological growth X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 15:12:21 -0000 1) Unlike previous blocksize hardfork proposals, this uses median time instead of block.nTime for activation. I like that more but my preference is still using height for everything. But that discussion is not specific to this proposal, so it's better if we discuss that for all of them here: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.htm= l 2) I think uncontroversial hardforks should also take miner confirmation into account, just like uncontroversial softforks do. We cannot make sure other users have upgraded before activating the chain, but we can know whether miners have upgraded or not. Having that tool available, why not use it. Of course other hardforks may not care about miners' upgrade state. For example "anti-miner hardforks, see https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org#asic-reset-= hardfork But again, this is common to all uncontroversial hardforks, so it would probably better to discussed it in http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.htm= l (gmaxwell assigned to bip99 to my bip draft). 3) As commented to you privately, I don't like to make any assumptions about technological advancements (much less on economical growth). I don't expect many people to agree with me here (I guess I've seen too many "peak oil" [or more generally, peak energy production] plus I've read Nietzsche's "On the utility and liability of history for life" [1]; so considering morals, technology or economics as "monotonic functions" in history is simply a ridiculous notion to me), but it's undeniable that internet connections have improved overall around the world in the last 6 years. I think we should wait for the technological improvements to happen and then adapt the blocksize accordingly. I know, that's not a "definitive solution", we will need to change it from time to time and this is somewhat ugly. But even if I'm the only one that considers a "technological de-growth" possible, I don't think is wise to rely on pseudo-laws like Moore's or Nielsen=E2=80=99s so-called "laws". Stealing a quote from another thread: "Prediction is difficult, especially about the future." - Niels Bohr So I would prefer a more limited solution like bip102 (even though I would prefer to have some simulations leading to a concrete value (even if it's bigger) rather than using 2MB's arbitrary number. Those are my 3 cents. [1] https://philohist.files.wordpress.com/2008/01/nietzsche-uses-history.pd= f On Thu, Jul 30, 2015 at 4:25 PM, Pieter Wuille via bitcoin-dev wrote: > Hello all, > > here is a proposal for long-term scalability I've been working on: > https://gist.github.com/sipa/c65665fc360ca7a176a6 > > Some things are not included yet, such as a testnet whose size runs ahead= of > the main chain, and the inclusion of Gavin's more accurate sigop checking > after the hard fork. > > Comments? > > -- > Pieter > > > _______________________________________________ > 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 75FEE4A5 for ; Thu, 30 Jul 2015 16:20:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D66C2214 for ; Thu, 30 Jul 2015 16:20:31 +0000 (UTC) Received: by lagw2 with SMTP id w2so28290274lag.3 for ; Thu, 30 Jul 2015 09:20:30 -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=aQjv0cvXKPJot52bFV16+lfYpUvw/96318SZ2D6r5dI=; b=vkckuRSbFP1YvfVMZ79g8Db/zXjKULEgRrusxirkSoGo19bCYTA9V5BHgzvuY7Bzo0 AQjZeFTYF28UNT2+qxuxyVwweuvA/0uvemPNGKVnPL0ipQ/6yEK8pdE9otCSKxtoB0eB RNwAVNEDAOwthZmEaDpEsJD9qgZzbY+Q5+TPymGesebUtPfTOSraeXZrvGAGSWP8eCMz N1KJE6KPoCwbol93o/HVM79c6BKLCHCoydHHoJIqQaRb/gX2KxjlpJ8/NLaEwA8S9N9Y AON56h3lCmwf3ThF3MJbJQmNELpn+fnsw9j/37GgekkUgy3Wa5yIdYa4qFDiNMYQS5Y6 g2WQ== MIME-Version: 1.0 X-Received: by 10.112.199.133 with SMTP id jk5mr46261958lbc.32.1438273230104; Thu, 30 Jul 2015 09:20:30 -0700 (PDT) Received: by 10.25.18.228 with HTTP; Thu, 30 Jul 2015 09:20:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jul 2015 12:20:30 -0400 Message-ID: From: Gavin Andresen To: Pieter Wuille Content-Type: multipart/alternative; boundary=001a11c264bef87130051c1a14f7 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] Block size following technological growth X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 16:20:32 -0000 --001a11c264bef87130051c1a14f7 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Some things are not included yet, such as a testnet whose size runs ahead > of the main chain, and the inclusion of Gavin's more accurate sigop > checking after the hard fork. > > Comments? > First, THANK YOU for making a concrete proposal! Specific comments: So we'd get to 2MB blocks in the year 2021. I think that is much too conservative, and the most likely effect of being that conservative is that the main blockchain becomes a settlement network, affordable only for large-value transactions. I don't think your proposal strikes the right balance between centralization of payments (a future where only people running payment hubs, big merchants, exchanges, and wallet providers settle on the blockchain) and centralization of mining. I'll comment on using median time generally in Jorge's thread, but why does monotonically increasing matter for max block size? I can't think of a reason why a max block size of X bytes in block N followed by a max size of X-something bytes in block N+1 would cause any problems. -- -- Gavin Andresen --001a11c264bef87130051c1a14f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On T= hu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

Some things are not includ= ed yet, such as a testnet whose size runs ahead of the main chain, and the = inclusion of Gavin's more accurate sigop checking after the hard fork.<= br>

Comments?

First, THANK YOU f= or making a concrete proposal!

Specific comments:<= /div>

So we'd get to 2MB blocks in the year 2021. I = think that is much too conservative, and the most likely effect of being th= at conservative is that the main blockchain becomes a settlement network, a= ffordable only for large-value transactions.

I don= 't think your proposal strikes the right balance between centralization= of payments (a future where only people running payment hubs, big merchant= s, exchanges, and wallet providers settle on the blockchain) and centraliza= tion of mining.

I= 9;ll comment on using median time generally in Jorge's thread, but why = does monotonically increasing matter for max block size? I can't think = of a reason why a max block size of X bytes in block N followed by a max si= ze of X-something bytes in block N+1 would cause any problems.

<= div>

--
Gavin Andresen

--001a11c264bef87130051c1a14f7-- 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 E6418282 for ; Thu, 30 Jul 2015 16:23:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A407A15B for ; Thu, 30 Jul 2015 16:23:18 +0000 (UTC) Received: by wibxm9 with SMTP id xm9so251882119wib.0 for ; Thu, 30 Jul 2015 09:23:17 -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=+eC3r3oqcBrAgiPRvVPmzmBuGQ3bay3Ts+MyOWNUIq4=; b=fIQpwiigeGl1FQu1v+L/LHHdLvgXBpzRpyPpPhIQG23a4WAaGLK3AJod2cTmLWt89h ZN0eiB3CJfxy7O27wQBQtFiUrP2/VdrXP/U362cPy7c/xjS67QVUYLFlqLYH2ridK0GP V2UyOY8SKHuTKfWPtC9Zm0CXHTvvYK2AlTrKW64jwIoqrFa/Ol4WwvGUVd4B5icTTbLd 1lCp09Kx88G40hyI7Mv58OvILE0hkNhaWrzROSB0Gepleu9KB4MzZBTdpOt9BuA1G4FM gXEiwVtKjboVnN9FlbVQ3BVgFg483mxw3dXqJA2zD9CecQS7gSMCVbTwZmXz2f4CMb+o 03eQ== MIME-Version: 1.0 X-Received: by 10.180.218.195 with SMTP id pi3mr7707619wic.71.1438273397380; Thu, 30 Jul 2015 09:23:17 -0700 (PDT) Received: by 10.27.171.138 with HTTP; Thu, 30 Jul 2015 09:23:17 -0700 (PDT) In-Reply-To: References:

Date: Thu, 30 Jul 2015 12:23:17 -0400 Message-ID: From: Jameson Lopp To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary=001a1134ce04f0dda5051c1a1e52 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] Block size following technological growth X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 16:23:20 -0000 --001a1134ce04f0dda5051c1a1e52 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I find it to be an admirable goal to try to keep node operation costs low and accessible to the average user. On the other hand, if we are able to keep the resource requirements of nodes at the level of, say, whatever the latest Raspberry Pi model on a residential Internet connection can handle, I'm not sure how helpful it will be if the demand for inclusion in blocks results in transaction fees prices out more users. Stated differently, if the cost or contention of using the network rises to the point of excluding the average user from making transactions, then they probably aren't going to care that they can run a node at trivial cost. If we're approaching the block size from a resource usage standpoint, it seems to me that someone is going to be excluded one way or another. Not raising the block size will exclude some users from sending transactions while raising the block size will exclude some users from running nodes. The latter seems preferable to me because more users will grow the ecosystem, which should increase the value of the ecosystem, which should increase the cost that entities are willing to pay to run nodes. I see two primary points of view / objectives clashing in this debate: 1) Decentralization and stability even if it retards growth of the ecosyste= m 2) Push the system's load as far as we are comfortable in order to accommodate the growth it is experiencing It's clear to me that Core developers have a responsibility to maintain a stable platform for the ecosystem. I think it's less clear that they have a responsibility to grow it or ask node operators to expend more resources in order to support more users. As an operator of several nodes, I can anecdotally state that I find their resource usage to be trivial and I welcome more load. - Jameson On Thu, Jul 30, 2015 at 11:12 AM, Jorge Tim=C3=B3n < bitcoin-dev@lists.linuxfoundation.org> wrote: > 1) Unlike previous blocksize hardfork proposals, this uses median time > instead of block.nTime for activation. I like that more but my > preference is still using height for everything. But that discussion > is not specific to this proposal, so it's better if we discuss that > for all of them here: > > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.h= tml > > 2) I think uncontroversial hardforks should also take miner > confirmation into account, just like uncontroversial softforks do. We > cannot make sure other users have upgraded before activating the > chain, but we can know whether miners have upgraded or not. Having > that tool available, why not use it. Of course other hardforks may not > care about miners' upgrade state. For example "anti-miner hardforks, > see > https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org#asic-reset-ha= rdfork > But again, this is common to all uncontroversial hardforks, so it > would probably better to discussed it in > > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.h= tml > (gmaxwell assigned to bip99 to my bip draft). > > 3) As commented to you privately, I don't like to make any assumptions > about technological advancements (much less on economical growth). I > don't expect many people to agree with me here (I guess I've seen too > many "peak oil" [or more generally, peak energy production] plus I've > read Nietzsche's "On the utility and liability of history for life" > [1]; so considering morals, technology or economics as "monotonic > functions" in history is simply a ridiculous notion to me), but it's > undeniable that internet connections have improved overall around the > world in the last 6 years. I think we should wait for the > technological improvements to happen and then adapt the blocksize > accordingly. I know, that's not a "definitive solution", we will need > to change it from time to time and this is somewhat ugly. > But even if I'm the only one that considers a "technological > de-growth" possible, I don't think is wise to rely on pseudo-laws like > Moore's or Nielsen=E2=80=99s so-called "laws". > Stealing a quote from another thread: > > "Prediction is difficult, especially about the future." - Niels Bohr > > So I would prefer a more limited solution like bip102 (even though I > would prefer to have some simulations leading to a concrete value > (even if it's bigger) rather than using 2MB's arbitrary number. > > Those are my 3 cents. > > [1] > https://philohist.files.wordpress.com/2008/01/nietzsche-uses-history.pdf > > On Thu, Jul 30, 2015 at 4:25 PM, Pieter Wuille via bitcoin-dev > wrote: > > Hello all, > > > > here is a proposal for long-term scalability I've been working on: > > https://gist.github.com/sipa/c65665fc360ca7a176a6 > > > > Some things are not included yet, such as a testnet whose size runs > ahead of > > the main chain, and the inclusion of Gavin's more accurate sigop checki= ng > > after the hard fork. > > > > Comments? > > > > -- > > Pieter > > > > > > _______________________________________________ > > 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 > --001a1134ce04f0dda5051c1a1e52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I find it to be an admirable goal to try to keep node oper= ation costs low and accessible to the average user. On the other hand, if w= e are able to keep the resource requirements of nodes at the level of, say,= whatever the latest Raspberry Pi model on a residential Internet connectio= n can handle, I'm not sure how helpful it will be if the demand for inc= lusion in blocks results in transaction fees prices out more users. Stated = differently, if the cost or contention of using the network rises to the po= int of excluding the average user from making transactions, then they proba= bly aren't going to care that they can run a node at trivial cost.

If we're approaching the block size from a resource usag= e standpoint, it seems to me that someone is going to be excluded one way o= r another. Not raising the block size will exclude some users from sending = transactions while raising the block size will exclude some users from runn= ing nodes. The latter seems preferable to me because more users will grow t= he ecosystem, which should increase the value of the ecosystem, which shoul= d increase the cost that entities are willing to pay to run nodes.

I see two primary points of view / objectives clashing in = this debate:

1) Decentralization and stability eve= n if it retards growth of the ecosystem

2) Push the system's = load as far as we are comfortable in order to accommodate the growth it is = experiencing

It's clear to me that Core develo= pers have a responsibility to maintain a stable platform for the ecosystem.= I think it's less clear that they have a responsibility to grow it or = ask node operators to expend more resources in order to support more users.= As an operator of several nodes, I can anecdotally state that I find their= resource usage to be trivial and I welcome more load.

- Jameson

On Thu, Jul 30, 2015 at 11:12 AM, Jorge Tim=C3=B3n <bitcoin-dev@lists.linuxfoundation.org> wrote:
1) Unlike previous blocksize hardfork proposals, = this uses median time
instead of block.nTime for activation. I like that more but my
preference is still using height for everything. But that discussion
is not specific to this proposal, so it's better if we discuss that
for all of them here:
http://lists.linuxfounda= tion.org/pipermail/bitcoin-dev/2015-July/009731.html

2) I think uncontroversial hardforks should also take miner
confirmation into account, just like uncontroversial softforks do. We
cannot make sure other users have upgraded before activating the
chain, but we can know whether miners have upgraded or not. Having
that tool available, why not use it. Of course other hardforks may not
care about miners' upgrade state. For example "anti-miner hardfork= s,
see https://github.co= m/jtimon/bips/blob/bip-forks/bip-forks.org#asic-reset-hardfork
But again, this is common to all uncontroversial hardforks, so it
would probably better to discussed it in
http://lists.linuxfounda= tion.org/pipermail/bitcoin-dev/2015-June/008936.html
(gmaxwell assigned to bip99 to my bip draft).

3) As commented to you privately, I don't like to make any assumptions<= br> about technological advancements (much less on economical growth). I
don't expect many people to agree with me here (I guess I've seen t= oo
many "peak oil" [or more generally, peak energy production] plus = I've
read Nietzsche's "On the utility and liability of history for life= "
[1]; so considering morals, technology or economics as "monotonic
functions" in history is simply a ridiculous notion to me), but it'= ;s
undeniable that internet connections have improved overall around the
world in the last 6 years. I think we should wait for the
technological improvements to happen and then adapt the blocksize
accordingly. I know, that's not a "definitive solution", we w= ill need
to change it from time to time and this is somewhat ugly.
But even if I'm the only one that considers a "technological
de-growth" possible, I don't think is wise to rely on pseudo-laws = like
Moore's or Nielsen=E2=80=99s so-called "laws".
Stealing a quote from another thread:

"Prediction is difficult, especially about the future." - Niels B= ohr

So I would prefer a more limited solution like bip102 (even though I
would prefer to have some simulations leading to=C2=A0 a concrete value
(even if it's bigger) rather than using 2MB's arbitrary number.

Those are my 3 cents.

[1] https://philohist.files.= wordpress.com/2008/01/nietzsche-uses-history.pdf

On Thu, Jul 30, 2015 at 4:25 PM, Pieter Wuille via bitcoin-dev
<bitcoin-dev@li= sts.linuxfoundation.org> wrote:
> Hello all,
>
> here is a proposal for long-term scalability I've been working on:=
> https://gist.github.com/sipa/c65665fc360ca7a17= 6a6
>
> Some things are not included yet, such as a testnet whose size runs ah= ead of
> the main chain, and the inclusion of Gavin's more accurate sigop c= hecking
> after the hard fork.
>
> Comments?
>
> --
> Pieter
>
>

> __________________= _____________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--001a1134ce04f0dda5051c1a1e52-- 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 B805D5AA for ; Thu, 30 Jul 2015 16:36:26 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bihthai.net (unknown [5.255.87.165]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7606E214 for ; Thu, 30 Jul 2015 16:36:25 +0000 (UTC) Received: from [10.8.0.6] (unknown [10.8.0.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: venzen) by mail.bihthai.net (Postfix) with ESMTPSA id BB7AF20B46; Thu, 30 Jul 2015 18:38:02 +0200 (CEST) Message-ID: <55BA5283.2000405@mail.bihthai.net> Date: Thu, 30 Jul 2015 23:36:19 +0700 From: Venzen Khaosan Reply-To: venzen@mail.bihthai.net Organization: Bihthai Bai Mai User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= , Bitcoin Dev References:

In-Reply-To: OpenPGP: id=1CF07D66; url=pool.sks-keyservers.net Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,RDNS_NONE 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] Block size following technological growth X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 16:36:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/30/2015 10:12 PM, Jorge Timón via bitcoin-dev wrote: [snip] > But even if I'm the only one that considers a "technological > de-growth" possible, I don't think is wise to rely on pseudo-laws > like Moore's or Nielsen’s so-called "laws". Stealing a quote from > another thread: You raise a good point: "de-growth" Assuming linear (or exponential) growth without sympathetic contraction at some time in the future would make our future selves look back and smile at the youthful exuberance. The pseudo-laws you mention (Moore's etc) do not cater for contraction and, you're right, scaling UP plans should also wisely make provision for scaling DOWN, for when the need arises. > > So I would prefer a more limited solution like bip102 (even though > I would prefer to have some simulations leading to a concrete > value (even if it's bigger) rather than using 2MB's arbitrary > number. I just had a look your existing Size N testnet code https://github.com/bitcoin/bitcoin/pull/6382 and i'll set up a node over the weekend and post its address in that PR's conversation. Do you or anyone else already have a node running? what blocksize? > > Those are my 3 cents. > > [1] > https://philohist.files.wordpress.com/2008/01/nietzsche-uses-history.pdf Thanks, > will broaden my horizon soon! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVulKBAAoJEGwAhlQc8H1mUSAH/Rmlek3uitGyIritwyDO4Kf7 BfynlztWmPbnWl7aFYQCS+aIPgS+BvQWIiA0dTI633yj071DWEvcGDzhtcVrk0KT //Ty8bp8yqsJRdd+SWgnqUzSmB6TI31F3ssxjDfSZhKiy8YF4+pKqjerQmBqlgLY sKts3md8N8qWV5Onjd7ea+7SoFjhJ6GOm2UFgxO27LCeDH5Ax5fG4MsolNg3MBTT 5y7Hfo1YeFXRwRRSy5uCSSR0afBb8Wauqi/EnSYDuMe5HBcLztc7icXa6oLTlvBC sfYswasmLRbvHLs4Vy51g75+k60QBjgFKtVlPXJXGN2trbcedF0UbDmenxGqJaI= =rJPX -----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 7E4DB5AE for ; Thu, 30 Jul 2015 16:36:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 32589211 for ; Thu, 30 Jul 2015 16:36:31 +0000 (UTC) Received: by lbbyj8 with SMTP id yj8so30720103lbb.0 for ; Thu, 30 Jul 2015 09:36:29 -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=bBFzooy8QcmLzHzV4nAl4X7J0fb4auje9IVPM6pjmw4=; b=dFV/Pn/CdJPlPq6XC0c0pB+OyNF42Vgk4i4TmZPnAFYKTrPpt2+P/8RderUOgd8rZ3 aXPwMqH/kNl2wYb62dQt6OwDHpYfWHZYkeH/Dsz0RC6cFKJxK3KOd6qm5lQQJo/Mhsl0 78imNOdRbhwdGqGUIkGuGoDeQYfqR0WslkdqPFpgPm3IxMd+gYZfO1vrHmCLdRZib9Fu pcLslty8Wl99oSgFKkWUvN6l4kTW0Kz0pqDKcIhMdLRX8L9m59kcVrFcXrXF7acr1YPp GVFeI9AgO74mKePlp1Rx1pCXUo8pG0Ryt8AgLz9hFHtasERxiyM13zAB0KptVuyxAo1M t1Iw== MIME-Version: 1.0 X-Received: by 10.112.13.97 with SMTP id g1mr45454351lbc.52.1438274189604; Thu, 30 Jul 2015 09:36:29 -0700 (PDT) Received: by 10.152.18.166 with HTTP; Thu, 30 Jul 2015 09:36:29 -0700 (PDT) In-Reply-To: References:

Date: Thu, 30 Jul 2015 11:36:29 -0500 Message-ID: From: Bryan Bishop To: Jameson Lopp , Bryan Bishop , bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a11c3b208293d9b051c1a4e69 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] Block size following technological growth X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 16:36:32 -0000 --001a11c3b208293d9b051c1a4e69 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 30, 2015 at 11:23 AM, Jameson Lopp via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Stated differently, if the cost or contention of using the network rises > to the point of excluding the average user from making transactions, then > they probably aren't going to care that they can run a node at trivial cost. That's an interesting claim; so suppose you're living in a future where transactions are summarizing millions or billions of other daily transactions, possibly with merkle hashes. You think that because a user can't individually broadcast his own personal transaction, that the user would not be interested in verifying the presence of a summarizing transaction in the blockchain? I'm just curious if you could elaborate on this effect. Why would I need to see my individual transactions on the network, but not see aggregate transactions that include my own? - Bryan http://heybryan.org/ 1 512 203 0507 --001a11c3b208293d9b051c1a4e69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On T= hu, Jul 30, 2015 at 11:23 AM, Jameson Lopp via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Stated differently, if the cost or contention of u= sing the network rises to the point of excluding the average user from maki= ng transactions, then they probably aren't going to care that they can = run a node at trivial cost.

That's an interesting= claim; so suppose you're living in a future where transactions are sum= marizing millions or billions of other daily transactions, possibly with me= rkle hashes. You think that because a user can't individually broadcast= his own personal transaction, that the user would not be interested in ver= ifying the presence of a summarizing transaction in the blockchain? I'm= just curious if you could elaborate on this effect. Why would I need to se= e my individual transactions on the network, but not see aggregate transact= ions that include my own?

= - Bryan
http://heybry= an.org/
1 512 203 0507

--001a11c3b208293d9b051c1a4e69-- 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 C4A95282 for ; Thu, 30 Jul 2015 16:41:56 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 66083ED for ; Thu, 30 Jul 2015 16:41:56 +0000 (UTC) Received: by oibn4 with SMTP id n4so24847165oib.3 for ; Thu, 30 Jul 2015 09:41:55 -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=W7WEkDqfiHL7P0EL5nw0Sx0AhY/nZZQWJrqH5r0yMZk=; b=EeQYa0vrZ2yoj0EyO+hhko3CfPYjGRmRLNbLBjUrZRV3AoLWBk+74B2y658a6/Vefk k6F87GM9Wdm5MgEhWX+rrFykzNCAc9h76WbjMth/K//Sa1k8bJvN9uuQz2p55cY5mkyX w2h6LbWmQkGYw8ysfdVo5KgywC1CHS2mU4nDxW/DBag4DiebMXgQJT8xDDTsung1LGUG D3oYlEJqhWxxjdUTc+gMZogxVy6ccLIJilDtF1qGpqduhEyCWIOy9ozfZOB4bjCbbtja k21EzvP9peHWIDmNdkBfl6+m8BCgHUTwBFXBbnnUzDqiT2udyQlUF8VaqYQ6HsfyyNe8 UOHw== MIME-Version: 1.0 X-Received: by 10.202.196.18 with SMTP id u18mr41681289oif.58.1438274515850; Thu, 30 Jul 2015 09:41:55 -0700 (PDT) Received: by 10.202.87.215 with HTTP; Thu, 30 Jul 2015 09:41:55 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jul 2015 12:41:55 -0400 Message-ID: From: Suhas Daftuar To: Gavin Andresen Content-Type: multipart/alternative; boundary=001a113e38509b5b62051c1a6139 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] Block size following technological growth X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 16:41:56 -0000 --001a113e38509b5b62051c1a6139 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 30, 2015 at 12:20 PM, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > So we'd get to 2MB blocks in the year 2021. I think that is much too > conservative, and the most likely effect of being that conservative is that > the main blockchain becomes a settlement network, affordable only for > large-value transactions. > While that may be true I think that's okay -- if it turns out that this is too conservative, and we succeed in scaling the system so that it's non-controversial to increase these limits later via another hard fork, we would still be free to do so. It seems to me that everyone who has been arguing recently to increase the block size limit ought to find this proposal to be a strict improvement over where we are now, and this proposal seems like it's reasonably likely to be non-controversial enough to be worth proposing as a hard fork in Bitcoin Core -- thank you Pieter for putting this together. For my part, I'd give this a concept ACK, pending hearing further thoughts from others. Suhas Daftuar --001a113e38509b5b62051c1a6139 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On T= hu, Jul 30, 2015 at 12:20 PM, Gavin Andresen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

So we'd get to 2MB blocks in the year 2021.= I think that is much too conservative, and the most likely effect of being= that conservative is that the main blockchain becomes a settlement network= , affordable only for large-value transactions.

While that may be true I think that's okay= -- if it turns out that this is too conservative, and we succeed in scalin= g the system so that it's non-controversial to increase these limits la= ter via another hard fork, we would still be free to do so.

<= /div>

It seems to me that everyone who has been arguing recently to inc= rease the block size limit ought to find this proposal to be a strict impro= vement over where we are now, and this proposal seems like it's reasona= bly likely to be non-controversial enough to be worth proposing as a hard f= ork in Bitcoin Core -- thank you Pieter for putting this together.

For my part, I'd give this a concept ACK, pending hear= ing further thoughts from others.

Suhas Daftuar

--001a113e38509b5b62051c1a6139-- 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 6B1944A7 for ; Thu, 30 Jul 2015 16:43:59 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 839A6ED for ; Thu, 30 Jul 2015 16:43:58 +0000 (UTC) Received: by wicgb10 with SMTP id gb10so251839917wic.1 for ; Thu, 30 Jul 2015 09:43:57 -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=Ka75a2W8XLM5p87wKbFkHWAYo1o+6vopYtvZIUwV2O4=; b=yiP6H2d860L1Fc5crxPUeNcHfkOmVL2M3ziwOiCldSODN3jLRA2X9/ghfkwGhXtonS vwA8Tp3MYRmvUnyxXNwDM7HO3oLU1j7bX2EUqQNtzezLT50ifddfref/MSCeQRt96WJk EOtKoAAVZamz8lXHKdptETOxo/U2yzxe5EL+3KmLHRmEOLbExfsnCydZXmqHG6H/xIBr BArm+gVTyrnZ7/HckMMZ4WNpScxUry7lRTxp9y8jCF9MXHzFAQULoi8KNi4eXbkfMJVP Niiz7FNHwjHX6NSVNs2xp0PZ27B9x+AE/sJHHej5B2pYnMB56sef6JI4FT+oyP6rBUig LDkQ== MIME-Version: 1.0 X-Received: by 10.194.209.167 with SMTP id mn7mr86329181wjc.64.1438274636987; Thu, 30 Jul 2015 09:43:56 -0700 (PDT) Received: by 10.27.171.138 with HTTP; Thu, 30 Jul 2015 09:43:56 -0700 (PDT) In-Reply-To: References:

Date: Thu, 30 Jul 2015 12:43:56 -0400 Message-ID: From: Jameson Lopp To: Bryan Bishop Content-Type: multipart/alternative; boundary=047d7b3a8954d3c524051c1a6885 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] Block size following technological growth X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 16:43:59 -0000 --047d7b3a8954d3c524051c1a6885 Content-Type: text/plain; charset=UTF-8 I fully expect that new layers will someday allow us to facilitate higher transaction volumes, though I'm concerned about the current state of the network and the fact that there are no concrete timelines for the rollout of aforementioned high volume networks. As for reasoning behind why users will still need to settle on-chain even with the existence of high volume networks, see these posts: http://sourceforge.net/p/bitcoin/mailman/message/34119233/ http://sourceforge.net/p/bitcoin/mailman/message/34113067/ Point being, the scalability proposals that are currently being developed are not magic bullets and still require the occasional on-chain settlement. Larger blocks will be necessary with or without the actual scalability enhancements. - Jameson On Thu, Jul 30, 2015 at 12:36 PM, Bryan Bishop wrote: > On Thu, Jul 30, 2015 at 11:23 AM, Jameson Lopp via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Stated differently, if the cost or contention of using the network rises >> to the point of excluding the average user from making transactions, then >> they probably aren't going to care that they can run a node at trivial cost. > > > That's an interesting claim; so suppose you're living in a future where > transactions are summarizing millions or billions of other daily > transactions, possibly with merkle hashes. You think that because a user > can't individually broadcast his own personal transaction, that the user > would not be interested in verifying the presence of a summarizing > transaction in the blockchain? I'm just curious if you could elaborate on > this effect. Why would I need to see my individual transactions on the > network, but not see aggregate transactions that include my own? > > - Bryan > http://heybryan.org/ > 1 512 203 0507 > --047d7b3a8954d3c524051c1a6885 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I fully expect that new layers will someday allow us to fa= cilitate higher transaction volumes, though I'm concerned about the cur= rent state of the network and the fact that there are no concrete timelines= for the rollout of aforementioned high volume networks.

As for reasoning behind why users will still need to settle on-chain even = with the existence of high volume networks, see these posts:

http://sourceforge.net/p/bitcoin/mailman/message/34119233/

http://sourceforge.net/p/bitcoin/mailman/message/341130= 67/

Point being, the scalability proposals= that are currently being developed are not magic bullets and still require= the occasional on-chain settlement. Larger blocks will be necessary with o= r without the actual scalability enhancements.

- J= ameson

On Thu, Jul 30, 2015 at 12:36 PM, Bryan Bishop <kanzure@gmail.com>= wrote:

On Thu, Jul 3= 0, 2015 at 11:23 AM, Jameson Lopp via bitcoin-dev <bit= coin-dev@lists.linuxfoundation.org> wrote:
Stated differently, if the cost or contention of using the = network rises to the point of excluding the average user from making transa= ctions, then they probably aren't going to care that they can run a nod= e at trivial cost.

That's an interesting c= laim; so suppose you're living in a future where transactions are summa= rizing millions or billions of other daily transactions, possibly with merk= le hashes. You think that because a user can't individually broadcast h= is own personal transaction, that the user would not be interested in verif= ying the presence of a summarizing transaction in the blockchain? I'm j= ust curious if you could elaborate on this effect. Why would I need to see = my individual transactions on the network, but not see aggregate transactio= ns that include my own?

- Bryan
http://heybryan.org/
1 512 203 = 0507

--047d7b3a8954d3c524051c1a6885-- 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 1AE0F4A8 for ; Thu, 30 Jul 2015 16:48:21 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EE008F2 for ; Thu, 30 Jul 2015 16:48:19 +0000 (UTC) Received: from mail-qk0-f169.google.com ([209.85.220.169]) by mrelay.perfora.net (mreueus003) with ESMTPSA (Nemesis) id 0M3kt5-1Z3b8N4BNZ-00rGfq for ; Thu, 30 Jul 2015 18:48:19 +0200 Received: by qkfc129 with SMTP id c129so20131300qkf.1 for ; Thu, 30 Jul 2015 09:48:18 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.55.15.20 with SMTP id z20mr70615311qkg.16.1438274898215; Thu, 30 Jul 2015 09:48:18 -0700 (PDT) Received: by 10.96.226.68 with HTTP; Thu, 30 Jul 2015 09:48:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jul 2015 18:48:18 +0200 Message-ID: From: Adam Back To: Gavin Andresen Content-Type: text/plain; charset=UTF-8 X-Provags-ID: V03:K0:cSIhUvNBt8FA6ibFk0NYCa69f1QXN9TvrHPWupeW/o41J7dRGoQ 4e+2gOHLpBeBRw+ZlxtaQhyr68yLnNNXyWQXJ2jK/XatEoQrCSv+S1+vASvo3rh5fEs/02j lgxkMzbqy8vaz2QjHEtMV0Y6GY0xLwVHhdXEtE2uNf9t98mjO07x+UtWa/QmwEgxdH1NWFn GoAig8iG44dN2YYJK+b5g== X-UI-Out-Filterresults: notjunk:1;V01:K0:sjTwkGasLOg=:jJvdYS5Ir430X3gMoloOtR FIAY5hovqTTUgWe23wlfcIYeoQUfO0N4CBNEENhmZI0ZHBVOCTGkVQrOu8YPTXFmsNsZ47wOE lp1k04K4ucyrtdkkXydsDb86ULs3c+Qv59PIPZOijWWIKHkw1c683oaGJUci8b5BLAhLli79A KLVQUsNsao4HLjoXmE57lvF9j0H6zNauRkryBJ6ku66fMTAUkILOtT5g8KEdMJpW6NyTlXRup SaHAuXcZTqD1fr0sat5Aek0At8LYbI4ekKqHALMXgo5P1Oy4adpvfv0hcsZgnDiz1h2nK2WHl 2qfl0Q0pzsMwg6vBpfVDxS5b/Vz8qNV9avwba3sffLf5e+VK5XBkU++xQByO2FmU/CkR1zKRm vAcEfBhgB0ubO5pvajTOeUGGuAhpNypydTZlgPyB756uS960e46GTVXR61+GVHf299qDTnMdD 71I+rhsoZnTAxkjR+S1ekyDx4TzLJIpU9MgVr0wFLX2cbfFJvvDvZvHwobqy/xWQOkjKpHKg8 U+EKwg5qfzDFiJBM6fr60GK+LZh8JsWIXaBIBv9ie2M7IVd0ANRdJtoQA10wUVl9ySB4km6Dj +9iQFxB/dqQXGbgp3szBu7ZqdqxE6GTdg7ZoVg+277yKfnQHlgoTBdc0iENUpgLWGbj2/4fxJ mB4iJ5vUph79IOKJngH/QxongVNjMIkII/hWxS0m6mGuMbA== X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Block size following technological growth X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 16:48:21 -0000 That's what is nice about proposals, they are constructive and help move the conversation forward! On 30 July 2015 at 18:20, Gavin Andresen via bitcoin-dev wrote: > Specific comments: > > So we'd get to 2MB blocks in the year 2021. I think that is much too > conservative, and the most likely effect of being that conservative is that > the main blockchain becomes a settlement network, affordable only for > large-value transactions. But, if we agree that 17%/year is consistent with network improvements, by arguing this is too conservative, does that not mean you are actually going beyond suggesting throughput increases to benefit from bandwidth improvements, and explicitly arguing to borrowing from Bitcoin's already very weak decentralisation to create more throughput? (Or arguing to subsidise transaction fees if borrowing so deeply that excess capacity pushes beyond demand). I think the logical implication of this would be that we should be first focussing on improving decentralisation, to make security room to reclaim extra throughput. (To be clear there are concrete things that can be done and actually are being done to improve decentralisation via ecosystem education and mining protocol improvements, but it's safer to wait a few months and see if those things take effect well). Secondly in this assumption are you considering that lightning will likely be online for many years by 2021 and the situation will be hugely different? I think an incremental and conservative approach is safer. People can probably get a lightning prototype running about as fast as a hard-fork could be safely rolled out. I do think it is normal to be conservative with security and with $4b of other peoples money. It's no longer an experimental system to consider fail fast experiments on. > I don't think your proposal strikes the right balance between centralization > of payments (a future where only people running payment hubs, big merchants, > exchanges, and wallet providers settle on the blockchain) and centralization > of mining. What criteria should we be using in your opinion to balance? I think throughput increases trading off decentralisation would be more reasonable if decentralisation wasnt in very bad shape. Adam 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 736364A8 for ; Thu, 30 Jul 2015 16:49:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9CE4110A for ; Thu, 30 Jul 2015 16:49:53 +0000 (UTC) Received: by ioii16 with SMTP id i16so59649571ioi.0 for ; Thu, 30 Jul 2015 09:49:53 -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=VjUx52X4e3lM0b11kPwkv4B3uPZbryG4dndVVAE0Jp0=; b=kz/yAWf28mXk5N5atUtse3Jf/V27p5eDUi7fAEjzG3TGCZ22r1jU7/dSkcXpZ/jIVJ 3f1jOwlrr7v+m/zW9M9hmcn60RSwrII3VgC2QhEHs4SVMQqy7eAZ246aaMl1tyzELZ48 mjuX8JfGIsfnWhYK+gt0PP+oHxR3faNp8Y0RM3H/8Ih/GR4QV3hGoU/dJfWfJMhk9Q/V o9y5muKbqBDcUYbJ0xsyPiwqndt7tRUKxGvcunQTg/O8ClSeb2LQ02byKfcOox0+pOPD 3TUsW8TnJ4YiFuVT/Q0x6udm+dR7YFzvFRSugWXSFlSj+WFns6VUobvJLRZLOyaAFUmr Oung== MIME-Version: 1.0 X-Received: by 10.107.9.137 with SMTP id 9mr12486315ioj.50.1438274993030; Thu, 30 Jul 2015 09:49:53 -0700 (PDT) Received: by 10.36.77.201 with HTTP; Thu, 30 Jul 2015 09:49:52 -0700 (PDT) Received: by 10.36.77.201 with HTTP; Thu, 30 Jul 2015 09:49:52 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jul 2015 18:49:52 +0200 Message-ID: From: Pieter Wuille To: Gavin Andresen Content-Type: multipart/alternative; boundary=001a113f8f140c8ff2051c1a7e84 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] Block size following technological growth X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 16:49:54 -0000 --001a113f8f140c8ff2051c1a7e84 Content-Type: text/plain; charset=UTF-8 On Jul 30, 2015 6:20 PM, "Gavin Andresen" wrote: > > On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> Some things are not included yet, such as a testnet whose size runs ahead of the main chain, and the inclusion of Gavin's more accurate sigop checking after the hard fork. >> >> Comments? > > > First, THANK YOU for making a concrete proposal! You're welcome. > Specific comments: > > So we'd get to 2MB blocks in the year 2021. I think that is much too conservative, and the most likely effect of being that conservative is that the main blockchain becomes a settlement network, affordable only for large-value transactions. If there is demand for high-value settlements in Bitcoin, and this results in a functioning economy where fees support the security of a transparent network, I think that would be a much better outcome than what we have now. > I don't think your proposal strikes the right balance between centralization of payments (a future where only people running payment hubs, big merchants, exchanges, and wallet providers settle on the blockchain) and centralization of mining. Well, centralization of mining is already terrible. I see no reason why we should encourage making it worse. On the other hand, sure, not every transaction fits on the blockchain. That is already the case, and will remain the case with 2 MB or 8 MB or 100 MB blocks. Some use cases fit, and others won't. We need to accept that, and all previous proposals I've seen don't seem to do that. Maybe the only ones that will fit are large settlements between layer-2 services, and maybe it will be something entirely different. But at least we don't need to compromise the security of the main layer, or promise the ecosystem unrealistic growth of space for on-chain transactions. If Bitcoin needs to support a large scale, it already failed. > I'll comment on using median time generally in Jorge's thread, but why does monotonically increasing matter for max block size? I can't think of a reason why a max block size of X bytes in block N followed by a max size of X-something bytes in block N+1 would cause any problems. I don't think it matters much, but it offers slightly easier transition for the mempool (something Jorge convinced me of), and validation can benefit from a single variable that can be set in a chain to indicate a switchover happened, without needing to recalculate it every time. I assume you're asking this because using raw nTime means you can check what limits a p2p message should obey to by looking at just the first bytes. I don't think this matters: your p2p protocol should deal with whatever limits the system requires anyway. An attacker can take a valid message of far in the chain, change a few bytes, and spam you with it at zero extra effort anyway. -- Pieter --001a113f8f140c8ff2051c1a7e84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Jul 30, 2015 6:20 PM, "Gavin Andresen" <gavinandresen@gmail.com> wrote:
>
> On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.li= nuxfoundation.org> wrote:
>>
>> Some things are not included yet, such as a testnet whose size run= s ahead of the main chain, and the inclusion of Gavin's more accurate s= igop checking after the hard fork.
>>
>> Comments?
>
>
> First, THANK YOU for making a concrete proposal!

You're welcome.

> Specific comments:
>
> So we'd get to 2MB blocks in the year 2021. I think that is much t= oo conservative, and the most likely effect of being that conservative is t= hat the main blockchain becomes a settlement network, affordable only for l= arge-value transactions.

If there is demand for high-value settlements in Bitcoin, an= d this results in a functioning economy where fees support the security of = a transparent network, I think that would be a much better outcome than wha= t we have now.

> I don't think your proposal strikes the right balan= ce between centralization of payments (a future where only people running p= ayment hubs, big merchants, exchanges, and wallet providers settle on the b= lockchain) and centralization of mining.

Well, centralization of mining is already terrible. I see no= reason why we should encourage making it worse. On the other hand, sure, n= ot every transaction fits on the blockchain. That is already the case, and = will remain the case with 2 MB or 8 MB or 100 MB blocks. Some use cases fit= , and others won't. We need to accept that, and all previous proposals = I've seen don't seem to do that.

Maybe the only ones that will fit are large settlements betw= een layer-2 services, and maybe it will be something entirely different. Bu= t at least we don't need to compromise the security of the main layer, = or promise the ecosystem unrealistic growth of space for on-chain transacti= ons.

If Bitcoin needs to support a large scale, it already failed= .

> I'll comment on using median time generally in Jorg= e's thread, but why does monotonically increasing matter for max block = size? I can't think of a reason why a max block size of X bytes in bloc= k N followed by a max size of X-something bytes in block N+1 would cause an= y problems.

I don't think it matters much, but it offers slightly ea= sier transition for the mempool (something Jorge convinced me of), and vali= dation can benefit from a single variable that can be set in a chain to ind= icate a switchover happened, without needing to recalculate it every time.<= /p>

I assume you're asking this because using raw nTime mean= s you can check what limits a p2p message should obey to by looking at just= the first bytes. I don't think this matters: your p2p protocol should = deal with whatever limits the system requires anyway. An attacker can take = a valid message of far in the chain, change a few bytes, and spam you with = it at zero extra effort anyway.

--
Pieter

--001a113f8f140c8ff2051c1a7e84-- 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 CF01A514 for ; Thu, 30 Jul 2015 16:57:06 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yk0-f180.google.com (mail-yk0-f180.google.com [209.85.160.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9F990ED for ; Thu, 30 Jul 2015 16:57:03 +0000 (UTC) Received: by ykax123 with SMTP id x123so38990354yka.1 for ; Thu, 30 Jul 2015 09:57:03 -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=nXwo/zgjTWngypPR+b4He1G0eWcQnqL0b6Kec3+B8WM=; b=ttpWrITwPo6OZZ99J2478zwrAfMEl9ligHxu8hkyyUOyv07WChvgbxrF3R5NxCFmu2 uMReQZ+Ht3b7mXG4f/ro7vs1drF9LE67yjYO5zfkJitaG8p0IwIwxz56qCupnMfTAOj9 y0luh+8lQ2bCKIsltBqOOnKaSVPtfRlTDmyeKlr33VBJ3eY2B5eQUDijYkPytQWcvfXG fPHeU/3xN+UT32LtOi83Wr4k+ygKUfKWren8qhbDfpMHpQXhqsnWsBoV6vEljhL7DSEm jscLO2X9ateG3cVQFh2haaOE92uCS/mVFKW00p0d8axObajiw1bvFD+pOnjUPSgvc1we o/0Q== X-Received: by 10.13.204.150 with SMTP id o144mr52859464ywd.54.1438275423023; Thu, 30 Jul 2015 09:57:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.74.8 with HTTP; Thu, 30 Jul 2015 09:56:23 -0700 (PDT) In-Reply-To: References:

From: Gary Mulder Date: Thu, 30 Jul 2015 17:56:23 +0100 Message-ID: To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary=001a114e43a6adb56c051c1a9766 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] Block size following technological growth X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 16:57:06 -0000 --001a114e43a6adb56c051c1a9766 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 30 July 2015 at 16:12, Jorge Tim=C3=B3n wrote: > 1) Unlike previous blocksize hardfork proposals, this uses median time > instead of block.nTime for activation. I like that more but my > preference is still using height for everything. But that discussion > is not specific to this proposal, so it's better if we discuss that > for all of them here: > > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.h= tml Note that a "median" is a special case of a 50% percentile. If you desire to apply a more stringent criteria you can use the 75th or even 90th percentile. https://en.wikipedia.org/wiki/Percentile Perhaps if a statistician (i.e. not me) could be found to offer her services, she could become a resource for helping selecting the most appropriate statistical algorithms on request (and implemented Integer math as per Gavin, from memory), considering the consequences of learning post-fork that a "bad statistical model" was chosen. e.g. an exponentially weighted moving average is usually much less volatile and harder to manipulate than a simple moving average, but still can "respond" to short term drivers. Regards, Gary --001a114e43a6adb56c051c1a9766 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 30 July 2015 at 16:12, Jorge Tim=C3=B3n=C2=A0<bitcoin-dev@lists.li= nuxfoundation.org>=C2=A0wrote:
1) Unlike previous blocksize hardfork pr= oposals, this uses median time
instead of block.nTime for activation. I = like that more but my
preference is still using height for everything. B= ut that discussion
is not specific to this proposal, so it's better = if we discuss that
for all of them here:
http://lists.linuxfoundation.org/pipermail/bitcoin-d= ev/2015-July/009731.html

Note that a= "median" is a special case of a 50% percentile. If you desire to= apply a more stringent criteria you can use the 75th or even 90th percenti= le.

https://en.wikipedia.org/wiki/Percentile<= br>

Perhaps if a statistician (i.e. not me) c= ould be found to offer her services, she could become a resource for helpin= g selecting the most appropriate statistical algorithms on request (and imp= lemented Integer math as per Gavin, from memory), considering the consequen= ces of learning post-fork that a "bad statistical model" was chos= en.

e.g. an exponentially weighted moving ave= rage is usually much less volatile and harder to manipulate than a simple m= oving average, but still can "respond" to short term drivers.=C2= =A0

Regards,

Gary

--001a114e43a6adb56c051c1a9766-- 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 A29AA415 for ; Thu, 30 Jul 2015 17:13:15 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 05236253 for ; Thu, 30 Jul 2015 17:13:13 +0000 (UTC) Received: by iodd187 with SMTP id d187so60269427iod.2 for ; Thu, 30 Jul 2015 10:13:13 -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=TkspycX4j7UsBjoR46sd8Ai2cii2WH/7DoUR8oKUOBY=; b=L2PF8Dj06xy81ajlWpgv6gL1pkcgTcXTjkUU+02S4UoIDhsBNwjQioeYX/eNGu+eGY j/Vt0kYBNy2NPCVerxAkO55iLVmQe9kneXbHvjfkme5SWoKzEtRmmEydyG3R1FhLsJ+d UXE6rZ1QKpZ+5JioGZiQOUPFYFmq5h46MKaN3FB7kQJhKvkgvggboAdRAhOIMukKkMVR JctXqodxHqYPyTIMq440FyokBOajBBKCWH8rnE0ymrwWfyqfAa7qnbP7AE8d0odZeNbO Vf6vctFyUjcqwWKa6IcOnfT7BTVZqQMUCrJwtMifVmBDLgw3bgQmARIGMyI95j+P4C03 rvww== X-Gm-Message-State: ALoCoQkd8oTJXdBVId02RY7N6GMLs70N0naaadPNcWHSZsprkNbmItQHtEaq2aTIeFJurhE6eCAF MIME-Version: 1.0 X-Received: by 10.107.130.166 with SMTP id m38mr13569421ioi.77.1438276393442; Thu, 30 Jul 2015 10:13:13 -0700 (PDT) Received: by 10.107.158.140 with HTTP; Thu, 30 Jul 2015 10:13:13 -0700 (PDT) X-Originating-IP: [172.56.17.151] Received: by 10.107.158.140 with HTTP; Thu, 30 Jul 2015 10:13:13 -0700 (PDT) In-Reply-To: References:

Date: Thu, 30 Jul 2015 10:13:13 -0700 Message-ID: From: Mark Friedenbach To: Gary Mulder Content-Type: multipart/alternative; boundary=001a113eb9c88552a1051c1ad18e 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] Block size following technological growth X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 17:13:15 -0000 --001a113eb9c88552a1051c1ad18e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The median is used here because that is the consensus rule -- a block cannot have a timestamp older than the median time of the last 11 blocks. By linking the changeover to this rule we avoid perverse incentives about miners lying in their timestamps, or the threshold being crossed, then reverted, then crossed again, etc. Maybe a different percentile would have been a better choice, but that ship sailed in 2009. The rule is what it is right now, and we benefit the most from using the same rule as consensus for the threshold. On Jul 30, 2015 9:57 AM, "Gary Mulder via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 30 July 2015 at 16:12, Jorge Tim=C3=B3n < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> 1) Unlike previous blocksize hardfork proposals, this uses median time >> instead of block.nTime for activation. I like that more but my >> preference is still using height for everything. But that discussion >> is not specific to this proposal, so it's better if we discuss that >> for all of them here: >> >> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.= html > > > Note that a "median" is a special case of a 50% percentile. If you desire > to apply a more stringent criteria you can use the 75th or even 90th > percentile. > > https://en.wikipedia.org/wiki/Percentile > > Perhaps if a statistician (i.e. not me) could be found to offer her > services, she could become a resource for helping selecting the most > appropriate statistical algorithms on request (and implemented Integer ma= th > as per Gavin, from memory), considering the consequences of learning > post-fork that a "bad statistical model" was chosen. > > e.g. an exponentially weighted moving average is usually much less > volatile and harder to manipulate than a simple moving average, but still > can "respond" to short term drivers. > > Regards, > Gary > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a113eb9c88552a1051c1ad18e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The median is used here because that is the consensus rule -= - a block cannot have a timestamp older than the median time of the last 11= blocks. By linking the changeover to this rule we avoid perverse incentive= s about miners lying in their timestamps, or the threshold being crossed, t= hen reverted, then crossed again, etc.

Maybe a different percentile would have been a better choice= , but that ship sailed in 2009. The rule is what it is right now, and we be= nefit the most from using the same rule as consensus for the threshold.

On Jul 30, 2015 9:57 AM, "Gary Mulder via b= itcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:

On 30 July 2015 at 16:12,= Jorge Tim=C3=B3n=C2=A0<bitcoin-dev@lists.linuxfoundation.org>=C2=A0wrote:
1) U= nlike previous blocksize hardfork proposals, this uses median time
inste= ad of block.nTime for activation. I like that more but my
preference is = still using height for everything. But that discussion
is not specific t= o this proposal, so it's better if we discuss that
for all of them h= ere:
http://lists.lin= uxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html

Note that a "median" is a special case o= f a 50% percentile. If you desire to apply a more stringent criteria you ca= n use the 75th or even 90th percentile.

https://en.= wikipedia.org/wiki/Percentile

Perhaps i= f a statistician (i.e. not me) could be found to offer her services, she co= uld become a resource for helping selecting the most appropriate statistica= l algorithms on request (and implemented Integer math as per Gavin, from me= mory), considering the consequences of learning post-fork that a "bad = statistical model" was chosen.

e.g. an exp= onentially weighted moving average is usually much less volatile and harder= to manipulate than a simple moving average, but still can "respond&qu= ot; to short term drivers.=C2=A0

Regards,
=
Gary

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

--001a113eb9c88552a1051c1ad18e-- 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 9121747F for ; Thu, 30 Jul 2015 17:46:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D059F262 for ; Thu, 30 Jul 2015 17:46:31 +0000 (UTC) Received: by wibxm9 with SMTP id xm9so1869276wib.0 for ; Thu, 30 Jul 2015 10:46: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:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=U/2xZnOY0lzyPGaJqMDNWhSyVNEE/DLBcjZ1ueVGVwA=; b=dqsSiXmnosy78IJwg/ezRQhVsrIydO6G/o9uXw0u+7PpEtmvJZP3pQxXuGDmpChBfP 0GPgZc/qmKJL2d5ArVoSnktp+3Sv0fI++4XAX/w2UM07v4kzSOflWcjv5Dizv79n3ObK 6DDcZT6vgAC0WSIRMzwMsErKM2tsRELOzHRnLpZU3rIlLsbQQXUYDqY7cJKQeBblO/uA 94pH07hK/SBWa6Kj1L+Abn5Dk9qnZX+Zo4xs6KSAk2zl8eORJI6CakIiTmh43hM4U5bw KocQ/4S8nyXKBGvjTqfz+7sYgt/X4jw5tW8QZXsSWzoCDCmlFyKKov2WCrTzTIGMCz/S 07LA== X-Gm-Message-State: ALoCoQmjwuQvBR1hv/BvhFP/q5brxb/Dp9l+hZOIx/GwfPDCVp2NWPsJb7W6yK7fv+AIqaetZuT3 MIME-Version: 1.0 X-Received: by 10.180.186.35 with SMTP id fh3mr8596067wic.7.1438278390437; Thu, 30 Jul 2015 10:46:30 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Thu, 30 Jul 2015 10:46:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jul 2015 19:46:30 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Gavin Andresen 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] Block size following technological growth X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 17:46:32 -0000 On Thu, Jul 30, 2015 at 6:20 PM, Gavin Andresen via bitcoin-dev wrote: > On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev > wrote: > So we'd get to 2MB blocks in the year 2021. I think that is much too > conservative When considering "too conservative" options, let's not forget that, say, scheduling 2MB for 2020 doesn't preclude us from deciding that was too conservative and schedule, say 4MB for 2018 later. The first hardfork would be "useless", but it would set a "minimum increase" that would have been useful if the second one never happened. > I'll comment on using median time generally in Jorge's thread, but why does > monotonically increasing matter for max block size? I can't think of a > reason why a max block size of X bytes in block N followed by a max size of > X-something bytes in block N+1 would cause any problems. To be clear, for this concrete case block.nTime would just work just fine. I just want us to decide on one of the options and uniformly recommend that options for all cases in BIP99 [just renamed the file, https://github.com/jtimon/bips/blob/bip-forks/bip-0099.org ]. But, yes, please, let's discuss this in the other thread. 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 06B5F48A for ; Thu, 30 Jul 2015 17:51:15 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 62C64170 for ; Thu, 30 Jul 2015 17:51:14 +0000 (UTC) Received: by wibxm9 with SMTP id xm9so1912777wib.1 for ; Thu, 30 Jul 2015 10:51:13 -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=VxT/b3gAUF5QrpITI2piHkAqINylE2Ctd2JpLLu8ugE=; b=SFwNnjMZ+js6ss0z7rNXvRByzl9w1xtjvfpWbeR1BfZaX2hbni/q/gXp1M1eFo6OiX JDXPrjT+iLk2AADd5q7QvPdsFFH7knpBDFr3eUybioc73zfamgeuCjuMxwnJ9QDLqzHy ukGSfdxt8nZmufvUw6WhRfz8RbAyVRjVK3QYVaC8nImdW4sQG8mS35k7hOl69dDtCosP NMTQF/Ljz/sRBSsWviuSrkXOMYtJDkRAkTj5QwYisFfM6aFXqwcyNWbl6cVyqtqrcs9u QOIgc4JfRXhxpP77os5LqMYe7MPXojx9SIQfpAN8DfCIS1vM/FpMotCXGyFQ3hWGSBgo lsvg== X-Gm-Message-State: ALoCoQm0H8p85JVf9yL/Av6cIVVv7OWD8KuvLwn+h3un8cLeQmj15pjODdFqOnmXpjrtOsX24yrX MIME-Version: 1.0 X-Received: by 10.194.238.39 with SMTP id vh7mr17805821wjc.109.1438278673056; Thu, 30 Jul 2015 10:51:13 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Thu, 30 Jul 2015 10:51:12 -0700 (PDT) In-Reply-To: <55BA5283.2000405@mail.bihthai.net> References:

<55BA5283.2000405@mail.bihthai.net> Date: Thu, 30 Jul 2015 19:51:12 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: venzen@mail.bihthai.net 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] Block size following technological growth X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 17:51:15 -0000 On Thu, Jul 30, 2015 at 6:36 PM, Venzen Khaosan wrote: > I just had a look your existing Size N testnet code > https://github.com/bitcoin/bitcoin/pull/6382 > and i'll set up a node over the weekend and post its address in that > PR's conversation. Do you or anyone else already have a node running? > what blocksize? Great! No, I'm not running any node right now at any size. Take into account that it's not a regular testnet (ie like testnet3), it's a regtest-like testnet to make mining and simulations cheap. That also means that anybody can trivially create reorgs, so it is expected to be used in a controlled environment (you can control which node creates a new block and when). 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 D5C13499 for ; Thu, 30 Jul 2015 18:00:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DA93B172 for ; Thu, 30 Jul 2015 18:00:22 +0000 (UTC) Received: by wibud3 with SMTP id ud3so30580522wib.1 for ; Thu, 30 Jul 2015 11:00:21 -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=QtCptDDgIDLmESS5B9U46FzmCBiGteIjvlzbRRTCLf4=; b=abivQkbt1vtb9kMKCgCbhEA3wdwBW9JF2bvkuC9lfHTYwKx9yKORRd5/GaWzz+4YQj riOtWGMlVNtZocQimWUTctrEO8VtthoZ/ENKYJ+YUrw2VsaAUD8WP3r6UMNqwbT2bnuF cCevrj9shfa+jD5MJLhyTPHi0/boE/XtMxqe0jS7ZDMhL+MWCKkCpfgyTx8/4mVnqIsy RAjqlihGN3UlsyYnM6BZTBDcsB169KyRa/mzRIhK50s4uysogXWKo0208a97LNodAlEZ VX90rK2TQ879ft5jD/emaXqSMaAo8xD0apS0d+T5ud1XCYvbnI+evMHYVWtLgKDKD4rt vPzw== X-Gm-Message-State: ALoCoQnB1M+FEcBQ0qq2S1SIunuqejYBd7p+G3WtS6IvcFyuB54nQGiledUJs38Kcx/ZAjcoEhqj MIME-Version: 1.0 X-Received: by 10.194.120.198 with SMTP id le6mr90048653wjb.133.1438279221664; Thu, 30 Jul 2015 11:00:21 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Thu, 30 Jul 2015 11:00:21 -0700 (PDT) In-Reply-To: References:

<55BA5283.2000405@mail.bihthai.net> Date: Thu, 30 Jul 2015 20:00:21 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: venzen@mail.bihthai.net 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] Block size following technological growth X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 18:00:24 -0000 Gavin, Pieter, Mark, Gary, can we move the median time discussion to its own thread? http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.htm= l I really don't want to fill this thread with that discussion. On Thu, Jul 30, 2015 at 7:51 PM, Jorge Tim=C3=B3n wrote: > On Thu, Jul 30, 2015 at 6:36 PM, Venzen Khaosan = wrote: >> I just had a look your existing Size N testnet code >> https://github.com/bitcoin/bitcoin/pull/6382 >> and i'll set up a node over the weekend and post its address in that >> PR's conversation. Do you or anyone else already have a node running? >> what blocksize? > > Great! No, I'm not running any node right now at any size. > Take into account that it's not a regular testnet (ie like testnet3), > it's a regtest-like testnet to make mining and simulations cheap. > That also means that anybody can trivially create reorgs, so it is > expected to be used in a controlled environment (you can control which > node creates a new block and when). 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 AAA04491 for ; Thu, 30 Jul 2015 20:20:47 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from pmx.vmail.no (pmx.vmail.no [193.75.16.11]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id F30D7ED for ; Thu, 30 Jul 2015 20:20:46 +0000 (UTC) Received: from pmx.vmail.no (localhost [127.0.0.1]) by localhost (pmx.isp.as2116.net) with SMTP id 2A4BA5FA9E; Thu, 30 Jul 2015 22:20:45 +0200 (CEST) Received: from smtp.bluecom.no (smtp.bluecom.no [193.75.75.28]) by pmx.vmail.no (pmx.isp.as2116.net) with ESMTP id ED2E05F13D; Thu, 30 Jul 2015 22:20:44 +0200 (CEST) Received: from coldstorage.localnet (unknown [81.191.185.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.bluecom.no (Postfix) with ESMTPS id D52D31F54B; Thu, 30 Jul 2015 22:20:44 +0200 (CEST) From: Thomas Zander To: bitcoin-dev@lists.linuxfoundation.org, Pieter Wuille Date: Thu, 30 Jul 2015 22:20:43 +0200 Message-ID: <25710699.lX8S1tS4UG@coldstorage> User-Agent: KMail/4.14.1 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Block size following technological growth X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 20:20:47 -0000 On Thursday 30. July 2015 16.25.02 Pieter Wuille via bitcoin-dev wrote: > Hello all, > > here is a proposal for long-term scalability I've been working on: > https://gist.github.com/sipa/c65665fc360ca7a176a6 > > Some things are not included yet, such as a testnet whose size runs ahead > of the main chain, and the inclusion of Gavin's more accurate sigop > checking after the hard fork. > > Comments? Maybe this part could use a bit more rationale, it looks like its a sudden and unexplained. > No hard forking change that relaxes the block size limit can be guaranteed > to provide enough space for every possible demand - or even any particular > demand - unless strong centralization of the mining ecosystem is expected. -- Thomas Zander 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 1F5C5405 for ; Fri, 31 Jul 2015 10:16:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F092FEE for ; Fri, 31 Jul 2015 10:16:46 +0000 (UTC) Received: by ioii16 with SMTP id i16so80744972ioi.0 for ; Fri, 31 Jul 2015 03:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vinumeris.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3vxxKpGRqLr/ki9mCTgQGyeCbUoWt2z0v5kby2ZBLAE=; b=pm+X5IogYfIvLtj1yuDlqqUFaxTuD2t0Mk2BScGp0pPtOyDjWUfPcqlc2gBP6b3+2o uNu+PJrUjFCJOcLpMSINhQESlsGmZhomYDm75MJrYCKGPLeg3Ddpp7YupX3+vRK/zwQC 2LASyllTBSghOs3LJ9Iq7q4/kEG5kFhKV1RwM= 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=3vxxKpGRqLr/ki9mCTgQGyeCbUoWt2z0v5kby2ZBLAE=; b=GLq5EeMiE8DOvA+PeoR2ts05AcrOg1f+p59QZC1MF8Ke02xzUCkNWDvMkyY451PshQ uHRbDxitbRUmzDtkPGknJFrIC2JOghaaZlz7V3KjewPBCdSdCBzcZt59F2+1ICydFrDZ Iu6zvuJhxpujqa5dFQNAWB79Zn5lkwhTbY/PjuIBtAEwL+O+UEje3z7dw81dkGjz06H6 TR4WQyo7URXuuB+STsfXGFftKbrwWU9FcvtMF9f911bk8jAvYdbslteWJn2Au241fSCK RijpFZnW00wszAgf1ZqSy5NYcbnFL533KwR32HGwml2pRwGOMWG3qNEWUeE5p6BioABS xWFw== X-Gm-Message-State: ALoCoQkcFwBbpGAiJ+tR5AwP+MCzJKGFYTarH4shdKJ7Fn0KHwVtZ3mEjL6k1JmlsG4ZB2p51QCf MIME-Version: 1.0 X-Received: by 10.107.135.193 with SMTP id r62mr3198481ioi.29.1438337806445; Fri, 31 Jul 2015 03:16:46 -0700 (PDT) Received: by 10.50.108.111 with HTTP; Fri, 31 Jul 2015 03:16:46 -0700 (PDT) In-Reply-To: References: Date: Fri, 31 Jul 2015 12:16:46 +0200 Message-ID: From: Mike Hearn To: Pieter Wuille Content-Type: multipart/alternative; boundary=001a113eceb2054cb8051c291e9f X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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] Block size following technological growth X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 10:16:48 -0000 --001a113eceb2054cb8051c291e9f Content-Type: text/plain; charset=UTF-8 I agree with Gavin - whilst it's great that a Blockstream employee has finally made a realistic proposal (i.e. not "let's all use Lightning") - this BIP is virtually the same as keeping the 1mb cap. > Well, centralization of mining is already terrible. I see no reason why we > should encourage making it worse. > Centralization of mining has been a continual gripe since Slush first invented pooled mining. There has never been a time after that when people weren't talking about the centralisation of mining, and back then blocks were ~10kb. I see constant assertions that node count, mining centralisation, developers not using Bitcoin Core in their own businesses etc is all to do with block sizes. But nobody has shown that. Nobody has even laid the groundwork for that. Verifying blocks takes milliseconds and downloading them takes seconds everywhere except, apparently, China: this resource usage is trivial. Yet developers, miners and users even outside of China routinely delegate validation to others. Often for quite understandable technical reasons that have nothing to do with block sizes. So I see no reason why arbitrarily capping the block size will move the needle on these metrics. Trying to arrest the growth of Bitcoin for everyone won't suddenly make Bitcoin-Qt a competitive wallet, or make service devs migrate away from chain.com, or make merchants stop using BitPay. We need to accept that, and all previous proposals I've seen don't seem to > do that. > I think that's a bit unfair: BIP 101 keeps a cap. Even with 8mb+growth you're right, some use cases will be priced out. I initiated the micropayment channels project (along with Matt, tip of the hat) specifically to optimise a certain class of transactions. Even with 8mb+ blocks, there will still be a need for micropayment channels, centralised exchange platforms and other forms of off chain transaction. If Bitcoin needs to support a large scale, it already failed. > It hasn't even been tried. The desperately sad thing about all of this is that there's going to be a fork, and yet I think most of us agree on most things. But we don't agree on this. Bitcoin can support a large scale and it must, for all sorts of reasons. Amongst others: 1. Currencies have network effects. A currency that has few users is simply not competitive with currencies that have many. There's no such thing as a settlement currency for high value transactions only, as evidenced by the ever-dropping importance of gold. 2. A decentralised currency that the vast majority can't use doesn't change the amount of centralisation in the world. Most people will still end up using banks, with all the normal problems. You cannot solve a problem by creating a theoretically pure solution that's out of reach of ordinary people: just ask academic cryptographers! 3. Growth is a part of the social contract. It always has been. The best quote Gregory can find to suggest Satoshi wanted small blocks is a one sentence hypothetical example about what *might* happen if Bitcoin users became "tyrannical" as a result of non-financial transactions being stuffed in the block chain. That position makes sense because his scaling arguments assuming payment-network-sized traffic and throwing DNS systems or whatever into the mix could invalidate those arguments, in the absence of merged mining. But Satoshi did invent merged mining, and so there's no need for Bitcoin users to get "tyrannical": his original arguments still hold. 4. All the plans for some kind of ultra-throttled Bitcoin network used for infrequent transactions neglect to ask where the infrastructure for that will come from. The network of exchanges, payment processors and startups that are paying people to build infrastructure are all based on the assumption that the market will grow significantly. It's a gamble at best because Bitcoin's success is not guaranteed, but if the block chain cannot grow it's a gamble that is guaranteed to be lost. So why should anyone go through the massive hassle of setting up exchanges, without the lure of large future profits? 5. Bitcoin needs users, lots of them, for its political survival. There are many people out there who would like to see digital cash disappear, or be regulated out of existence. They will argue for that in front of governments and courts .... some already are. And if they're going to lose those arguments, the political and economic damage of getting rid of Bitcoin must be large enough to make people think twice. That means it needs supporters, it needs innovative services, it needs companies, and it needs legal users making legal payments: as many of them as possible. If Bitcoin is a tiny, obscure currency used by drug dealers and a handful of crypto-at-any-cost geeks, the cost of simply banning it outright will seem trivial and the hammer will drop. There won't be a large scale payment network OR a high-value settlement network. And then the world is really screwed, because nobody will get a second chance for a very long time. --001a113eceb2054cb8051c291e9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I agree with Gavin - whilst it's great that a Blockstream employee has= finally made a realistic proposal (i.e. not "let's all use Lightn= ing") - this BIP is virtually the same as keeping the 1mb cap.

Well, centralization of mining = is already terrible. I see no reason why we should encourage making it wors= e.

Centralization of mining has been a continual gripe= since Slush first invented pooled mining. There has never been a time afte= r that when people weren't talking about the centralisation of mining, = and back then blocks were ~10kb.=C2=A0

I see const= ant assertions that node count, mining centralisation, developers not using= Bitcoin Core in their own businesses etc is all to do with block sizes. Bu= t nobody has shown that. Nobody has even laid the groundwork for that. Veri= fying blocks takes milliseconds and downloading them takes seconds everywhe= re except, apparently, China: this resource usage is trivial.=C2=A0

Yet developers, miners and users even outside of China ro= utinely delegate validation to others. Often for quite understandable techn= ical reasons that have nothing to do with block sizes.

So I see no reason why arbitrarily capping the block size will move th= e needle on these metrics. Trying to arrest the growth of Bitcoin for every= one won't suddenly make Bitcoin-Qt a competitive wallet, or make servic= e devs migrate away from chain.com, or mak= e merchants stop using BitPay.

We need to accept that, and all previous proposals I&= #39;ve seen don't seem to do that.

I think that= 9;s a bit unfair: BIP 101 keeps a cap. Even with 8mb+growth you're righ= t, some use cases will be priced out. I initiated the micropayment channels= project (along with Matt, tip of the hat) specifically to optimise a certa= in class of transactions. Even with 8mb+ blocks, there will still be a need= for micropayment channels, centralised exchange platforms and other forms = of off chain transaction.

If Bitcoin needs to support a large scale, it already fail= ed.

It hasn't even been tried.=C2=A0

The desperately sad thing about all of this is that th= ere's going to be a fork, and yet I think most of us agree on most thin= gs.=C2=A0 But we don't agree on this.=C2=A0

Bi= tcoin can support a large scale and it must, for all sorts of reasons. Amon= gst others:

Currencies have network effects. A currency t= hat has few users is simply not competitive with currencies that have many.= There's no such thing as a settlement currency for high value transact= ions only, as evidenced by the ever-dropping importance of gold.
A decentralised currency that the vast majority can't use doe= sn't change the amount of centralisation in the world. Most people will= still end up using banks, with all the normal problems. You cannot solve a= problem by creating a theoretically pure solution that's out of reach = of ordinary people: just ask academic cryptographers!
G= rowth is a part of the social contract. It always has been.=C2=A0

Th= e best quote Gregory can find to suggest Satoshi wanted small blocks is a o= ne sentence hypothetical example about what might happen if Bitcoin = users became "tyrannical" as a result of non-financial transactio= ns being stuffed in the block chain. That position makes sense because his = scaling arguments assuming payment-network-sized traffic and throwing DNS s= ystems or whatever into the mix could invalidate those arguments, in the ab= sence of merged mining. But Satoshi did invent merged mining, and so there&= #39;s no need for Bitcoin users to get "tyrannical": his original= arguments still hold.
All the plans for some kind of u= ltra-throttled Bitcoin network used for infrequent transactions neglect to = ask where the infrastructure for that will come from. The network of exchan= ges, payment processors and startups that are paying people to build infras= tructure are all=C2=A0based on the assumption that the market will grow sig= nificantly. It's a gamble at best because Bitcoin's success is not = guaranteed, but if the block chain cannot grow it's a gamble that is gu= aranteed to be lost.

So why should anyone go through the massive has= sle of setting up exchanges, without the lure of large future profits?
<= br>
Bitcoin needs users, lots of them, for its political surviv= al. There are many people out there who would like to see digital cash disa= ppear, or be regulated out of existence. They will argue for that in front = of governments and courts .... some already are. And if they're going t= o lose those arguments, the political and economic damage of getting rid of= Bitcoin must be large enough to make people think twice. That means it nee= ds supporters, it needs innovative services, it needs companies, and it nee= ds legal users making legal payments: as many of them as possible.

I= f Bitcoin is a tiny, obscure currency used by drug dealers and a handful of= crypto-at-any-cost geeks, the cost of simply banning it outright will seem= trivial and the hammer will drop. There won't be a large scale payment= network OR a high-value settlement network. And then the world is really s= crewed, because nobody will get a second chance for a very long time.

--001a113eceb2054cb8051c291e9f-- 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 E68DC268 for ; Fri, 31 Jul 2015 11:44:08 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bihthai.net (unknown [5.255.87.165]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9C5427C for ; Fri, 31 Jul 2015 11:44:07 +0000 (UTC) Received: from [10.8.0.6] (unknown [10.8.0.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: venzen) by mail.bihthai.net (Postfix) with ESMTPSA id 78C2D20CA7 for ; Fri, 31 Jul 2015 13:45:42 +0200 (CEST) Message-ID: <55BB5F7E.2020604@mail.bihthai.net> Date: Fri, 31 Jul 2015 18:43:58 +0700 From: Venzen Khaosan Reply-To: venzen@mail.bihthai.net Organization: Bihthai Bai Mai User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Bitcoin Dev References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_05,NO_DNS_FOR_FROM, RDNS_NONE 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] Block size following technological growth X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 11:44:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mike Hearn, I might be a nobody to you, but you know i talk with skill, so let me tell this Friday... On 07/31/2015 05:16 PM, Mike Hearn via bitcoin-dev wrote: > I agree with Gavin You would, of course. > Bitcoin can support a large scale and it must, for all sorts of > reasons. Amongst others: > > 1. Currencies have network effects. A currency that has few users > is simply not competitive with currencies that have many. There's > no such thing as a settlement currency for high value transactions > only, as evidenced by the ever-dropping importance of gold. References are imperative if you want to appeal to intelligence in this list. Studies. Impirical evidence. The above sounds like a a mainstream precis of how money works - an over-simplistic precis. It's more complex than that. Besides, all we know for a fact is that currencies come and go. That's not me being down on Bitcoin - that is the historical record. > > 2. A decentralised currency that the vast majority can't use > doesn't change the amount of centralisation in the world. Most > people will still end up using banks, with all the normal > problems. You cannot solve a problem by creating a theoretically > pure solution that's out of reach of ordinary people: just ask > academic cryptographers! Conjecture. And assumption. Banks might not accept most people forever. Or banks' credibility might not survive the next credit contraction, for example. > > 3. Growth is a part of the social contract. It always has been. > Half the story. Casual observation shows that growth and contraction alternate at every level of existence. Just because the present fiat-era credit expansion has lasted 40 years does not mean that the economy will keep expanding forever. > The best quote Gregory can find to suggest Satoshi wanted small > blocks is a one sentence hypothetical example about what /might/ [snip] yes, anyway, Greg Maxwell was justified in bringing you down a few notches from your "I am Satoshi's rep on earth" history revision, you were spinning there. > 4. All the plans for some kind of ultra-throttled Bitcoin network > used [snip] > The network of exchanges, payment processors and startups that are > paying people to build infrastructure are all based on _the > assumption_ that the market will grow significantly. The assumption (my emphasis). You've seen that movie Pulp Fiction: "Assume makes an "ass" of "U" and "me". Business + assumption = gambling and potential loss of funds. The ass-U-me cannot be laid at the doorstep of those developers who prioritize security, decentralization and conservative, tested progress of scaling. > So why should anyone go through the massive hassle of setting up > exchanges, without the lure of large future profits? > Their SWOT analysis includes risks from the banking sector, too. Plus competition from other exchanges. A sapling 0.x Bitcoin community is not responsible for nannying anyone's lucrative business model at the expense of security. How would that make the developers look in relation to their duty of custody of the protocol? To this and future generations: Not Good. > > 5. Bitcoin needs users, lots of them, for its political survival. > There are many people out there who would like to see digital cash > disappear, or be regulated out of existence. Nonsense, and again that assumption about "how things work" you like to high horse so. Bitcoin's political survival is guaranteed by its censorship resistance and its array of innovative and unique utility functions. What's more, the caliber of developer working on Bitcoin is not just pulled out of a hat and harnessed for an arbitrary altcoin. Sometimes the fire of moral incentive overrides monetary reward. The Fed, Nasdaq, IBM, and every other company whose trusted authority is being threatened by this flagship are developing blockchains in a hurry. How is that "many people out there who would like to see digital cash disappear"? Why would you even type such a blatant falsehood? > If Bitcoin is a tiny, obscure currency used by drug dealers and a > handful of crypto-at-any-cost geeks, the cost of simply banning it > outright will seem trivial and the hammer will drop. There won't be > a large scale payment network OR a high-value settlement network. > And then the world is really screwed, because nobody will get a > second chance for a very long time. > That is a low estimation of Bitcoin. Your framing does not honor Bitcoin or the hard work - your _own_ hard work - on this project. If you noticed, there has been an increase in technical discussion in this list in recent days - with the goal of comparing and testing the various blocksize proposals. Mike Hearn, I am sorry to say that your pronouncements sound like jazz - - but jazz without rhythm. "So what?" - Miles Davis -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVu199AAoJEGwAhlQc8H1mkCMH/iWnFDXAGc5GEjLi81dRLUnz 3UfciwOiby8r+7pvyDsuMYR/9RQZv2RlFoMFjUBkJxwvdUh3eXY5tsQ6F209O+gk QleFaTKCZLVuZg5UBbwBttGfK3MmejueGWNhExYnlbm6yXpBa2jt0i5n0tr++zVw RN+zAejOy2OEBjs7jkodgVdy7kfCXsfsn/DKGdSO7nE9m5q0ocuUFBLEf/PJErBw NncLSDhd2SfVz3Q7L9UrGqKIgQTJT1nR9kJmSPCasIRoLWJzfNemH6RL3XcmiACn xIQBN19FPnKLv1OY3GlFLlmIlq0mu6MeidJsPl80yyI2h4SciCp39T1Ah/tCnf4= =2uWe -----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 843ED3C8 for ; Fri, 31 Jul 2015 11:51:06 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ADD0A7C for ; Fri, 31 Jul 2015 11:51:05 +0000 (UTC) Received: by wicmv11 with SMTP id mv11so55124846wic.0 for ; Fri, 31 Jul 2015 04:51:04 -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=OsTiQgbevT7zDmtYHdQJW/MgF9t62xO/gkx2t+tVZ68=; b=SJ6IcUYkxEQqXLhVmaomCphVDLGW3TDAdVtZqDyeN9fhcZm7XgV1wIlHAOnzGsWy5X +jIFMaG46uwX5V3WflBh5js7JDQO0XYlnCw2pbaCoLsXSR452iOxabGfXvLAW2sU69aJ XkDLao+ymbeUflTkE63yndVIg70oFWjPL054ZKmbu+oogc6fvbToEEAbb9XEyrlHSseU ar8WtAAlmWAezc1wPiZio3puUQcZ6YFBjxdtGxX4tIUZ/0hIGe+61r5Lc6++B4MaP/q8 gpUeR9wjZKBCYPpxpoWsShAOD08OUNYR4VS86L3PhD+LULgDDi/zPJh3KNFjcHjOHWnP rO2Q== X-Gm-Message-State: ALoCoQk5Nn3WLWBCvt74uHGxyiIqQ40AgNYNcNZH8wyz9wQkkms0khM35UBMOTrATPwLE8OiRO+y MIME-Version: 1.0 X-Received: by 10.180.109.106 with SMTP id hr10mr6375725wib.58.1438343464314; Fri, 31 Jul 2015 04:51:04 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Fri, 31 Jul 2015 04:51:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 31 Jul 2015 13:51:04 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Mike Hearn 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] Block size following technological growth X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 11:51:06 -0000 On Fri, Jul 31, 2015 at 12:16 PM, Mike Hearn via bitcoin-dev wrote: >> Well, centralization of mining is already terrible. I see no reason why we >> should encourage making it worse. > > I see constant assertions that node count, mining centralisation, developers > not using Bitcoin Core in their own businesses etc is all to do with block > sizes. But nobody has shown that. Nobody has even laid the groundwork for > that. Verifying blocks takes milliseconds and downloading them takes seconds > everywhere except, apparently, China: this resource usage is trivial. He is not saying that. Whatever the reasons for centralization are, it is obvious that increasing the size won't help. In the best case, it will only make it slightly worse. How big of a "slightly worse" are we willing to risk to increase the size is the open question. > So I see no reason why arbitrarily capping the block size will move the > needle on these metrics. Trying to arrest the growth of Bitcoin for everyone > won't suddenly make Bitcoin-Qt a competitive wallet, or make service devs > migrate away from chain.com, or make merchants stop using BitPay. As far as I know, people just want to change an arbitrary number for another arbitrary number. But this arbitrary cap is a cap to centralization, not a tool to make Bitcoin-Qt more important or to attack concrete Bitcoin companies like you seem to think. If you don't think the blocksize cap helps limiting centralization and you think it would be fine to completely remove it, then it would be better for the conversation that you said that directly instead of supporting other arbitrary caps like 8GB (bip101). I think it would be nice to have some sort of simulation to calculate a "centralization heuristic" for different possible blocksize values so we can compare these arbitrary numbers somehow. Even if the first definition of this "centralization heuristic" is stupid, it would be better than keep rolling dices and heatedly defend one result over another. To reiterate, If you don't think the blocksize cap helps limiting centralization, please, say so. If we can't agree on what the limit is for, we will never be able to agree on whether 1MB (current situation) or 8GB (bip101) is the most appropriate value to have at a given point in time. >> We need to accept that, and all previous proposals I've seen don't seem to >> do that. > > I think that's a bit unfair: BIP 101 keeps a cap. Even with 8mb+growth > you're right, some use cases will be priced out. I initiated the > micropayment channels project (along with Matt, tip of the hat) specifically > to optimise a certain class of transactions. Even with 8mb+ blocks, there > will still be a need for micropayment channels, centralised exchange > platforms and other forms of off chain transaction. Lightning is nothing more than a better design for trustless payment channels, but it's really good that you agree that if we want to scale not everything can be broadcast in-chain. >> If Bitcoin needs to support a large scale, it already failed. > > It hasn't even been tried. What he means is that if Bitcoin needs to support a scale that is only feasible with high degrees of centralization (say, supporting 1 M tx/s right now), then it has already failed in its decentralization goals. In fact, with only a few miners, I'm not sure regulators will still agree Bitcoin transactions are irreversible... But you are right, we haven't tried to destroy bitcoin by removing the only available consensus tool to limit centralization yet. I don't want to try, do you? > A decentralised currency that the vast majority can't use doesn't change the > amount of centralisation in the world. Most people will still end up using > banks, with all the normal problems. You cannot solve a problem by creating > a theoretically pure solution that's out of reach of ordinary people: just > ask academic cryptographers! Let's go to "most people use bitcoin" first and then think about "many people ONLY use Bitcoin" later, please. I believe everybody here thinks that the more people are able to use Bitcoin, the better. But that doesn't > All the plans for some kind of ultra-throttled Bitcoin network used for > infrequent transactions neglect to ask where the infrastructure for that > will come from. The network of exchanges, payment processors and startups > that are paying people to build infrastructure are all based on the > assumption that the market will grow significantly. It's a gamble at best > because Bitcoin's success is not guaranteed, but if the block chain cannot > grow it's a gamble that is guaranteed to be lost. Risking destroying Bitcoin through centralization to be able to keep free transactions for longer it's a very risky gamble. Doing so explicitly against the will of some of the users by promoting schism hardfork, and thus risking to economically destroy both Bitcoin and Bitcoin_new_size (different currencies) in the process is also a very risky gamble. So may want to give some example of responsibility yourself to make these calls to responsibility more credible. You certainly cannot know what "all the payment processors and startups plans" are based on, and spreading conspiracy theories about the evil secret plans of Blockstream (or any other Bitcoin company) doesn't help in keeping this discussion civilized, contaminates bitcoin development in general and unhealthily polarizes the whole Bitcoin ecosystem. Also, I believe is doing a disservice to your reputation among technical people, but since you don't seem worried about that, why should I be? > So why should anyone go through the massive hassle of setting up exchanges, > without the lure of large future profits? Are you suggesting that bitcoin consensus rules should be designed to maximize the profits of Bitcoin exchanges? I assume not, but I'm really having troubles trying to read the question with another meaning. Can you rephrase this, please? 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 11759407 for ; Fri, 31 Jul 2015 12:15:06 +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 6B69AFA for ; Fri, 31 Jul 2015 12:15:05 +0000 (UTC) Received: by igbij6 with SMTP id ij6so15052674igb.1 for ; Fri, 31 Jul 2015 05:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vinumeris.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iywlwQzDlW5LRDxS/df1DgowTnvP386SP1N2uFzs8GE=; b=b6BZOCvpLwHEdJgvS890xcRIy4I65XzqI5KaI2bdQbYnniBuxX7ABoBKOkctBZ37sw WaLeAbMBrYNfLQPRNUTpPiqKKrrvKQdWBGWWncID27SN3MV1lh3d6z/Xg+kLAK9pCpGd EOm9jlt5rEwfo95jQTyVe5HbKT1+LSGttH78s= 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=iywlwQzDlW5LRDxS/df1DgowTnvP386SP1N2uFzs8GE=; b=ZLH55c2fbsyG2QOHfakZXdNSVq6ATflbPJE1Mryeyeb1oKLOzPA4He25aoT8tMtY6D UB7g0VtmmJBTuaqN7IiuygQMck/vX0Gc4YO4HC43mBmtcYMFmoI+KgrFQymeXYONPsVL zVo9zJ8EAyR4Atbhn2sPFWPVolwYb9Wgw6W7Zj1i+ByOUxTO5H0kb1CM5xZ5Ovf7avbM edAE0aTeuR0ODI1jRZBLh5sZ6MyphwhSKEI1zTc28cEZQ17tEQnh5aD6WbE+ZtMd+OQ3 ljP1O2mE/8T8zRCFIvHnoVtsXYAlWzoMXan+hf2d58KlXlK7bcPzbUzxv3WyEN9svkTl hLPQ== X-Gm-Message-State: ALoCoQkh55TijjvKfBUwXkDtPPtnXqbInG4arqYuwHihWiIKoIVJGLTxn04JkKMomOO9xs+AzzbV MIME-Version: 1.0 X-Received: by 10.50.45.41 with SMTP id j9mr5415013igm.34.1438344904865; Fri, 31 Jul 2015 05:15:04 -0700 (PDT) Received: by 10.50.108.111 with HTTP; Fri, 31 Jul 2015 05:15:04 -0700 (PDT) In-Reply-To: References:

Date: Fri, 31 Jul 2015 14:15:04 +0200 Message-ID: From: Mike Hearn To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary=089e0111ba961e973d051c2ac582 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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] Block size following technological growth X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 12:15:06 -0000 --089e0111ba961e973d051c2ac582 Content-Type: text/plain; charset=UTF-8 Hey Jorge, He is not saying that. Whatever the reasons for centralization are, it > is obvious that increasing the size won't help. > It's not obvious. Quite possibly bigger blocks == more users == more nodes and more miners. To repeat: it's not obvious to me at all that everything wrong with Bitcoin can be solved by shrinking blocks. I don't think that's going to suddenly make everything magically more decentralised. The 8mb cap isn't quite arbitrary. It was picked through negotiation with different stakeholders, in particular, Chinese miners. But it should be high enough to ensure organic growth is not constrained, which is good enough. I think it would be nice to have some sort of simulation to calculate > a "centralization heuristic" for different possible blocksize values > so we can compare these arbitrary numbers somehow. Centralization is not a single floating point value that is controlled by block size. It's a multi-faceted and complex problem. You cannot "destroy Bitcoin through centralization" by adjusting a single constant in the source code. To say once more: block size won't make much difference to how many merchants rely on payment processors because they aren't using them due to block processing overheads anyway. So trying to calculate such a formula won't work. Ditto for end users on phones, ditto for developers who want JSON/REST access to an indexed block chain, or hosted wallet services, or miners who want to reduce variance. None of these factors have anything to do with traffic levels. What people like you are Pieter are doing is making a single number a kind of proxy for all fears and concerns about the trend towards outsourcing in the Bitcoin community. Everything gets compressed down to one number you feel you can control, whether it is relevant or not. > So why should anyone go through the massive hassle of setting up > exchanges, > > without the lure of large future profits? > > Are you suggesting that bitcoin consensus rules should be designed > to maximize the profits of Bitcoin exchanges? > That isn't what I said at all Jorge. Let me try again. Setting up an exchange is a lot of risky and expensive work. The motivation is profit, and profits are higher when there are more users to sell to. This is business 101. If you remove the potential for future profit, you remove the motivation to create the services that we now enjoy and take for granted. Because if you think Bitcoin can be useful without exchanges then let me tell you, I was around when there were none. Bitcoin was useless. --089e0111ba961e973d051c2ac582 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hey Jorge,

He is not saying that. Whateve= r the reasons for centralization are, it
is obvious that increasing the size won't help.

It's not obvious. Quite possibly bigger blocks =3D=3D more= users =3D=3D more nodes and more miners.

To repea= t: it's not obvious to me at all that everything wrong with Bitcoin can= be solved by shrinking blocks. I don't think that's going to sudde= nly make everything magically more decentralised.

= The 8mb cap isn't quite arbitrary. It was picked through negotiation wi= th different stakeholders, in particular, Chinese miners. But it should be = high enough to ensure organic growth is not constrained, which is good enou= gh.

I think it would be = nice to have some sort of simulation to calculate
a "centralization heuristic" for different possible blocksize val= ues
so we can compare these arbitrary numbers somehow.

Centralization is not a single floating point value that is contro= lled by block size. It's a multi-faceted and complex problem. You canno= t "destroy Bitcoin through centralization" by adjusting a single = constant in the source code.

To say once more: blo= ck size won't make much difference to how many merchants rely on paymen= t processors because they aren't using them due to block processing ove= rheads anyway. So trying to calculate such a formula won't work. Ditto = for end users on phones, ditto for developers who want JSON/REST access to = an indexed block chain, or hosted wallet services, or miners who want to re= duce variance.

None of these factors have anything= to do with traffic levels.

What people like you a= re Pieter are doing is making a single number a kind of proxy for all fears= and concerns about the trend towards outsourcing in the Bitcoin community.= Everything gets compressed down to one number you feel you can control, wh= ether it is relevant or not.

> So why should anyone go through the massive hass= le of setting up exchanges,
> without the lure of large future profits?

Are you suggesting that bitcoin consensus rules should be designed t= o=C2=A0maximize the profits of Bitcoin exchanges?

That isn't what I said at all Jorge. Let me try again.

Setting up an exchange is a lot of risky and expensive = work. The motivation is profit, and profits are higher when there are more = users to sell to. This is business 101.

If you rem= ove the potential for future profit, you remove the motivation to create th= e services that we now enjoy and take for granted. Because if you think Bit= coin can be useful without exchanges then let me tell you, I was around whe= n there were none. Bitcoin was useless.

--089e0111ba961e973d051c2ac582-- 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 16643268 for ; Fri, 31 Jul 2015 13:07:45 +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 263AD1AC for ; Fri, 31 Jul 2015 13:07:44 +0000 (UTC) Received: by ykdu72 with SMTP id u72so58448717ykd.2 for ; Fri, 31 Jul 2015 06:07:43 -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=5bhLQIrzQclFFpf11jo8VhY9ZU5liO4MM7n66lZMFvk=; b=R0DouLHv6z4/VEmdYUI7mUdOjVtrNJVg7EtLfswIOsj9d6K1gllWn97s7PpGOMzkVd TcyqjY7vSRjIMdGfxN65/k5VHDO24VaTZv5Y6iZzb/iJxLWNpU93onfc9D2wAMCfMGbA UiifOd6xQqDgn20/6Gg6N/HA3RlFs5kSc8noDSz6Qv8jOv1UW7+947pf5I7pFd2f2V8Q hb7XMMRxi8G5ut7cHgUqYNZiLlYlTpdsoIOZEo4WGksCwxhyroUDTjVI1hoIoUgujd4r FA8RrbZ6kF7E+dPBibB3EFjFw0pF7N5Rt3+lEW+1vzdOM62gePXYm6hEih8xP09xfx4/ gwTA== X-Gm-Message-State: ALoCoQmzFNU5i916Bz408GIOzMlC5egHLZIPBTgbkt+CedRR96WHfi3TgqqYpNI1UaAAxzKSp+TG MIME-Version: 1.0 X-Received: by 10.129.117.196 with SMTP id q187mr3050592ywc.15.1438348063047; Fri, 31 Jul 2015 06:07:43 -0700 (PDT) Received: by 10.13.224.69 with HTTP; Fri, 31 Jul 2015 06:07:42 -0700 (PDT) In-Reply-To: References:

--001a1147f7285cb153051c2b81f9-- 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 3DF0D481 for ; Fri, 31 Jul 2015 14:33:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B401C1C9 for ; Fri, 31 Jul 2015 14:33:16 +0000 (UTC) Received: by wicmv11 with SMTP id mv11so60605329wic.0 for ; Fri, 31 Jul 2015 07:33: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:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kytUwBBsA4G2K339vEXdMXsyzXau+tEBFGjtS2SuO58=; b=P9NrS9zuQLFSZ6Zb0Ay4F5NUeqFlLIYqMQXAHNkDEcnOLdas4KybiD548rgDKUXfCK +2q5GzxOiB2L8xQ9lerPPVZ+w4VamOP1XROw3i3K7tW44UNiAbn0f5OxMr9DqILnO1Ds U5z8EPO98TwBMqRQr2om2I39gci4QQMn7YJ/AkMq+nT3nUdVVJ3MK13IIpzJK530gSkj auVLZYfEaGE9HL1RzBkPNU9WNhZIxmTKn7Yl9++nqhXpdp/+6j5VKwOkFDZOnHDJ5aob +q3cYaT6Ga24SXeYtb1IpsXtpZ6leEYvWTXtTgrcpAbEeNLLUFbCDBqhHaW3tkoOWN2P 28nw== X-Gm-Message-State: ALoCoQn9KVPW5t0RWyqb5rJoA1vVA/h9uOSYjYzFejUoECUaYCFpO7q1MSgnUlvhsHRBBVzQLvya MIME-Version: 1.0 X-Received: by 10.181.13.169 with SMTP id ez9mr6568263wid.92.1438353195082; Fri, 31 Jul 2015 07:33:15 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Fri, 31 Jul 2015 07:33:14 -0700 (PDT) In-Reply-To: References: