Message-ID: <53E25F8A.5070905@thinlink.com>
Date: Wed, 06 Aug 2014 10:02:02 -0700
From: Tom Harding <tomh@thinlink.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
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>	<CAJHLa0OtPA3DGQuJhp3zkK5dnBux6TFAw3qDsBdO0zaxrqBgRg@mail.gmail.com>	<CALxbBHXh-Fktsr96PMXdohJdgcUKoNreJ-ZuApKOX3-qSkdk2w@mail.gmail.com>	<63a80796-609e-43f5-9280-4cd8cf5d2648@email.android.com>
	<CAJHLa0OQJEvQht_chF1gVG_BOwp=DW0zOOo3VE_acZonsSguWw@mail.gmail.com>
In-Reply-To: <CAJHLa0OQJEvQht_chF1gVG_BOwp=DW0zOOo3VE_acZonsSguWw@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------080602060402000605060602"
Subject: Re: [Bitcoin-development] deterministic transaction expiration
Precedence: list

This is a multi-part message in MIME format.
--------------080602060402000605060602
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Today we have first-eligible-height (nLockTime), and mempool expiration 
measured from this height would work for the goals being discussed, no 
fork or protocol rev.

With first-eligible-height and last-eligible-height, creator could 
choose a lifetime shorter than the max,  and in addition, lock the whole 
thing until some point in the future.


On 8/6/2014 9:15 AM, Jeff Garzik wrote:
> A fork is not necessarily required, if you are talking about 
> information that deals primarily with pre-consensus mempool behavior.  
> You can make a "network TX" with some information that is digitally 
> signed, yet discarded before it reaches miners.
>
>
> On Wed, Aug 6, 2014 at 11:42 AM, Peter Todd <pete@petertodd.org 
> <mailto:pete@petertodd.org>> wrote:
>
>     -----BEGIN PGP SIGNED MESSAGE-----
>     Hash: SHA256
>
>
>
>     On 6 August 2014 08:17:02 GMT-07:00, Christian Decker
>     <decker.christian@gmail.com <mailto:decker.christian@gmail.com>>
>     wrote:
>     >+1 for the new field, overloading fields with new meaning is
>     definitely
>     >not
>     >a good idea.
>
>     To add a new field the best way to do it is create a new,
>     parallel, tx format where fields are committed by merkle radix
>     tree in an extensible and provable way. You'd then commit to that
>     tree with a mandatory OP_RETURN output in the last txout, or with
>     a new merkle root.
>
>     Changing the tx format itself in a hard-fork is needlessly
>     disruptive, and in this case, wastes opportunities for improvement.
>     -----BEGIN PGP SIGNATURE-----
>     Version: APG v1.1.1
>
>     iQFQBAEBCAA6BQJT4kzQMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
>     cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhamzCAC+zRaXRodP63+ke3K+
>     Viapiepvk4uIOlqxqtMB2O0zWcyu2+xCJDiRPykK/6HLDBeFDEC9/dGK8++Lovl6
>     //qZ340LOPFlgT2kYy9E5h/yX469fhtsWhBCv2K47fWwkMS0S/0r4SQnCkbt2R2c
>     4dQjkoldhw6rNMBTUmwvhSlL30KsT/msWTZiX7DW/YjfOzezEJzy+mYyKp9Sk7ba
>     1fOiBXORk7mNOs7sTYTvje3sqEGpGTOLP08cY/RCEvl6bG8mHkPqwiojq+3biHFP
>     RsoBVu1f5cbnU7Wq0gPNdVnQssnEQDadyTX8gT0Wze7PuVyaZT2mXFZBKzSHuLy2
>     sJKN
>     =oPSo
>     -----END PGP SIGNATURE-----
>
>
>
>
> -- 
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> 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


--------------080602060402000605060602
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    Today we have first-eligible-height (nLockTime), and mempool
    expiration measured from this height would work for the goals being
    discussed, no fork or protocol rev.<br>
    <br>
    With first-eligible-height and last-eligible-height, creator could
    choose a lifetime shorter than the max,&nbsp; and in addition, lock the
    whole thing until some point in the future.<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 8/6/2014 9:15 AM, Jeff Garzik wrote:<br>
    </div>
    <blockquote
cite="mid:CAJHLa0OQJEvQht_chF1gVG_BOwp=DW0zOOo3VE_acZonsSguWw@mail.gmail.com"
      type="cite">
      <div dir="ltr">A fork is not necessarily required, if you are
        talking about information that deals primarily with
        pre-consensus mempool behavior.&nbsp; You can make a "network TX"
        with some information that is digitally signed, yet discarded
        before it reaches miners.<br>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Wed, Aug 6, 2014 at 11:42 AM, Peter
          Todd <span dir="ltr">&lt;<a moz-do-not-send="true"
              href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN
            PGP SIGNED MESSAGE-----<br>
            Hash: SHA256<br>
            <div class=""><br>
              <br>
              <br>
              On 6 August 2014 08:17:02 GMT-07:00, Christian Decker &lt;<a
                moz-do-not-send="true"
                href="mailto:decker.christian@gmail.com">decker.christian@gmail.com</a>&gt;
              wrote:<br>
              &gt;+1 for the new field, overloading fields with new
              meaning is definitely<br>
              &gt;not<br>
              &gt;a good idea.<br>
              <br>
            </div>
            To add a new field the best way to do it is create a new,
            parallel, tx format where fields are committed by merkle
            radix tree in an extensible and provable way. You'd then
            commit to that tree with a mandatory OP_RETURN output in the
            last txout, or with a new merkle root.<br>
            <br>
            Changing the tx format itself in a hard-fork is needlessly
            disruptive, and in this case, wastes opportunities for
            improvement.<br>
            -----BEGIN PGP SIGNATURE-----<br>
            Version: APG v1.1.1<br>
            <br>
iQFQBAEBCAA6BQJT4kzQMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8<br>
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhamzCAC+zRaXRodP63+ke3K+<br>
Viapiepvk4uIOlqxqtMB2O0zWcyu2+xCJDiRPykK/6HLDBeFDEC9/dGK8++Lovl6<br>
//qZ340LOPFlgT2kYy9E5h/yX469fhtsWhBCv2K47fWwkMS0S/0r4SQnCkbt2R2c<br>
4dQjkoldhw6rNMBTUmwvhSlL30KsT/msWTZiX7DW/YjfOzezEJzy+mYyKp9Sk7ba<br>
1fOiBXORk7mNOs7sTYTvje3sqEGpGTOLP08cY/RCEvl6bG8mHkPqwiojq+3biHFP<br>
RsoBVu1f5cbnU7Wq0gPNdVnQssnEQDadyTX8gT0Wze7PuVyaZT2mXFZBKzSHuLy2<br>
            sJKN<br>
            =oPSo<br>
            -----END PGP SIGNATURE-----<br>
            <br>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <br>
        -- <br>
        Jeff Garzik<br>
        Bitcoin core developer and open source evangelist<br>
        BitPay, Inc. &nbsp; &nbsp; &nbsp;<a moz-do-not-send="true"
          href="https://bitpay.com/" target="_blank">https://bitpay.com/</a>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">------------------------------------------------------------------------------
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.
<a class="moz-txt-link-freetext" href="http://pubads.g.doubleclick.net/gampad/clk?id=153845071&amp;iu=/4140/ostg.clktrk">http://pubads.g.doubleclick.net/gampad/clk?id=153845071&amp;iu=/4140/ostg.clktrk</a></pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------080602060402000605060602--