<div dir="ltr"><div> ...because nLockTime is the exact opposite of expiration.  A locked TX begins life invalid, and becomes valid (not-expired) after nLockTime passes.<br><br></div>A new field containing expiration time would work.<br>

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

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#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 tx
    expiring?<div class=""><br>
    <br>
    <br>
    <div>On 8/6/2014 6:54 AM, Mike Hearn wrote:<br>
    </div>
    </div><blockquote type="cite"><div class="">
      <div dir="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.</div>
      </div><div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote"><div class="">On Wed, Aug 6, 2014 at 2:55 PM, Jeff
          Garzik <span dir="ltr">&lt;<a href="mailto:jgarzik@bitpay.com" target="_blank">jgarzik@bitpay.com</a>&gt;</span>
          wrote:<br>
          </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
            <div dir="ltr"> ...and existing users and uses of nLockTime
              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="gmail_extra">
              <div>
                <div><br>
                  <br>
                  <div class="gmail_quote"><div class="">On Wed, Aug 6, 2014 at 12:01
                    AM, Tom Harding <span dir="ltr">&lt;<a href="mailto:tomh@thinlink.com" target="_blank">tomh@thinlink.com</a>&gt;</span>
                    wrote:<br>
                    </div><blockquote class="gmail_quote" style="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="">
    <br>
    <blockquote type="cite">
      <div class="gmail_extra">
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div class="gmail_extra">
              <div>
                <div>
                  <div class="gmail_quote">
                    <blockquote class="gmail_quote" style="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.  Very pretty.  It would also
                      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="all"><br>-- <br>Jeff Garzik<br>Bitcoin core developer and open source evangelist<br>BitPay, Inc.      <a href="https://bitpay.com/" target="_blank">https://bitpay.com/</a>
</div>