{"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-18\n📝 Original message:On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik \u003cjgarzik at bitpay.com\u003e wrote:\n\n\u003e\n\u003e The whole point is getting out in front of the need, to prevent\n\u003e significant negative impact to users when blocks are consistently full.\n\u003e\n\u003e To do that, you need to (a) plan forward, in order to (b) set a hard fork\n\u003e date in the future.\n\u003e\n\nOr alternatively, fix the reasons why users would have negative experiences\nwith full blocks, chiefly:\n\n  * Get safe forms of replace-by-fee and child-pays-for-parent finished and\nin 0.12.\n  * Develop cross-platform libraries for managing micropayment channels,\nand get wallet authors to adopt\n  * Use fidelity bonds, solvency proofs, and other tricks to minimize the\nrisk of already deployed off-chain solutions as an interim measure until:\n  * Deploy soft-fork changes for truly scalable solutions like Lightning\nNetwork.\n\nNot raising the block size limit does not mean doing nothing to solve the\nproblem.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/b7699ac6/attachment.html\u003e"}