The signrawtransaction RPC will verify the input scripts of the transaction after it signs it. If the transaction has not been fully signed (i.e. it isn't complete), then the script verification will fail and produce this error.
This also happens with multisig transactions. When you don't have enough signatures, the script will fail to verify with the error ...
The easiest way to do this by importing the address you generated on the offline Bitcoin Core client into an online fully synced Bitcoin-Core. The command is: bitcoin-cli importaddress <address>. The benefit of importing this address into the synced Bitcoin-Core machine is that you can use it as a watch-only address which will allow you to see all the ...
Figured out a few things:
For segwit transactions one must sign the following (see BIP 143):
Double SHA256 of the serialization of:
1. nVersion of the transaction (4-byte little endian)
2. hashPrevouts (32-byte hash)
3. hashSequence (32-byte hash)
4. outpoint (32-byte hash + 4-byte little endian)
5. scriptCode ...
You provided the amount incorrectly. The amount is 0.54551 not 545500. This is important as Segwit inputs include the previous output's amount in the signature. Providing the wrong amount will result in the wrong signature which will then fail validation.
Do i need to sign each input in a raw transaction?
Technically, yes. But software like Bitcoin Core Client signs all inputs where the private keys are known. And of course, leave unsigned/untouched all other inputs.
Good day! Finally I found a solution, I hope it will useful to someone.
The problem was that I tried to sign inputs before adding outputs and other info into transaction. So now I add inputs with method addInput(). Before I did it with addSignedInput() method. After adding all inputs and outputs in my TX I try to sign every input manually:
for (int i = 0;...
I'm not an expert in this field by any means (and my error message was different), but I spent last week trying to make Bitcoinj sign a transaction and send in raw form (i.e. without using transport protocol which Bitcoinj provides) and here's what I've learned (the hard way): You can't sign transactions like that. If you call tx.addSignedInput in a loop, ...
Signing the same piece of data with the same key typically produces different signatures unless you are using a deterministic signature scheme. Check if that is the case with the library you are using for signing.
EDIT: Seems like python-ecdsa supports deterministic signatures
As the error message says, signrawtransaction is deprecated. Stop using it. Instead use signrawtransactionwithwallet (if the transaction you are signing uses keys from your wallet) or signrawtransactionwithkey (if you are specifying keys on the command line).
You also need to acquire the UTXO's which are spendable by your private key.
The private key in WIF private key format provides the information required to derive the pubkeyhash found in P2PKH(pubkeyhash) and P2WPKH(pubkeyhash) output scripts spendable by the private key. Deriving the pubkeyhash, or even address, can be done with BitcoinJS on the front-end....
createTX() doesn't sign the transaction. That is performed by sign() in wallet.js. If your private keys are offline anyway, what kind of unexpected behavior are you getting from createTX()? It wouldn't be able to sign without the keys...?
New functionality was also recently merged to return the MTX before the input scripts are templated (when the public ...
Assuming the two private keys are unrelated, the answer is no.
The reason for this is simple: there are 3 unknowns (the two private keys, and the single secret k value), but only two equations (the ECDSA validation equation for both signatures).
If a relation is known between the two private keys (like one is twice the other, or one is one higher than the ...
You are passing the parameter with signedTx incorrectly. A JSON-RPC param key must have a value that is either an array or an object. You are passing in a string. Instead you should pass in the parameter similarly to how you did for the signrawtransactionwithkey call.
You should have something like this:
Dictionary<string, object> param = new ...
It looks like the new calls are not yet supported in btcClient.
https://github.com/ruimarinho/bitcoin-core/issues/77 refers generally to your issue.
v2.0.0 was released "a year ago" according to https://www.npmjs.com/package/bitcoin-core; v0.17 bitcoind, which made the change, four months ago.
If you're just tinkering, you might consider downgrading your ...
The original Bitcoin client did not have a debug console or many things that we see in modern Bitcoin software. Furthermore, it is a compiled software (C++ needs to be compiled) so you can't inspect the thing being run for its source code. However, Satoshi did publish the source code along with the pre-compiled binary. For transaction creation, you can find ...
The hex-encoded transaction itself looks okay to me at first glance. When you send it, do you get an error? It could just be that you have a transaction fee of zero, try increasing the fee (by reducing the amount in your only output) and try again.
I had the same error, but perhaps different problem. See:
Trying rawtransaction BCC/BCH with failed CHECK(MULTI)SIG. What is wrong?
It is important that the hash used for signing is based on the same data actualy send + sigscript. Any difference will result in a different signature. Also for the signature the amounts of the outpoints need to be used and ...
Since i'm sure others will encounter the same problem, the solution is that BCC requires you to put in the amount-tag when signing a transaction. You have to put in the full amount that is shown on the listunspent-command though, else you won't be able to send the transaction.
The wallet does not know how to sign for segwit stuff until you use addwitnessaddress. This is because it is only tracking the P2PKH outputs for that key. You have to explicitly tell it to track the witness outputs for the key by using addwitnessaddress.