InvalidChainFound?

Weil ich es gerade zufällig im debug.log meiner Bitcoin Core Node sehe:

2023-04-01T07:29:52Z UpdateTip: new best=00000000000000000001244128897a9f32c24ca0e7ee578063f8580deed9ccb7 height=783425 version=0x20800000 log2_work=94.093200 tx=819475866 date='2023-04-01T07:29:18Z' progress=1.000000 cache=96.0MiB(670142txo)
2023-04-01T07:31:37Z Socks5() connect to <zensiert>.onion:8333 failed: host unreachable
2023-04-01T07:33:17Z ERROR: ConnectBlock(): too many sigops
2023-04-01T07:33:17Z InvalidChainFound: invalid block=00000000000000000002ec935e245f8ae70fc68cc828f05bf4cfa002668599e4  height=783426  log2_work=94.093214  date=2023-04-01T07:32:51Z
2023-04-01T07:33:17Z InvalidChainFound:  current best=00000000000000000001244128897a9f32c24ca0e7ee578063f8580deed9ccb7  height=783425  log2_work=94.093200  date=2023-04-01T07:29:18Z
2023-04-01T07:33:17Z ERROR: ConnectTip: ConnectBlock 00000000000000000002ec935e245f8ae70fc68cc828f05bf4cfa002668599e4 failed, bad-blk-sigops
2023-04-01T07:33:17Z InvalidChainFound: invalid block=00000000000000000002ec935e245f8ae70fc68cc828f05bf4cfa002668599e4  height=783426  log2_work=94.093214  date=2023-04-01T07:32:51Z
2023-04-01T07:33:17Z InvalidChainFound:  current best=00000000000000000001244128897a9f32c24ca0e7ee578063f8580deed9ccb7  height=783425  log2_work=94.093200  date=2023-04-01T07:29:18Z
2023-04-01T07:35:21Z UpdateTip: new best=00000000000000000004e0ec4f27bd3347381e8e19ed98d7f918e8c1c292ae97 height=783426 version=0x21386000 log2_work=94.093214 tx=819477925 date='2023-04-01T07:34:57Z' progress=1.000000 cache=97.1MiB(677880txo)

Schräge Sache das ist! Insbesondere irritiert mich die Zeile mit ERROR: ConnectBlock(): too many sigops, das kann ja eigentlich keine ehrliche oder aktuellere Node so weitergeleitet haben, wenn Konsensregeln bzgl. Anzahl von Sigops mißachtet worden sind. Oder ist das ein Anzeichen für einen aktuellen Bug im Core bitcoind?

2 „Gefällt mir“

Hab ich bei mir auch. Ist auch auf fork.observer sichtbar.

Wäre interessant zu wissen welcher Miner da jetzt seine Belohnung versenkt hat. Aktuell ist das Sigop Limit bei 80 000. Die unterschiedlichen Opcodes die Signaturen verifizieren zählen zu diesem Limit auch mit unterschiedlicher Gewichtung – je nach Kontext im Script. In P2TR Outputs werden Sigops z.B. gar nicht gezählt.

Keine Ahnung ob das relevant ist. Aber das ist evtl. eine potenzielle Fehlerquelle auf Seite der Miner beim Block bauen.

Gibs doch zu: Die Bitcoin Core Logs zu lesen ist fester Bestandteil deiner Morning-Routine… :smiley:

3 „Gefällt mir“

Allerdings, teurer Bug in der Candidate-Block-Assembly! Ich bin erstaunt, daß sowas vorkommt.

Mich wundert aber auch, daß solche fehlerhaften Blöcke überhaupt propagiert werden. Mein Kenntnisstand ist, daß eine Node einen empfangenen Block prüft, bevor dieser in die Kopie der Blockchain wandert und weiter an die Node-Peers verbreitet wird. Wieso erhalten meine laufenden Bitcoin-Nodes so einen fehlerhaften Block überhaupt. Ich hab’ bei meinem RaspiBlitz mit Core 24.0.1 nachgesehen, der diese auch im debug.log hatte, während auf meinem Ubuntu-Desktop noch ein Core 23.0.0 läuft, wo ich ein Fenster mit dem debug.log offen im Hintergrund habe, wo bestimmte mich interessierende Keywords farblich hervorgehoben werden.

Verdammt, ertappt. Naja, von der Morgen-Zeitung kriegt man ja meist nur schlechte Laune beim Lesen…

2 „Gefällt mir“

Habe ich mich auch schon gefragt.

Der Block Header verteilt sich anfangs sowieso schnell und zuerst im Netzwerk. Und der war bei diesem Block schließlich gültig. Wenn eine Node einen gültigen Header bekommt will sie mehr über diesen Block wissen, sofern sie ihn bisher noch nicht kannte. Dass der Block Schrott ist stellt sich dann sozusagen erst später heraus.

