Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.49 as permitted sender)
	client-ip=209.85.192.49; envelope-from=voisine@gmail.com;
	helo=mail-qg0-f49.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAOG=w-tBokq6FQkEbH-w0oF0Mg7EG=Qmo7G_WAxvK2K06trQZw@mail.gmail.com>
References: <16096345.A1MpJQQkRW@crushinator>
	<CAOG=w-szbLgc1jLpkE_uMa3bkFTi-RiBEaQ6Y-u5aKLBC2HvUg@mail.gmail.com>
	<CACq0ZD6hkyU0ABmM6FDKxTszjYk=5zrhkWn2-9RAtzcbyydokg@mail.gmail.com>
	<CAOG=w-tBokq6FQkEbH-w0oF0Mg7EG=Qmo7G_WAxvK2K06trQZw@mail.gmail.com>
Date: Fri, 8 May 2015 16:15:41 -0700
Message-ID: <CACq0ZD7hm5_moqkBOPDRUTnQf16rPggRiLf5ZwBNLbrrgajttA@mail.gmail.com>
From: Aaron Voisine <voisine@gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary=001a1147bae2f7af9f05159a34b2
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
	function
Precedence: list

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

That's fair, and we've implemented child-pays-for-parent for spending
unconfirmed inputs in breadwallet. But what should the behavior be when
those options aren't understood/implemented/used?

My argument is that the less risky, more conservative default fallback
behavior should be either non-propagation or delayed confirmation, which is
generally what we have now, until we hit the block size limit. We still
have lots of safe, non-controversial, easy to experiment with options to
add fee pressure, causing users to economize on block space without
resorting to dropping transactions after a prolonged delay.

Aaron Voisine
co-founder and CEO
breadwallet.com

On Fri, May 8, 2015 at 3:45 PM, Mark Friedenbach <mark@friedenbach.org>
wrote:

> On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine <voisine@gmail.com> wrote:
>
>> This is a clever way to tie block size to fees.
>>
>> I would just like to point out though that it still fundamentally is
>> using hard block size limits to enforce scarcity. Transactions with below
>> market fees will hang in limbo for days and fail, instead of failing
>> immediately by not propagating, or seeing degraded, long confirmation times
>> followed by eventual success.
>>
>
> There are already solutions to this which are waiting to be deployed as
> default policy to bitcoind, and need to be implemented in other clients:
> replace-by-fee and child-pays-for-parent.
>

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

<div dir=3D"ltr">That&#39;s fair, and we&#39;ve implemented child-pays-for-=
parent for spending unconfirmed inputs in breadwallet. But what should the =
behavior be when those options aren&#39;t understood/implemented/used?<div>=
<br></div><div>My argument is that the less risky, more conservative defaul=
t fallback behavior should be either non-propagation or delayed confirmatio=
n, which is generally what we have now, until we hit the block size limit. =
We still have lots of safe, non-controversial, easy to experiment with opti=
ons to add fee pressure, causing users to economize on block space without =
resorting to dropping transactions after a prolonged delay.</div><div class=
=3D"gmail_extra"><br><div><div class=3D"gmail_signature"><div dir=3D"ltr"><=
div><div dir=3D"ltr"><div>Aaron Voisine</div><div>co-founder and CEO<br><a =
href=3D"http://breadwallet.com" target=3D"_blank">breadwallet.com</a></div>=
</div></div></div></div></div>
<br><div class=3D"gmail_quote">On Fri, May 8, 2015 at 3:45 PM, Mark Frieden=
bach <span dir=3D"ltr">&lt;<a href=3D"mailto:mark@friedenbach.org" target=
=3D"_blank">mark@friedenbach.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><span class=3D"">On Fri, May 8, 2015 at 3:43=
 PM, Aaron Voisine <span dir=3D"ltr">&lt;<a href=3D"mailto:voisine@gmail.co=
m" target=3D"_blank">voisine@gmail.com</a>&gt;</span> wrote:<br></span><div=
 class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">This is a clever way to tie block s=
ize to fees.<div><br></div><div>I would just like to point out though that =
it still fundamentally is using hard block size limits to enforce scarcity.=
 Transactions with below market fees will hang in limbo for days and fail, =
instead of failing immediately by not propagating, or seeing degraded, long=
 confirmation times followed by eventual success.</div></div></blockquote><=
div><br></div></span><div>There are already solutions to this which are wai=
ting to be deployed as default policy to bitcoind, and need to be implement=
ed in other clients: replace-by-fee and child-pays-for-parent. <br></div></=
div></div></div>
</blockquote></div><br></div></div>

--001a1147bae2f7af9f05159a34b2--