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 <mark@friedenbach.org>) 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 <bitcoin-development@lists.sourceforge.net>; 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: <COL402-EAS4043863D3AB49C167CB2DCACDDE0@phx.gbl> References: <COL402-EAS4043863D3AB49C167CB2DCACDDE0@phx.gbl> From: Mark Friedenbach <mark@friedenbach.org> Date: Fri, 8 May 2015 13:40:50 -0700 Message-ID: <CAOG=w-tZGiiFu0CGqSzsF4FPLRP-wwzPiWSrm+Z+zE1vxpvBBg@mail.gmail.com> To: "Raystonn ." <raystonn@hotmail.com> 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 <bitcoin-development@lists.sourceforge.net> Subject: Re: [Bitcoin-development] Block Size Increase 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 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 . <raystonn@hotmail.com> 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 <voisine@gmail.com> 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 <div dir=3D"ltr">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.<br><div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On= Fri, May 8, 2015 at 1:38 PM, Raystonn . <span dir=3D"ltr"><<a href=3D"m= ailto:raystonn@hotmail.com" target=3D"_blank">raystonn@hotmail.com</a>><= /span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">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.</p> <p dir=3D"ltr">-Raystonn<br> </p> <div class=3D"gmail_quote">On 8 May 2015 1:17 pm, Aaron Voisine <<a href= =3D"mailto:voisine@gmail.com" target=3D"_blank">voisine@gmail.com</a>> w= rote:<br type=3D"attribution"><blockquote style=3D"margin:0 0 0 .8ex;border= -left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">As the author of a = popular SPV wallet, I wanted to weigh in, in support of the Gavin's 20M= b block proposal.<div><br></div><div>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.<br><div><br></d= iv><div>When users pay too low a fee, they should:</div><div><br></div><div= >1) See immediate failure as they do now with fees that fail to propagate.<= /div><div><br></div><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><div><br></div><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.</div><div><br></div><div>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.</div><div><br><div><div><div d= ir=3D"ltr"><div><div dir=3D"ltr"><div>Aaron Voisine</div><div>co-founder an= d CEO<br><a href=3D"http://breadwallet.com" target=3D"_blank">breadwallet.c= om</a></div></div></div></div></div></div></div></div></div> </blockquote></div><br>----------------------------------------------------= --------------------------<br> One dashboard for servers and applications across Physical-Virtual-Cloud<br= > Widest out-of-the-box monitoring support with 50+ applications<br> Performance metrics, stats and reports that give you Actionable Insights<br= > Deep dive visibility with transaction tracing using APM Insight.<br> <a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target= =3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>= _______________________________________________<br> Bitcoin-development mailing list<br> <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo= pment@lists.sourceforge.net</a><br> <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= " target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment</a><br> <br></blockquote></div><br></div></div></div> --20cf30291f2a6d96930515980c93--