Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <tomh@thinlink.com>) id 1XF4bj-0007IX-Op
	for bitcoin-development@lists.sourceforge.net;
	Wed, 06 Aug 2014 17:02:35 +0000
X-ACL-Warn: 
Received: from mail-pa0-f45.google.com ([209.85.220.45])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1XF4bi-0002Or-EW
	for bitcoin-development@lists.sourceforge.net;
	Wed, 06 Aug 2014 17:02:35 +0000
Received: by mail-pa0-f45.google.com with SMTP id eu11so3760984pac.18
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 06 Aug 2014 10:02:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:subject:references:in-reply-to:content-type;
	bh=BwwFT5ST6aPNXTlaq4Djv5HTAaQpRDrzKOtgLeXisA4=;
	b=Xsnhe2lF9GSjJgTGI4kidlFAFucR3At0kD7G+UOghTs9Kmh6phOshqqirRo/1Wdf1I
	4260xs2muhH9kBfnpiN/SorjmgF8w0KGOxe1eUxQV8abma5eB8NsM9RlDKi2S6VtAFwH
	JdN6n5eVfl9vT12q2zAk2kLYsYu/WsGdSIMC7v8h2kDoXty7jX7+OqfCxUO4K+WLWL12
	IRcA4Rxv/yzSxKbcaTFHjCeo9MCtjB712+fLUEe+cWaO/a9krOCgS1TEXWe3XaDIshLh
	qng0dONHn8A7fTRa+wug8b9vFhEz0P0JC4Hjn9tBS9wrxqOgIT3pT9nuJYbl8sow6E/r
	TbsA==
X-Gm-Message-State: ALoCoQmvmJ+1ZA7knxbwZut3L/NscVXGbS6ITCmvLUyAG5ftolnXMX08wL/U+wv1qFzvt/27gJ6G
X-Received: by 10.70.127.207 with SMTP id ni15mr12240065pdb.129.1407344548633; 
	Wed, 06 Aug 2014 10:02:28 -0700 (PDT)
Received: from [10.100.1.239] ([204.58.254.99])
	by mx.google.com with ESMTPSA id id4sm1817030pbb.57.2014.08.06.10.02.27
	for <bitcoin-development@lists.sourceforge.net>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 06 Aug 2014 10:02:28 -0700 (PDT)
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"
X-Spam-Score: 1.6 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server
	[204.58.254.99 listed in dnsbl.sorbs.net]
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1XF4bi-0002Or-EW
Subject: Re: [Bitcoin-development] deterministic transaction expiration
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: Wed, 06 Aug 2014 17:02:35 -0000

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