Spezifische Instanz von Tx, die einen fehlerhaften Null-Byte-Vektor für P2SH verwendet; Einsicht erf

Aus Biteasys API für TXID fccf964964c34994e5dbbb9ff7f914159b524b0831f6eea12255aa424b39090e können wir die folgenden Informationen zu Eingaben (für einen P2SH-Tx) sehen:

"script_sig_string": "[] [3044022016c09f09b6c55....]
"script_sig": "ff473044022016c09f09b6c55....

Ich weiß, dass ein Null-Byte-Vektor (OP_0) für den Off-by-1-Fehler für Multisig-Txs erforderlich ist. Aber es ist das rohe Hex, in dem ffdas OP_0 (leeres Array) dargestellt wird, das mich verwirrt. Wird dies als Zweierkomplement von 0x00 gelesen oder liest es sich OP_INVALIDOPCODEwie auf der Bitcoin-Wiki-Skriptseite (unten zitiert) beschrieben?

OP_PUBKEYHASH      253  0xfd    Represents a public key hashed with OP_HASH160.
OP_PUBKEY          254  0xfe    Represents a public key compatible with OP_CHECKSIG.
OP_INVALIDOPCODE   255  0xff    Matches any opcode that is not yet assigned.

Zu Ihrer Information, dieser Tx verursachte vor einiger Zeit Probleme mit der Kernsoftware, die die Blockchain analysierte; so viel ist mir bewusst. Allerdings muss ich online noch eine Erklärung finden (ohne Github/C++-Code, den ich nicht gut lesen kann).

Antworten (2)

Noch eine sehr interessante Frage!

Notieren Sie sich zunächst das Datum der Transaktion. Speziell:

"created_at": "2013-10-25T13:16:51.598Z"

Es stellt sich heraus, dass bis zu diesem Problem jeder Wert anstelle von OP_0 verwendet werden konnte. Um Peter Todd zu zitieren:

Während normalerweise OP_0 verwendet wird, wird der tatsächliche Wert dieses Arguments nicht überprüft und schafft somit eine Quelle der Veränderlichkeit für jede Transaktion mit CHECKMULTISIG-Eingaben.

Der Patch hier hat es tatsächlich so gemacht, dass das erste Argument einer Standard-Multisig OP_0 sein musste, um keine Transaktionsformbarkeit zu verursachen.

Angesichts der Tatsache, dass diese Transaktion stattfand, bevor dieser Commit in den Standard-Bitcoin-Client gelangte, war diese Transaktion vollkommen in Ordnung. Sie hätten buchstäblich fast jeden Wert als erstes Byte eingeben können, und es wäre durchgegangen.

Beachten Sie auch, dass dies eine Soft-Forking-Änderung war. Es ist immer noch legal, OP_INVALIDCODE anstelle von OP_0 zu setzen, es wird nur nicht vom Standard-Bitcoin-Client weitergegeben und wird daher wahrscheinlich nicht in einen Block gelangen. Andernfalls wäre dies eine Hard-Fork-Änderung gewesen.


Bearbeiten: Es sieht so aus, als ob die API von biteasy anders ist als andere Orte wie Blockchain:

Beachten Sie, dass das Skript mit beginnt 00, nicht ffwie bei biteasy.

https://blockchain.info/rawtx/fccf964964c34994e5dbbb9ff7f914159b524b0831f6eea12255aa424b39090e

