Topic: Spend P2PK output in 2017? (Read 667 times)

Okay, I lied. It was signed. I just thought it wasn't because both Electrum and coinb.in said it wasn't, and it was not the normal size of most signed transactions I've seen. I apologize. The transaction successfully broadcasted.

Also, I think that means coinb.in was signing it the entire time as well. It just wasn't recognizing that it had. It looks like this was all a big misunderstanding.

Anyway, thank you very much for your assistance achow101. Once everything gets confirmed and sorted out, there will be a bit arriving in your address.

Oops. I forgot a few brackets. I will edit my post.

The txid, vout, scriptPubKey, and amount are all the values for the input that you are spending.

Right, I forgot to add the curly braces in my command for you earlier.

If it says complete, then the transaction is signed. Complete is only true when the returned transaction has a full set of signatures. In what way is it not actually signed?

I'm getting "Error parsing JSON" on the second argument (the part containing the scriptPubKey), so I have a few more dumb questions:

1. Is the txid supposed to be the txid of the new unsigned transaction (the first one you see when decoding it), or the txid of the input (the one included in the "createrawtransaction" command)?

2. Is the amount field here supposed to contain the value of the input (say 10), or the value of the combined outputs (say 9.9993 accounting for transaction fees)?

Here's basically what I'm typing in:

./bitcoin-cli signrawtransaction "d52825f5b691e5815b1cfcf235cfb62c1d48ec34ae190832953ff6845587f3a59c68996baa1efa4 76f767dd9c035ca34c5a0c8bf069718bfb0128c9a92bc1812c6aa20fa7017e72fd7e24c67d8b94" '["txid":"bf45e632541ce5a4f6ede6e3d4de85079cfd5fca99b973de9d73c8edb8261777","vout":0,"scriptPubKey":"7eb2d089b5cdf6e6cb9d0b84fd51a0e64a03911c337022591818812873ca8fbf","amount":2.77]' '["52f1muMCNa7goXYhYAQC61hxEgGacmncB"]'

(All of the values are fake.)

Is there anything I'm missing?

Edit: I was able to eliminate the JSON error by adding in curly brackets in the square ones. Now it completes, but it still doesn't sign the transaction. It adds in the script, but it does not actually sign it. (It throws me no errors though and deems the action complete).

I know at this point you might be inclined to say "It's the wrong private key". I can send you a signed message via PM if you'd like.

The correct syntax that you want is
with hex and privkey being the actual values and not those strings. The position of the quotes is verbatim.

You can get the scriptpubkey from any block explorer. The easiest for this, IMO, is blockcypher. Use the following url format: https://api.blockcypher.com/v1/btc/main/txs/?limit=50&includeHex=true. Just use that link verbatim except replacing with the transaction id. On the page that you get, scroll down to where it says outputs and find the output that you want to spend from. The scriptpubkey is the hex string for the field labeled script.

Then to sign the transaction with Core and completely offline, your command should be like this:

Code:

bitcoin-cli signrawtransaction "" '[{"txid":"","vout":,"scriptPubKey":"","amount":}]' '["

Everything in angle brackets and the angle brackets themselves (<>) should be replaced with their respective values. The rest should be verbatim. The that is the unsigned transaction should also be one that is produced by the createrawtransaction command. All that really means is that the scriptsig of each input will just be a 0x00 byte.

This should produce a validly signed transaction that can be broadcast to the network by any node. If you are still unable to broadcast it, make sure that the output you are trying to spend is actually still unspent.

The signature was generated by Electrum. I have tried multiple times and there is no difference. coinb.in will not even produce a signature (it simply spits the unsigned transaction back out). (And Armory crashes while creating a wallet so I can't try that yet.)


I have tried:

./bitcoin-cli signrawtransaction "(txinhex)" (which I thought might prompt me interactively for a private key but instead just produced the "input not found" error)

and the rest which all produced the "Error parsing JSON: (privkey)" (with whatever punctuation I put it in attached too) error:

./bitcoin-cli signrawtransaction "(txinhex)" ["(privkey)"] ALL
./bitcoin-cli signrawtransaction "(txinhex)" ["(privkey)"] "ALL"
./bitcoin-cli signrawtransaction "(txinhex)" "(privkey)" ALL
./bitcoin-cli signrawtransaction "(txinhex)" "(privkey)" "ALL"
./bitcoin-cli signrawtransaction "(txinhex)" "" "(privkey)" "ALL"
./bitcoin-cli signrawtransaction "(txinhex)" "[]" "(privkey)" "ALL"
./bitcoin-cli signrawtransaction "(txinhex)" "[]" ["(privkey)"] ALL
./bitcoin-cli signrawtransaction "(txinhex)" [] ["(privkey)"] ALL

And every other variation thereof (including with single quotes). Either way it does not seem to be the transaction in hex that it takes issue with, but the private key. That's what it always highlights in the error.

The documentation says that the second argument is optional so I was going based off of that.


I only say that by comparison to other tools. The transaction I was attempting to send to bitcoind was in a state that it could be signed by coinb.in entirely offline at that point (if it actually worked like it did with other transactions), though certainly Core's format is different I'm sure.

Where would I find the scriptPubKey to provide manually? Or how would I manually formulate it?

I would rather not post the exact transaction for privacy's sake (if that's not too offensive).

Ideally I would like to generate a transaction that does not need to be broadcasted by Core and can be sent out from coinb.in, blockchain.info, or the like.

You are probably correct that coinb.in's format is incompatible with Core's. I just thought that signing an unsigned transaction would be relatively atomic and independent of the minor formatting differences between programs and had hoped that I was simply making a syntax error on the command line.

The same way you would spend one in any other year. P2PK outputs are still standard and can be used as they were previously used.

What software generated the signature? It either produced the signature incorrectly or the signature contains a High-S value.

What is the command that you are using to try to sign the transaction (without the privkey of course)?

That error means that it cannot find the input. If you are not synced past the date that the input you are trying to spend was confirmed, then it will not work.

Then you clearly do not understand how transactions are signed. When a transaction is signed, the scriptPubKey must be added to the transaction as it is part of the data that is signed. You must either provide that or Bitcoin Core must be synced so that it can look it up.

How so? Can you post it here? The format the coinb.in uses for unsigned transactions may not necessarily be the same format that Bitcoin Core uses.

How can I spend a P2PK output in 2017? Electrum will not broadcast a signed TX containing it ("Non-canonical DER signature"), and coinb.in will craft the transaction but will not sign it properly with the private key (it just outputs the unsigned transaction again). I am willing to use bitcoind's RPC, or bitcoin-tx, but I cannot figure out the proper syntax for either. It always spits out "Error parsing JSON: (my private key)" at me, regardless of whether I put it in quotes, brackets, or anything (or it tells me that the input doesn't exist or has been spent (which it hasn't according to all blockchain explorers)). I don't have this copy of Bitcoin Core synced and I'd rather not have to sync it just to sign a transaction since I think it should very well work offline. The unsigned transaction I am attempting to sign was generated by coinb.in so it already includes the scriptsig.

Basically I will use any software that I can as long as I can sign this transaction offline. It's one input, one output, and a small transaction fee. The input is just an old P2PK one. How can I get this done?

Edit: I can sign/verify messages with the private key, by the way, so I know it's correct.