Dazu kommt dass mittlerweile nicht mal der komplette Block verteilt wird, sondern erstmal nur die nötigsten Informationen um den Block selbst mit dem lokalen Mempool zu rekonstruieren. Siehe BIP-152 Compact Block Relay. Da kann es schon mal passieren dass so ein ungültiger Block wie hier die Runde macht.

Aber keine Ahnung ob das so korrekt ist. Kenne mich mit den exakten Abläufen bei der Block Propagation nicht aus.

Das wäre aber mal was für eine Frage auf BSE.

2 „Gefällt mir“

Ah, interessante Stichworte von dir und ein Hinweis, mich mal bei Gelegenheit mit den Details der Informationsverteilung im Bitcoin-Netzwerk zu beschäftigen. Das war mir nicht im Detail geläufig, daß z.B. nur die kleinen Block Header anfangs verteilt werden, bevor man die dicken Blöcke nachschiebt.

Ich kenne „BSE“ nur in einem weniger appetitlichen Kontext (Bovine…). Wofür steht deine Abkürzung?

Bitcoin Stack Exchange

Ich kann Murch auch mal direkt diesen Thread hier schicken, vielleicht will er ja ausnahmsweise mal was in deutsch beantworten xD

3 „Gefällt mir“

Aufgrund der Zieladresse der Coinbase-Transaktion sollte es der F2Pool gewesen sein:

$ ./bitcoin-cli getrawtransaction eb6e6080a351e20f840741b56b1d92f920d19a1bb1dc10970dfa6e0fdc032dea true 00000000000000000002ec935e245f8ae70fc68cc828f05bf4cfa002668599e4
{
  "in_active_chain": false,
  "txid": "eb6e6080a351e20f840741b56b1d92f920d19a1bb1dc10970dfa6e0fdc032dea",
  "hash": "d44c787805d9ec5f06540d89f6945e281bf50f2df4b6664237e0292b7e7f96e7",
  "version": 1,
  "size": 424,
  "vsize": 397,
  "weight": 1588,
  "locktime": 1049682829,
  "vin": [
    {
      "coinbase": "0342f40b2cfabe6d6d76eebeccd7ca22e72d1f7c18b9a3ae8c3f93c04072e77b94dfcf0f0dd560be4410000000f09f909f092f4632506f6f6c2f66000000000000000000000000000000000000000000000000000000000000000000000005007c000000",
      "txinwitness": [
        "0000000000000000000000000000000000000000000000000000000000000000"
      ],
      "sequence": 0
    }
  ],
  "vout": [
    {
      "value": 6.50925715,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 c825a1ecf2a6830c4401620c3a16f1995057c2ab OP_EQUALVERIFY OP_CHECKSIG",
        "desc": "addr(1KFHE7w8BhaENAswwryaoccDb6qcT6DbYY)#flw9lhul",
        "hex": "76a914c825a1ecf2a6830c4401620c3a16f1995057c2ab88ac",
        "address": "1KFHE7w8BhaENAswwryaoccDb6qcT6DbYY",
        "type": "pubkeyhash"
      }
    },
    {
      "value": 0.00000000,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_RETURN aa21a9edf8b71f0213d7b0bc1cefcfe26f15f0faeb470790cdf2fa733e372e2ac86dbd9b",
        "desc": "raw(6a24aa21a9edf8b71f0213d7b0bc1cefcfe26f15f0faeb470790cdf2fa733e372e2ac86dbd9b)#mxdkcvex",
        "hex": "6a24aa21a9edf8b71f0213d7b0bc1cefcfe26f15f0faeb470790cdf2fa733e372e2ac86dbd9b",
        "type": "nulldata"
      }
    },
    {
      "value": 0.00000000,
      "n": 2,
      "scriptPubKey": {
        "asm": "OP_RETURN 434f524501bc0fbef688bca8f9ec86c688cdfbe6e0fe6086e9bdb2a04b4ccf74792cc6753c27c5fd5f1d6458bf",
        "desc": "raw(6a2d434f524501bc0fbef688bca8f9ec86c688cdfbe6e0fe6086e9bdb2a04b4ccf74792cc6753c27c5fd5f1d6458bf)#ckn567kp",
        "hex": "6a2d434f524501bc0fbef688bca8f9ec86c688cdfbe6e0fe6086e9bdb2a04b4ccf74792cc6753c27c5fd5f1d6458bf",
        "type": "nulldata"
      }
    },
    {
      "value": 0.00000000,
      "n": 3,
      "scriptPubKey": {
        "asm": "OP_RETURN 48617468541f47c104f1690e5ff047144796590532263943499eb325769b2b4abe54e4a2",
        "desc": "raw(6a2448617468541f47c104f1690e5ff047144796590532263943499eb325769b2b4abe54e4a2)#9a9g966l",
        "hex": "6a2448617468541f47c104f1690e5ff047144796590532263943499eb325769b2b4abe54e4a2",
        "type": "nulldata"
      }
    },
    {
      "value": 0.00000000,
      "n": 4,
      "scriptPubKey": {
        "asm": "OP_RETURN 52534b424c4f434b3a8faeec671a86c6204caaab8ee63d185f62fa271a6ca971fd84e9851e004f05e5",
        "desc": "raw(6a4c2952534b424c4f434b3a8faeec671a86c6204caaab8ee63d185f62fa271a6ca971fd84e9851e004f05e5)#cy0daxqf",
        "hex": "6a4c2952534b424c4f434b3a8faeec671a86c6204caaab8ee63d185f62fa271a6ca971fd84e9851e004f05e5",
        "type": "nulldata"
      }
    }
  ],
  "hex": "010000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff640342f40b2cfabe6d6d76eebeccd7ca22e72d1f7c18b9a3ae8c3f93c04072e77b94dfcf0f0dd560be4410000000f09f909f092f4632506f6f6c2f66000000000000000000000000000000000000000000000000000000000000000000000005007c00000000000000059356cc26000000001976a914c825a1ecf2a6830c4401620c3a16f1995057c2ab88ac0000000000000000266a24aa21a9edf8b71f0213d7b0bc1cefcfe26f15f0faeb470790cdf2fa733e372e2ac86dbd9b00000000000000002f6a2d434f524501bc0fbef688bca8f9ec86c688cdfbe6e0fe6086e9bdb2a04b4ccf74792cc6753c27c5fd5f1d6458bf0000000000000000266a2448617468541f47c104f1690e5ff047144796590532263943499eb325769b2b4abe54e4a200000000000000002c6a4c2952534b424c4f434b3a8faeec671a86c6204caaab8ee63d185f62fa271a6ca971fd84e9851e004f05e5012000000000000000000000000000000000000000000000000000000000000000008de3903e",
  "blockhash": "00000000000000000002ec935e245f8ae70fc68cc828f05bf4cfa002668599e4",
  "confirmations": 0
}

