path: root/2b/97f53028edca176bd317e0a95d1382cb2f547e

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mark@friedenbach.org>) id 1YqsAL-00061s-07
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 May 2015 23:58:49 +0000
X-ACL-Warn: 
Received: from mail-ig0-f169.google.com ([209.85.213.169])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YqsAH-0000DA-W6
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 May 2015 23:58:48 +0000
Received: by igbpi8 with SMTP id pi8so33727681igb.1
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 08 May 2015 16:58:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=Qx1ReQWbA+A7m6nEcB6vYLIKSFtZH1BehkCwBMBTGRQ=;
	b=MvKA2Pzd3Q7FqlmnwXsCfXcMBWr2C8yEs+hlfFaA2AgDJ8go4lJ60xWe/DpNBGHiJy
	WAWl0nvfl1HU/nxqgUp0u25wKOT0LR+dO4ebS8jlc7xeSghzDgr5Jrp4rfLkpCgCkktl
	vwx2H46sDn/RM55RTNyCkP5bt12tGfOxX1Jr5s3ckZspEnSDSUgGQrVkSIusQxIRRemk
	5IBNVduCm187hu6AcSu+yp+xT83m15of5MJephx3EbmWxz22A29iNsuTI9tgSBjyWv3o
	bCcJZx5qjhyNs+6EaJzF+mKob0VCDi8/TPlUr5mLD6kKQYTwk5d7qfqaOIpUSWQL9CpQ
	KqMw==
X-Gm-Message-State: ALoCoQkMgWaYPpeWygTXl4IAx4CqAQs3OuU7TiTIOTGZBqhJHfpDRvdYBkREPen092N3gdWa16st
X-Received: by 10.50.85.113 with SMTP id g17mr769602igz.46.1431129520589; Fri,
	08 May 2015 16:58:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.25.203 with HTTP; Fri, 8 May 2015 16:58:20 -0700 (PDT)
X-Originating-IP: [173.228.107.141]
In-Reply-To: <CACq0ZD7hm5_moqkBOPDRUTnQf16rPggRiLf5ZwBNLbrrgajttA@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>
	<CACq0ZD7hm5_moqkBOPDRUTnQf16rPggRiLf5ZwBNLbrrgajttA@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Fri, 8 May 2015 16:58:20 -0700
Message-ID: <CAOG=w-vTxmg+8eC5FqkBZV8v5NcxHJ-dDu_ST1fHzvSRGHWmjA@mail.gmail.com>
To: Aaron Voisine <voisine@gmail.com>
Content-Type: multipart/alternative; boundary=089e014954e0b3e49005159acee6
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1YqsAH-0000DA-W6
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
	function
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2015 23:58:49 -0000

--089e014954e0b3e49005159acee6
Content-Type: text/plain; charset=UTF-8

In a fee-dominated future, replace-by-fee is not an opt-in feature. When
you create a transaction, the wallet presents a range of fees that it
expects you might pay. It then signs copies of the transaction with spaced
fees from this interval and broadcasts the lowest fee first. In the user
interface, the transaction is shown with its transacted amount and the
approved fee range. All of the inputs used are placed on hold until the
transaction gets a confirmation. As time goes by and it looks like the
transaction is not getting accepted, successively higher fee versions are
released. You can opt-out and send a no-fee or base-fee-only transaction,
but that should not be the default.

On the receiving end, local policy controls how much fee should be spent
trying to obtain confirmations before alerting the user, if there are fees
available in the hot wallet to do this. The receiving wallet then adds its
own fees via a spend if it thinks insufficient fees were provided to get a
confirmation. Again, this should all be automated so long as there is a hot
wallet on the receiving end.

Is this more complicated than now, where blocks are not full and clients
generally don't have to worry about their transactions eventually
confirming? Yes, it is significantly more complicated. But such
complication is unavoidable. It is a simple fact that the block size cannot
increase so much as to cover every single use by every single person in the
world, so there is no getting around the reality that we will have to
transition into an economy where at least one side has to pay up for a
transaction to get confirmation, at all. We are going to have to deal with
this issue whether it is now at 1MB or later at 20MB. And frankly, it'll be
much easier to do now.

On Fri, May 8, 2015 at 4:15 PM, Aaron Voisine <voisine@gmail.com> wrote:

> 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.
>>
>
>

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

<div dir=3D"ltr"><div><div>In a fee-dominated future, replace-by-fee is not=
 an opt-in feature. When you create a transaction, the wallet presents a ra=
nge of fees that it expects you might pay. It then signs copies of the tran=
saction with spaced fees from this interval and broadcasts the lowest fee f=
irst. In the user interface, the transaction is shown with its transacted a=
mount and the approved fee range. All of the inputs used are placed on hold=
 until the transaction gets a confirmation. As time goes by and it looks li=
ke the transaction is not getting accepted, successively higher fee version=
s are released. You can opt-out and send a no-fee or base-fee-only transact=
ion, but that should not be the default.<br><br></div>On the receiving end,=
 local policy controls how much fee should be spent trying to obtain confir=
mations before alerting the user, if there are fees available in the hot wa=
llet to do this. The receiving wallet then adds its own fees via a spend if=
 it thinks insufficient fees were provided to get a confirmation. Again, th=
is should all be automated so long as there is a hot wallet on the receivin=
g end.<br><br></div><div>Is this more complicated than now, where blocks ar=
e not full and clients generally don&#39;t have to worry about their transa=
ctions eventually confirming? Yes, it is significantly more complicated. Bu=
t such complication is unavoidable. It is a simple fact that the block size=
 cannot increase so much as to cover every single use by every single perso=
n in the world, so there is no getting around the reality that we will have=
 to transition into an economy where at least one side has to pay up for a =
transaction to get confirmation, at all. We are going to have to deal with =
this issue whether it is now at 1MB or later at 20MB. And frankly, it&#39;l=
l be much easier to do now.<br></div></div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote">On Fri, May 8, 2015 at 4:15 PM, Aaron Voisine <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:voisine@gmail.com" target=3D"_blank">v=
oisine@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr">That&#39;s fair, and we&#39;ve implemented child-pays-for-pa=
rent for spending unconfirmed inputs in breadwallet. But what should the be=
havior be when those options aren&#39;t understood/implemented/used?<div><b=
r></div><div>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 option=
s to add fee pressure, causing users to economize on block space without re=
sorting to dropping transactions after a prolonged delay.</div><div class=
=3D"gmail_extra"><span class=3D""><br><div><div><div dir=3D"ltr"><div><div =
dir=3D"ltr"><div>Aaron Voisine</div><div>co-founder and CEO<br><a href=3D"h=
ttp://breadwallet.com" target=3D"_blank">breadwallet.com</a></div></div></d=
iv></div></div></div>
<br></span><div><div class=3D"h5"><div class=3D"gmail_quote">On Fri, May 8,=
 2015 at 3:45 PM, Mark Friedenbach <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;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>On Fri, Ma=
y 8, 2015 at 3:43 PM, Aaron Voisine <span dir=3D"ltr">&lt;<a href=3D"mailto=
:voisine@gmail.com" target=3D"_blank">voisine@gmail.com</a>&gt;</span> wrot=
e:<br></span><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr">This is a clever way to tie b=
lock size 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 sca=
rcity. 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></blockq=
uote><div><br></div></span><div>There are already solutions to this which a=
re waiting to be deployed as default policy to bitcoind, and need to be imp=
lemented in other clients: replace-by-fee and child-pays-for-parent. <br></=
div></div></div></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>

--089e014954e0b3e49005159acee6--