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, 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. 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"><<a moz-do-not-send="true" href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>></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 <<a moz-do-not-send="true" href="mailto:decker.christian@gmail.com">decker.christian@gmail.com</a>> wrote:<br> >+1 for the new field, overloading fields with new meaning is definitely<br> >not<br> >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. <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&iu=/4140/ostg.clktrk">http://pubads.g.doubleclick.net/gampad/clk?id=153845071&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--