txout 腳本標準 (scriptpubkey critieria)
將 txout 腳本納入已開採區塊的標準是什麼？有什麼標準嗎？我問的原因是它
OP_RETURN經常在 txout 腳本中使用，但它不可用：case OP_RETURN: { return set_error(serror, SCRIPT_ERR_OP_RETURN); }而且我還看到了將超過MAX_SCRIPT_ELEMENT_SIZE字節的元素推送到堆棧的事務。
我猜是一個語法不正確的腳本，例如：
05aa (ie OP_PUSHDATA(5) <aa>)不會被允許？
有人可以指出礦工用來驗證 tx 是否會被包含或丟棄為無效的程式碼（由於其 txout 腳本）。我猜它位於main.cpp中，但我想知道確切的位置，謝謝。
顯然，任何人都可以探勘一個以任何他們喜歡的方式設置的塊，但大概有固定的規則來確定它是否被認為是有效的 - 所以其他礦工在探勘時會知道是否使用它的雜湊作為他們的 prev-header-hash下一個街區？
來自實時區塊鏈的交易
ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767包含許多語法錯誤的 txout 腳本，可用作展示：使用 pybitcointools：
#!/usr/bin/env python2.7 from bitcoin import * tx_hex = fetchtx("ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767") tx_dict = deserialize(tx_hex) for (txout_num, txout) in enumerate(tx_dict["outs"]): script = txout["script"] print "raw txout %d script: %s" % (txout_num, script)輸出：
raw txout 0 script: 01 raw txout 1 script: 0201 raw txout 2 script: 4c raw txout 3 script: 4c0201 raw txout 4 script: 4d raw txout 5 script: 4dffff01 raw txout 6 script: 4e raw txout 7 script: 4effffffff01分析每個 txout 腳本：
01 = OP_PUSHDATA0(1)這失敗了，因為它聲稱它將把 1 個字節壓入堆棧，但隨後不提供任何字節壓入堆棧
0201 = OP_PUSHDATA0(2) <01>這失敗了，因為它聲稱它將把 2 個字節壓入堆棧，但隨後只提供 1 個字節壓入堆棧
4c = OP_PUSHDATA1(?)這失敗了，因為它是一個不完整的 OP_PUSHDATA1 操作碼。該
4c字節後面應該跟著另一個字節，指定要壓入堆棧的數據字節數，但事實並非如此。4c0201 = OP_PUSHDATA1(2) <01>這失敗了，因為它聲稱它將 2 個字節壓入堆棧，但隨後僅提供 1 個字節壓入堆棧。
etc有趣的是，這個特定事務中的輸出腳本每個都有不同的語法錯誤使用 OP_PUSHDATA 命令。幾乎就像有人有同樣的問題並想測試是否在 scriptpubkeys 上實施了任何語法檢查。我很高興他們這樣做了，因為這是一種非常確鑿的方式來證明在 scriptpubkeys 被使用之前絕對沒有進行語法檢查（因此也沒有其他檢查）。
絕對沒有對
scriptPubKey. 節點具有稱為 IsStandard 的軟要求，它們將作為交易中繼給對等方的內容（例如，完全垃圾腳本或非常大的 OP_RETURN 輸出不會通過），但這些不是共識規則。一些礦工會將非標準交易探勘到他們的區塊中，但通常要獲得交易給他們，需要使用 P2P 網路以外的傳輸。
OP_RETURN是一種被稱為“可證明不可花費”的特殊情況，這是對人們將雜湊和其他數據干擾到PubKeyHash輸出中作為及時將它們與區塊鏈掛鉤的一種方式的回應。由於無法知道輸出是否實際有效，這些輸出必須永久儲存在 UTXO 池中。絕對不會使用OP_RETURN帶前綴的輸出，因此節點可以安全地忘記它們曾經存在過。