From: Matt Whitlock <bip@mattwhitlock.name>
To: Gregory Maxwell <gmaxwell@gmail.com>
Date: Thu, 31 Jul 2014 23:26:20 -0400
Message-ID: <1515086.GQImTWpAiA@crushinator>
User-Agent: KMail/4.13.3 (Linux/3.12.21-gentoo-r1; KDE/4.13.3; x86_64; ; )
In-Reply-To: <CAAS2fgQPVwMzHBWmbRLBHZcm+YEbioqUHoL_a-SLr9yWDmguiw@mail.gmail.com>
References: <CA+iPb=HkxeVPF0SynxCPgUkq4msrdfayFrVNFjzg29rFwqXv1w@mail.gmail.com>
	<3826251.5rGb1MfKOu@crushinator>
	<CAAS2fgQPVwMzHBWmbRLBHZcm+YEbioqUHoL_a-SLr9yWDmguiw@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] deterministic transaction expiration
Precedence: list

On Thursday, 31 July 2014, at 7:28 pm, Gregory Maxwell wrote:
> On Thu, Jul 31, 2014 at 6:38 PM, Matt Whitlock <bip@mattwhitlock.name> wrote:
> > 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.
> 
> Transactions that become invalid later are have pretty severe
> consequences because they might mean that completely in an absence of
> fraud transactions are forever precluded due to a otherwise harmless
> reorg.

I understand what you're saying, but I don't understand why it's a problem. Transactions shouldn't be considered "final" until a reasonable number of confirmations anyway, so the possibility that an "accepted" transaction could become invalid due to a chain reorganization is not a new danger. Ordinary transactions can similarly become invalid due to chain reorganizations, due to inputs already having been spent in the new branch.