MIME-Version: 1.0
In-Reply-To: <CALgxB7udA85BWetBGc-RN=72ZtVPK9Q5HW8YRDKA08M38XqJqQ@mail.gmail.com>
References: <CALgxB7udA85BWetBGc-RN=72ZtVPK9Q5HW8YRDKA08M38XqJqQ@mail.gmail.com>
Date: Sat, 27 Jun 2015 17:33:11 +0200
Message-ID: <CALqxMTHjszPcf=S20kquF=5y3zfYb+foP6tL1okOT2jhdrW08A@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Michael Naber <mickeybob@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
Precedence: list

Michael Naber wrote:
> Bitcoin Core must remain the lowest-fee, highest-capacity, most secure, d=
istributed, fastest, overall best solution possible to the global consensus=
 problem.

Everyone here is excited about the potential of Bitcoin and would
aspirationally like it to reach its full potential as fast as
possible.  But the block-size is not a free variable, half those
parameters you listed are in conflict with each other.  We're trying
to improve both decentralisation and throughput short-term while
people work on algorithmic improvements mid-term.  If you are
interested you can take a look through the proposals:

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008603.htm=
l

Note that probably 99% of Bitcoin transactions already happen
off-chain in exchanges, tipping services, hosted wallets etc.  Maybe
you're already using them, assuming you are a bitcoin user.
They constitute an early stage layer 2, some of them even have on
chain netting and scale faster than the block-chain.

You can also read about layer 2, the lightning network paper and the
duplex micropayment channel paper:

http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf
http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micr=
opayment-channels.pdf

and read the development list and look at the code:

http://lists.linuxfoundation.org/pipermail/lightning-dev/
https://github.com/ElementsProject/lightning

Adam


On 27 June 2015 at 16:39, Michael Naber <mickeybob@gmail.com> wrote:
> Demand to participate in a low-fee global consensus network will likely
> continue to rise. Technology already exists to meet that rising demand us=
ing
> a blockchain with sufficient block size. Whether that blockchain is Bitco=
in
> Core with an increased block size, or whether it is a fork, market forces
> make it almost certain that demand will be met by a blockchain with adequ=
ate
> capacity. These forces ensure that not only today=E2=80=99s block size wi=
ll be
> increased, but also that future increases will occur should the demand
> arise.
>
> In order to survive, Bitcoin Core must remain the lowest-fee,
> highest-capacity, most secure, distributed, fastest, overall best solutio=
n
> possible to the global consensus problem. Attempting to artificially
> constrain the block size below the limits of technology for any reason is=
 a
> conflict with this objective and a threat to the survival of Bitcoin Core=
.
> At the same time, scheduling large future increases or permitting unlimit=
ed
> dynamic scaling of the block size limit raises concerns over availability=
 of
> future computing resources. Instead, we should manually increase the bloc=
k
> size limit as demand occurs, except in the special case that increasing t=
he
> limit would cause an undue burden upon users wishing to validate the
> integrity of the blockchain.
>
> Compromise: Can we agree that raising the block size to a static 8MB now
> with a plan to increase it further should demand necessitate except in th=
e
> special case above is a reasonable path forward?
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>