Mark Friedenbach [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-18 📝 Original message:On Thu, Jun 18, 2015 at ...

📅 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>;