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


             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 ` 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$(echo .)cc \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=thomas@thomaszander$(echo .)se \
    /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