Topic: P2PK - send to AND spend from a public address - will it work in 2023? (Read 240 times)

Be careful with non-standard transactions. I told you. You tried using P2PK again, and created some always-true-stack-push. Again. Maybe you should use Bitcoin Core, or at least some better block explorer, like mempool.space, to see, what is really P2PK, and what is simply non-standard? Also, I guess bitpay.com cannot show you OP_RETURN, and cannot even tell you, that it is unspendable.

I thought about simply sending you all of those coins back. But I guess, in this way, you will not learn anything, and repeat the same mistakes. So, this time I will send you those coins, but this time with a locktime, and with some OP_CHECKSIG, to show you, what is missing.

Which means, you have two options:

1. Wait, and broadcast my transaction, after locktime will expire.
2. Use P2PK correctly, and get your coins faster than this locktime.

I send you my key again, and I hope you will do that correctly this time.

Also, I include that timelocked transaction publicly, to prove that all of the above is true:
Also, the funny thing is that some block explorers even accept that transaction with this locktime. But of course, they cannot make it valid, before reaching unix time 17,0000,0000: https://live.blockcypher.com/btc-testnet/tx/cd8ad764c3c83a67ff5f04cbac1bfab93654bc387f8d1ab35e8c0e1e38cbed43/

And then, after few hours, they drop it, after being unconfirmed for a long time, but you can always rebroadcast it again: https://live.blockcypher.com/btc-testnet/pushtx/

Alternatively, he can dedicate a blank descriptor wallet and import a "pk" descriptor containing the public key's private key pair.
Then, Bitcoin Core will be able to conveniently spend P2PK outputs for that pubKey with wallet commands or GUI.

Example import command with P2PK descriptor:

My only concern in this is the misleading GUI elements which shows an address in the 'receiving addresses' and in the 'inputs' list (as well in "listunspent" command)

No. What was missing, was simply OP_CHECKSIG at the end. In your example, also no signatures are needed, just pushing "OP_TRUE " will do the trick. And that OP_TRUE is needed only because you used OP_EQUALVERIFY, instead of OP_EQUAL, which means that boolean will be consumed by your script, so it should be unnecessarily added inside input to make it spendable.

Quote

It's not too difficult to translate this into asm hex that you can paste into the raw transaction, though I guess you'd want to make a raw transaction sending to some random P2PKH address first and then replace the P2PKH output with this manually.

It doesn't matter, what exactly is replaced. You can send it to OP_RETURN as well, and then replace it. Also, "decoderawtransaction" and "decodescript" are your friends, and will tell you, if your script is standard or not. And to be absolutely sure, you can try it on regtest first, before touching even testnet, and locally confirm, that your transaction is standard, and will be picked by your own node, when broadcasted.

For P2PK we can just a simple script with the contents "OP_PUSHDATA (32 bytes of public key) OP_EQUALVERIFY", and that would be enough to require a valid signature, right?

It's not too difficult to translate this into asm hex that you can paste into the raw transaction, though I guess you'd want to make a raw transaction sending to some random P2PKH address first and then replace the P2PKH output with this manually.

Wrong. It was sent to "always true stack push", not protected by any key. It can be spent without any signatures, as I just demonstrated. If you paste your transaction into Bitcoin Core, it will tell you this output is "nonstandard". I told you to avoid that, if you don't know, what are you doing:


You are lucky that you tried all of that on test network first. On main network, it would be non-standard of course, but if some miner would accept your transaction anyway, then that miner could sweep your 1 BTC, without any signatures. So, be careful!

This is not a mistake, they are 100% right. It is not P2PK, and as it was shown, it can be moved without any signatures. It is just because of the missing OP_CHECKSIG.

I took it without signatures, so it is probably not what you intended. That means, I will give you another chance, to learn about P2PK, and do it correctly. Those are testnet coins anyway, so you can take them back, and move into P2PK, as you planned.

I just created a transaction, without signing anything.


As you can see, I didn't need to sign it. That output matches exactly, what was broadcasted: https://mempool.space/testnet/api/tx/a38c3bbe14df0e10af990b3393635abdfa0b20622c22fdab92333ead0b89c252/hex

I sent you my key. You can try to move coins from tb1qdjnnvlg9k674f9zarujthkz32ne4asxexnptz4, and try again using P2PK correctly.

Dang. Finder keepers - check out this tx on testnet (confirmation was FAST)

https://bitpay.com/insight/BTC/testnet/tx/24cd5df1dcbc1139054c36c989bae4d8a2e992111a112c3f6b31ab309689ed4d

1 tBTC sent to the uncompressed private key, NOT public address, first entry. #wholecoiner

I love that the blockchain explorer (Insnight) doesn't know what to think of it, or parse it right, and just says, "Unparsed address."

Difficult to follow the (play)money!

Take it! Keys are in the OP. Only one condition: That you immediately come bach here and write here how you did it. Very detailed, such as: did you use a wallet software or entirely manual or using some online tool to help assembling a complex tx or did you, finally, just do it in notepad and broadcast it at the nearest outlet?

If you feel extra kind, send all or at least the majority back to 2N2EJxoRy5hRE74aV4NDiC22dcH3QEqzf5G

Win-win!

Formidable! Much obliged. Looking forward to sharing a tx id, one that blockchain explorers will struggle to parse, and - nerdy mission accomplished

Of course. In testnet, mainnet, signet, and regtest. It works in all official networks, supported by Bitcoin Core.

