MIME-Version: 1.0
In-Reply-To: <CAJHLa0Mhnma8_ys2ckEA+dLT-EWnqO4j8YKMSaf3Tvv_K14czQ@mail.gmail.com>
References: <55828737.6000007@riseup.net>
	<CABm2gDoa7KxsgvREo3yiNjfd6AeayqAqkjMe2rvX8yyxR_ddcA@mail.gmail.com>
	<55831CAB.2080303@jrn.me.uk> <1867667.WXWC1C9quc@crushinator>
	<CAOG=w-scXm-46sp2NgR2UUp20R5ujuaAzW-jU_Owh20C4Xc=9A@mail.gmail.com>
	<CAJHLa0Mhnma8_ys2ckEA+dLT-EWnqO4j8YKMSaf3Tvv_K14czQ@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Thu, 18 Jun 2015 15:33:00 -0700
Message-ID: <CAOG=w-tf7qz9XSkDg5POKtFLkHWDA==jf2iVxVL8wz1hqcAVOg@mail.gmail.com>
To: Jeff Garzik <jgarzik@bitpay.com>
Content-Type: multipart/alternative; boundary=001a1140ea0211caa10518d265d1
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>,
	Gavin Andresen <gavin@bitcoinfoundation.org>
Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer
 to Remove Commit Access from Other Developers
Precedence: list

--001a1140ea0211caa10518d265d1
Content-Type: text/plain; charset=UTF-8

On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik <jgarzik@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.

--001a1140ea0211caa10518d265d1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik <span dir=3D"=
ltr">&lt;<a href=3D"mailto:jgarzik@bitpay.com" target=3D"_blank">jgarzik@bi=
tpay.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><br><div dir=3D"ltr">The whole =
point is getting out in front of the need, to prevent significant negative =
impact to users when blocks are consistently full.<div><br></div><div>To do=
 that, you need to (a) plan forward, in order to (b) set a hard fork date i=
n the future.</div></div></blockquote><div><br></div><div>Or alternatively,=
 fix the reasons why users would have negative experiences with full blocks=
, chiefly:<br><br></div><div>=C2=A0 * Get safe forms of replace-by-fee and =
child-pays-for-parent finished and in 0.12.<br></div><div>=C2=A0 * Develop =
cross-platform libraries for managing micropayment channels, and get wallet=
 authors to adopt <br></div><div>=C2=A0 * Use fidelity bonds, solvency proo=
fs, and other tricks to minimize the risk of already deployed off-chain sol=
utions as an interim measure until:<br></div><div>=C2=A0 * Deploy soft-fork=
 changes for truly scalable solutions like Lightning Network.<br><br></div>=
<div>Not raising the block size limit does not mean doing nothing to solve =
the problem.<br></div></div><br></div></div>

--001a1140ea0211caa10518d265d1--