From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YqpRJ-0003Ti-Ug for bitcoin-development@lists.sourceforge.net; Fri, 08 May 2015 21:04:09 +0000 X-ACL-Warn: Received: from mail-ig0-f170.google.com ([209.85.213.170]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YqpRI-00011J-2A for bitcoin-development@lists.sourceforge.net; Fri, 08 May 2015 21:04:09 +0000 Received: by iget9 with SMTP id t9so38285736ige.1 for ; Fri, 08 May 2015 14:04:02 -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=gn3hEb9afnPRehUVZy4hOdjV9tlfPIdaj4hTonutCpg=; b=E7fS+5r+6QL9N5XFAIKCnZsao9TfTj2aEvgBr9Y4mhz2/uQz+SJq1bQjRrrJ1xRpdB NIVs2fRkNcZlqdafPatS+4eROPjm/dqG2v+WPuyCNWBesrJcGWTIaJ+zrV7FrbgaAOYo UVQMlzr5sfObEsNLGHH40JyVd2iPKvysVMMyFR0P/i+V9XTwQROH6WiP66E/S2YTw10Z jtjsToFLWjN9ivKv7roDAEO9hiiYigksQAEutg0AxCuZhNjZfOaHsEfLHMxglULW7qUH u6cIARMI8hZyLEL360zhCgLM/xPiw1oNnFOo5ilyEhhJFryK7Jg+G8PtH0A6ABR23sTc EwQQ== X-Gm-Message-State: ALoCoQl7stYtPtUtmgKcCOjL7drJCQ3FpT9k5wXWxC8Q/FQxmjD+RD2nfMpu6PlH/ak+JmwpUrQ4 X-Received: by 10.42.20.197 with SMTP id h5mr6406icb.22.1431117671268; Fri, 08 May 2015 13:41:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.25.203 with HTTP; Fri, 8 May 2015 13:40:50 -0700 (PDT) X-Originating-IP: [173.228.107.141] In-Reply-To: References: From: Mark Friedenbach Date: Fri, 8 May 2015 13:40:50 -0700 Message-ID: To: "Raystonn ." Content-Type: multipart/alternative; boundary=20cf30291f2a6d96930515980c93 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: 1YqpRI-00011J-2A Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Block Size Increase 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 21:04:10 -0000 --20cf30291f2a6d96930515980c93 Content-Type: text/plain; charset=UTF-8 Transactions don't expire. But if the wallet is online, it can periodically choose to release an already created transaction with a higher fee. This requires replace-by-fee to be sufficiently deployed, however. On Fri, May 8, 2015 at 1:38 PM, Raystonn . wrote: > I have a proposal for wallets such as yours. How about creating all > transactions with an expiration time starting with a low fee, then > replacing with new transactions that have a higher fee as time passes. > Users can pick the fee curve they desire based on the transaction priority > they want to advertise to the network. Users set the priority in the > wallet, and the wallet software translates it to a specific fee curve used > in the series of expiring transactions. In this manner, transactions are > never left hanging for days, and probably not even for hours. > > -Raystonn > On 8 May 2015 1:17 pm, Aaron Voisine wrote: > > As the author of a popular SPV wallet, I wanted to weigh in, in support of > the Gavin's 20Mb block proposal. > > The best argument I've heard against raising the limit is that we need fee > pressure. I agree that fee pressure is the right way to economize on > scarce resources. Placing hard limits on block size however is an > incredibly disruptive way to go about this, and will severely negatively > impact users' experience. > > When users pay too low a fee, they should: > > 1) See immediate failure as they do now with fees that fail to propagate. > > 2) If the fee lower than it should be but not terminal, they should see > degraded performance, long delays in confirmation, but eventual success. > This will encourage them to pay higher fees in future. > > The worst of all worlds would be to have transactions propagate, hang in > limbo for days, and then fail. This is the most important scenario to > avoid. Increasing the 1Mb block size limit I think is the simplest way to > avoid this least desirable scenario for the immediate future. > > We can play around with improved transaction selection for blocks and > encourage miners to adopt it to discourage low fees and create fee > pressure. These could involve hybrid priority/fee selection so low fee > transactions see degraded performance instead of failure. This would be the > conservative low risk approach. > > Aaron Voisine > co-founder and CEO > breadwallet.com > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --20cf30291f2a6d96930515980c93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Transactions don't expire. But if the wallet is online= , it can periodically choose to release an already created transaction with= a higher fee. This requires replace-by-fee to be sufficiently deployed, ho= wever.

On= Fri, May 8, 2015 at 1:38 PM, Raystonn . <raystonn@hotmail.com><= /span> wrote:

I have a pro= posal for wallets such as yours.=C2=A0 How about creating all transactions = with an expiration time starting with a low fee, then replacing with new tr= ansactions that have a higher fee as time passes.=C2=A0 Users can pick the = fee curve they desire based on the transaction priority they want to advert= ise to the network.=C2=A0 Users set the priority in the wallet, and the wal= let software translates it to a specific fee curve used in the series of ex= piring transactions.=C2=A0 In this manner, transactions are never left hang= ing for days, and probably not even for hours.

-Raystonn

On 8 May 2015 1:17 pm, Aaron Voisine <voisine@gmail.com> w= rote:
As the author of a = popular SPV wallet, I wanted to weigh in, in support of the Gavin's 20M= b block proposal.

The best argument I've heard again= st raising the limit is that we need fee pressure.=C2=A0 I agree that fee p= ressure is the right way to economize on scarce resources. Placing hard lim= its on block size however is an incredibly disruptive way to go about this,= and will severely negatively impact users' experience.

When users pay too low a fee, they should:

1) See immediate failure as they do now with fees that fail to propagate.<= /div>

2) If the fee lower than it should be but not term= inal, they should see degraded performance, long delays in confirmation, bu= t eventual success. This will encourage them to pay higher fees in future.<= /div>

The worst of all worlds would be to have transacti= ons propagate, hang in limbo for days, and then fail. This is the most impo= rtant scenario to avoid. Increasing the 1Mb block size limit I think is the= simplest way to avoid this least desirable scenario for the immediate futu= re.

We can play around with improved transaction s= election for blocks and encourage miners to adopt it to discourage low fees= and create fee pressure. These could involve hybrid priority/fee selection= so low fee transactions see degraded performance instead of failure. This = would be the conservative low risk approach.

Aaron Voisine
co-founder an= d CEO
breadwallet.c= om

----------------------------------------------------= --------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
= _______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--20cf30291f2a6d96930515980c93--