diff options
author | Jeff Garzik <jgarzik@bitpay.com> | 2014-08-06 11:08:36 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2014-08-06 15:09:04 +0000 |
commit | 83e9c54b3051bf52fe57491cf8d891df277c1b9c (patch) | |
tree | af8ed57d10b1b2c4c7d5d1da1a6e2cc26b81dfad | |
parent | 1d023289b6035953925ea38ad59cba65152636c1 (diff) | |
download | pi-bitcoindev-83e9c54b3051bf52fe57491cf8d891df277c1b9c.tar.gz pi-bitcoindev-83e9c54b3051bf52fe57491cf8d891df277c1b9c.zip |
Re: [Bitcoin-development] deterministic transaction expiration
-rw-r--r-- | 55/e1d1240e51b12442822eb92c5bcf1b2f85577e | 244 |
1 files changed, 244 insertions, 0 deletions
diff --git a/55/e1d1240e51b12442822eb92c5bcf1b2f85577e b/55/e1d1240e51b12442822eb92c5bcf1b2f85577e new file mode 100644 index 000000000..21f8b06b5 --- /dev/null +++ b/55/e1d1240e51b12442822eb92c5bcf1b2f85577e @@ -0,0 +1,244 @@ +Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] + helo=mx.sourceforge.net) + by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <jgarzik@bitpay.com>) id 1XF2ps-0001NR-3x + for bitcoin-development@lists.sourceforge.net; + Wed, 06 Aug 2014 15:09:04 +0000 +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; +Received: from mail-ig0-f171.google.com ([209.85.213.171]) + by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1XF2pq-0002SB-3c + for bitcoin-development@lists.sourceforge.net; + Wed, 06 Aug 2014 15:09:04 +0000 +Received: by mail-ig0-f171.google.com with SMTP id l13so8822899iga.10 + for <bitcoin-development@lists.sourceforge.net>; + Wed, 06 Aug 2014 08:08:56 -0700 (PDT) +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:mime-version:in-reply-to:references:from:date + :message-id:subject:to:cc:content-type; + bh=0g4MTjaAtsQDSlMdXEGsBiW6xXhe/YqwN+d2miz/U6k=; + b=k8EfdijW1PhUnE7UdYkeM8p4hv890V4dTPDGcshGGSpae0CQKZADx4p0tWjaTgbWxg + XwNPENsFxwmVybp35sBG/l5fpW0uIqyGIoZPUYMjQbS80uBG8vUBDKM/tO57z3GGTH3M + SbNziSWEK3uv9NOYhXGtLw3zL7WXB59onyjzB1z5aOrEFerub59BOnm4067QrreRV3Ky + nR74C911GTet/1ZbgE0HHDkJHJYGa9bLv58eTCsUAXfYLzdrIkd784tTu/2nqNrsic9z + It9/FikWWix1+B4ro/kgjgvFCekYzpZSBFWohEQO1gDQ7GR132JOl+uwafBnhjOg8hN0 + Lc9Q== +X-Gm-Message-State: ALoCoQn+THv6g8h0beFpCnYXTCre1VdMqEdDLNiwaGkYXdi4h4Dr6r1ivfOPwNurUrX8us3RJ1lz +X-Received: by 10.50.80.116 with SMTP id q20mr60608690igx.22.1407337736286; + Wed, 06 Aug 2014 08:08:56 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.107.10.78 with HTTP; Wed, 6 Aug 2014 08:08:36 -0700 (PDT) +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 +X-Spam-Score: -0.6 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1XF2pq-0002SB-3c +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +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 15:09:04 -0000 + +--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"><<a href=3D"= +mailto:tomh@thinlink.com" target=3D"_blank">tomh@thinlink.com</a>></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 "breaking", 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"><<a href=3D"mailto:jgarzik@bitpay.com= +" target=3D"_blank">jgarzik@bitpay.com</a>></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"><<a href=3D"mailto= +:tomh@thinlink.com" target=3D"_blank">tomh@thinlink.com</a>></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'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 "fill or kill"<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-- + + |