Understanding ScriptPubKey, Standard and Non-Standard Transactions

I've been trying to wrap my head around how ScriptPubKey connects with standard transactions, and honestly, it’s been a struggle. When I think about both terms, I see some overlap. So, ScriptPubKey is basically a script that lays out how Bitcoin can be spent. It’s like a set of rules on how you can use your Bitcoin. On the flip side, I see standard transactions as those that check all the boxes like getting confirmed and validated. There are actually quite a few attributes linked to these concepts, including: 1. P2PK 2. P2PKH 3. P2SH 4. P2MS 5. P2TR 6. P2WKH 7. P2WSH I recognize a few of these types, like P2PK, which stands for paying to a public key. Then there’s P2PKH, which is like paying to a public key hash (essentially paying to an address). P2SH refers to paying to a script hash, P2WKH is paying to a witness key hash, and P2WSH means paying to a witness script hash. On top of that, I noticed there's this term “non-standard transactions” which seems to be the opposite of standard ones. I tried looking for a clear article to break down what it means, but ended up just thinking it through myself: non-standard transactions are likely those that don’t meet the usual criteria. I’ve heard rumors that these transactions can still make their way into a block, but that confuses me since they’re labeled as non-standard. So, here are my questions: 1. Is there an actual definition for ScriptPubKey, standard transactions, and non-standard ones?

https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L70 No. When you have "scriptPubKey", then it is just a field, expressed as "const CScript& scriptPubKey", which contains raw bytes of the Script. But "IsStandard()" is a function, taking "scriptPubKey" as one of arguments, and it can return "bool" saying "true" if a transaction is standard, or "false" if it is not. https://github.com/bitcoin/bitcoin/blob/master/src/script/solver.cpp#L140 Of course. Non-standard and invalid are two different things. Non-standard transaction, which is valid: https://mempool.space/testnet4/tx/09096e1e6fb31f33f3de40b9a1d76908e565e9646e5aed4e0813e0a2a799fc4c

Non standard transaction is something that doesn't follow Bitcoin's protocol rules which are Any transaction that doesn't meet these criteria can be classified as a non-standard transaction and it was supposed to be rejected by the nodes and so the miners but not necessary, there are examples that nonstandard transactions were mined. As the name suggests it's highly rare though.

Do you write it yourself or find it elsewhere? While i don't remember all rules, i recall transaction considered as non-standard if the size is higher than 100 vKB or 400000 weight unit.

Let's see: https://en.bitcoin.it/wiki/Protocol_rules#%22tx%22_messages

NOTED With the basic knowledge I have in C++, I was able to remember some syntax here, so reading wasn't that difficult. But the last line of code Is a little bit confusing Does the NULL_DATA represents txoutput(data) with zero value entry? . This part was a little bit complex to understand, but with list of switch statements written above the code, I will assume that they were all threated in the main code. Noted. Have just bookmarked the rules for future referencing. Noted. Should probably add this to the rules also.

The term "non-standard" do not apply to transactions that have broken the Bitcoin "protocol". Those that broken the protocol have no chance to be included to a block because if ever included by a miner, the block itself will be invalid. The provided example (the quote of my post) is something that didn't comply with the majority of the nodes' "policy" instead. So the miner that included the transaction to his block still managed to add it to the blockchain since it is still valid in the protocol. The policy related to that "Uncompressed SegWit" incident is in (SCRIPT_VERIFY_WITNESS_PUBKEYTYPE): github.com/bitcoin/bitcoin/blob/5ee6b76c69d51158c13f6ad9ea1b264372e58d4d/src/policy/policy.h#L112github.com/bitcoin/bitcoin/blob/5ee6b76c69d51158c13f6ad9ea1b264372e58d4d/src/script/interpreter.h#L124-L126

https://github.com/bitcoin/bitcoin/blob/master/src/script/solver.h#L22 https://github.com/bitcoin/bitcoin/blob/master/src/script/solver.cpp#L164 This is Taproot, also known as P2TR. https://github.com/bitcoin/bitcoin/blob/master/src/script/solver.cpp#L196 And this is bare multisig, also known as P2MS.

A non-standard transaction is a valid transaction that we prefer not to have included in a block. It can have different reasons as well. For example it is perfectly valid to create a P2WPKH output using an uncompressed public key but it is considered non-standard and rejected. The reason is because uncompressed pubkeys are bigger and using them would be inefficient usage of block space. So they are "discouraged" by being counted as non-standard. They weren't made invalid because after all an uncompressed public key is still a valid public key. Another example would be the limits on OP_RETURN size which is to prevent abuse so that people don't turn bitcoin blockchain into cloud storage. So the size of such outputs are limited to 80 bytes. Another example is limits on other fields such as transaction version (ver >3 or <1 are non-standard) that is to preserve them for possible future usage. It is easier to just add the (if ver == x) line in the code if there has never been any tx version = x than it is to add exception cases that skip the previous txs with version = x.

The scriptpubkey field contains what you might consider to be a scripting language, and the opcodes that are inside take one parameter, the "stack", which is either in the scriptsig or in the witness data depending on whether the transaction format is segwit or legacy. The stack has a bunch of values on it which the code in the scriptpubkey "pops" (in stack nomenclature, removing the top value) and it can also "push" (add values to the top) its own data to it. The purpose of the scriptpubkey is to keep the bitcoins in place until someone unlocks them by putting a stack that makes the script return a "1" (just a single 1 on the stack) inside a transaction - along with the UTXO being spent, of course. If it returns anything else then it is considered a failure and the transaction is invalid.

The choice of not including a non-standard transaction in the block, was it a general community agreement?. Because I read an article which am not too sure of the authenticity, that says : Non-standard transactions are submitted to a miner directly rather than dropping them in the mempool waiting for approval. The article specified that this transactions are hard to get approval especially when they are seated at the mempool. I am not really sure of how certain transactions are given to miners directly because it sounds strange to me.  Please clarify me on this, so I don't learn something wrong. Noted So, for more clarity, does this mean that the ScriptPubKey acts as a locking script, while the other two (ScriptSig and ScriptWitness) act as unlocking scripts for SegWit and Legacy individually?.

When you want to spend coins, you create a transaction then broadcast it to the network by sending it to a handful other full nodes. The Bitcoin Network is a web of these interconnected nodes. Your transaction would propagate throughout the network as each node relays it to other nodes, eventually reaching majority of node including the nodes used by miners. Then the miner can select some of transactions from its own node and mine the block, hence confirming your tx. Each full node has its own mempool that stores the valid transactions they receive. They criteria to enter their mempool is consensus rules and they can also choose to enforce standard rules. Since the majority of full nodes are running bitcoin core, majority of the network is enforcing all standard rules by default. This means when you broadcast a non-standard transaction, majority of full nodes reject it so it won't propagate and the chances of it reaching a miner is small. This is why the only way to get your non-standard tx confirmed is to first find a miner that accepts non-standard transactions (miners run the same software and usually reject such txs as well) and then directly send your tx to their node.