Discussion:
P2WPKH Scripts, P2PKH Addresses, and Uncompressed Public Keys
Add Reply
Alex Nagy via bitcoin-dev
2017-08-28 15:29:31 UTC
Reply
Permalink
Raw Message
Let's say Alice has a P2PKH address derived from an uncompressed public key, 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a (from https://bitcoin.stackexchange.com/questions/3059/what-is-a-compressed-bitcoin-key).

If Alice gives Bob 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a, is there any way Bob can safely issue Native P2WPKH outputs to Alice?

BIPs 141 and 143 make it very clear that P2WPKH scripts may only derive from compressed public-keys. Given this restriction, assuming all you have is a P2PKH address - is there any way for Bob to safely issue spendable Native P2WPKH outputs to Alice?

The problem is Bob as no idea whether Alice's P2PKH address represents a compressed or uncompressed public-key, so Bob cannot safely issue a Native P2WPKH output.

AFAICT all code is supposed to assume P2WPHK outputs are compressed public-key derived. The conclusion would be that the existing P2PKH address format is generally unsafe to use with SegWit since P2PKH addresses may be derived from uncompressed public-keys.

Am I missing something here?





Referencing BIP141 and BIP143, specifically these sections:

https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#New_script_semantics

"Only compressed public keys are accepted in P2WPKH and P2WSH"

https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Restrictions_on_public_key_type

"As a default policy, only compressed public keys are accepted in P2WPKH and P2WSH. Each public key passed to a sigop inside version 0 witness program must be a compressed key: the first byte MUST be either 0x02 or 0x03, and the size MUST be 33 bytes. Transactions that break this rule will not be relayed or mined by default.

Since this policy is preparation for a future softfork proposal, to avoid potential future funds loss, users MUST NOT use uncompressed keys in version 0 witness programs."
Gregory Maxwell via bitcoin-dev
2017-08-28 17:06:04 UTC
Reply
Permalink
Raw Message
On Mon, Aug 28, 2017 at 3:29 PM, Alex Nagy via bitcoin-dev
Post by Alex Nagy via bitcoin-dev
If Alice gives Bob 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a, is there any way Bob
can safely issue Native P2WPKH outputs to Alice?
Absolutely not. You can only pay people to a script pubkey that they
have specified.

Trying to construct some alternative one that they didn't specify but
in theory could spend would be like "paying someone" by putting a
cheque in a locked safe labeled "danger radioactive" that you quietly
bury in their back yard. Or taking the payment envelope they gave you
stuffing it with cash after changing the destination name to pig latin
and hiding it in the nook of a tree they once climbed as a child.

There have been technical reasons why some wallets would sometimes
display some outputs they didn't generate but could spend, but these
cases are flaws-- they're not generic for all cases they could in
theory spend, and mostly exist because durability to backup recovery
makes it impossible for it to tell what it did or didn't issue.

So regardless of your query about uncompressed keys, you cannot do
what you described: Wallets will not see the payment and may have no
mechanism to recover it even if you tell the recipient what you've
done. And yes, the use of an uncompressed yet could later render it
unspendable.
Alex Nagy via bitcoin-dev
2017-08-28 20:55:47 UTC
Reply
Permalink
Raw Message
Thanks Gregory - to be clear should Native P2WPKH scripts only appear in redeem scripts? From reading the various BIPs it had seemed like Native P2WPKH and Native P2WSH were also valid and identifiable if they were encoded in TxOuts. The theoretical use case for this would be saving bytes in Txes with many outputs.

-----Original Message-----
From: Gregory Maxwell [mailto:***@gmail.com]
Sent: Monday, August 28, 2017 10:04 AM
To: Alex Nagy <***@hotmail.com>; Bitcoin Protocol Discussion <bitcoin-***@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] P2WPKH Scripts, P2PKH Addresses, and Uncompressed Public Keys
Post by Alex Nagy via bitcoin-dev
If Alice gives Bob 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a, is there any
way Bob can safely issue Native P2WPKH outputs to Alice?
Absolutely not. You can only pay people to a script pubkey that they have specified.

Trying to construct some alternative one that they didn't specify but in theory could spend would be like "paying someone" by putting a cheque in a locked safe labeled "danger radioactive" that you quietly bury in their back yard. Or taking the payment envelope they gave you stuffing it with cash after changing the destination name to pig latin and hiding it in the nook of a tree they once climbed as a child.

There have been technical reasons why some wallets would sometimes display some outputs they didn't generate but could spend, but these cases are flaws-- they're not generic for all cases they could in theory spend, and mostly exist because durability to backup recovery makes it impossible for it to tell what it did or didn't issue.

So regardless of your query about uncompressed keys, you cannot do what you described: Wallets will not see the payment and may have no mechanism to recover it even if you tell the recipient what you've done. And yes, the use of an uncompressed yet could later render it unspendable.
Johnson Lau via bitcoin-dev
2017-08-29 03:30:07 UTC
Reply
Permalink
Raw Message
Yes it is allowed in TxOuts. And yes it is designed to save space. But the problem is Bob can’t assume Alice understands the new TxOuts format. If Bob really wants to save space this way, he should first ask for a new BIP173 address from Alice. Never try to convert a P2PKH address to a P2SH or BIP173 address without the consent of the recipient.
Post by Alex Nagy via bitcoin-dev
Thanks Gregory - to be clear should Native P2WPKH scripts only appear in redeem scripts? From reading the various BIPs it had seemed like Native P2WPKH and Native P2WSH were also valid and identifiable if they were encoded in TxOuts. The theoretical use case for this would be saving bytes in Txes with many outputs.
Peter Todd via bitcoin-dev
2017-09-04 13:51:35 UTC
Reply
Permalink
Raw Message
Post by Alex Nagy via bitcoin-dev
Thanks Gregory - to be clear should Native P2WPKH scripts only appear in redeem scripts? From reading the various BIPs it had seemed like Native P2WPKH and Native P2WSH were also valid and identifiable if they were encoded in TxOuts. The theoretical use case for this would be saving bytes in Txes with many outputs.
It's not a theoretical use-case: the two OpenTimestamps calendar servers I run
- {alice,bob}.btc.calendar.opentimestamps.org - use native P2WPKH segwit
outputs to keep transaction size to the absolute minimum possible; previously
they used bare CHECKSIG <pubkey> output scripts for the same reason.

I enabled support for it the moment segwit activated, so I'm probably the first
ever production user of P2WPKH on mainnet, and quite possibly, the first person
to create P2WPKH outputs on mainnet for any reason.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
Mark Friedenbach via bitcoin-dev
2017-08-28 21:33:52 UTC
Reply
Permalink
Raw Message
Post by Alex Nagy via bitcoin-dev
If Alice gives Bob 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a, is there any way Bob can safely issue Native P2WPKH outputs to Alice?
No, and the whole issue of compressed vs uncompressed is a red herring. If Alice gives Bob 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a, she is saying to Bob “I will accept payment to the scriptPubKey [DUP HASH160 PUSHDATA(20)[e4e517ee07984a4000cd7b00cbcb545911c541c4] EQUALVERIFY CHECKSIG]”.

Payment to any other scriptPubKey may not be recognized by Alice.
Loading...