From: Elliot Olds <elliot.olds@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size
Date: Sat, 15 Aug 2015 13:36:06 -0700 [thread overview]
Message-ID: <CA+BnGuEb+AosiCkhuYMhSrhwj0wJLFf8M3OKWa7Xyig+=ge+Aw@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDqzSOQ38Rt4xQgCrNpNsoZLd+nKC8X5z_hQnt9qWOEg=A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5526 bytes --]
On Fri, Aug 14, 2015 at 3:55 PM, Jorge Timón <jtimon@jtimon.cc> wrote:
> On Wed, Aug 12, 2015 at 9:52 PM, Elliot Olds <elliot.olds@gmail.com>
> wrote:
>
> -Reduce the utility of people using the network, even if the higher fees
> > don't reduce their amount of transactions.
>
> "Utility" like "value" is always subjective and very vague. I prefer
> to identify more concrete ways in which "utility is reduced".
Change 'utility' to 'money.' I'm just saying that paying more money for the
same thing is worse for users. If I'm a user who is used to making txns for
1 cent each and suddenly all my txns cost 1 dollar each. then the benefit I
get for each of my transactions that I still make is reduced by 99 cents
per tx. This is as concrete a negative effect as I can imagine. It might
seem obvious that this is a cost, but it seems to be ignored by a lot of
participants.
> > -Make some use cases nonviable, depriving people of Bitcoin's
> decentralized
> > benefits.
>
> It is clear that not all use cases fit the blockchain, but it's still
> unclear which ones don't fit yet.
> But the amount of use cases supported is not a valid metric for
> decentralization.
>
Not sure what you mean by "valid metric for decentralization." I thought
the goal here was to list all negative consequences of high fees. Not just
consequences to decentralization. We're trying to figure out how to trade
off risks to decentralization against these other things we're listing
which aren't necessarily about decentralization (such as reduced use cases).
> In any case, it would be interesting if we could list some concrete
> cases that would be lost.
>
If tx fees rise to $1, then I'll stop making on-blockchain purchases of
less than about $100, meaning pretty much all retail purchases are
eliminated. It's hard to list a lot of use cases that will be lost because
Bitcoin usage is very low right now. I assume most of us believe that there
are lots of interesting use cases that have not developed yet. Just because
they don't exist now doesn't mean we should ignore the fact that high fees
might make them nonviable.
Some examples of stuff that doesn't exist now but might be prevented or
significantly harmed by high fees: small international remittances, machine
to machine payments, decentralized prediction markets (maybe people like
making lots of small bets). Just take any potential use case you can think
of: if the per-tx benefit to the person is less than $1, then $1 tx fees
will prevent it. See below for another example.
> > -Discourage experimentation with new Bitcoin use cases, making it more
> > unlikely that such cases are discovered/improved/popular before Bitcoin's
> > security relies on having many users.
>
> Experimentation can be done with worthless testchains. I'm not sure
> I'm following on this one.
>
I think this is one of the most important costs to worry about. So much of
experimentation can't be done on a testchain, because most experiments that
are being done by early stage companies are about product market fit, and
which services are valuable to users.
Let's say that you and I start a company that allows people to charge money
to people who want to email/message them. There are so many things that we
need to figure out that can't be figured out without participating in the
actual market, with real people, who are really trying to use our service.
It might take us years of making little tweaks to the product before we hit
on some solution that people finally like enough to use in large numbers.
Let's say that right now tx fees are $1, and imagine that the highest
amount that most people are willing to pay to email people is 25 cents. If
we are experimenting in a market with $1 tx fees, perhaps our company will
just die and we'll never figure out how to bring people this service that
they want. Perhaps there are a lot of other innovations relating to 'pay to
message' that would have otherwise been developed (maybe celebrities like
doing AMAs via pay-to-message and devote the funds to charities. Maybe this
becomes a huge source of charitable giving in the future), but because
Bitcoin's high fee environment didn't allow us to explore these ideas, this
whole service category goes undeveloped for many years.
> -Reduce the amount of time we have between now and when tx fees need to
> pay
> > for a significant portion of Bitcoin's security, by keeping the exchange
> > rate and thus the value of block rewards low
> > (https://en.wikipedia.org/wiki/Equation_of_exchange)
>
> Related to exchange rate.
>
Elsewhere you write "I believe 'fear of exchange rate declining' can
probably be added to any concern/risk 'leaf', so we should probably leave
that for the end or just omit it."
It's true that you could tell some indirect story about how pretty much
anything could affect the exchange rate, but separate from all the
hypothetical stories there is a strong theoretical reason to believe that
the exchange rate will be higher the more value is transacted in the
Bitcoin ecosystem. See the wiki link on the equation of exchange. More
people using Bitcoin for transactions will drive up the price, all else
being equal. Perhaps many people care about the price for irrelevant
reasons (they just want to be rich), but as long as Bitcoin's security is
tied to the exchange rate via block rewards, it's also an important
consideration for security.
[-- Attachment #2: Type: text/html, Size: 7189 bytes --]
next prev parent reply other threads:[~2015-08-15 20:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-12 9:59 [bitcoin-dev] A summary list of all concerns related to not rising the block size Jorge Timón
2015-08-12 11:21 ` Venzen Khaosan
2015-08-14 22:35 ` Jorge Timón
2015-08-14 23:12 ` Jorge Timón
2015-08-14 23:57 ` Jorge Timón
2015-08-20 21:11 ` Elliot Olds
2015-08-20 21:29 ` Ahmed Zsales
2015-08-12 19:52 ` Elliot Olds
2015-08-14 22:55 ` Jorge Timón
2015-08-15 20:36 ` Elliot Olds [this message]
2015-08-13 9:52 ` Ashley Holman
2015-08-13 16:36 ` Jean-Paul Kogelman
2015-08-14 22:57 ` Jorge Timón
2015-08-13 22:01 ` Geir Harald Hansen
2015-08-14 2:26 ` Venzen Khaosan
2015-08-14 11:35 ` Marcel Jamin
2015-08-14 13:48 ` Thomas Zander
2015-08-14 22:59 ` Jorge Timón
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='CA+BnGuEb+AosiCkhuYMhSrhwj0wJLFf8M3OKWa7Xyig+=ge+Aw@mail.gmail.com' \
--to=elliot.olds@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/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