From: "Jorge Timón" <jtimon@jtimon.cc>
To: Thomas Zander <thomas@thomaszander.se>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] A summary list of all concerns related to rising the block size
Date: Wed, 12 Aug 2015 12:28:39 +0200 [thread overview]
Message-ID: <CABm2gDqn4bDTqmp=9h_qBjgjV0=LhY97bTHdRevAREYVyR07EQ@mail.gmail.com> (raw)
We've identified a fundamental disagreement in:
- The block size maximum consensus rule serves to limit mining centralization
But as said I believe at least 2 different formal proofs can be
produced that in fact this is the case. One of them (the one I'm
working on) remains true even after superluminal communication, free
unlimited global bandwidth and science fiction snarks.
But let's just list the concerns first.
I believe there's 2 categories:
1) Increasing the block size may increase centralization.
- Mining centralization will get worse (for example, China's aggregate
hashrate becomes even larger)
- Government control in a single jurisdiction could enforce
transaction censorship and destroy irreversibility of transactions
- Some use cases that rely on a decentralized chain (like
trustless options) cannot rely on Bitcoin anymore.
- Reversible transactions will have proportional fees rather
than flat ones.
- Some use cases that rely on flat fees (like remittance) may
not be practical in Bitcoin anymore
- The full node count will decrease, leaving less resources to serve SPV nodes.
2) Trying to avoid "hitting the limit" permanently minimizes minimum
fees (currently zero) and fees in general
- If fees' block reward doesn't increase enough, the subsidy block
reward may become insufficient to protect the irreversibility of the
system at some point in time, and the system is attacked and destroyed
at that point in time
- Miners will continue to run noncompetitive block creation policies
(ie accepting free transactions)
- More new Bitcoin businesses may be created based on unsustainable
assumptions and consequently fail.
- "Free transactions bitcoin marketing" may continue and users may get
angry when they discover they have been lied about the sustainability
of that property and the reliability of free transactions.
Please suggest more concerns or new categories if you think they're needed.
next reply other threads:[~2015-08-12 10:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-12 10:28 Jorge Timón [this message]
2015-08-12 16:41 ` [bitcoin-dev] A summary list of all concerns related to rising the block size Thomas Zander
2015-08-12 17:08 ` Milly Bitcoin
2015-08-14 22:01 ` 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='CABm2gDqn4bDTqmp=9h_qBjgjV0=LhY97bTHdRevAREYVyR07EQ@mail.gmail.com' \
--to=jtimon@jtimon.cc \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=thomas@thomaszander.se \
/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