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 3F7CD1203 for ; Fri, 11 Sep 2015 18:17:22 +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 3E216216 for ; Fri, 11 Sep 2015 18:17:21 +0000 (UTC) Received: by wicge5 with SMTP id ge5so72935198wic.0 for ; Fri, 11 Sep 2015 11:17: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; bh=yLbyz7HlHbtFqu8uQ63NgIkE5VJErs7O07c3ukvNRuU=; b=MAcZZqUC7KcF1zbuR34m+nEuB90nhIiYNJxwWZRup/Gljl2pIMlC5NyaP7uvmse5jp oU6WGW46GuYv0S3e2vrYvEoDv7b/AZcZIqpT1l3DMKyUk6zyXHVYJK7lRj08P+Kzs6Al uC8EhL2ypfs/+RIzVulwZYNM2dy4DrMBe5KvpD9SENUqUiNll8FK+ks+bUKb2ZmJTb7r 6XKc1UVkeEr9fS0lRS6FaGNjDbztSzREDGifKb12uqYl8MrBlPnOh1aw9Xd4uLqHMzTb Ll+H4IpkXg/WDmr7bX3nVrTTOjFRxLyb4bW6YtvIPgallMSpVKKF/rzM8ffde944waWX PeAw== X-Gm-Message-State: ALoCoQnWbNIa8/GKV+TwOuFx4DatWM+SWiJIQdfdSMb3TNgN9yYnbALpYKeYHllctk3mx4lH6dyd MIME-Version: 1.0 X-Received: by 10.194.122.97 with SMTP id lr1mr290688wjb.26.1441995439833; Fri, 11 Sep 2015 11:17:19 -0700 (PDT) Received: by 10.194.37.5 with HTTP; Fri, 11 Sep 2015 11:17:19 -0700 (PDT) Received: by 10.194.37.5 with HTTP; Fri, 11 Sep 2015 11:17:19 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 Sep 2015 20:17:19 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Marcel Jamin Content-Type: multipart/alternative; boundary=089e01228c70f59c6d051f7cb9d0 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 18:17:22 -0000 --089e01228c70f59c6d051f7cb9d0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sep 11, 2015 1:54 PM, "Marcel Jamin" wrote: > 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. No. People seem to think "Chinese have slow connections? Screw them, free competition." But not being well connected with the other miners is not a problem for the Chinese miners (who are the hashrate majority), it's a problem for the rest of the miners!! It's not about being well connected to the "global internet", it's about being well connected to the hashrate majority. > 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 Mark: >> >> https://www.reddit.com/r/Bitcoin/comments/3h7eei/greg_luke_adam_if_xt_takes= _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 operation 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 currently >> >> > 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 >> > > > --089e01228c70f59c6d051f7cb9d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sep 11, 2015 1:54 PM, "Marcel Jamin" <marcel@jamin.net> wrote:
> And what they felt "remained fair to all=C2=A0to all miners and n= ode operators worldwide." Increasing network connection requirements m= ight even decrease mining centralization right now.

No. People seem to think "Chinese have slow connections= ? Screw them, free competition."
But not being well connected with the other miners is not a problem for the= Chinese miners (who are the hashrate majority), it's a problem for the= rest of the miners!!
It's not about being well connected to the "global internet",= it's about being well connected to the hashrate majority.

> 2015-09-11 18:47 GMT+02:00 Adam Back <adam@cypherspace.org>:
>>
>> Bitcoin security depends on the enforcement of consensus rules whi= ch
>> is done by economically dependent full nodes.=C2=A0 This is distin= ct from
>> miners fullnodes, and balances miners interests, otherwise SPV nod= es
>> 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/Bi= tcoin/comments/3h7eei/greg_luke_adam_if_xt_takes_over_and_wins_the/cu53eq3<= /a>
>>
>> I think you maybe misunderstanding what the Chinese miners said al= so,
>> about 8MB, that was a cap on the maximum they felt they could hand= le
>> with current network infrastructure.
>>
>> I had proposed 2-4-8MB growing over a 4 year time frame with 2MB o= nce
>> the hard-fork is upgraded by everyone in the network.=C2=A0 (I don= t
>> 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 avoi= d a
>> temporary hashrate drop off affecting security).
>>
>> Adam
>>
>> On 9 September 2015 at 15:00, Marcel Jamin via bitcoin-dev
>> <bitco= in-dev@lists.linuxfoundation.org> wrote:
>> > I think the overlap of people who want to run a serious minin= g operation and
>> > people who are unable to afford a slightly above average inte= rnet connection
>> > is infinitesimally small.
>> >
>> > 2015-09-09 20:51 GMT+02:00 Jorge Tim=C3=B3n <jtimon@jtimon= .cc>:
>> >>
>> >>
>> >> On Sep 9, 2015 8:36 PM, "Marcel Jamin via bitcoin-de= v"
>> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >> >
>> >> > I propose to:
>> >> >
>> >> > a) assess what blocklimit is currently technically p= ossible without
>> >> > 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 centrali= zation?
>> >
>> >
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitc= oin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-de= v
>> >
>
>

--089e01228c70f59c6d051f7cb9d0--