path: root/2b/31f9190e3e12fe384b32022d8c856f0607687b

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&#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--