From: Tom Harding <tomh@thinlink•com>
To: "Raystonn ." <raystonn@hotmail•com>,
Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] High fees / centralization
Date: Thu, 30 Mar 2017 08:38:20 -0700 [thread overview]
Message-ID: <CALJP9GDH1xQ-cYc1SN6jejXDA49eiy_OR49XLLWd+=VdNo7ekA@mail.gmail.com> (raw)
In-Reply-To: <CALJP9GBk4gG0H+tEJmEiz=0+LAQoe6_sL1Fv-BCJSfmvfY8PRA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 3078 bytes --]
next parent reply other threads:[~2017-03-30 15:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CALJP9GB2Fds8m9JpaVv0NxGDr579BtR9RMs7-KNSLkK8Mz7LoA@mail.gmail.com>
[not found] ` <CALJP9GAOgpSAhrrYFPRbGKZXwqZn_oDUmv6B7wcvwxcZufDd0g@mail.gmail.com>
[not found] ` <CALJP9GDkdxsvOZHJxzx+0pvjWBAkAswZCWXcp=zL7LNMRNfCOg@mail.gmail.com>
[not found] ` <CALJP9GBk4gG0H+tEJmEiz=0+LAQoe6_sL1Fv-BCJSfmvfY8PRA@mail.gmail.com>
2017-03-30 15:38 ` Tom Harding [this message]
2017-03-30 16:14 ` David Vorick
2017-03-30 21:52 ` Jared Lee Richardson
2017-03-31 1:39 ` Vladimir Zaytsev
2017-03-31 2:01 ` Jared Lee Richardson
2017-03-31 2:26 ` Vladimir Zaytsev
2017-04-02 19:45 ` Staf Verhaegen
2017-03-31 1:13 ` Tom Harding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALJP9GDH1xQ-cYc1SN6jejXDA49eiy_OR49XLLWd+=VdNo7ekA@mail.gmail.com' \
--to=tomh@thinlink$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=raystonn@hotmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox