rich1.0npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uhttps://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0unjumphttps://nostr.ae📅 Original date posted:2015-06-18 📝 Original message:On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik <jgarzik at bitpay.com> wrote: > > The whole point is getting out in front of the need, to prevent > significant negative impact to users when blocks are consistently full. > > To do that, you need to (a) plan forward, in order to (b) set a hard fork > date in the future. > Or alternatively, fix the reasons why users would have negative experiences with full blocks, chiefly: * Get safe forms of replace-by-fee and child-pays-for-parent finished and in 0.12. * Develop cross-platform libraries for managing micropayment channels, and get wallet authors to adopt * Use fidelity bonds, solvency proofs, and other tricks to minimize the risk of already deployed off-chain solutions as an interim measure until: * Deploy soft-fork changes for truly scalable solutions like Lightning Network. Not raising the block size limit does not mean doing nothing to solve the problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/b7699ac6/attachment.html>