From: Vladimir Zaytsev <vladimir.zaytsev@gmail.com>
To: Jared Lee Richardson <jaredr26@gmail.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] High fees / centralization
Date: Thu, 30 Mar 2017 21:39:23 -0400 [thread overview]
Message-ID: <61B9AE0D-5A58-4A72-8834-8ED164ED627F@gmail.com> (raw)
In-Reply-To: <CAD1TkXsfb7VC7stXV33me1PDem750adpyETg-finKyjnV=Syxg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]
There must be a way to organize “branches” of smaller activity to join main tree after they grow. Outsider a bit, I see going circles here, but not everything must be accepted in the chain. Good idea as it is, it’s just too early to record every sight….
> On Mar 30, 2017, at 5:52 PM, Jared Lee Richardson via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > Further, we are very far from the point (in my appraisal) where fees are high enough to block home users from using the network.
>
> This depends entirely on the usecase entirely. Most likely even without a blocksize increase, home purchases will be large enough to fit on the blocksize in the forseeable future. Microtransactions(<$0.25) on the other hand aren't viable no matter what we try to do - There's just too much data.
>
> Most likely, transaction fees above $1 per tx will become unappealing for many consumers, and above $10 is likely to be niche-level. It is hard to say with any certainty, but average credit card fees give us some indications to work with - $1.2 on a $30 transaction, though paid by the business and not the consumer.
>
> Without blocksize increases, fees higher than $1/tx are basically inevitable, most likely before 2020. Running a node only costs $10/month if that. If we were going to favor node operational costs that highly in the weighting, we'd better have a pretty solid justification with mathematical models or examples.
>
> > We should not throw away the core innovation of monetary sovereignty in pursuit of supporting 0.1% of the world's daily transactions.
>
> If we can easily have both, why not have both?
>
> An altcoin with both will take Bitcoin's monetary sovereignty crown by default. No crown, no usecases, no Bitcoin.
>
>
[-- Attachment #2: Type: text/html, Size: 2747 bytes --]
next prev parent reply other threads:[~2017-03-31 1:39 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 ` [bitcoin-dev] High fees / centralization Tom Harding
2017-03-30 16:14 ` David Vorick
2017-03-30 21:52 ` Jared Lee Richardson
2017-03-31 1:39 ` Vladimir Zaytsev [this message]
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=61B9AE0D-5A58-4A72-8834-8ED164ED627F@gmail.com \
--to=vladimir.zaytsev@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=jaredr26@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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