[bitcoin-dev] P2WPKH Scripts, P2PKH Addresses, and Uncompressed Public Keys

[bitcoin-dev] P2WPKH Scripts, P2PKH Addresses, and Uncompressed Public Keys

[Alex Nagy]

[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]

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."

[-- Attachment #2: Type: text/html, Size: 4877 bytes --]

[bitcoin-dev] Fwd: P2WPKH Scripts, P2PKH Addresses, and Uncompressed Public Keys

[Gregory Maxwell]

On Mon, Aug 28, 2017 at 3:29 PM, Alex Nagy via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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.

Re: [bitcoin-dev] P2WPKH Scripts, P2PKH Addresses, and Uncompressed Public Keys

[Alex Nagy]

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:gmaxwell@gmail.com] 
Sent: Monday, August 28, 2017 10:04 AM
To: Alex Nagy <optimiz3@hotmail.com>; Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] P2WPKH Scripts, P2PKH Addresses, and Uncompressed Public Keys

On Mon, Aug 28, 2017 at 3:29 PM, Alex Nagy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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.

Re: [bitcoin-dev] P2WPKH Scripts, P2PKH Addresses, and Uncompressed Public Keys

[Mark Friedenbach]

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]


> On Aug 28, 2017, at 8:29 AM, Alex Nagy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> 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.

[-- Attachment #2: Type: text/html, Size: 1485 bytes --]

Re: [bitcoin-dev] P2WPKH Scripts, P2PKH Addresses, and Uncompressed Public Keys

[Johnson Lau]

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.
 

> On 29 Aug 2017, at 4:55 AM, Alex Nagy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> 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.
> 

Re: [bitcoin-dev] P2WPKH Scripts, P2PKH Addresses, and Uncompressed Public Keys

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]

On Mon, Aug 28, 2017 at 08:55:47PM +0000, Alex Nagy via bitcoin-dev wrote:
> 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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]