Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B524D102D for ; Fri, 11 Sep 2015 17:54:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yk0-f169.google.com (mail-yk0-f169.google.com [209.85.160.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AD25E121 for ; Fri, 11 Sep 2015 17:54:18 +0000 (UTC) Received: by ykdu9 with SMTP id u9so99617885ykd.2 for ; Fri, 11 Sep 2015 10:54:17 -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=tCdNojmWl7Kk8gGoxwTb3I5rOSxyzheNIjAEa+DHFaw=; b=bOgrTWk7j/0h5g+wDVwz0bcX8GAsDmLas8+Tium3Mc4cGj8rvfr7lduB3eSBqqPnSs ivQJ2J/UVsUIa4CSQrUOe5jMfvFyk711CT/1iiTRzdA0wp1pr1iuDdr1tQ8oYbZoQDRo Az/EYrKLXiA8JNiwCYDodVzvankXZcAvrYiS/mkzYDIHS+fU0mxLiXCYRNtTEx0COFLw Ei/Ra2Bv/wDA4IgtitJNdzqaUw1gZVR93CHW9xuaZ35Wy4QjHaXDQEaPPaqRNtyzg7nR A/fHqxlbuZ02mBqyMtYauL6CGD7sUZQRHgTrSUbhNdeBgYZHpRTNixD7U/vJk0gzaPTA gy0g== X-Gm-Message-State: ALoCoQmG/Bp9F1g5ZtrZqEmaNxGN6ZoTyERIqz2tpWjYKgq3KnuKOLQ1D0wEZtDt9TTBX5d3Z970 MIME-Version: 1.0 X-Received: by 10.170.69.66 with SMTP id l63mr126ykl.89.1441994057301; Fri, 11 Sep 2015 10:54:17 -0700 (PDT) Received: by 10.13.220.65 with HTTP; Fri, 11 Sep 2015 10:54:17 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 Sep 2015 19:54:17 +0200 Message-ID: From: Marcel Jamin To: Adam Back Content-Type: multipart/alternative; boundary=001a113998ba8e76fb051f7c67b4 X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,URIBL_BLACK autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Yet another blocklimit proposal / compromise 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, 11 Sep 2015 17:54:19 -0000 --001a113998ba8e76fb051f7c67b4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Therefore it is important that it be reasonably convenient to run full nodes for decentralisation security. Yes, and I'm suggesting to define what "reasonably convenient" is in 2016. Most likely node operators have more than a little headroom for larger blocks. If you just use more of the processing power / storage / bandwidth you very likely already paid for then there is no increase in costs. > I think you maybe misunderstanding what the Chinese miners said also, abo= ut 8MB, that was a cap on the maximum they felt they could handle with current network infrastructure. And what they felt "remained fair to all to all miners and node operators worldwide." Increasing network connection requirements might even decrease mining centralization right now. 2015-09-11 18:47 GMT+02:00 Adam Back : > Bitcoin security depends on the enforcement of consensus rules which > is done by economically dependent full nodes. This is distinct from > miners fullnodes, and balances miners interests, otherwise SPV nodes > and decentralisation of policy would tend degrade, I think. Therefore > it is important that it be reasonably convenient to run full nodes for > decentralisation security. > > Also you may want to read this summary of Bitcoin decentralisation by Mar= k: > > > https://www.reddit.com/r/Bitcoin/comments/3h7eei/greg_luke_adam_if_xt_tak= es_over_and_wins_the/cu53eq3 > > I think you maybe misunderstanding what the Chinese miners said also, > about 8MB, that was a cap on the maximum they felt they could handle > with current network infrastructure. > > I had proposed 2-4-8MB growing over a 4 year time frame with 2MB once > the hard-fork is upgraded by everyone in the network. (I dont > consider miner triggers, as with soft-fork upgrades, to be an > appropriate roll out mechanism because it is more important that > economically dependent full nodes upgrade, though it can be useful to > know that miners also have upgraded to a reasonable extent to avoid a > temporary hashrate drop off affecting security). > > Adam > > On 9 September 2015 at 15:00, Marcel Jamin via bitcoin-dev > wrote: > > I think the overlap of people who want to run a serious mining operatio= n > and > > people who are unable to afford a slightly above average internet > connection > > is infinitesimally small. > > > > 2015-09-09 20:51 GMT+02:00 Jorge Tim=C3=B3n : > >> > >> > >> On Sep 9, 2015 8:36 PM, "Marcel Jamin via bitcoin-dev" > >> wrote: > >> > > >> > I propose to: > >> > > >> > a) assess what blocklimit is currently technically possible without > >> > driving up costs of running a node up too much. Most systems current= ly > >> > running a fullnode probably have some capacity left. > >> > >> What about the risk of further increasing mining centralization? > > > > > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > --001a113998ba8e76fb051f7c67b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0Therefore=C2=A0= it is important that it be reasonab= ly convenient to run full nodes for=C2=A0decentralisation security.

Yes, and I'm s= uggesting to define what "reasonably convenient" is in 2016. Most= likely node operators have more than a little headroom for larger blocks. = If you just use more of the processing power / storage / bandwidth you very= likely already paid for then there is no increase in costs.

>=C2=A0I think y= ou maybe misunderstanding what the Chinese miners said also,=C2=A0about 8MB, that was a cap on the maximum the= y felt they could handle=C2=A0with = current network infrastructure.

And what they= felt "remained fair to all=C2=A0to all miners and node operators worl= dwide." Increasing network connection requirements might even decrease= mining centralization right now.


=

2015-= 09-11 18:47 GMT+02:00 Adam Back <adam@cypherspace.org>:
Bitcoin security depends on the enforcemen= t of consensus rules which
is done by economically dependent full nodes.=C2=A0 This is distinct from miners fullnodes, and balances miners interests, otherwise SPV nodes
and decentralisation of policy would tend degrade, I think.=C2=A0 Therefore=
it is important that it be reasonably convenient to run full nodes for
decentralisation security.

Also you may want to read this summary of Bitcoin decentralisation by Mark:=

https://www.reddit.com/r/Bitcoin/comments/3h7eei/greg_luke_adam_if_xt_take= s_over_and_wins_the/cu53eq3

I think you maybe misunderstanding what the Chinese miners said also,
about 8MB, that was a cap on the maximum they felt they could handle
with current network infrastructure.

I had proposed 2-4-8MB growing over a 4 year time frame with 2MB once
the hard-fork is upgraded by everyone in the network.=C2=A0 (I dont
consider miner triggers, as with soft-fork upgrades, to be an
appropriate roll out mechanism because it is more important that
economically dependent full nodes upgrade, though it can be useful to
know that miners also have upgraded to a reasonable extent to avoid a
temporary hashrate drop off affecting security).

Adam

On 9 September 2015 at 15:00, Marcel Jamin via bitcoin-dev
<bitcoin-dev@li= sts.linuxfoundation.org> wrote:
> I think the overlap of people who want to run a serious mining operati= on and
> people who are unable to afford a slightly above average internet conn= ection
> is infinitesimally small.
>
> 2015-09-09 20:51 GMT+02:00 Jorge Tim=C3=B3n <jtimon@jtimon.cc>:<= br> >>
>>
>> On Sep 9, 2015 8:36 PM, "Marcel Jamin via bitcoin-dev" >> <bitco= in-dev@lists.linuxfoundation.org> wrote:
>> >
>> > I propose to:
>> >
>> > a) assess what blocklimit is currently technically possible w= ithout
>> > driving up costs of running a node up too much. Most systems = currently
>> > running a fullnode probably have some capacity left.
>>
>> What about the risk of further increasing mining centralization? >
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev
>

--001a113998ba8e76fb051f7c67b4--