From: Rusty Russell <rusty@rustcorp.com.au>
To: Gavin Andresen <gavinandresen@gmail.com>,
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CABsx9T0Evf3B_NtmdKxc_M1xRQh-jSC4JzTHCx8Ez9RzCypvMg@mail.gmail.com>
References: <CABsx9T0Evf3B_NtmdKxc_M1xRQh-jSC4JzTHCx8Ez9RzCypvMg@mail.gmail.com>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1
	(x86_64-pc-linux-gnu)
Date: Sat, 31 Oct 2015 14:13:13 +1030
Message-ID: <8737wrwvn2.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [bitcoin-dev] Compatibility requirements for hard or soft forks
Precedence: list

Gavin Andresen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:
> Should it be a requirement that ANY one-megabyte transaction that is valid
> under the existing rules also be valid under new rules?
>
> Pro:  There could be expensive-to-validate transactions created and given a
> lockTime in the future stored somewhere safe. Their owners may have no
> other way of spending the funds (they might have thrown away the private
> keys), and changing validation rules to be more strict so that those
> transactions are invalid would be an unacceptable confiscation of funds.

Not just lockTime; potentially any tx locked away in a safe.

Consider low-S enforcement: high chance a non-expert user will be unable
to spend an old transaction.  They need to compromise their privacy
and/or spend time and money.  A milder "confiscation" but a more likely
one.

By that benchmark, we should aim for "reasonable certainty".  A
transaction which would never have been generated by any known software
is the minimum bar.  Adding "...which would have to be deliberately
stupid with many redundant OP_CHECKSIG etc" surpasses it.  The only extra
safeguard I can think of is clear, widespread notification of the
change.

Cheers,
Rusty.