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