MIME-Version: 1.0
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
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
Precedence: list

--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&#39;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">&lt;<a href=3D"m=
ailto:raystonn@hotmail.com" target=3D"_blank">raystonn@hotmail.com</a>&gt;<=
/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 &lt;<a href=
=3D"mailto:voisine@gmail.com" target=3D"_blank">voisine@gmail.com</a>&gt; 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&#39;s 20M=
b block proposal.<div><br></div><div>The best argument I&#39;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&#39; 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--