<oembed><type>rich</type><version>1.0</version><author_name>npub1ac86vemj7ce5z8jyxt39rna3tvwql6xd30ha3vxcd6esysp23d9qrlswfj</author_name><author_url>https://nostr.ae/npub1ac86vemj7ce5z8jyxt39rna3tvwql6xd30ha3vxcd6esysp23d9qrlswfj</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-06-27&#xA;📝 Original message:Michael Naber wrote:&#xA;&gt; Bitcoin Core must remain the lowest-fee, highest-capacity, most secure, distributed, fastest, overall best solution possible to the global consensus problem.&#xA;&#xA;Everyone here is excited about the potential of Bitcoin and would&#xA;aspirationally like it to reach its full potential as fast as&#xA;possible.  But the block-size is not a free variable, half those&#xA;parameters you listed are in conflict with each other.  We&#39;re trying&#xA;to improve both decentralisation and throughput short-term while&#xA;people work on algorithmic improvements mid-term.  If you are&#xA;interested you can take a look through the proposals:&#xA;&#xA;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008603.html&#xA;&#xA;Note that probably 99% of Bitcoin transactions already happen&#xA;off-chain in exchanges, tipping services, hosted wallets etc.  Maybe&#xA;you&#39;re already using them, assuming you are a bitcoin user.&#xA;They constitute an early stage layer 2, some of them even have on&#xA;chain netting and scale faster than the block-chain.&#xA;&#xA;You can also read about layer 2, the lightning network paper and the&#xA;duplex micropayment channel paper:&#xA;&#xA;http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf&#xA;http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf&#xA;&#xA;and read the development list and look at the code:&#xA;&#xA;http://lists.linuxfoundation.org/pipermail/lightning-dev/&#xA;https://github.com/ElementsProject/lightning&#xA;&#xA;Adam&#xA;&#xA;&#xA;On 27 June 2015 at 16:39, Michael Naber &lt;mickeybob at gmail.com&gt; wrote:&#xA;&gt; Demand to participate in a low-fee global consensus network will likely&#xA;&gt; continue to rise. Technology already exists to meet that rising demand using&#xA;&gt; a blockchain with sufficient block size. Whether that blockchain is Bitcoin&#xA;&gt; Core with an increased block size, or whether it is a fork, market forces&#xA;&gt; make it almost certain that demand will be met by a blockchain with adequate&#xA;&gt; capacity. These forces ensure that not only today’s block size will be&#xA;&gt; increased, but also that future increases will occur should the demand&#xA;&gt; arise.&#xA;&gt;&#xA;&gt; In order to survive, Bitcoin Core must remain the lowest-fee,&#xA;&gt; highest-capacity, most secure, distributed, fastest, overall best solution&#xA;&gt; possible to the global consensus problem. Attempting to artificially&#xA;&gt; constrain the block size below the limits of technology for any reason is a&#xA;&gt; conflict with this objective and a threat to the survival of Bitcoin Core.&#xA;&gt; At the same time, scheduling large future increases or permitting unlimited&#xA;&gt; dynamic scaling of the block size limit raises concerns over availability of&#xA;&gt; future computing resources. Instead, we should manually increase the block&#xA;&gt; size limit as demand occurs, except in the special case that increasing the&#xA;&gt; limit would cause an undue burden upon users wishing to validate the&#xA;&gt; integrity of the blockchain.&#xA;&gt;&#xA;&gt; Compromise: Can we agree that raising the block size to a static 8MB now&#xA;&gt; with a plan to increase it further should demand necessitate except in the&#xA;&gt; special case above is a reasonable path forward?&#xA;&gt;&#xA;&gt; _______________________________________________&#xA;&gt; bitcoin-dev mailing list&#xA;&gt; bitcoin-dev at lists.linuxfoundation.org&#xA;&gt; https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev&#xA;&gt;</html></oembed>