JSON-RPC signrawtransaction gibt false zurück, wenn private Schlüssel verwendet werden

Ich habe mit BitcoinLib gearbeitet und verschiedene Parameter beim RPC-Aufruf signrawtransaction getestet.

Es war größtenteils erfolgreich, es scheint jedoch ein anhaltendes Problem zu geben, wenn nur private Schlüssel zum Signieren einer Transaktion verwendet werden. (zweites optionales Argument des signrawtransaction-Aufrufs). Der Server antwortet falseund gibt das fehlgeschlagene Hex zurück. Ich habe dieselbe Transaktion auf der qt-Konsole mit denselben Tasten getestet und sie gibt true.

Der Wrapper verwendet eine SignRawTransactionRequestKlasse, die den vier Argumenten des rpc-Aufrufs entspricht.

public SignRawTransactionRequest(String rawTransactionHex)
    {
        RawTransactionHex = rawTransactionHex;
        Inputs = new List<SignRawTransactionInput>();
        PrivateKeys = new List<String>();
        SigHashType = SignRawTransaction.SigHashType.All;
    }

Es erlaubt, dass „inputs“ und „privatekeys“ gemäß der signrawtransaction-Syntax null sind, während „sighashtype=all“ angenommen wird, sofern nicht ausdrücklich anders angegeben.

Die Implementierung umfasst auch eine SignRawTransactionInputKlasse, die dem ersten optionalen Argument des rpc-Aufrufs entspricht. ([{"txid":txid,"vout":n, "scriptPubKey":hex, "redeemScript":hex } ,...])

public class SignRawTransactionInput
{
    [JsonProperty(PropertyName = "txid", Order = 0)]
    public String TransactionId { get; set; }

    [JsonProperty(PropertyName = "vout", Order = 1)]
    public Int32 Output { get; set; }

    [JsonProperty(PropertyName = "scriptPubKey", Order = 2)]
    public String ScriptPubKey { get; set; }

    [JsonProperty(PropertyName = "redeemScript", Order = 3)]
    public String RedeemScript { get; set; }
}

Die Anfrage wird der Wrapper-Methode zugeführt RpcServer.SignRawTransactionund gibt eine zurück SignRawTransactionResponse, die das Ergebnis und den vom Server zurückgegebenen Hex enthält.

public class SignRawTransactionResponse
    {
        public String Hex { get; set; }
        public Boolean Complete { get; set; }
    }

Bisher waren Signierungen mit nur dem Hex (keine anderen Argumente), Eingaben, verschiedenen Seufzertypen und verschiedenen Kombinationen davon erfolgreich. Der Server antwortet mit TRUE und gibt das Hex der signierten Transaktion zurück, wenn er mit Plain Hex aufgerufen wird

Geben Sie hier die Bildbeschreibung ein Antwort des Servers

oder wenn mit einigen Argumenten aufgerufen

Geben Sie hier die Bildbeschreibung ein

Geben Sie hier die Bildbeschreibung ein

Es gibt jedoch false zurück, wenn das zweite optionale Argument (Liste der privaten Schlüssel) verwendet wird. Es wurde mit einem, allen und verschiedenen Kombinationen der verfügbaren privaten Schlüssel des Wallets getestet.

Geben Sie hier die Bildbeschreibung ein Geben Sie hier die Bildbeschreibung ein

Ich vermute, dass es sich um einen JSON-Fehler handeln könnte und dass der Wrapper diesen Teil des JSON nicht richtig konstruiert, aber das führt normalerweise zu einem Parsing-Fehler und nicht zu der falseAntwort, die ich hier bekomme.

Dieselben Kombinationen werden zurückgegeben, truewenn signrawtransaction von der Konsole aus aufgerufen wird.

Geben Sie hier die Bildbeschreibung ein

Irgendwelche Ideen, was mit dem Argument der privaten Schlüssel falsch sein könnte?

Habt ihr es alle geschafft, das herauszufinden? Ich kämpfe mit der gleichen RPC-Methode und versuche, eine Rohtransaktion zu signieren, indem ich die erforderlichen privaten Schlüssel bereitstelle, anstatt die Brieftasche zu entsperren. Leider ist es problematisch...
@Tony Sie müssen die richtigen Schlüssel bereitstellen, um jede nicht ausgegebene Eingabe zu signieren. Raw-Transaktionen wurden für diese Bibliothek ausgiebig getestet und sie funktionieren wie erwartet, aber wenn Sie ein bestimmtes Problem haben, können Sie es gerne melden unter: github.com/GeorgeKimionis/BitcoinLib/issues

Antworten (1)

Dies war in keiner Weise ein Fall einer Fehlfunktion von BitcoinLib. Es ging einfach darum, falsche Privkeys zu verwenden, um die nicht ausgegebenen Ausgaben zu signieren.