Raw SegWit TX sieht solide aus und verifiziert, wird aber abgelehnt. Benötigen Sie Hilfe, um herauszufinden, warum

Es ist gültig. Wenn Sie die Transaktion hier einfügen, wird tatsächlich ein kleines Häkchen neben dem Symbol „Signiert“ angezeigt, das eine ordnungsgemäße Signatur anzeigt.

Es ist nicht gültig. Diese Website hat nichts validiert. Es hat nur geprüft, ob etwas im scriptWitness-Feld steht, und wenn ja, wurde es als signiert markiert. Dieses Häkchen bedeutet nicht, dass es gültig ist.

Deine Signatur ist einfach falsch. Anders kann man es nicht sagen. Wenn Sie es über meinen Bitcoin Core-Knoten ausführen, erhalten Sie

64: non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation)

Dies ist der typische Fehler aufgrund einer ungültigen Signatur.

Überprüfen Sie noch einmal, ob Sie den Seufzer korrekt erstellen. Probleme wie dieses sind normalerweise das Ergebnis einer falschen Serialisierung der Transaktion zum Signieren.

Ich vermute, es wird in Programmiererkreisen als kitschig angesehen, eine Antwort auf die eigene Frage zu posten, aber in diesem Fall war mein Fehler ziemlich gefährlich, daher möchte ich die Details mit Ihnen allen teilen.

REKAPITULIEREN:

Meine Frage besagte, dass die öffentlichen „Push tx“-APIs keine brauchbaren Fehlermeldungen ausgaben, nachdem sie meine hexadezimal formatierten Rohtransaktionen abgelehnt hatten. Die Antwort von Mr. Chow deutete darauf hin, dass es sich bei dem Problem um einen Signaturfehler handelte, den er erhielt, nachdem er versucht hatte, meinen fehlerhaften TX durch seinen persönlichen Knoten zu schieben. Das hat mich in die richtige Richtung gewiesen.

Sein Vorschlag war, dass ich meinen Seufzer vielleicht nicht richtig serialisiert habe, da dies oft zu der Fehlermeldung führt, auf die er sich bezieht. Aber der Code, der diesen Sighash formuliert, funktioniert seit Jahren gut, also dachte ich, das Problem sei woanders. Tatsächlich war es so. Die Kurzgeschichte ist, dass meine Logik, die verwendet wurde, um einen öffentlichen Schlüssel von einem privaten Schlüssel abzuleiten, der ewig einwandfrei funktioniert hatte, nun nach einem Upgrade der BouncyCastle .NET-Verschlüsselungskomponente fehlschlug.

Hier ist ein Auszug meines Codes, der einen privaten Schlüssel in einen öffentlichen Schlüssel umwandelt:

public class BTCUtils2{
    public static byte[] DerivePublicKey(byte[] privKey,bool isCompr){
        ECPoint pubPt=ComputePublicECPoint(privKey);

        //byte[] xCoord = pubPt.X.ToBigInteger().ToByteArrayUnsigned(),     //2015: worked properly in with BouncyCastle 1.7.4114.6375
        //       yCoord = pubPt.Y.ToBigInteger().ToByteArrayUnsigned();

        //byte[] xCoord = pubPt.XCoord.GetEncoded(),                        //2019-07-01: upgraded to 1.8.5; generates bad data
        //       yCoord = pubPt.YCoord.GetEncoded();

        ECPublicKeyParameters publicParams = new ECPublicKeyParameters(pubPt,ECParams); //2019-07-16; proper usage of 1.8.5
        byte[] xCoord=publicParams.Q.XCoord.GetEncoded(),
               yCoord=publicParams.Q.YCoord.GetEncoded();

        if(xCoord.Length!=32 || yCoord.Length!=32){throw new ApplicationException("SANITY CHECK: Expected 32 bytes for X/Y coords");}
        byte[] bytes=new byte[isCompr?33:65];                               //public key consists of a one byte prefix (0x04=uncompress,0x02=compressed w\ y=even, 0x03=compressed w\ y=odd) prior to the payload
        if(isCompr){
            bytes[0]=((yCoord[31] & 0x01)==0)?(byte)0x02:(byte)0x03;        //compressed; set prefix based on whether Y is even or odd
            Array.Copy(xCoord,0,bytes,1,32);                                //x coord
        }
        else{
            bytes[0]=0x04;                                                  //uncompressed; set prefix to 0x04
            Array.Copy(xCoord,0,bytes,1,32);                                //x coord
            Array.Copy(yCoord,0,bytes,33,32);                               //y coord
        }
        return bytes;
    }
    private static ECPoint ComputePublicECPoint(byte[] privKey){return ECParams.G.Multiply(new BigInteger(1,privKey));}
    private static readonly ECDomainParameters  ECParams=null;
    static BTCUtils2(){
        X9ECParameters crv = Org.BouncyCastle.Asn1.Sec.SecNamedCurves.GetByName("secp256k1");
        ECParams=new ECDomainParameters(crv.Curve, crv.G, crv.N, crv.H);
    }
}

Das Problem tritt oben auf, wo ich einen privaten Schlüssel, ausgedrückt als Byte-Array, in einen öffentlichen Schlüssel umwandle, ausgedrückt in Form seiner x/y-Koordinaten. Siehe meine Kommentare. Der Code von 2015 hat mit der Ausgabe von BouncyCastle von 2011 jahrelang gut funktioniert.

Am 01.07.2019 musste ich auf Version 1.8.5 der Hüpfburg upgraden. Der Code wird nicht mehr kompiliert. Ich dachte mir, hey, sie müssen ein paar Dinge oder was auch immer umbenannt haben, also habe ich die beiden Zeilen mit der Bezeichnung 2019-07-01 angewendet, weil ich dachte, ich würde dasselbe erreichen. GROSSER FEHLER. Ich bin mir nicht sicher, was genau diese Funktionsaufrufe zurückgeben, aber sie sind nicht die x/y-Koordinate des öffentlichen Schlüssels. Sie sind etwas ganz anderes.

Wie Sie sich vorstellen können, führt ein öffentlicher Schlüssel, der Ihrem privaten Schlüssel nicht richtig entspricht, zu allen möglichen Problemen, einschließlich fehlerhafter Bitcoin-Adressen, Signaturfehlern usw.

Heute habe ich diese schlechten Zeilen durch die mit der Bezeichnung 2019-07-16 ersetzt. Das hat funktioniert. Ich habe überprüft, ob diese Zeilen tatsächlich einen gültigen öffentlichen Schlüssel generiert haben. Transaktionen werden jetzt fehlerfrei übermittelt.

Hoffe, das ist Wert für jemanden.

Am besten,

Festus