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 ) 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 ; 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: References: <16096345.A1MpJQQkRW@crushinator> From: Mark Friedenbach Date: Fri, 8 May 2015 16:58:20 -0700 Message-ID: To: Aaron Voisine 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > wrote: > >> On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine 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
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.

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.

Is this more complicated than now, where blocks ar= e not full and clients generally don'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'l= l be much easier to do now.

<= div class=3D"gmail_quote">On Fri, May 8, 2015 at 4:15 PM, Aaron Voisine <v= oisine@gmail.com> wrote:
That's fair, and we've implemented child-pays-for-pa= rent for spending unconfirmed inputs in breadwallet. But what should the be= havior 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 option= s to add fee pressure, causing users to economize on block space without re= sorting 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, Ma= y 8, 2015 at 3:43 PM, Aaron Voisine <voisine@gmail.com> wrot= e:
This is a clever way to tie b= lock size to fees.

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.

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.


--089e014954e0b3e49005159acee6--