Re: [Bitcoin-development] deterministic transaction expiration

[Mark Friedenbach <mark@monetize.io>]

On 08/06/2014 11:42 AM, Peter Todd wrote:
> On 6 August 2014 08:17:02 GMT-07:00, Christian Decker
> <decker.christian@gmail.com> wrote:
>> +1 for the new field, overloading fields with new meaning is
>> definitely not a good idea.
> 
> To add a new field the best way to do it is create a new, parallel,
> tx format where fields are committed by merkle radix tree in an
> extensible and provable way. You'd then commit to that tree with a
> mandatory OP_RETURN output in the last txout, or with a new merkle
> root.
> 
> Changing the tx format itself in a hard-fork is needlessly
> disruptive, and in this case, wastes opportunities for improvement.

I highly doubt that is the best approach.

If this nExpiry field is a consensus rule, then the Merkle tree or the
appropriate paths through needs to be included with the transaction as
part of the network and on-disk data structures, so that proper
validation can be done. This would be both more disruptive and less
efficient than simply adding an nExpiry field to the transaction format,
as we do in Freimarkets.

If the field is pre-consensus (a mempool gentleman's agreement), then it
has no business in the transaction structure at all and should be
packaged in some sort of envelope container.