Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bitpay.com
	designates 209.85.213.170 as permitted sender)
	client-ip=209.85.213.170; envelope-from=jgarzik@bitpay.com;
	helo=mail-ig0-f170.google.com; 
MIME-Version: 1.0
In-Reply-To: <53E1A8AF.4030206@thinlink.com>
References: <CA+iPb=HkxeVPF0SynxCPgUkq4msrdfayFrVNFjzg29rFwqXv1w@mail.gmail.com>
	<CAJHLa0O2wFq2Vs5Bes_8x1q_j0VC+U4DQkx=6GqT8w5e8Lh5Qg@mail.gmail.com>
	<CA+iPb=ET+A-qB8TgPX8D-ut1DWnq9tZJ=14igfRVWO6eog6Xgw@mail.gmail.com>
	<53E1A8AF.4030206@thinlink.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Wed, 6 Aug 2014 08:55:51 -0400
Message-ID: <CAJHLa0MfRhCPX8H92qc1kSebc=WrUzmSgbG331t4-zDHhTNu4w@mail.gmail.com>
To: Tom Harding <tomh@thinlink.com>
Content-Type: multipart/alternative; boundary=089e0149c57e1a38a004fff57f15
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] deterministic transaction expiration
Precedence: list

--089e0149c57e1a38a004fff57f15
Content-Type: text/plain; charset=UTF-8

 ...and existing users and uses of nLockTime suddenly become worthless,
breaking payment channel refunds and other active uses of nLockTime.

You cannot assume the user is around to rewrite their nLockTime, if it
fails to be confirmed before some arbitrary deadline being set.


On Wed, Aug 6, 2014 at 12:01 AM, Tom Harding <tomh@thinlink.com> wrote:

> On 8/5/2014 12:10 PM, Kaz Wesley wrote:
> > Any approach based on beginning a transaction expiry countdown when a
> > transaction is received (as in mempool janitor) seems unviable to me:
> > once a node has forgotten a transaction, it must be susceptible to
> > reaccepting it;
>
> It's hard to argue with that logic.
>
> If nLockTime is used for expiration, transaction creator can't lie to
> help tx live longer without pushing initial confirmation eligibility
> into the future.  Very pretty.  It would also enable "fill or kill"
> transactions with a backdated nLockTime, which must be confirmed in a
> few blocks, or start vanishing from mempools.
>
>
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>


-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

--089e0149c57e1a38a004fff57f15
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">=C2=A0...and existing users and uses of nLockTime suddenly=
 become worthless, breaking payment channel refunds and other active uses o=
f nLockTime.<br><br>You cannot assume the user is around to rewrite their n=
LockTime, if it fails to be confirmed before some arbitrary deadline being =
set.<br>

<br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On =
Wed, Aug 6, 2014 at 12:01 AM, Tom Harding <span dir=3D"ltr">&lt;<a href=3D"=
mailto:tomh@thinlink.com" target=3D"_blank">tomh@thinlink.com</a>&gt;</span=
> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 8/5/2014 12:10 PM, Kaz We=
sley wrote:<br>
&gt; Any approach based on beginning a transaction expiry countdown when a<=
br>
&gt; transaction is received (as in mempool janitor) seems unviable to me:<=
br>
&gt; once a node has forgotten a transaction, it must be susceptible to<br>
&gt; reaccepting it;<br>
<br>
</div>It&#39;s hard to argue with that logic.<br>
<br>
If nLockTime is used for expiration, transaction creator can&#39;t lie to<b=
r>
help tx live longer without pushing initial confirmation eligibility<br>
into the future. =C2=A0Very pretty. =C2=A0It would also enable &quot;fill o=
r kill&quot;<br>
transactions with a backdated nLockTime, which must be confirmed in a<br>
few blocks, or start vanishing from mempools.<br>
<br>
<br>
---------------------------------------------------------------------------=
---<br>
Infragistics Professional<br>
Build stunning WinForms apps today!<br>
Reboot your WinForms applications with our WinForms controls.<br>
Build a bridge from your legacy apps to the future.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D153845071&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D153845071&amp;iu=3D/4140/ostg.clktrk</a><br>
<div class=3D"HOEnZb"><div class=3D"h5">___________________________________=
____________<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>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Jeff Garzik=
<br>Bitcoin core developer and open source evangelist<br>BitPay, Inc. =C2=
=A0 =C2=A0 =C2=A0<a href=3D"https://bitpay.com/" target=3D"_blank">https://=
bitpay.com/</a>
</div>

--089e0149c57e1a38a004fff57f15--