diff options
| author | Mark Friedenbach <mark@friedenbach.org> | 2015-05-08 13:40:50 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-05-08 21:04:09 +0000 |
| commit | ec339d18586ecd6f5ed9a64dc3b65d3e44e23435 (patch) | |
| tree | 5d057a0081af19014aa474e72c3e0fe53207d19f | |
| parent | b0adaf6cdaeed9e1e5c1c643f0c0a9ee2a4c3b04 (diff) | |
| download | pi-bitcoindev-ec339d18586ecd6f5ed9a64dc3b65d3e44e23435.tar.gz pi-bitcoindev-ec339d18586ecd6f5ed9a64dc3b65d3e44e23435.zip | |
Re: [Bitcoin-development] Block Size Increase
| -rw-r--r-- | 2b/31f9190e3e12fe384b32022d8c856f0607687b | 198 |
1 files changed, 198 insertions, 0 deletions
diff --git a/2b/31f9190e3e12fe384b32022d8c856f0607687b b/2b/31f9190e3e12fe384b32022d8c856f0607687b new file mode 100644 index 000000000..586c457bd --- /dev/null +++ b/2b/31f9190e3e12fe384b32022d8c856f0607687b @@ -0,0 +1,198 @@ +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-- + + |