Competency Check of Aviral Singh on Non-Standard P2SH: consensus validity vs relay policy

[Av1ralS1ngh]

View the video here: Walkthrough (updated)

This PR adds the fifteenth lesson as a competence check submission to rawBit.
The lesson explores one of the more subtle distinctions in Bitcoin: a transaction can satisfy every consensus rule and still never reach a miner, because relay policy and consensus validity are enforced independently.

The flow walks through a complete transaction lifecycle on testnet, deriving a P2PKH address from a private key, parsing the funding transaction with field extract nodes, constructing a non-standard P2SH output whose redeemScript is a simple arithmetic puzzle (OP_2 OP_ADD OP_5 OP_EQUAL), building the spending transaction, and running script verification.

VerifyScript returns true. AreInputsStandard returns false, because Solver cannot classify the redeemScript against any known template and returns NONSTANDARD.

The goal is to make that two-layer enforcement architecture visible and concrete, rather than abstract.
Every step —> the hash commitment, the scriptSig construction, the P2SH execution trace, the Bitcoin Core code path that drops the transaction, is laid out explicitly so the learner can follow the full chain of causality.

[Av1ralS1ngh]

@rawBit-io please review at your comfort.

[rawBit-io]

Thanks for the submission. The submission has several issues:

• The P2PKH address is created but the funding TX (cc13_fund_tx) is just pasted hex, no evidence it was actually broadcast to testnet3.
• TX1 (P2PKH → P2SH) is not signed and was not broadcast to the network — the task required this to be accepted by relay. Spending from P2PKH requires a signature.
• TX2 (cc49_tx2_hex) is a hand-crafted hex string in an identity node with the comment "dummy prev TXID for demo (replace with real TX1 TXID)". You didn't build the spending TX on canvas — you typed the bytes by hand with a zero TXID pointing to nothing.
• You manually type opcodes as hex (76, a9, 14, 88, ac, 52, 93, ...) in identity nodes instead of using the Opcode Sequence node.
• You don't use the TX template nodes for clear TX construction.
• The Verify Script node returns true only because you fed it your own scriptSig against your own scriptPubKey with a synthetic TX. That's not what was requested for concept demonstration.
• The whole pedagogical point — verify=true AND broadcast rejected — isn't shown. You have half the equation (a forced verify=true) and zero network evidence.

Most of what the task asks for is already demonstrated in the legacy transaction flow examples — signing, Opcode Sequence node, TX template nodes, verification. Please study those flows carefully before resubmitting.