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-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XF0lN-0008V7-WC for bitcoin-development@lists.sourceforge.net; Wed, 06 Aug 2014 12:56:18 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bitpay.com designates 209.85.213.170 as permitted sender) client-ip=209.85.213.170; envelope-from=jgarzik@bitpay.com; helo=mail-ig0-f170.google.com; Received: from mail-ig0-f170.google.com ([209.85.213.170]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XF0lM-0005Xl-S0 for bitcoin-development@lists.sourceforge.net; Wed, 06 Aug 2014 12:56:17 +0000 Received: by mail-ig0-f170.google.com with SMTP id h3so10322439igd.3 for ; Wed, 06 Aug 2014 05:56:11 -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=AVQq3n1nwFOkytW0up4x7WDG730V8scRla8uEZ0qDro=; b=UHPXYslbSFKUDut5SUTcb3ONaTvsudLa1+zrVszW3teWHj2sLFDpOX8pBLtgSyL8xY JIxbIzJ/E42RpSg0yXd20YeVRsvbkAEe0bLPJFtAAyh+B0KEGVuCywjGPu52CXAej0xn su0l1R6JYg7IkpGtvpeCy7Hcw6oBrd9C0VbbI8Rby+gmZ3tA1GP2pwyXBcBWOmQLn5x6 CK8FW43cl9eRZdrIuC3J8AW6BJP8luBEl5I5MZVSSXP5yV1GnvYDY8aXhsxaA5Gu1J3v o+2fm+hG83Kkh0cHgteWvwQtuLNP/Z90oMJbppF+gwi4QSjtIV5zH7TJk+kMLqgjZBLh WCLA== X-Gm-Message-State: ALoCoQnyN/d0OInCO6g41+L1RaW+zpktJ6FT8oPtTH4UI+3d53biqDI5OSJePMZd7h8pt/BXnCtS X-Received: by 10.50.178.172 with SMTP id cz12mr18290391igc.22.1407329771261; Wed, 06 Aug 2014 05:56:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.10.78 with HTTP; Wed, 6 Aug 2014 05:55:51 -0700 (PDT) In-Reply-To: <53E1A8AF.4030206@thinlink.com> References: <53E1A8AF.4030206@thinlink.com> From: Jeff Garzik Date: Wed, 6 Aug 2014 08:55:51 -0400 Message-ID: To: Tom Harding Content-Type: multipart/alternative; boundary=089e0149c57e1a38a004fff57f15 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: 1XF0lM-0005Xl-S0 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 12:56:18 -0000 --089e0149c57e1a38a004fff57f15 Content-Type: text/plain; charset=UTF-8 ...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: > On 8/5/2014 12:10 PM, Kaz Wesley wrote: > > Any approach based on beginning a transaction expiry countdown when a > > transaction is received (as in mempool janitor) seems unviable to me: > > once a node has forgotten a transaction, it must be susceptible to > > reaccepting it; > > It's hard to argue with that logic. > > 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. > > > > ------------------------------------------------------------------------------ > 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 > -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ --089e0149c57e1a38a004fff57f15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0...and existing users and uses of nLockTime suddenly= become worthless, breaking payment channel refunds and other active uses o= f nLockTime.

You cannot assume the user is around to rewrite their n= LockTime, 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:
On 8/5/2014 12:10 PM, Kaz We= sley wrote:
> Any approach based on beginning a transaction expiry countdown when a<= br> > transaction is received (as in mempool janitor) seems unviable to me:<= br> > once a node has forgotten a transaction, it must be susceptible to
> reaccepting it;

It's hard to argue with that logic.

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 also enable "fill o= r kill"
transactions with a backdated nLockTime, which must be confirmed in a
few blocks, or start vanishing from mempools.


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



--
Jeff Garzik=
Bitcoin core developer and open source evangelist
BitPay, Inc. =C2= =A0 =C2=A0 =C2=A0https://= bitpay.com/
--089e0149c57e1a38a004fff57f15--