I will show you that on testnet coins, you can use the same method in all other networks.

First, we can get some testnet address, to get some coins from some faucet.


Then, we generate some new address to send to, exactly in the same way:


Now, we can ask Bitcoin Core for the public key for our address, as well as many more useful information:


Then, we can copy the most interesting part: our public key. It is compressed by default, because we can get Segwit addresses by default, but it can be uncompressed as well, if we force Bitcoin Core to use that. However, in general, we should use compressed ones, because they are cheaper, and they are always standard, when wrapped into Segwit or Taproot.


Now, we are ready to make some transaction, that will send coins to some regular address. Let's just send everything we have into our Segwit address first, just to get transaction data:


I already put the proper amount, but you can go through the whole procedure first, then get transaction size in virtual bytes, and correct the amount in the end. But I already did that, so I know my transaction would take 123 virtual bytes with all signatures, so I can do it now, to not repeat commands.

Now, we can edit our transaction in Notepad, and replace our Segwit address with P2PK:


And then, we can confirm all of that, if we are not sure. First, to use different Scripts, we can use this command:


Then, if we can see "pubkey" in our "type" field, we are good to go. We should definitely avoid anything marked as "nonstandard", other outputs are usually fine, it depends, what exactly we need. But let's double check it, and decode a transaction:


As we can see, our "type" is "pubkey" in our output. Everything is fine, we can sign it.


Then, we can decode it once more, to double check everything, mainly related to fees, if we didn't know, what to put there before:


As we can see, our "vsize" is 123, which means if we want to send our transaction with one satoshi per virtual byte fee, then we can subtract 123 satoshis from our output. As I said previously, usually I put the full amount first, then create and sign my transaction, then read the amount of virtual bytes, and then do it once more with a proper fee. And, as you can see, this "txid" and "hash" matches exactly with what you can see in testnet.

See and compare: https://mempool.space/testnet/api/tx/04863e19ccf833b7d0e68f6e2173466cf97325ad1da3ba9d980c6ba05b25ede1/hex

Spending from P2PK is similar, you just use different "scriptPubKey" when you specify, what should be signed, and put "2321...ac", instead of putting the script related to other address types. Then, the Core client will sign it, and you can broadcast it directly from your node, or by using any online tool, for example this one: https://live.blockcypher.com/btc-testnet/pushtx/

By using the software bech32p2pkaddress, which takes as input a public key and builds a raw transaction wherein you spend UTXOs and create new P2PK UTXOs. You can read how it works in this medium article, asides from the Github repo.

As you can see from the software above, there is no script needed to spend the P2PK output. Bitcoin Core will normally allow you to spend the P2PK output if you give the private key in WIF and the TXID.

There are definitely more software to try out. According to this SE post, python-bitcoinlib does provide the utilities to create and spend P2PK.

Where would you recommend I start testing in practice? Using a service like Cointoolkit to semi-manually create transactions?

Wallets might not support uncompressed public keys, but you can always send and spend by using public keys alone, that's the core function of bitcoin and  can never change. Upub will require more fees though.

If you paste the public key on Electrum, it will not be recognized. Only what can be recognized are bitcoin addresses, starting from 1, 3, and bc1 (both bc1q and bc1p).

You can still send to public key, but wallets are not supporting that.

I wanted to refer to some questions in the past about checking bitcoin address on explorers that are able to know the amount paid to public key and its address, but while Electrum is displaying only the coin sent to an address. I could not see any of the topics right now.

Paying to public key is now obsolete, you should not just try it.

I don't think an introduction to P2PK is necessary in this forum. Briefly, it was popular in the early days of the blockchain and more or less abandoned for P2PHK ("Legacy", "1-addresses", or what you prefer to call them; several years later, Segwit and Taproot and yadda yadda.)

Here, consider this random 32-byte string as the starting point/private key. (I like "openssl rand -hex 32" but won't argue against other random number generation methods.)


(Never use it; the usual disclaimers.)

From it, we can derive the uncompressed public key, which will always be a 130-digit hexadecimal number (intentionally disregarding the compressed version for simplicity).


We can type out the private key in standard base58check WIF format and the corresponding public addresses on mainnet and testnet - but let's not use these for now.


What I'm not after is a lecture on whether using P2PK today is a good idea; the only question is - can we?

More specifically, the question is two-fold:

1. How would I send to the public key (NOT the public address) - in practice?
2. How would I claim the unspent transition to "only" a public key - in practice?

I think, please chime in, that the answer to the first question is straightforward. A quick-and-dirty dry-run in Electrum, and sure, I can specify the public key as to where I want to send to. I can sign the transaction, but I haven't tried it online yet, i.e. broadcast it. Would it propagate and be picked up, or would the current p2p network consider it unusual or even invalid and drop it?

The proof is in the pudding, I guess - I could try with some tBTC and see what happens. In my experience, however, just because something works on testnet, it is not guaranteed to work on mainnet.

Would the transaction go through (i.e. be picked up and included in coming blocks) on the mainnet today?

Question number 2 is more interesting, in my opinion. Let's assume I indeed can spend to a public key on mainnet using old-school (2009) kung fu. What would be the most straightforward approach to claim it? I have assumed, without actual testing, that importing the private key in Bitcoin Core or Electrum (or other wallet software) will not allow me to spend from the associated public key, since P2PK barely been used in the past decade. And that I, in that case, would need to author (there are decent online tools) the transaction manually. Yes, no?

Looking forward to your thoughts and insights!