Ich versuche derzeit, eine Transaktion von Grund auf neu zu erstellen und zu signieren. Ich habe es geschafft, eine Transaktion zu konstruieren und zu unterzeichnen. Wenn ich es manuell verifiziere, sieht es gut aus, aber mit einer "richtigen" Brieftasche wird meine Transaktion abgelehnt:
error code: -26
error message:
64: scriptsig-not-pushonly
Davon bekomme ichbitcoin-cli
Mein ScriptSig ist:4a304602210090c4fc2369cf225559c1141a1e9be3d7598f0fb7affe8a29f86e737972c7587a022100cbd8619ecae3baa40fdb565014fdac28a95deb90c0fcd4adcbd97d58d0e96f9801410442718de90a0a10f0cd10054ff4ab6037fd230c5d4b50c07eed0bc247e1e3dbd9ad3f4c65680396813bd96b0c2db5647e355082db34c7106a74337d51e5730f45
Ich würde es wie folgt entschlüsseln:
4a=> Länge der Signatur, 74 Byte
304602210090c4fc2369cf225559c1141a1e9be3d7598f0fb7affe8a29f86e737972c7587a022100cbd8619ecae3baa40fdb565014fdac28a95deb90c0fcd4adcbd97d58d0e96f98DER-Signatur
01Operationscode SIGHASH_ALL
41öffentliche Schlüssellänge, 65 Byte
0442718de90a0a10f0cd10054ff4ab6037fd230c5d4b50c07eed0bc247e1e3dbd9ad3f4c65680396813bd96b0c2db5647e355082db34c7106a74337d51e5730f45Öffentlicher Schlüssel
Können Sie ein Problem mit dieser ScriptSig erkennen?
Ihre Signatur ist nicht korrekt. Zunächst einmal darf seine Länge nicht 74 Bytes lang sein. Laut dem Bitcoin-Wiki :
Signaturen sind entweder 73, 72 oder 71 Bytes lang, mit Wahrscheinlichkeiten von etwa 25 %, 50 % bzw. 25 %, obwohl mit exponentiell abnehmender Wahrscheinlichkeit auch kleinere Größen möglich sind.
Allerdings scheint es, dass Sie die Länge der Signatur zweimal falsch berechnet haben. Erstens ist das, was Sie als DER-Signatur dekodiert haben, nicht 74 Byte lang, sondern 72:
sig = "304602210090c4fc2369cf225559c1141a1e9be3d7598f0fb7affe8a29f86e737972c7587a022100cbd8619ecae3baa40fdb565014fdac28a95deb90c0fcd4adcbd97d58d0e96f98"
len(sig/2) = 72
Außerdem haben Sie das Hash-Flag nicht als Teil der Signaturlänge gezählt, und das sollten Sie auch. Dadurch wird ein zusätzliches Byte hinzugefügt, wodurch die Signatur 73 Byte lang wird.
Alles zusammen sollte das Skript lauten:
ScriptSig = 49304602210090c4fc2369cf225559c1141a1e9be3d7598f0fb7affe8a29f86e737972c7587a022100cbd8619ecae3baa40fdb565014fdac28a95deb90c0fcd4adcbd97d58d0e96f9801410442718de90a0a10f0cd10054ff4ab6037fd230c5d4b50c07eed0bc247e1e3dbd9ad3f4c65680396813bd96b0c2db5647e355082db34c7106a74337d51e5730f45
Beachten Sie schließlich, dass Sie gemäß dem, was @pebwindkraft Ihnen in seiner Antwort gesagt hat, High-S-Signaturen produzieren, also sollten Sie das auch umgehen.
Das scriptSigFeld soll nur Daten-Push-Operationen enthalten. Ein gültiges scriptSigwird von der Form sein
[Operator to push x bytes][x bytes of data][Operator to push y bytes][y bytes of data]...
Die scriptSigvon Ihnen angegebene wurde (am Anfang) wie folgt interpretiert:
`4a` // Pushe 74 Bytes `30460...96f980141` // 74 Datenbytes `04` // Pushe 4 Bytes `42718de9` // 4 Byte Daten `0a` // Pushe 10 Bytes `0a10f0cd10054ff4ab60` // 10 Byte Daten
Das nächste Byte, auf das der Interpreter trifft, ist fdkein Push-Datenoperator (nur die nachstehenden Opcodes 0x60werden als Push-Datenoperatoren betrachtet). Es endet mit einem Fehler, der sich darüber beschwert, dass es sich scriptSignicht um einen "Nur-Push" handelt.
Ich habe das mit python-bitcoinlib herausgefunden .
aus bitcoin.core importieren *
aus bitcoin.core.script importieren *
s = x('4a304602210090c4fc2369cf225559c1141a1e9be3d7598f0fb7affe8a29f86e737972c7587a022100cbd8619ecae3baa40fdb565014fdac28a95deb90c0fcd4adcbd97d58d0e96f9801410442718de90a0a10f0cd10054ff4ab6037fd230c5d4b50c07eed0bc247e1e3dbd9ad3f4c65680396813bd96b0c2db5647e355082db34c7106a74337d51e5730f45')
CScript(s)
Der letzte Befehl liefert die Ausgabe:
CScript([x('30460...96f980141'),
x('42718de9'),
x('0a10f0cd10054ff4ab60'),
x('fd230c...30f45') FEHLER: PUSHDATA(55): abgeschnittene Daten])
Wie die anderen Antworten bereits gezeigt haben, ist die Ausgabe von fehlerfrei, wenn Sie das erste Byte in Ihrem scriptSigvon 4azu ändern. Es ist wie folgt:49CScript(s)
CScript([x('3046022...96f9801'), x('0442718de...30f45')])
Ich bin mir nicht sicher, von welchem Betriebssystem und welcher Brieftasche Sie sprechen ... Ich habe zwei Beobachtungen.
printf "304602210090c4fc2369cf225559c1141a1e9be3d7598f0fb7affe8a29f86e737972c7587a022100cbd8619ecae3baa40fdb565014fdac28a95deb90c0fcd4adcbd97d58d0e96f9801" | wc -c
146
Das sind nur 73 Bytes, und wenn Sie 01 entfernen, was die Skript-Sig beendet, erhält es 72 Bytes (Hex 0x48). Das ist wahrscheinlich das, was Sie verwenden möchten.
Auch:
######################################################### ### procedure to strictly check DER-encoded signature ### ######################################################### Minimum and maximum size constraints - ok scriptsig always starts with 0x30 - ok length 140 chars is less than actual sig length (144 chars) - ok (hex 0x46, decimal 70, 140 chars) length of R coordinate (66) >= 0 - ok length of S coordinate (66) >= 0 - ok S-Value is within scriptsig boundaries - ok Make sure the R & S length covers the entire signature - ok --> S is not smaller than N/2, need new S-Value (new_s = N - s)
Ist das vielleicht eine ältere Version? Neuere Versionen korrigieren S-Werte kleiner als N/2.
Korrektur zum S-Wert (November 2017):
der S-Wert hier ist: 00cbd8619ecae3baa40fdb565014fdac28a95deb90c0fcd4adcbd97d58d0e96f98
Pieter erklärt Zero Padding und S-Value in diesem Thread: http://bitcoin-development.narkive.com/OOU2XVSG/bitcoin-development-who-is-creating-non-der-signatures
Für S-Werte sagt er:
... 2. Signaturen sind strikt DER-kodiert (+ Hashtyp-Byte). Das Format ist:
0x30 <lenT> 0x02 <lenR> <R> 0x02 <lenS> <S> <hashtype>
R und S sind Ganzzahlen mit Vorzeichen, die als Big-Endian-Bytesequenz codiert sind. Sie werden in so wenigen Bytes wie möglich gespeichert (dh kein 0x00-Padding davor), außer dass ein einzelnes 0x00-Byte benötigt wird und sogar erforderlich ist, wenn das darauf folgende Byte sein höchstes Bit gesetzt hat, um zu verhindern, dass es als negativ interpretiert wird Nummer.
Basierend darauf ist der S-Wert mit Nullen aufgefüllt und als solcher korrekt.
sr-gi
pebwindkraft