From: Adam Back <adam@cypherspace.org>
To: Michael Naber <mickeybob@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
Date: Sat, 27 Jun 2015 17:33:11 +0200 [thread overview]
Message-ID: <CALqxMTHjszPcf=S20kquF=5y3zfYb+foP6tL1okOT2jhdrW08A@mail.gmail.com> (raw)
In-Reply-To: <CALgxB7udA85BWetBGc-RN=72ZtVPK9Q5HW8YRDKA08M38XqJqQ@mail.gmail.com>
Michael Naber wrote:
> Bitcoin Core must remain the lowest-fee, highest-capacity, most secure, distributed, 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.html
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-micropayment-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 using
> a blockchain with sufficient block size. Whether that blockchain is Bitcoin
> 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 adequate
> capacity. These forces ensure that not only today’s block size will 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 solution
> 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 unlimited
> dynamic scaling of the block size limit raises concerns over availability of
> future computing resources. Instead, we should manually increase the block
> size limit as demand occurs, except in the special case that increasing the
> 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 the
> 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
>
next prev parent reply other threads:[~2015-06-27 15:33 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-27 14:39 [bitcoin-dev] A Proposed Compromise to the Block Size Limit Michael Naber
2015-06-27 15:21 ` Peter Todd
2015-06-27 15:29 ` Randi Joseph
2015-06-27 15:32 ` Peter Todd
2015-06-27 16:19 ` Michael Naber
2015-06-27 17:20 ` Peter Todd
2015-06-27 17:26 ` Benjamin
2015-06-27 17:37 ` Peter Todd
2015-06-27 17:46 ` Benjamin
2015-06-27 17:54 ` Peter Todd
2015-06-27 17:58 ` Venzen Khaosan
2015-06-27 19:34 ` Benjamin
2015-06-27 15:33 ` Adam Back [this message]
2015-06-27 16:09 ` Michael Naber
2015-06-27 16:28 ` Mark Friedenbach
2015-06-27 16:37 ` Peter Todd
2015-06-27 17:25 ` Michael Naber
2015-06-27 17:34 ` Peter Todd
2015-06-27 18:02 ` Jameson Lopp
2015-06-27 18:47 ` Peter Todd
2015-06-28 5:34 Raystonn
2015-06-28 10:07 ` Adam Back
2015-06-28 10:29 ` Benjamin
2015-06-28 12:37 ` Adam Back
2015-06-28 16:32 ` Raystonn .
2015-06-28 17:12 ` Mark Friedenbach
2015-06-28 17:18 ` Benjamin
2015-06-28 17:29 ` Gavin Andresen
2015-06-28 17:45 ` Mark Friedenbach
2015-06-28 17:51 ` Adam Back
2015-06-28 18:58 ` Adam Back
2015-06-28 21:05 ` Gavin Andresen
2015-06-28 21:23 ` Michael Naber
2015-06-28 22:07 ` Adam Back
2015-06-29 0:59 ` Eric Lombrozo
2015-06-29 1:13 ` Eric Lombrozo
2015-06-29 1:45 ` Andy Schroder
2015-06-30 0:42 ` Tom Harding
2015-07-10 2:55 ` Tom Harding
2015-06-28 17:53 ` Jorge Timón
2015-06-28 19:22 ` Andrew Lapp
2015-06-28 19:40 ` Benjamin
2015-06-28 12:32 ` Milly Bitcoin
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='CALqxMTHjszPcf=S20kquF=5y3zfYb+foP6tL1okOT2jhdrW08A@mail.gmail.com' \
--to=adam@cypherspace.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=mickeybob@gmail.com \
/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