From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C1DF1273 for ; Sat, 27 Jun 2015 15:33:13 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E38807C for ; Sat, 27 Jun 2015 15:33:12 +0000 (UTC) Received: from mail-qk0-f176.google.com ([209.85.220.176]) by mrelay.perfora.net (mreueus001) with ESMTPSA (Nemesis) id 0LdnYT-1Yi5vI452p-00izJ6 for ; Sat, 27 Jun 2015 17:33:12 +0200 Received: by qkbp125 with SMTP id p125so71026535qkb.2 for ; Sat, 27 Jun 2015 08:33:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.101.8 with SMTP id t8mr9385432qge.9.1435419191347; Sat, 27 Jun 2015 08:33:11 -0700 (PDT) Received: by 10.96.28.39 with HTTP; Sat, 27 Jun 2015 08:33:11 -0700 (PDT) In-Reply-To: References: Date: Sat, 27 Jun 2015 17:33:11 +0200 Message-ID: From: Adam Back To: Michael Naber Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:7izOrFj0UvFuFggYuf3WOZy0V/cPapy57sKsz0nIxGg8U0nV6q8 +ci6uy6NZOjP8IQRonMMJi3xDIDRQsXrlkkdPLsEnRPr77XkUkVxSNvd/FXlrSabxQr7lUg WG98TL0U3yuNxavybDvsiaFpu8XxeYzoLLoEIpiMD2tUXSaQs8BEy8aFYJoDJK0MypnAk8N 5+hknfGwSC+O8Dz5x+JfA== X-UI-Out-Filterresults: notjunk:1;V01:K0:HVNwmggl/Ao=:BYeXE84M/hSymdI4LLDlgd 6kNvnfyLc7wGjpFPcq1ntZsm7woyIyxB+6LNzKCi8k+RlUGJqSTxXvXzPn/ZY1PAclNEsUsb2 f6M7CHVN/OdOqH4jLN4TViDK6vsTMfUtCbFduIi90LPgeiUNPalv0C4QZOzbE6UW4hFHVdv3o PMuSMKF5/0W8g89Vgn92z/WhN3PKNLNvdmNyfnBxXZupEjVHa2WvS+q8BPpL0lwFI66t90xJf 59PEK0K6AL8VHQOu7kLPQ93iZHkX+iMWko4CGJ1S4nTaxyUb5+FU40pg1Ym9PA0Nl4rSNGmHx sMJ+Uy7Yo/R9F7J4iAG2YztT/AqQqYrLyMTXOV/rmULU8lVQdAZPeRWEjQFIOKWD6Gh0H7xQJ uEypM3x7LUQWIB8R7lBbCMAwicAtNIQmReT8tnX+r5FCwouTGaXFmHEjCnZq7WoxHdgqx+var kHhMMxpqIv+oZYuhcsUdy+V7LSrS6P92GpTJ5oserlxu8+IY59dZhgFNp+DLOTNaelU/PH0dk bvskYzzJAKWHHnlGRlb2BV2GPP9yd0ydRwY8GfrSXhlZ1dX0XsWFLeQApTWGw9BgPutNpW1Qt lUFNJmYgrhgC/eu2PpiC4xymVnncCmvyucZT6WFAgN01AtMETpcJvZQ/lMVX33HxHQ2XLL/cC E5zo143+Ekwi3iSjLdKKtMQ6M4N/PqED9wMMSDs1uayKNwg== X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 15:33:13 -0000 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 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 >