Ich lese auf bitcointalk.org, daß Nodes aber den Block-Header nur dann allein verteilen sollten, wenn sie zuvor den Block vollständig als valide geprüft haben. Anscheinend soll das Verteilen von neuen Blöcken auch nicht fragmentiert erfolgen. Also Block Relaying zum Zwecke des Bekanntmachens von neuen Blöcken sollte vollständige Blockdaten herumschubsen.

So langsam werden die Details durchaus spannend.

2 „Gefällt mir“

Jo, BitMEX hat das auch auf dem Schirm: https://twitter.com/BitMEXResearch/status/1642151592609607685?s=20

Sollte also bald nähere Infos geben.

Sollte, sollte, sollte – Für einen Miner ist das Interesse groß dass ein neuer Block so schnell wie möglich im Netzwerk bekannt wird. Je mehr Zeit nach finden eines Blockes vergeht, desto größer das Risiko für einen Stale Block. Die werden also den gültigen Header raus hauen bevor sie überhaupt verifiziert haben ob ihr eigener Block gültig ist.

Siehe „Direct Header Announcement“: P2P Network — Bitcoin

Trotzdem ist das wie du schon sagst seltsam, weil meine Popel-Node hängt schließlich nicht so nah an irgendwelchen Mining Nodes. Oder vielleicht doch. Große Mining Pools werden verteilt und in hoher Anzahl im Netzwerk verteilt sein um neue Blöcke möglichst effektiv bekannt zu machen. Das bleibt also die interessante Frage.

Du hattest vorhin erwähnt dass du Core auch auf dem Desktop laufen hattest: Da wurde der ungültige Block nicht gesehen oder doch?

1 „Gefällt mir“

RaspiBlitz, Umbrel und der Core bitcoind, der bei mir als Daemon auf Ubuntu im Hintergrund mitläuft, haben den ungültigen Block gesehen.

2 „Gefällt mir“

@Cricktor Hängt wahrscheinlich tatsächlich wie oben schon vermutet mit BIP-152 zusammen:

2 „Gefällt mir“

And another one: https://twitter.com/0xb10c/status/1643871608401014785

2 „Gefällt mir“

Muss man das verstehen, was F2Pool da treibt? Offensichtlich haben die aus dem ersten Invalid Block nichts gelernt. Teurer Bug, mal eben 6,50925715+6,46874095 BTC durch die Lappen gehen zu lassen.

@Cricktor Und der Block infrage war 3 Sigops drüber… :smiley:

1 „Gefällt mir“

Knapp daneben ist auch vorbei und macht es nicht besser. Mal sehen, wie es beim zweiten Fehlschuss bei Blockhöhe 784121 war, geflickt hat F2Pool ihr SigOpsCount-Problem ja offenbar bis dahin nicht.

1 „Gefällt mir“