<div dir="ltr"><div>The goal of Bitcoin Core is to meet the demand for global consensus as effectively as possible. Please let's keep the conversation on how to best meet that goal.<br></div><div><br></div><div>The off-chain solutions you enumerate are are useful solutions in their respective domains, but none of them solves the global consensus problem with any greater efficiency than Bitcoin does.<br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 27, 2015 at 11:33 AM, Adam Back <span dir="ltr"><<a href="mailto:adam@cypherspace.org" target="_blank">adam@cypherspace.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Michael Naber wrote:<br>
> Bitcoin Core must remain the lowest-fee, highest-capacity, most secure, distributed, fastest, overall best solution possible to the global consensus problem.<br>
<br>
</span>Everyone here is excited about the potential of Bitcoin and would<br>
aspirationally like it to reach its full potential as fast as<br>
possible. But the block-size is not a free variable, half those<br>
parameters you listed are in conflict with each other. We're trying<br>
to improve both decentralisation and throughput short-term while<br>
people work on algorithmic improvements mid-term. If you are<br>
interested you can take a look through the proposals:<br>
<br>
<a href="http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008603.html" rel="noreferrer" target="_blank">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008603.html</a><br>
<br>
Note that probably 99% of Bitcoin transactions already happen<br>
off-chain in exchanges, tipping services, hosted wallets etc. Maybe<br>
you're already using them, assuming you are a bitcoin user.<br>
They constitute an early stage layer 2, some of them even have on<br>
chain netting and scale faster than the block-chain.<br>
<br>
You can also read about layer 2, the lightning network paper and the<br>
duplex micropayment channel paper:<br>
<br>
<a href="http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf" rel="noreferrer" target="_blank">http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf</a><br>
<a href="http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf" rel="noreferrer" target="_blank">http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf</a><br>
<br>
and read the development list and look at the code:<br>
<br>
<a href="http://lists.linuxfoundation.org/pipermail/lightning-dev/" rel="noreferrer" target="_blank">http://lists.linuxfoundation.org/pipermail/lightning-dev/</a><br>
<a href="https://github.com/ElementsProject/lightning" rel="noreferrer" target="_blank">https://github.com/ElementsProject/lightning</a><br>
<br>
Adam<br>
<div><div class="h5"><br>
<br>
On 27 June 2015 at 16:39, Michael Naber <<a href="mailto:mickeybob@gmail.com">mickeybob@gmail.com</a>> wrote:<br>
> Demand to participate in a low-fee global consensus network will likely<br>
> continue to rise. Technology already exists to meet that rising demand using<br>
> a blockchain with sufficient block size. Whether that blockchain is Bitcoin<br>
> Core with an increased block size, or whether it is a fork, market forces<br>
> make it almost certain that demand will be met by a blockchain with adequate<br>
> capacity. These forces ensure that not only today’s block size will be<br>
> increased, but also that future increases will occur should the demand<br>
> arise.<br>
><br>
> In order to survive, Bitcoin Core must remain the lowest-fee,<br>
> highest-capacity, most secure, distributed, fastest, overall best solution<br>
> possible to the global consensus problem. Attempting to artificially<br>
> constrain the block size below the limits of technology for any reason is a<br>
> conflict with this objective and a threat to the survival of Bitcoin Core.<br>
> At the same time, scheduling large future increases or permitting unlimited<br>
> dynamic scaling of the block size limit raises concerns over availability of<br>
> future computing resources. Instead, we should manually increase the block<br>
> size limit as demand occurs, except in the special case that increasing the<br>
> limit would cause an undue burden upon users wishing to validate the<br>
> integrity of the blockchain.<br>
><br>
> Compromise: Can we agree that raising the block size to a static 8MB now<br>
> with a plan to increase it further should demand necessitate except in the<br>
> special case above is a reasonable path forward?<br>
><br>
</div></div>> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
> <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
><br>
</blockquote></div><br></div>