{"type":"rich","version":"1.0","author_name":"npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","author_url":"https://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-27\n📝 Original message:I really suggest you look into the layer2 systems Adam pointed to, as you\nappear to be misinformed about their properties. There are many proposals\nwhich really do achieve global consensus using the block chain, just in a\ndelayed (and cached) fashion that is still 100% safe.\n\nIt is possible to go off-chain without losing the trustlessness and\nsecurity of the block chain.\n\nOn Sat, Jun 27, 2015 at 9:09 AM, Michael Naber \u003cmickeybob at gmail.com\u003e wrote:\n\n\u003e The goal of Bitcoin Core is to meet the demand for global consensus as\n\u003e effectively as possible. Please let's keep the conversation on how to best\n\u003e meet that goal.\n\u003e\n\u003e The off-chain solutions you enumerate are are useful solutions in their\n\u003e respective domains, but none of them solves the global consensus problem\n\u003e with any greater efficiency than Bitcoin does.\n\u003e\n\u003e\n\u003e On Sat, Jun 27, 2015 at 11:33 AM, Adam Back \u003cadam at cypherspace.org\u003e wrote:\n\u003e\n\u003e\u003e Michael Naber wrote:\n\u003e\u003e \u003e Bitcoin Core must remain the lowest-fee, highest-capacity, most secure,\n\u003e\u003e distributed, fastest, overall best solution possible to the global\n\u003e\u003e consensus problem.\n\u003e\u003e\n\u003e\u003e Everyone here is excited about the potential of Bitcoin and would\n\u003e\u003e aspirationally like it to reach its full potential as fast as\n\u003e\u003e possible.  But the block-size is not a free variable, half those\n\u003e\u003e parameters you listed are in conflict with each other.  We're trying\n\u003e\u003e to improve both decentralisation and throughput short-term while\n\u003e\u003e people work on algorithmic improvements mid-term.  If you are\n\u003e\u003e interested you can take a look through the proposals:\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008603.html\n\u003e\u003e\n\u003e\u003e Note that probably 99% of Bitcoin transactions already happen\n\u003e\u003e off-chain in exchanges, tipping services, hosted wallets etc.  Maybe\n\u003e\u003e you're already using them, assuming you are a bitcoin user.\n\u003e\u003e They constitute an early stage layer 2, some of them even have on\n\u003e\u003e chain netting and scale faster than the block-chain.\n\u003e\u003e\n\u003e\u003e You can also read about layer 2, the lightning network paper and the\n\u003e\u003e duplex micropayment channel paper:\n\u003e\u003e\n\u003e\u003e http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf\n\u003e\u003e\n\u003e\u003e http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf\n\u003e\u003e\n\u003e\u003e and read the development list and look at the code:\n\u003e\u003e\n\u003e\u003e http://lists.linuxfoundation.org/pipermail/lightning-dev/\n\u003e\u003e https://github.com/ElementsProject/lightning\n\u003e\u003e\n\u003e\u003e Adam\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On 27 June 2015 at 16:39, Michael Naber \u003cmickeybob at gmail.com\u003e wrote:\n\u003e\u003e \u003e Demand to participate in a low-fee global consensus network will likely\n\u003e\u003e \u003e continue to rise. Technology already exists to meet that rising demand\n\u003e\u003e using\n\u003e\u003e \u003e a blockchain with sufficient block size. Whether that blockchain is\n\u003e\u003e Bitcoin\n\u003e\u003e \u003e Core with an increased block size, or whether it is a fork, market\n\u003e\u003e forces\n\u003e\u003e \u003e make it almost certain that demand will be met by a blockchain with\n\u003e\u003e adequate\n\u003e\u003e \u003e capacity. These forces ensure that not only today’s block size will be\n\u003e\u003e \u003e increased, but also that future increases will occur should the demand\n\u003e\u003e \u003e arise.\n\u003e\u003e \u003e\n\u003e\u003e \u003e In order to survive, Bitcoin Core must remain the lowest-fee,\n\u003e\u003e \u003e highest-capacity, most secure, distributed, fastest, overall best\n\u003e\u003e solution\n\u003e\u003e \u003e possible to the global consensus problem. Attempting to artificially\n\u003e\u003e \u003e constrain the block size below the limits of technology for any reason\n\u003e\u003e is a\n\u003e\u003e \u003e conflict with this objective and a threat to the survival of Bitcoin\n\u003e\u003e Core.\n\u003e\u003e \u003e At the same time, scheduling large future increases or permitting\n\u003e\u003e unlimited\n\u003e\u003e \u003e dynamic scaling of the block size limit raises concerns over\n\u003e\u003e availability of\n\u003e\u003e \u003e future computing resources. Instead, we should manually increase the\n\u003e\u003e block\n\u003e\u003e \u003e size limit as demand occurs, except in the special case that increasing\n\u003e\u003e the\n\u003e\u003e \u003e limit would cause an undue burden upon users wishing to validate the\n\u003e\u003e \u003e integrity of the blockchain.\n\u003e\u003e \u003e\n\u003e\u003e \u003e Compromise: Can we agree that raising the block size to a static 8MB now\n\u003e\u003e \u003e with a plan to increase it further should demand necessitate except in\n\u003e\u003e the\n\u003e\u003e \u003e special case above is a reasonable path forward?\n\u003e\u003e \u003e\n\u003e\u003e \u003e _______________________________________________\n\u003e\u003e \u003e bitcoin-dev mailing list\n\u003e\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e \u003e\n\u003e\u003e\n\u003e\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\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/d47f275d/attachment.html\u003e"}