Jeff Garzik [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 3:33 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:
> 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.
>
This is a long, unreasonable list of work. None of this exists and it
equates to "upgrade all wallets and websites everywhere" It requires all
exchanges, payment processors, merchants, etc. to - basically everybody
but miners - to update.
It is a far, far larger amount of work to write, test and deploy than
simply increasing the block size limit.
Think through roll-out of these ambitious suggestions, before suggesting as
an alternative!
Not a realistic alternative except in an alternate universe where (a)
developer work at all companies is cost free, plus (b) we can pause the
business universe while we wait for The Perfect Solution.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/6a902283/attachment.html>;
š Original message:On Thu, Jun 18, 2015 at 3:33 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:
> 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.
>
This is a long, unreasonable list of work. None of this exists and it
equates to "upgrade all wallets and websites everywhere" It requires all
exchanges, payment processors, merchants, etc. to - basically everybody
but miners - to update.
It is a far, far larger amount of work to write, test and deploy than
simply increasing the block size limit.
Think through roll-out of these ambitious suggestions, before suggesting as
an alternative!
Not a realistic alternative except in an alternate universe where (a)
developer work at all companies is cost free, plus (b) we can pause the
business universe while we wait for The Perfect Solution.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/6a902283/attachment.html>;