Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 35B61B80 for ; Thu, 30 Mar 2017 15:38:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f178.google.com (mail-wr0-f178.google.com [209.85.128.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7F919186 for ; Thu, 30 Mar 2017 15:38:23 +0000 (UTC) Received: by mail-wr0-f178.google.com with SMTP id w43so65712394wrb.0 for ; Thu, 30 Mar 2017 08:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thinlink-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1DujFZqXuLIx5Bbx6g+Q+vHq/qs0V1bppNZN+8f9pQ8=; b=AHWSF+LEh0UwCDwq8OOUgV//NA53QXH1EAsrnPvNZFPKPiIwFmynzrRE2zFiGti1+D 7IAfUZOQLwhgkNgfxIGG2mgKnzyGMrS1X7kEyVeKS0+byKc+iI0RiwqB6tInGX81ku+o 9eWwUqsK99w5AaBc52Rhr04cTU2RKh+2RKyGVzJEnJ20bk5Ee8lQ9MMtGsm1iFXnLW+M n3xW4eAVvcF1f+ziC/rSO3m7UGwVmfpoOVg+iUhmOltVdN1mgGTuW2S7wA4lR2Y1o9ri Bov7gA5aDooONYhb44QE1EAz5kBCzl0gFzp8IMe8verRNZvmT/Ns9t8U6VgSMje5/BTZ rDZg== 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:cc; bh=1DujFZqXuLIx5Bbx6g+Q+vHq/qs0V1bppNZN+8f9pQ8=; b=gcGn3Dhu/hvHX03CLDgW0ijO/+wwCQGYo6sle6Uv4wKmzUaIBqcu9/+cvzanCyAAPH 2I1s86yGtuc41tqnvclKm2dJQEgbtzW8i0iSdNtPVF4GT8paOkHftskBpltg7aG438jY LtooD8zBBw3Rw2MrfPLIRhK4YX9qc2QyA7YqFrJ2LyxjjON9VNYN/6GdRjnOfEyQB82C 7R3C8E3Q2TDTKHOBnHkzpDxvQ1UicUCEsHPuz2gMOw2Ldl5AkHPhLnsLXUpBDZisQ2sG QomZeZoEy/fMmeT5bnrzzkSzHeA528fJsfuhP9PIhceMqcJdY1/w6CUtOTXZrJHVWGuJ OxSw== X-Gm-Message-State: AFeK/H3wWe1YGbbTzIbropiYZ9pP3A/PKbzKNPCgU/r6tLALHLygf1DUkwYzs5bUo2Gu1vr97p3ETt4wGjzruwNP X-Received: by 10.28.18.207 with SMTP id 198mr4246256wms.133.1490888301904; Thu, 30 Mar 2017 08:38:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.15.80 with HTTP; Thu, 30 Mar 2017 08:38:20 -0700 (PDT) Received: by 10.28.15.80 with HTTP; Thu, 30 Mar 2017 08:38:20 -0700 (PDT) In-Reply-To: References: From: Tom Harding Date: Thu, 30 Mar 2017 08:38:20 -0700 Message-ID: To: "Raystonn ." , Bitcoin Dev Content-Type: multipart/alternative; boundary=001a1145b928a2c1d4054bf47bee X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, 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: Thu, 30 Mar 2017 16:03:29 +0000 Subject: [bitcoin-dev] High fees / centralization 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: Thu, 30 Mar 2017 15:38:24 -0000 --001a1145b928a2c1d4054bf47bee Content-Type: text/plain; charset=UTF-8 Raystonn, Your logic is very hard to dispute. An important special case is small miners. Small miners use pools exactly because they want smaller, more frequent payments. Rising fees force them to take payments less frequently, and will only tend to make more of them give up. With fees rising superlinearly, this centralizing effect is much stronger than the oft-cited worry of small miners joining large pools to decrease orphan rates. On Mar 29, 2017 15:01, "Raystonn . via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: Low node costs are a good goal for nodes that handle transactions the node operator can afford. Nobody is going to run a node for a network they do not use for their own transactions. If transactions have fees that prohibit use for most economic activity, that means node count will drop until nodes are generally run by those who settle large amounts. That is very centralizing. Raystonn On 29 Mar 2017 12:14 p.m., Jared Lee Richardson via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: In order for any blocksize increase to be agreed upon, more consensus is needed. The proportion of users believing no blocksize increases are needed is larger than the hardfork target core wants(95% consensus). The proportion of users believing in microtransactions for all is also larger than 5%, and both of those groups may be larger than 10% respectively. I don't think either the Big-blocks faction nor the low-node-costs faction have even a simple majority of support. Getting consensus is going to be a big mess, but it is critical that it is done. --001a1145b928a2c1d4054bf47bee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Raysto= nn,=C2=A0

Your logic is very hard= to dispute. An important special case is small miners.

Small miners use pools exactly because they want sma= ller, more frequent payments.

Ris= ing fees force them to take payments less frequently, and will only tend to= make more of them give up.

With = fees rising superlinearly, this centralizing effect is much stronger than t= he oft-cited worry of small miners joining large pools to decrease orphan r= ates.


On Mar 29, 2017 15:01, "Raystonn . via bitcoin-dev" &l= t;bitcoin-dev@list= s.linuxfoundation.org> wrote:
Low node costs are a good goal for nodes that handle transactions the = node operator can afford.=C2=A0 Nobody is going to run a node for a network= they do not use for their own transactions.=C2=A0 If transactions have fee= s that prohibit use for most economic activity, that means node count will drop until nodes are generally run by those who= settle large amounts.=C2=A0 That is very centralizing.

Raystonn

On 29 Mar 2017 12:14 = p.m., Jared Lee Richardson via bitcoin-dev <bitcoin-dev@lists.linux= foundation.org> wrote:
In order for any blocksize increase to be agreed upon, mor= e consensus is needed.=C2=A0 The proportion of users believing no blocksize= increases are needed is larger than the hardfork target core wants(95% con= sensus).=C2=A0 The proportion of users believing in microtransactions for all is also larger than 5%, and both of those gro= ups may be larger than 10% respectively.=C2=A0 I don't think either the= Big-blocks faction nor the low-node-costs faction have even a simple major= ity of support.=C2=A0 Getting consensus is going to be a big mess, but it is critical that it is done.

=

=
--001a1145b928a2c1d4054bf47bee--