<p>First of all, the operations <code>signmessage</code> and <code>verifymessage</code> allow to prove that whoever creates a signed message with this address specified can receive Bitcoins in that address. This does not prove the user owns the private key (corresponding to the public key the address is generated from) as this address' private key could be handled by a third-party wallet service (like an exchange), so the exchange would be able to create this signed message too (and the user may not have access to the private key).</p>

<p>With <em>P2SH</em> addresses you cannot create signed messages as they are <em>Pay-to-script-hash (P2SH)</em> addresses. This means using this addresses in outputs can only be unlocked by specifying a valid <em><a href="https://bitcoin.org/en/glossary/redeem-script" rel="nofollow noreferrer">redeem script</a></em> in a transaction that spends this outputs where the adress is specified. Therefore, not necessarily public keys must be present in the mentioned script (like a <a href="https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts" rel="nofollow noreferrer">HTLC</a>) and a signing scheme can't be developed as it would require to reveal the redeem script which may cause a serious security issue (like in HTLC after the timelock is over). </p>

<p>A fix you could try in order to get the same functionality is to create a transaction that spends this UTXO where the address is specified with a minimal amount of 1 satoshi and no outputs. This way who does this can prove they can receive Bitcoins in that address.</p>

<p>But notice the security issues revealing a <em>redeem script</em> means (for instance this would not be appropiate for a HTLC but could be for a multisig where every one agrees to create that transaction). This problem replies also to the problem with performing this operations with <em>P2WSH</em> addresses as they share the same main problem.</p>

<p>With native <em>P2WPKH</em> (and <em>P2SH-P2WPKH</em>), <a href="https://github.com/bitcoin/bitcoin/issues/10542" rel="nofollow noreferrer">a new signing scheme had to be defined due to technical issues</a>. This is already <a href="https://github.com/trezor/trezor-mcu/issues/169#issuecomment-317811585" rel="nofollow noreferrer">partially implemented</a> (just implemented with P2SH-P2WPKH addresses) in <a href="https://wallet.trezor.io" rel="nofollow noreferrer">Trezor's web wallet</a> and <a href="https://github.com/bitcoin/bitcoin/issues/10542#issuecomment-372934927" rel="nofollow noreferrer">under development in Bitcoin Core</a>.</p>

CC BY-SA 4.0
2018-06-29T22:26:08.287Z
This is a lot to decompress, but it will be a good education. I'll mark as answer once I can understand it. Good answer!
toddmo
CC BY-SA 3.0
2018-04-27T02:11:05.333Z
2018-04-27T02:16:33.303Z
2018-04-27T02:16:33.303Z
davidlj95
<p>With a legacy <code>P2PKH</code> address, <code>signmessage</code> and <code>verifymessage</code> can be used to verify that the other party actually controls the bitcoin address in question. However, <code>P2SH</code>, <code>P2WPKH</code> and <code>P2WSH</code> addresses throw an error for <code>signmessage</code>, and we don't know when or if this will be made to work. So, another procedure is necessary if we want to accomplish the same thing with segwit.</p>

<p>As a work-around, I could have the owner of the segwit address send 1 satoshi to a verification address that I create in my wallet just for them. But that's a hassle and it's off-putting to them. And what if they want their satoshi back? =D; that would be a hassle.</p>

<p>Is there a way to accomplish the same proof of ownership without them having to send me coin?</p>

<p>I prefer an answer using the json rpc on my end (But failing that, I also have access to bitwasp, and failing that, I'm open to anything that runs in php), and the easiest (manual) procedure on their end. These are non-technical ordinary users. I might be able to nudge them into using a particular wallet if that wallet has a feature which will allow them to implement the idea in a better work-around.</p>

<p><em>I didn't tag this with <code>json-rpc</code> because I don't know what technology the answer will come from.</em></p>

<message-signing>
How can I verify someone controls the private key behind a segwit address?
toddmo
# How can I verify someone controls the private key behind a segwit address?

(Asked by: username_0 on 2018-04-24)

With a legacy `P2PKH` address, `signmessage` and `verifymessage` can be used to verify that the other party actually controls the bitcoin address in question. However, `P2SH`, `P2WPKH` and `P2WSH` addresses throw an error for `signmessage`, and we don't know when or if this will be made to work. So, another procedure is necessary if we want to accomplish the same thing with segwit.

As a work-around, I could have the owner of the segwit address send 1 satoshi to a verification address that I create in my wallet just for them. But that's a hassle and it's off-putting to them. And what if they want their satoshi back? =D; that would be a hassle.

Is there a way to accomplish the same proof of ownership without them having to send me coin?

I prefer an answer using the json rpc on my end (But failing that, I also have access to bitwasp, and failing that, I'm open to anything that runs in php), and the easiest (manual) procedure on their end. These are non-technical ordinary users. I might be able to nudge them into using a particular wallet if that wallet has a feature which will allow them to implement the idea in a better work-around.

*I didn't tag this with `json-rpc` because I don't know what technology the answer will come from.*

**Tags:** message-signing


---

## 1 answers

### Answer by username_1 on 2018-04-27. Score: 1

First of all, the operations `signmessage` and `verifymessage` allow to prove that whoever creates a signed message with this address specified can receive Bitcoins in that address. This does not prove the user owns the private key (corresponding to the public key the address is generated from) as this address' private key could be handled by a third-party wallet service (like an exchange), so the exchange would be able to create this signed message too (and the user may not have access to the private key).

With *P2SH* addresses you cannot create signed messages as they are *Pay-to-script-hash (P2SH)* addresses. This means using this addresses in outputs can only be unlocked by specifying a valid *[redeem script](https://bitcoin.org/en/glossary/redeem-script)* in a transaction that spends this outputs where the adress is specified. Therefore, not necessarily public keys must be present in the mentioned script (like a [HTLC](https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts)) and a signing scheme can't be developed as it would require to reveal the redeem script which may cause a serious security issue (like in HTLC after the timelock is over).

A fix you could try in order to get the same functionality is to create a transaction that spends this UTXO where the address is specified with a minimal amount of 1 satoshi and no outputs. This way who does this can prove they can receive Bitcoins in that address.

But notice the security issues revealing a *redeem script* means (for instance this would not be appropiate for a HTLC but could be for a multisig where every one agrees to create that transaction). This problem replies also to the problem with performing this operations with *P2WSH* addresses as they share the same main problem.

With native *P2WPKH* (and *P2SH-P2WPKH*), [a new signing scheme had to be defined due to technical issues](https://github.com/bitcoin/bitcoin/issues/10542). This is already [partially implemented](https://github.com/trezor/trezor-mcu/issues/169#issuecomment-317811585) (just implemented with P2SH-P2WPKH addresses) in [Trezor's web wallet](https://wallet.trezor.io) and [under development in Bitcoin Core](https://github.com/bitcoin/bitcoin/issues/10542#issuecomment-372934927).

> **Comments:**
> **username_0**: This is a lot to decompress, but it will be a good education. I'll mark as answer once I can understand it. Good answer!  

---

