Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B72FDB8A for ; Fri, 27 Jan 2017 23:53:04 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f54.google.com (mail-vk0-f54.google.com [209.85.213.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F0A73A0 for ; Fri, 27 Jan 2017 23:53:03 +0000 (UTC) Received: by mail-vk0-f54.google.com with SMTP id t8so185621546vke.3 for ; Fri, 27 Jan 2017 15:53:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=AYQO3q0PSO4PDIs2n41ONOXw8TIVyo+FSwlx0EjDh4Y=; b=cuS8FOsVQvV2X04779qUvZU14HqodvfRb6RZpmKHPTjf8jPrRtbg7OwkT15Vf5cYBF Uh2B/uJJZvfFFdO8clrV11feuvwBwRKEF4YajRre6KS/ruR+iqMEDYCB9JSCrpomyN+k w9zjSENIKtMEG4jBpnnZyVjCHliYHFszCNnsLYjFWnhse4nfi2toCd/yUNo5qmtOsWo/ imuE5XT8R+a2ql90m4zz3W8B3SXOOn0hf6aKCvuI8/qcvw4G4u9hOkykKTV/nE0XOi49 qHV+wlTSkDd0Glj4UPVTQQWycY4OxE5XeNODWWVTeZkFruRaR1/JjH9fjYhMlYDXnqq+ 2JCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=AYQO3q0PSO4PDIs2n41ONOXw8TIVyo+FSwlx0EjDh4Y=; b=gwzzwgx4WvE0oUrCHdM5Nafb9xJ6kU3svn+LKgHNse5B3YXMRTb+/fGuBn/nTdfWfj RiQx3psuSn9hrytQGPH4W2I+GZ0JtJ9PycydOlRMo/zQ/IGhcLTmmJsu8yjiCI7JgSvU CsPnZXKv6Zs/qs2O92Sug8y+mfrIivXprAG3wQ8H5dXFiOYEitxVb6T1o/Z7KlmPlBCb 3qQjhdn3scCR5g17yphXNf9O5m8U7UmH6lvSdTaIvyUOoH9UMOB8nFcz6BokPIi4Dg0l lOVy3xVgGSlGU29xysGjUN6NA9Yp/QywC1LDFM+yAaGG4EHWkalj2b/fk+I81b0wZ6DP 6c4Q== X-Gm-Message-State: AIkVDXLA0qy1tAQHUbLSHGxe9Fv3OMB3cttVMnC5uQVPSAMNQj/fg1oraFzlDccUnzTuVQjX6m9zBBSBn91OQQ== X-Received: by 10.31.86.196 with SMTP id k187mr5257597vkb.4.1485561183106; Fri, 27 Jan 2017 15:53:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.152.19 with HTTP; Fri, 27 Jan 2017 15:53:02 -0800 (PST) Received: by 10.103.152.19 with HTTP; Fri, 27 Jan 2017 15:53:02 -0800 (PST) In-Reply-To: <20170127212810.GA5856@nex> References: <201701270107.01092.luke@dashjr.org> <201701270414.18553.luke@dashjr.org> <20170127212810.GA5856@nex> From: Andrew Johnson Date: Fri, 27 Jan 2017 17:53:02 -0600 Message-ID: To: Bitcoin Dev , Christian Decker Content-Type: multipart/alternative; boundary=001a114e569a9c7b8905471c2ae3 X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 28 Jan 2017 00:01:23 +0000 Subject: Re: [bitcoin-dev] Three hardfork-related BIPs X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 23:53:04 -0000 --001a114e569a9c7b8905471c2ae3 Content-Type: text/plain; charset=UTF-8 Thanks for replying, I'd be interested to see what you would come up with today using the same methodology, seeing as max single hard drive capacity has roughly doubled, global average internet bandwidth has increased 31% from 4.8Mbps to 6.3Mbps(sourced from Akamai State of the Internet reports 2014q4 and 2016q3), and we now have xThin and compact blocks to help significantly with block propagation time. Not to mention the usual improvements in CPUs(not that we're anywhere near a CPU bottleneck today anyway save for quadratic hashing when raising the blocksize, but I don't think that anyone would seriously suggest an increase without addressing that). I don't think that the 17% yearly increase is too far off base considering current global trends(although I still don't particularly like the idea of centrally planning the limit, especially not that far into the future), but the 66% decrease first seems completely out of touch with reality. I'd also like to point out to Luke that Satoshi envisioned most full nodes running in data centers in the white paper, not every single user needs to run a full node to use bitcoin. Not to present this as an argument from authority, but rather to remind us what the intention of the system was to be(p2p cash, not a settlement layer only afforded by the wealthiest and largest value transactions). That a lot of people want to continue to move in that direction shouldn't be a surprise. On Jan 27, 2017 3:28 PM, "Christian Decker via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: On Fri, Jan 27, 2017 at 03:47:20PM -0500, Greg Sanders via bitcoin-dev wrote: > Note that the 4MB number comes from a single network metric. > > Quotes directly from the paper in question: > http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf > > >Our results hinge on the key metric of effective throughput in the overlay > network, which we define here as which blocks propagate within an average > block interval period the percentage of nodes to. > ... > >Note that as we consider only a subset of possible metrics (due to > difficulty in accurately measuring others), our results on > reparametrization may be viewed as upper bounds: additional metrics could > reveal even stricter limits. > > It says nothing about any mining centralization pressure, DoS attacks, etc. > A single metric among many we have to contend with. > As one of the authors of that paper and the source of the measurement data I'd also like to point out that the 4MB number is indeed intended as an optimistic upper bound on todays network capacity. More importantly it's not a black and white situation, where there is a magic number beyond which Bad Things (TM) happen, it's a spectrum on which we can see a few threshold beyond which we _know_ Bad Things definitely happen. Miner centralization pressure is felt earlier. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --001a114e569a9c7b8905471c2ae3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for replying, I'd be interested to see wh= at you would come up with today using the same methodology, seeing as max s= ingle hard drive capacity has roughly doubled, global average internet band= width has increased 31% from 4.8Mbps to 6.3Mbps(sourced from Akamai State o= f the Internet reports 2014q4 and 2016q3), and we now have xThin and compac= t blocks to help significantly with block propagation time.=C2=A0 Not to me= ntion the usual improvements in CPUs(not that we're anywhere near a CPU= bottleneck today anyway save for quadratic hashing when raising the blocks= ize, but I don't think that anyone would seriously suggest an increase = without addressing that).

I don't think that the 17% yearly increase is too far off base consid= ering current global trends(although I still don't particularly like th= e idea of centrally planning the limit, especially not that far into the fu= ture), but the 66% decrease first seems completely out of touch with realit= y.

I'd also like to = point out to Luke that Satoshi envisioned most full nodes running in data c= enters in the white paper, not every single user needs to run a full node t= o use bitcoin.=C2=A0 Not to present this as an argument from authority, but= rather to remind us what the intention of the system was to be(p2p cash, n= ot a settlement layer only afforded by the wealthiest and largest value tra= nsactions).=C2=A0 That a lot of people want to continue to move in that dir= ection shouldn't be a surprise.

On Jan 27, 2017 3:28= PM, "Christian Decker via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Fri, Jan 27, 2017 at 03:47:20PM -0500, Greg Sanders via= bitcoin-dev wrote:
> Note that the 4MB number comes from a single network metric.
>
> Quotes directly from the paper in question:
> http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf=
>
> >Our results hinge on the key metric of effective throughput in the= overlay
> network, which we define here as which blocks propagate within an aver= age
> block interval period the percentage of nodes to.
> ...
> >Note that as we consider only a subset of possible metrics (due to=
> difficulty in accurately measuring others), our results on
> reparametrization may be viewed as upper bounds: additional metrics co= uld
> reveal even stricter limits.
>
> It says nothing about any mining centralization pressure, DoS attacks,= etc.
> A single metric among many we have to contend with.
>

As one of the authors of that paper and the source of the measurement=
data I'd also like to point out that the 4MB number is indeed intended<= br> as an optimistic upper bound on todays network capacity.

More importantly it's not a black and white situation, where there is a magic number beyond which Bad Things (TM) happen, it's a spectrum on<= br> which we can see a few threshold beyond which we _know_ Bad Things
definitely happen. Miner centralization pressure is felt earlier.
___________________________________________= ____
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--001a114e569a9c7b8905471c2ae3--