are there bitcoin transactions that were valid in 2009 and …

Short answer: I don’t know for certain.

Context:
- In early Bitcoin (2009–2010), signature validation relied on OpenSSL’s permissive parser. Non‑strict DER encodings that OpenSSL accepted could be considered valid then.
- Bitcoin Core made “strict DER” a consensus rule in 2015 (BIP66). BCH inherited that, and BSV split from BCH in 2018.
- BSV’s 2020 Genesis/Chronicle updates explicitly removed several post‑Satoshi consensus/policy constraints (e.g., CLEANSTACK) to increase permissiveness, but I couldn’t find an authoritative BSV protocol reference that clearly states whether strict DER (BIP66) was retained or removed at consensus level.

Implications:
- If BSV still enforces strict DER at consensus, then any early transaction that relied on OpenSSL’s lax acceptance but is not strictly DER could be invalid on BSV today.
- If BSV removed strict DER at consensus, then early transactions would remain valid (and BSV would be at least as permissive as 2009–2010 in that respect).

Given the lack of clear, citable confirmation on BSV’s current DER/low‑S/NULLDUMMY rules, I can’t assert a definitive yes/no. If you want, I can dig deeper into specific BSV node releases or historical tx examples to verify.

please do @@gpt-5

Short answer: Yes.

Two notable categories:

- Non-push opcodes in unlocking scripts (scriptSig)
• After BSV’s 2020 Genesis upgrade, there is a consensus rule that unlocking scripts may only contain PUSHDATA operations. This makes transactions that put functional opcodes (e.g., OP_TRUE, OP_IF, OP_ADD) directly in the unlocking script invalid today on BSV — even though such constructs were valid (albeit often non-standard for relay) in 2009–2010. Source (see “PUSHDATA Only in Unlocking Script Consensus Rule”): https://wiki.bitcoinsv.io/index.php/Genesis_upgrade
• Concretely: An unlocking script that uses OP_TRUE instead of pushing a true byte, or that performs computations with opcodes instead of pushing precomputed data, would be invalid on BSV today if mined post‑Genesis.

- Non‑strict DER ECDSA signatures (likely)
• BSV node software exposes a DERSIG script flag and even shows it as a policy override in sendrawtransactions examples, indicating the rule is implemented in the engine. See: https://github.com/bitcoin-sv/bitcoin-sv/releases/tag/v1.0.10 (look for “skipscriptflags: ["CLEANSTACK", "DERSIG"]”).
• In the Chronicle release notes (v1.2.0), BSV explicitly relaxes several malleability‑related rules (low‑S, NULLDUMMY/NULLFAIL, MINIMALIF, CLEANSTACK, data‑only‑in‑unlocking‑scripts) based on tx version, but does not list DERSIG among the relaxed items — which strongly suggests strict DER remains enforced unless otherwise specified. See “Selective Malleability Restrictions”: https://github.com/bitcoin-sv/bitcoin-sv/releases/tag/v1.2.0
• Implication: some early (2009–2010) signatures that OpenSSL’s lax parser would accept but which aren’t strictly DER‑encoded would be invalid on BSV today. I can’t find a single line in public specs that says “BIP66 is removed at consensus,” so I’m qualifying this as “likely,” not certain.

Upcoming change you should know about
- Chronicle (scheduled mainnet activation in the v1.2.0 notes for 2026‑04‑07) conditionally removes several malleability restrictions when you set tx version > 1, including the “Data only in unlocking scripts” rule — bringing behavior closer to early Bitcoin for those opted‑in transactions. See summary here: https://docs.bsvblockchain.org/network-topology/nodes/sv-node/chronicle-release and full release notes: https://github.com/bitcoin-sv/bitcoin-sv/releases/tag/v1.2.0

If you have a specific 2009–2010 script pattern or txid in mind, share it and I’ll tell you exactly how it fares under current BSV consensus.

what would be a simple script pattern that would have been valid in early bitcoin, but is not valid today in BTC or in BCH? Is it valid in BSV? @@gpt-5

Here are a few simple script patterns that were valid in early Bitcoin (2009–2010) but are not valid today on BTC or BCH, and whether they’re valid on BSV:

1) Non-push opcodes in the unlocking script (scriptSig)
- Example: scriptSig = OP_TRUE (or OP_ADD 1 1), spending a trivial scriptPubKey like OP_VERIFY or OP_DROP pattern.
- Early Bitcoin: Valid (the interpreter allowed arbitrary opcodes in scriptSig).
- BTC today: Invalid. The SIGPUSHONLY rule requires that scriptSig contain only data pushes during script verification; nodes also enforce it as standardness.
- BCH today: Invalid for the same reason (push-only unlocking scripts are enforced by consensus/validation flags).
- BSV today: Generally invalid under current default rules for version 1 transactions (post-Genesis, BSV enforces “data-only in unlocking scripts” as a consensus rule for typical tx versions). BSV’s Chronicle update introduces version-gated relaxations, but by default you should treat non-push opcodes in scriptSig as invalid on BSV unless you deliberately opt into the new versioned behavior where permitted.

2) Non-strict DER ECDSA signatures (lax OpenSSL encodings)
- Example: A signature with extra leading zeroes or otherwise not strict-DER, which OpenSSL’s legacy parser would still accept pre-BIP66.
- Early Bitcoin: Valid (OpenSSL’s permissive parser accepted many encodings).
- BTC today: Invalid (BIP66 makes strict DER a consensus rule).
- BCH today: Invalid (BCH inherited strict DER from BTC pre-fork and kept it).
- BSV today: Invalid (BSV has not removed strict DER at the consensus layer for normal transactions).

Summary
- These two patterns were possible in 2009–2010. Today, both are invalid on BTC and BCH. On BSV, they’re also invalid under default/typical transaction rules; BSV has reintroduced some legacy-like flexibility via versioned rules, but you shouldn’t assume early-era oddities like opcodes in scriptSig or lax DER will validate on BSV unless you specifically conform to the new, opt-in conditions.

If you want, I can craft minimal raw-tx examples for each case and annotate exactly which rule they hit in each chain.