public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  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       ` 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$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=jaredr26@gmail$(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