{
"ver": 1,
"inputs": [
{
"sequence": 4294967295,
"prev_out": {
"spent": true,
"tx_index": 38094378,
"type": 0,
"addr": "35aHovjnZ9xdfYZsB2yBVTs6CWqnBpHNDY",
"value": 100000,
"n": 1,
"script": "a9142a9ada309638ec606f67e6b107867184c58a3aab87"
},
"script": "00473044022016c09f09b6c55c0afefa1c0f0b7fa5789b3fa486d19ba3e7f5338fc8a2701dc502203ab665792d477ffabcfb736b6d6951d238d5a8af8f9754cc29e9caab46b9b1dd01473044022016c09f09b6c55c0afefa1c0f0b7fa5789b3fa486d19ba3e7f5338fc8a2701dc502203ab665792d477ffabcfb736b6d6951d238d5a8af8f9754cc29e9caab46b9b1dd014cc9524104d9399e85461d925e4c3932cc033aee59873e1212216c81943d5634c2e45ee0f45181f69d63b236e53d286a43b2de2b0ee64850191771924430f92ac6542f3cf24104d9399e85461d925e4c3932cc033aee59873e1212216c81943d5634c2e45ee0f45181f69d63b236e53d286a43b2de2b0ee64850191771924430f92ac6542f3cf241046d38a48ed6f12b132cdf14e84d1d6678bbf0e148e1b4791ee39fa0945cecf86ecb870cd4c74a4e472b8e3034f771df0375a7c097adf2bc48ce9f2ea3e64e20dc53ae"
}
],
"block_height": 265976,
"relayed_by": "24.212.184.180",
"out": [
{
"spent": true,
"tx_index": 38095095,
"type": 0,
"addr": "1QKjwQ7tJGaWrXyftce4ns47gvZ67GoqMt",
"value": 80000,
"n": 0,
"script": "76a914ffd6391cff55413edb04761ecf1a447d80bfe74188ac"
}
],
"lock_time": 0,
"size": 435,
"double_spend": false,
"time": 1382706718,
"tx_index": 38095095,
"vin_sz": 1,
"hash": "fccf964964c34994e5dbbb9ff7f914159b524b0831f6eea12255aa424b39090e",
"vout_sz": 1
}
Ich habe das bemerkt, da es nur ein bisschen einfach ist, das OP_0 als ffeher als zu kennzeichnen00

Aber es ist das rohe Hex, wo ff das OP_0 (leeres Array) darstellt, das mich verwirrt

Ich sehe keine Probleme mit diesem TX. OK, pubkey1 == pubkey2 und es gibt einen Signatur-Push, der zweimal wiederholt wird. Aber alles ist richtig

01000000
01

9f3c95a83feaa2a84f5800ce482a50387fd8a7a142b0619a29923aab45574ca4:01000000

fd5c01 // scriptSig len
00     // push empty vector/zero value 
473044022016c09f09b6c55c0afefa1c0f0b7fa5789b3fa486d19ba3e7f5338fc8a2701dc502203ab665792d477ffabcfb736b6d6951d238d5a8af8f9754cc29e9caab46b9b1dd01
473044022016c09f09b6c55c0afefa1c0f0b7fa5789b3fa486d19ba3e7f5338fc8a2701dc502203ab665792d477ffabcfb736b6d6951d238d5a8af8f9754cc29e9caab46b9b1dd01
4cc9
  52
  4104d9399e85461d925e4c3932cc033aee59873e1212216c81943d5634c2e45ee0f45181f69d63b236e53d286a43b2de2b0ee64850191771924430f92ac6542f3cf2
  4104d9399e85461d925e4c3932cc033aee59873e1212216c81943d5634c2e45ee0f45181f69d63b236e53d286a43b2de2b0ee64850191771924430f92ac6542f3cf2
  41046d38a48ed6f12b132cdf14e84d1d6678bbf0e148e1b4791ee39fa0945cecf86ecb870cd4c74a4e472b8e3034f771df0375a7c097adf2bc48ce9f2ea3e64e20dc
  53ae
ffffffff

01
8038010000000000
1976a914ffd6391cff55413edb04761ecf1a447d80bfe74188ac
00000000
Es ist seltsam, weil ich die gleichen Daten habe, wenn ich getrawtransaction ausführe , aber der Python-Code, den ich geschrieben habe, der rohe Hex-Daten von biteasy abruft, zeigtff
vertrau mir. vertraue dir selbst. vertraue biteasy nicht
Ich höre Sie, Kumpel: Der Python-Code, den ich geschrieben habe, kennzeichnet „interessante“ Txs, was normalerweise eine nicht standardmäßige Tx-Vorlage bedeutet, aber in diesem Fall war es sowohl eine nicht standardmäßige Tx-Vorlage als auch widersprüchliche Quell-Hex-Daten. Mir ist bewusst, dass ein vollständiger Knoten (Bitcoincore txindex=1) für Txs „kanonisch“ ist, während APIs dies viel weniger sind. Ich weiß, dass Blockchain.info und Blockexplorer.com Probleme mit UTXOs-Guthaben und dergleichen hatten, war mir aber nicht bewusst, dass sich APIs in raw hex unterscheiden können , da dies impliziert, dass die Blockchain-Daten vom Konsens abweichen