Warum verwendet die standardmäßige Miner-Implementierung Pay-to-Pubkey?

Blick auf die v0.9.3-Quelle in miner.cpp:

CBlockTemplate* CreateNewBlockWithKey(CReserveKey& reservekey)
{
    CPubKey pubkey;
    if (!reservekey.GetReservedKey(pubkey))
        return NULL;

    CScript scriptPubKey = CScript() << pubkey << OP_CHECKSIG;
    return CreateNewBlock(scriptPubKey);
}

Der Standardwert scriptPubKeyist ein Pay-to-Pubkey? Muss es aus Kompatibilitätsgründen aufbewahrt werden? Ich bin nur überrascht, dass es keinen Pay-to-Pubkey-Hash verwendet.

Beim Lesen des Codes stimme ich Ihrer Einschätzung zu. Wahrscheinlich muss es aus Kompatibilitätsgründen nicht so bleiben, aber ich habe keine Ahnung, warum sie es so gemacht haben.
Ich denke, P2PK war alles, was am Anfang verwendet wurde, also verstehe ich, warum es so angefangen hat, ich frage mich nur, warum es nie geändert wurde ...
Es ist nicht möglich, ein P2PK nur aus einer Bitcoin-Adresse zu konstruieren - daher muss P2PKH am Anfang existiert haben.
Ich sage nicht, dass es nicht hätte gemacht werden können, nur dass niemand P2PKH bis später verwendet hat.
@NickODell erinnert daran, dass Bitcoin ursprünglich IP-Transaktionen und keine Adressen verwendet hat. Ich müsste es überprüfen, um absolut sicher zu sein, aber ich glaube nicht, dass Bitcoin 0.1 P2PKH enthielt.
Macht nichts - Die erste Bitcoin-Transaktion war P2PK . Ich liege falsch.

Antworten (1)

Pay-to-PubKey (P2PK) und Pay-to-PubKey-Hash (P2PKH) wurden beide in der ursprünglichen Version von Bitcoin 0.1 eingeführt. P2PK wurde standardmäßig für Mining und Zahlungen verwendet, die mit dem interaktiven IP-zu-IP-Zahlungsprotokoll empfangen wurden ; P2PKH war für die Verwendung in nicht interaktiven Zahlungen gedacht – aber P2PKH-Transaktionen nehmen mehr Platz in der Blockchain ein als P2PK.

Ist diese Platzersparnis der Grund dafür, dass Nakamoto P2PK für Mining und interaktive Zahlungen verwendet, obwohl er P2PKH zur Verfügung hatte, oder hatte er einen anderen Grund für die Verwendung unterschiedlicher Transaktionstypen? Ich denke, nur er weiß es.

In einer Situation, in der Sie die kürzeren P2PKH-Adressen nicht benötigen, wie z. B. Mining, interaktive Zahlungen oder das Bezahlen mit Ihrem eigenen Pubkey für Wechselgeld, kann die Verwendung eines P2PK die bessere Option sein, obwohl P2PKH einen Sicherheitsvorteil bietet, wenn Sie es nicht tun Adressen nicht wiederverwenden und wenn ECDSA eines Tages auf eine bestimmte Art und Weise gebrochen wird, macht das Angriffe möglich, aber langsam auszuführen.

Type   Output                Input             Total Bytes
       ScriptPubKey          ScriptSig

       push ....... 1        push  ... 1
       <key> ...... 33       <sig> ... ~72
P2PK   checksig ... 1
       --------------        -------------
       Total ...... 35       Total ... ~73     ~108

       dup ........ 1        push .... 1
       hash160 .... 1        <sig> ... ~72
       push ....... 1        push .... 1
P2PKH  <hash> ..... 20       <key> ... 33
       equal ...... 1
       checksig ... 1
       --------------        --------------
       Total ...... 25       Total ... ~107   ~132

Die obigen Zahlen gehen davon aus, dass Sie einen komprimierten öffentlichen Schlüssel verwenden, der heute weit verbreitet ist, aber erst mit Bitcoin Core 0.6.0 implementiert wurde . Wenn Sie die älteren "unkomprimierten" öffentlichen Schlüssel berücksichtigen möchten, addieren Sie 32 Bytes zu den <key>Bytegrößen hinzu. Außerdem ignorieren wir alle konstanten Faktoren beim Erstellen einer Ausgabe oder Eingabe und berücksichtigen nur die Anzahl der Bytes im Skript.

Mir sind keine Kompatibilitätsprobleme bekannt – viele Miner und Mining-Pools verwenden ihre eigene Software, um an P2PKH-Adressen zu zahlen, wie Sie den Coinbases in den letzten Blöcken entnehmen können.

Ist es möglich, dass diese Informationen veraltet sind? Ich habe letzte Woche mit Pieter Kaffee getrunken, und er hat PREVOUT + SCRIPTSIG = 36 + (1 + 1 + 33 + 1 + (71 or 72)) = 143 or 144für die P2PKH-Eingabe gerechnet.
Die Zahlen hier 1) beinhalten nicht das Prevout und 2) gehen von einem unkomprimierten Pubkey aus.
@Murch Ich habe die Antwort aktualisiert, um komprimierte Pubkeys zu verwenden, unkomprimierte Pubkeys zu erwähnen und zu erwähnen, was nicht gezählt wird. Ich glaube, dass alle Berechnungen richtig waren (und sind); Einige der historischen Informationen waren jedoch falsch (wie ich gelernt habe, seit ich diese Antwort zum ersten Mal geschrieben habe), also habe ich das korrigiert. Außerdem bin ich froh, dass Sie und Pieter zusammen Kaffee trinken konnten. :-)
Warum verwendet die standardmäßige Miner-Implementierung Pay-to-Pubkey?
AntwortenHierDatenschutz-Bestimmungen1y, 0v