From: Matt Whitlock <bip@mattwhitlock•name>
To: Kaz Wesley <keziahw@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] deterministic transaction expiration
Date: Thu, 31 Jul 2014 21:38:56 -0400 [thread overview]
Message-ID: <3826251.5rGb1MfKOu@crushinator> (raw)
In-Reply-To: <CA+iPb=HkxeVPF0SynxCPgUkq4msrdfayFrVNFjzg29rFwqXv1w@mail.gmail.com>
It would make more sense to introduce a new script opcode that pushes the current block height onto the operand stack. Then you could implement arbitrary logic about which blocks the transaction can be valid in. This would require that the client revalidate all transactions in its mempool (really, only those making use of this opcode) whenever the chain tip changes.
On Thursday, 31 July 2014, at 5:58 pm, Kaz Wesley wrote:
> There is currently little in place for managing transaction lifetime
> in the network's mempools (see discussion in github in #3722 "mempool
> transaction expiration", and it seems to be a major factor blocking
> some mempool exchange, see #1833/1918, #3721). Expiry per-node a
> certain amount of wall time after receipt has been proposed, but
> that's a fragile mechanism -- a single node could keep all relayable
> transactions alive forever by remembering transactions until most
> nodes have dropped them and then releasing them back into the wild.
>
> I have a proposal for a way to add finite and predictable lifespans to
> transactions in mempools: we d̶e̶s̶t̶r̶o̶y̶ ̶t̶h̶e̶
> ̶r̶e̶s̶u̶r̶r̶e̶c̶t̶i̶o̶n̶ ̶h̶u̶b̶ use nLockTime and a new standardness
> rule. It could be done in stages, would not necessarily require even a
> soft fork, and does not cause problems with reorgs like the proposal
> in #3509:
> 1. start setting nLockTime to the current height by default in newly
> created transactions (or slightly below the current height, for
> reorg-friendliness)
> 2. once users have had some time to upgrade to clients that set
> nLockTime, start discouraging transactions without nLockTime --
> possibly with a slightly higher fee required for relay
> 3. start rate-limiting relay of transactions without an nLockTime
> (maybe this alone could be used to achieve [2])
> 4. add a new IsStandard rule rejecting transactions with an nLockTime
> more than N blocks behind the current tip (for some fixed value N, to
> be determined)
>
> 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.
next prev parent reply other threads:[~2014-08-01 1:39 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-01 0:58 Kaz Wesley
2014-08-01 1:06 ` Peter Todd
2014-08-01 1:37 ` Kaz Wesley
2014-08-01 1:38 ` Matt Whitlock [this message]
2014-08-01 2:28 ` Gregory Maxwell
2014-08-01 3:26 ` Matt Whitlock
2014-08-01 3:31 ` Gregory Maxwell
2014-08-05 18:01 ` Alex Mizrahi
2014-08-02 0:36 ` Tom Harding
2014-08-05 17:02 ` Flavien Charlon
2014-08-05 17:48 ` Jeff Garzik
2014-08-05 18:54 ` Mike Hearn
2014-08-05 19:08 ` Jeff Garzik
2014-08-05 19:10 ` Kaz Wesley
2014-08-05 19:36 ` Jeff Garzik
2014-08-06 4:01 ` Tom Harding
2014-08-06 12:55 ` Jeff Garzik
2014-08-06 13:54 ` Mike Hearn
2014-08-06 14:44 ` Tom Harding
2014-08-06 15:08 ` Jeff Garzik
2014-08-06 15:17 ` Christian Decker
2014-08-06 15:42 ` Peter Todd
2014-08-06 16:15 ` Jeff Garzik
2014-08-06 17:02 ` Tom Harding
2014-08-06 17:21 ` Mark Friedenbach
2014-08-06 17:34 ` Peter Todd
2014-08-06 17:24 ` Jeff Garzik
2014-08-06 16:31 ` Mark Friedenbach
2014-08-06 17:20 ` Peter Todd
2014-08-06 17:30 ` Mark Friedenbach
2014-08-06 17:38 ` Peter Todd
2014-08-08 17:38 ` Tom Harding
2014-08-08 18:13 ` Jeff Garzik
2014-08-08 18:42 ` Kaz Wesley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3826251.5rGb1MfKOu@crushinator \
--to=bip@mattwhitlock$(echo .)name \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=keziahw@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox