On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik <jgar...@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.
------------------------------------------------------------------------------
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
