Wie sieht eine doppelte Ausgabe (CVE-2018-17144) aus, wenn ich eine Transaktion erhalte?

Ich frage mich nur, wie die Ausgabe von gettransaction (oder sollte ich getblock verwenden?) aussehen würde, wenn ich ihr eine txid (oder einen Blockhash) übergeben würde, die eine Reihe von Transaktionen enthält, die den Double Spend Bug CVE-2018-17144 ausnutzen? Ist es von einer normalen, nicht doppelten Ausgabe zu unterscheiden? Muss die abgefragte Brieftasche beide Adressen kennen, an die sie ausgegeben wurde, um etwas Außergewöhnliches anzuzeigen?

Antworten (1)

Sie könnten $ getblock <blockhash> 2oder verwenden $ getrawtransaction <tx-hash> 2.

Hier ist eine Transaktion, die diesen Fehler im Testnetz ausgenutzt hat: fb7a8658ec015133e36e2cf7ddf7e8c887c3a5becec2f30f24ebfe43e72f4b59

$ bitcoin-cli -testnet getrawtransaction fb7a8658ec015133e36e2cf7ddf7e8c887c3a5becec2f30f24ebfe43e72f4b59
    {
      "txid": "fb7a8658ec015133e36e2cf7ddf7e8c887c3a5becec2f30f24ebfe43e72f4b59",
      "hash": "fb7a8658ec015133e36e2cf7ddf7e8c887c3a5becec2f30f24ebfe43e72f4b59",
      "version": 1,
      "size": 403,
      "vsize": 403,
      "weight": 1612,
      "locktime": 0,
      "vin": [
        {
          "txid": "6a08723bc717e1ddf91fa60fde25784ef66952e8687f3bffe391fc2c819dbfd9",
          "vout": 1,
          "scriptSig": {
            "asm": "3045022100e412610b2e2b8370f2eda0cf29fe19c2a4ea35191d8b42656e81bc97026b229e022046ff1df7293f8dbc3efd95b125ebf679a4a68e8de2265990ef7553f1060dc9e3[ALL] 0455fd1c1a6cbfb25b5bba1cf6f850de00d79852be3de51e50c0da683613303c533d079e147dfe07ce4d40df2b776b35184698d14fa107a61e0976b0d9416880c8",
            "hex": "483045022100e412610b2e2b8370f2eda0cf29fe19c2a4ea35191d8b42656e81bc97026b229e022046ff1df7293f8dbc3efd95b125ebf679a4a68e8de2265990ef7553f1060dc9e301410455fd1c1a6cbfb25b5bba1cf6f850de00d79852be3de51e50c0da683613303c533d079e147dfe07ce4d40df2b776b35184698d14fa107a61e0976b0d9416880c8"
          },
          "sequence": 4294967295
        },
        {
          "txid": "6a08723bc717e1ddf91fa60fde25784ef66952e8687f3bffe391fc2c819dbfd9",
          "vout": 1,
          "scriptSig": {
            "asm": "304402206fa6ef6c0727ecf8d40b2b4648a93b084396c9819d20a3300e83ac4d110589e8022060c78d44db1d5b5babd1629c55d8058643d11a14da933b4bc5f7a8a2a7da3773[ALL] 0455fd1c1a6cbfb25b5bba1cf6f850de00d79852be3de51e50c0da683613303c533d079e147dfe07ce4d40df2b776b35184698d14fa107a61e0976b0d9416880c8",
            "hex": "47304402206fa6ef6c0727ecf8d40b2b4648a93b084396c9819d20a3300e83ac4d110589e8022060c78d44db1d5b5babd1629c55d8058643d11a14da933b4bc5f7a8a2a7da377301410455fd1c1a6cbfb25b5bba1cf6f850de00d79852be3de51e50c0da683613303c533d079e147dfe07ce4d40df2b776b35184698d14fa107a61e0976b0d9416880c8"
          },
          "sequence": 4294967295
        }
      ],
      "vout": [
        {
          "value": 0.09900000,
          "n": 0,
          "scriptPubKey": {
            "asm": "OP_DUP OP_HASH160 c8b876680fef08df5278a9df92df7e30b83cbb71 OP_EQUALVERIFY OP_CHECKSIG",
            "hex": "76a914c8b876680fef08df5278a9df92df7e30b83cbb7188ac",
            "reqSigs": 1,
            "type": "pubkeyhash",
            "addresses": [
              "mypGR6pDS85nidXk3DoHZCNBuYd6WBhzgU"
            ]
          }
        }
      ],
      "hex": "0100000002d9bf9d812cfc91e3ff3b7f68e85269f64e7825de0fa61ff9dde117c73b72086a010000008b483045022100e412610b2e2b8370f2eda0cf29fe19c2a4ea35191d8b42656e81bc97026b229e022046ff1df7293f8dbc3efd95b125ebf679a4a68e8de2265990ef7553f1060dc9e301410455fd1c1a6cbfb25b5bba1cf6f850de00d79852be3de51e50c0da683613303c533d079e147dfe07ce4d40df2b776b35184698d14fa107a61e0976b0d9416880c8ffffffffd9bf9d812cfc91e3ff3b7f68e85269f64e7825de0fa61ff9dde117c73b72086a010000008a47304402206fa6ef6c0727ecf8d40b2b4648a93b084396c9819d20a3300e83ac4d110589e8022060c78d44db1d5b5babd1629c55d8058643d11a14da933b4bc5f7a8a2a7da377301410455fd1c1a6cbfb25b5bba1cf6f850de00d79852be3de51e50c0da683613303c533d079e147dfe07ce4d40df2b776b35184698d14fa107a61e0976b0d9416880c8ffffffff01e00f9700000000001976a914c8b876680fef08df5278a9df92df7e30b83cbb7188ac00000000",
      "blockhash": "00000000eba3f43a8624750f39e4520a1678c0dbdf8707bfa4854a12fbf086c5",
      "confirmations": 0,
      "time": 1537995498,
      "blocktime": 1537995498
    }

