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 1XF2SB-0006ZC-2a for bitcoin-development@lists.sourceforge.net; Wed, 06 Aug 2014 14:44:35 +0000 X-ACL-Warn: Received: from mail-pa0-f41.google.com ([209.85.220.41]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XF2S9-0001RN-96 for bitcoin-development@lists.sourceforge.net; Wed, 06 Aug 2014 14:44:35 +0000 Received: by mail-pa0-f41.google.com with SMTP id rd3so3580888pab.0 for ; Wed, 06 Aug 2014 07:44:27 -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 :cc:subject:references:in-reply-to:content-type; bh=A4lYVC1tQJO5riZHRGtCavWuZGAL5GXbzl6pQ2IrKOk=; b=lVmeUzpKhJtuMPtnQJjrDtGfwUjdMvPMIEgZR5FTuEURWPBjfu4Tuichm3vdYaw/os /L2ZmPoIdHpbjoVxFj8L2sYGYVwaCYU2tH7VtHVU9pOpTXFi7mh/Yqc4pnyINmPvL8EL mlz7KaJIDpY4QB8Vs/RIvCiS62ngzGMLNcyO8b3Jt5Ge0RNMp1Myuc/NpE4kmG2ZCicZ yi2H1Z/Ps4JCMdt3NSe55NgUcRO8jkP0UAB36SNh1VLe6GklN8pjzbWx+f3hDf80dN7A UqROpOhMN9htdQ7jWq2IU1bwwV/BsdPRW1K98WBHU2qIFSydSDrejrDvF7V25QrSDTdK 3/oA== X-Gm-Message-State: ALoCoQmt7/YXcvWhx3IwLnBItflIqX/1lxeAWt0403tdlTXCrBEVJTx1xIDy+YUf2x4LR+Y4mKQm X-Received: by 10.66.142.42 with SMTP id rt10mr11836561pab.1.1407336267077; Wed, 06 Aug 2014 07:44:27 -0700 (PDT) Received: from [192.168.1.89] (99-6-44-248.lightspeed.sntcca.sbcglobal.net. [99.6.44.248]) by mx.google.com with ESMTPSA id xq3sm4359031pab.0.2014.08.06.07.44.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 07:44:26 -0700 (PDT) Message-ID: <53E23F49.3020605@thinlink.com> Date: Wed, 06 Aug 2014 07:44:25 -0700 From: Tom Harding User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jeff Garzik , Mike Hearn References: <53E1A8AF.4030206@thinlink.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030804050901060002040904" X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1XF2S9-0001RN-96 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 14:44:35 -0000 This is a multi-part message in MIME format. --------------030804050901060002040904 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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. > --------------030804050901060002040904 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
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.

--------------030804050901060002040904--