4

I've been working with BitcoinLib testing various parameters on the signrawtransaction rpc call.

It's been mostly successful, however there seems to be a persisting problem when using only private keys to sign a transaction. (second optional argument of signrawtransaction call). The server replies false and returns the failed hex. I have tested the same transaction on the qt console using the same keys, and it returns true.

The wrapper employs a SignRawTransactionRequest class matching the four arguments of the rpc call.

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

It allows for 'inputs' and 'privatekeys' to be null, following the signrawtransaction syntax, while assuming 'sighashtype=all' unless explicitly specified otherwise.

The implementation also includes a SignRawTransactionInput class corresponding to the first optional argument of the rpc call. ([{"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; }
}

The request if fed to the wrapper method RpcServer.SignRawTransaction and returns a SignRawTransactionResponse containing the result and the hex as returned by the server.

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

So far, signings using just the hex (no other arguments), inputs, different sighashtypes and various combinations of those have been successful. The server replies TRUE and returns the hex of the signed transaction when called with plain hex

enter image description here server reply

or when called with some arguments

enter image description here

enter image description here

However, it returns false when the second optional argument(list of private keys) is used. It has been tested with one, all, and various combinations of the available private keys of the wallet.

enter image description here enter image description here

I suspect it might be a JSON error and that the wrapper is not constructing that part of the JSON properly, however that usually leads to a parsing error and not the false reply I get here.

The same combinations return true when signrawtransaction is called from the console.

enter image description here

Any ideas on what might be wrong with the private keys argument?

  • Did you every manage to figure this out? I'm doing battle with the same RPC method, trying to sign a raw transaction with by providing the necessary private keys rather than unlocking the wallet. Unfortunately it's proving problematic... – user14963 Apr 1 '14 at 10:53
  • @Tony you have to provide the right keys to sign each unspent input used. Raw transactions have been tested extensively for this library and they work as expected but if you have some specific issue feel free to report it at: github.com/GeorgeKimionis/BitcoinLib/issues – George Kimionis Apr 17 '14 at 10:24
2

This was not a case of BitcoinLib malfunctioning in any way. It was simply a case of using wrong privkeys to sign the unspent outputs.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.