Ist es von einer normalen, nicht doppelten Ausgabe zu unterscheiden?

Sie werden feststellen, dass die Eingabe zweimal im 'vin' aufgeführt ist:

"txid": "6a08723bc717e1ddf91fa60fde25784ef66952e8687f3bffe391fc2c819dbfd9",
"vout": 1,

Das wird als doppelte Ausgabe betrachtet.

Muss die abgefragte Brieftasche beide Adressen kennen, an die sie ausgegeben wurde, um etwas Außergewöhnliches anzuzeigen?

Die Brieftasche müsste die zugehörigen Adressen überwachen, oder sie hätte diese Transaktion wahrscheinlich nicht gespeichert. Auch wenn es sich um einen vollständigen Knoten handelt, können Sie den tx nur dann per txid abrufen, wenn Sie die Blockchain mit -txindexFlag indiziert haben.

Sie sehen in diesem json, wo Sie vin.voutzweimal haben, und beide 1. Ist es immer so? Während ich müßig die Block Explorer Rich List nach einer Coin durchstöberte, habe ich ein paar alte Hodlinge, mir ist folgendes aufgefallen: chainz.cryptoid.info/funk/tx.dws?1211915.htm - ist das auch derselbe Exploit? Das txid wird immer wieder wiederholt, aber das vout ist anders als in Ihrem Beispiel
Wenn nur der vout unterschiedlich ist, handelt es sich um eine andere Ausgabe derselben Transaktion
Also muss ich die Transaktionsausgaben zurückjagen, um diejenigen mit demselben Vout zu finden?
Wenn Sie nach doppelten Ausgaben suchen, ja. Eine Transaktionsausgabe wird eindeutig durch ihre txid und vout zusammen identifiziert. Dies liegt daran, dass Transaktionen mehrere Ausgaben haben können.
Ok, also in diesem tx, das ich verlinkt habe ( chainz.cryptoid.info/funk/tx.dws?1211915.htm ), sind alle diese vout unterschiedlich, also sind sie legitimerweise unterschiedliche Eingaben für diese Transaktion. ABER wenn ich einen weiteren Schritt zurückgehe und Sehen Sie sich die Transaktion an, in der sie ausgegeben wurden ( chainz.cryptoid.info/funk/tx.dws?1211349.htm ). Diese hat Dutzende identischer txid/vout. DAS ist also die Transaktion, die den Fehler ausgenutzt hat?
Ja, es scheint so