📅 Original date posted:2015-10-07
📝 Original message: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 at 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
Anthony Towns [ARCHIVE] /
npub17r…x9l2h
2023-06-07 17:42:05
in reply to nevent1q…nvmu
Author Public Key
npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hSeen on
wss://relay.nostr.bandPublished at
2023-06-07 17:42:05Event JSON
{
"id": "200900ff091eb0678cdee71c426c37ce7ab4fc13ac4eb3d6539fe81616a66adc",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686159725,
"kind": 1,
"tags": [
[
"e",
"7ff2050ebdfe33f92ad46edcffb5d61f26a94f61437237faeeaedfedde460e1c",
"",
"root"
],
[
"e",
"95bf311a8ff86bd786871ffffeace2a4759ae549506e3cfa7f6a5d7434002ec4",
"",
"reply"
],
[
"p",
"a6981f8714148d6f156b6e22a79aee044f45e2e8190257dc829f4a1970e4bccf"
]
],
"content": "📅 Original date posted:2015-10-07\n📝 Original message:On Wed, Oct 07, 2015 at 08:46:08AM -0700, Jonathan Toomim (Toomim Bros) via bitcoin-dev wrote:\n\u003e On Oct 7, 2015, at 8:00 AM, Anthony Towns via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e *But* a soft fork that only forbids transactions that would previously\n\u003e \u003e not have been mined anyway should be the best of both worlds, ...\n\u003e I agree with pretty much everything you wrote except the above paragraph.\n\u003e An attacker can create a transaction that [...] A miner on the old version \n\u003e includes this transaction into a block, [...]\n\nThe point of that case is that there aren't such miners, so that exploit\ndoesn't apply.\n\nIn particular, AIUI, you'll have a hard job right now finding someone to\nmine an OP_NOP2 transaction -- eligius might do it, but I don't think many\nothers will. And you also need your currently OP_NOP2-friendly miner not\nto upgrade to an OP_CLTV-validating codebase, so I don't think eligius\nwill qualify there.\n\n\u003e 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)?\n\u003e \n\u003e OP_DUP OP_HASH160 \u003cpubkeyhash\u003e OP_EQUALVERIFY OP_CHECKSIGVERIFY OP_PUSHDATA \u003clocktime far in the future\u003e OP_CLTV\n\nIf you want XOR, you'd need something more like:\n\n OP_IF OP_DUP OP_HASH160 \u003cpubkeyhash\u003e OP_EQUALVERIFY OP_CHECKSIGVERIFY\n OP_ELSE \u003clocktime\u003e OP_CLTV\n OP_ENDIF\n\nBut that' still fail IsStandard and DISCOURAGE_UPGRADABLE_NOPS checks\nif you tried spending without a valid sig, so wouldn't be mined by\ncurrent nodes. (Not having a sig would also allow anyone to spend it to\nthemselves, so that might make it hard to use as a basis for double\nspends anyway...)\n\nCheers,\naj",
"sig": "2bf019cd0a3de6e94733a650a93b4a5635d079a4314cf06156aa8bd60c3576748cf0ad019ed1367941cc02a34144049d3eb5365fac4ac6ade6a8a8fe47d9d453"
}