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 > <[email protected]> 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 _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
