From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) id 1XD1nP-0007xH-MY for bitcoin-development@lists.sourceforge.net; Fri, 01 Aug 2014 01:38:11 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.43 as permitted sender) client-ip=209.85.219.43; envelope-from=keziahw@gmail.com; helo=mail-oa0-f43.google.com; Received: from mail-oa0-f43.google.com ([209.85.219.43]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XD1nO-000790-R2 for bitcoin-development@lists.sourceforge.net; Fri, 01 Aug 2014 01:38:11 +0000 Received: by mail-oa0-f43.google.com with SMTP id i7so2645047oag.30 for ; Thu, 31 Jul 2014 18:38:05 -0700 (PDT) X-Received: by 10.182.66.130 with SMTP id f2mr2945040obt.84.1406857085392; Thu, 31 Jul 2014 18:38:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.61.195 with HTTP; Thu, 31 Jul 2014 18:37:45 -0700 (PDT) In-Reply-To: <20140801010657.GA15436@localhost.localdomain> References: <20140801010657.GA15436@localhost.localdomain> From: Kaz Wesley Date: Thu, 31 Jul 2014 18:37:45 -0700 Message-ID: To: Peter Todd Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.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 (keziahw[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -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: 1XD1nO-000790-R2 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: Fri, 01 Aug 2014 01:38:11 -0000 On Thu, Jul 31, 2014 at 6:06 PM, Peter Todd wrote: > Anything that changes the semantics of nLockTime will do harm to > existing and future applications that make use of nLockTime for things > like refund transactions. I think this would be compatible with most uses of nLockTime -- e.g., at the time a refund transaction becomes broadcastable, its beneficiary would usually have no reason to wait for a long time before broadcasting it; if they did so (probably because they weren't online to redeem the refund), they'd need to use the submit-directly-to-miner option, but they wouldn't lose their refund. > In any case, why do transactions need finite lifespans in mempools? If > you want to double-spend them with higher fees, then implement > replace-by-fee. Perpetuating transactions that have been in mempools for a long time and are not being confirmed has been cited as a reason for nodes not to exchange mempools (#3721, #1833, #3722); it's been implied that it would be desirable for wallets to wait until a transaction had had a chance to be accepted before double-spending with a higher fee (#3722); and an unconfirmed transaction-age-based policy for preventing mempool accumulation has been advocated (#3753, #3722) [I hope my summarization is not misrepresenting anyone's opinions here; please see the arguments made in the actual comments on the bugs]. These discussions are mostly fairly old, but I don't know of any changes that have been made that provide alternative answers to these concerns mentioned by at least three different developers. > In any case, lifetimes will never be deterministic as not everyone runs > the same software. That's true, but none of the benefits of these changes require the policy to be unanimous; most of the effect could be provided by most of the network following these rules. >> Transactions would stop being relayed and drop out of mempools a fixed >> number of blocks from their creation; once that window had passed, the >> sender's wallet could begin to expect the transaction would not be >> confirmed. In case a reorg displaces a transaction until after its >> expiry height, a miner can still put it back in the blockchain; the >> expiry height is just a relay rule. Also, a user who needed to get >> their original "expired" transaction confirmed could still do so by >> submitting it directly to a miner with suitable policies. > > ...in which case someone will circumvent this IsStandard() rule by > submitting "expired" transactions directly to miners with suitable > policies. Yes, that is a feature. None of the benefits of transaction expiration rely on expiration being final, and any possible downsides of expiration are largely mitigated by the option still being available to get expired transactions mined.