Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bitpay.com
	designates 209.85.213.171 as permitted sender)
	client-ip=209.85.213.171; envelope-from=jgarzik@bitpay.com;
	helo=mail-ig0-f171.google.com; 
MIME-Version: 1.0
In-Reply-To: <53E23F49.3020605@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>
	<CAJHLa0MfRhCPX8H92qc1kSebc=WrUzmSgbG331t4-zDHhTNu4w@mail.gmail.com>
	<CANEZrP3eEiLxYfsAURRm4ysfS4TRgXxa_THxJ43cVH1OyR95JQ@mail.gmail.com>
	<53E23F49.3020605@thinlink.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Wed, 6 Aug 2014 11:08:36 -0400
Message-ID: <CAJHLa0OtPA3DGQuJhp3zkK5dnBux6TFAw3qDsBdO0zaxrqBgRg@mail.gmail.com>
To: Tom Harding <tomh@thinlink.com>
Content-Type: multipart/alternative; boundary=089e01536682db5fce04fff759c0
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] deterministic transaction expiration
Precedence: list

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

 ...because nLockTime is the exact opposite of expiration.  A locked TX
begins life invalid, and becomes valid (not-expired) after nLockTime passes.

A new field containing expiration time would work.



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

>
> How is eventual expiration of a tx that started life with an nLockTime in
> the future "breaking", any more than any other tx expiring?
>
>
>
> On 8/6/2014 6:54 AM, Mike Hearn wrote:
>
> We could however introduce a new field in a new tx version. We know we
> need to rev the format at some point anyway.
>
>
> On Wed, Aug 6, 2014 at 2:55 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:
>
>>  ...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:
>>
>>> ...
>>>
>>
>      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.
>>>
>>
>


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

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

<div dir=3D"ltr"><div>=C2=A0...because nLockTime is the exact opposite of e=
xpiration.=C2=A0 A locked TX begins life invalid, and becomes valid (not-ex=
pired) after nLockTime passes.<br><br></div>A new field containing expirati=
on time would work.<br>

<br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On =
Wed, Aug 6, 2014 at 10:44 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">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    How is eventual expiration of a tx that started life with an
    nLockTime in the future &quot;breaking&quot;, any more than any other t=
x
    expiring?<div class=3D""><br>
    <br>
    <br>
    <div>On 8/6/2014 6:54 AM, Mike Hearn wrote:<br>
    </div>
    </div><blockquote type=3D"cite"><div class=3D"">
      <div dir=3D"ltr">We could however introduce a new field in a new tx
        version. We know we need to rev the format at some point anyway.</d=
iv>
      </div><div class=3D"gmail_extra"><br>
        <br>
        <div class=3D"gmail_quote"><div class=3D"">On Wed, Aug 6, 2014 at 2=
:55 PM, Jeff
          Garzik <span dir=3D"ltr">&lt;<a href=3D"mailto:jgarzik@bitpay.com=
" target=3D"_blank">jgarzik@bitpay.com</a>&gt;</span>
          wrote:<br>
          </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"">
            <div dir=3D"ltr">=C2=A0...and existing users and uses of nLockT=
ime
              suddenly become worthless, breaking payment channel
              refunds and other active uses of nLockTime.<br>
              <br>
              You cannot assume the user is around to rewrite their
              nLockTime, if it fails to be confirmed before some
              arbitrary deadline being set.<br>
              <br>
            </div>
            </div><div class=3D"gmail_extra">
              <div>
                <div><br>
                  <br>
                  <div class=3D"gmail_quote"><div class=3D"">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>
                    </div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">...<br>
                    </blockquote>
                  </div>
                </div>
              </div>
            </div>
          </blockquote>
        </div>
      </div>
    </blockquote><div class=3D"">
    <br>
    <blockquote type=3D"cite">
      <div class=3D"gmail_extra">
        <div class=3D"gmail_quote">
          <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
            <div class=3D"gmail_extra">
              <div>
                <div>
                  <div class=3D"gmail_quote">
                    <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                      If nLockTime is used for expiration, transaction
                      creator can&#39;t lie to<br>
                      help tx live longer without pushing initial
                      confirmation eligibility<br>
                      into the future. =C2=A0Very pretty. =C2=A0It would al=
so
                      enable &quot;fill or kill&quot;<br>
                      transactions with a backdated nLockTime, which
                      must be confirmed in a<br>
                      few blocks, or start vanishing from mempools.<br>
                    </blockquote>
                  </div>
                </div>
              </div>
            </div>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <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>

--089e01536682db5fce04fff759c0--