Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

[Anthony Towns <aj@erisian.com.au>]

On Wed, Oct 07, 2015 at 08:46:08AM -0700, Jonathan Toomim (Toomim Bros) via bitcoin-dev wrote:
> On Oct 7, 2015, at 8:00 AM, Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > *But* a soft fork that only forbids transactions that would previously
> > not have been mined anyway should be the best of both worlds, ...
> I agree with pretty much everything you wrote except the above paragraph.
> An attacker can create a transaction that [...] A miner on the old version 
> includes this transaction into a block, [...]

The point of that case is that there aren't such miners, so that exploit
doesn't apply.

In particular, AIUI, you'll have a hard job right now finding someone to
mine an OP_NOP2 transaction -- eligius might do it, but I don't think many
others will. And you also need your currently OP_NOP2-friendly miner not
to upgrade to an OP_CLTV-validating codebase, so I don't think eligius
will qualify there.

> Those of you who know Script better than me: would this be an example of a transaction that would be spendable with a valid sig XOR with (far future date OR old code)?
> 
> OP_DUP OP_HASH160 <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIGVERIFY OP_PUSHDATA <locktime far in the future> OP_CLTV

If you want XOR, you'd need something more like:

 OP_IF OP_DUP OP_HASH160 <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIGVERIFY
 OP_ELSE <locktime> OP_CLTV
 OP_ENDIF

But that' still fail IsStandard and DISCOURAGE_UPGRADABLE_NOPS checks
if you tried spending without a valid sig, so wouldn't be mined by
current nodes. (Not having a sig would also allow anyone to spend it to
themselves, so that might make it hard to use as a basis for double
spends anyway...)

Cheers,
aj