From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) id 1XF2yM-0001lt-0u for bitcoin-development@lists.sourceforge.net; Wed, 06 Aug 2014 15:17:50 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.50 as permitted sender) client-ip=209.85.219.50; envelope-from=decker.christian@gmail.com; helo=mail-oa0-f50.google.com; Received: from mail-oa0-f50.google.com ([209.85.219.50]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XF2yK-0002i5-Ho for bitcoin-development@lists.sourceforge.net; Wed, 06 Aug 2014 15:17:49 +0000 Received: by mail-oa0-f50.google.com with SMTP id g18so1963163oah.9 for ; Wed, 06 Aug 2014 08:17:43 -0700 (PDT) X-Received: by 10.60.34.98 with SMTP id y2mr16405223oei.9.1407338263047; Wed, 06 Aug 2014 08:17:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.3.161 with HTTP; Wed, 6 Aug 2014 08:17:02 -0700 (PDT) In-Reply-To: References: <53E1A8AF.4030206@thinlink.com> <53E23F49.3020605@thinlink.com> From: Christian Decker Date: Wed, 6 Aug 2014 16:17:02 +0100 Message-ID: To: Jeff Garzik Content-Type: multipart/alternative; boundary=089e01175d0740002104fff779d8 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (decker.christian[at]gmail.com) -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: 1XF2yK-0002i5-Ho Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] deterministic transaction expiration X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 15:17:50 -0000 --089e01175d0740002104fff779d8 Content-Type: text/plain; charset=UTF-8 +1 for the new field, overloading fields with new meaning is definitely not a good idea. Something like nExpireAt with a block height sounds reasonable to me, but we need to document that the usual caveats with blockchain reorgs apply. On Wed, Aug 6, 2014 at 4:08 PM, Jeff Garzik wrote: > ...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 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 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 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/ > > > ------------------------------------------------------------------------------ > 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 > > --089e01175d0740002104fff779d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 for the new field, overloading fields with new meaning = is definitely not a good idea.

Something like nExpireAt = with a block height sounds reasonable to me, but we need to document that t= he usual caveats with blockchain reorgs apply.


On Wed,= Aug 6, 2014 at 4:08 PM, Jeff Garzik <jgarzik@bitpay.com> w= rote:
=C2=A0...because nLock= Time is the exact opposite of expiration.=C2=A0 A locked TX begins life inv= alid, 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@th= inlink.com> wrote:
=20 =20 =20

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?



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, Jef= f Garzik <jgarzik@bitpay.com> wrote:
=C2=A0...and existing users and uses of nLockT= ime 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. =C2=A0Very pretty. =C2=A0It would al= so 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
Bi= tPay, Inc. =C2=A0 =C2=A0 =C2=A0https://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/gam= pad/clk?id=3D153845071&iu=3D/4140/ostg.clktrk
__________________= _____________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--089e01175d0740002104fff779d8--