From: Alex Nagy <optimiz3@hotmail•com>
To: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] P2WPKH Scripts, P2PKH Addresses, and Uncompressed Public Keys
Date: Mon, 28 Aug 2017 15:29:31 +0000 [thread overview]
Message-ID: <CY4PR1801MB181583C344B0993205D4B6C8809E0@CY4PR1801MB1815.namprd18.prod.outlook.com> (raw)
[-- 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 --]
next reply other threads:[~2017-08-28 15:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-28 15:29 Alex Nagy [this message]
[not found] ` <CAAS2fgT+HHg_xuuWuGrYcX0ALcBowmY-1Kt6-dzSBOwdcr08HQ@mail.gmail.com>
2017-08-28 17:06 ` [bitcoin-dev] Fwd: " Gregory Maxwell
2017-08-28 20:55 ` [bitcoin-dev] " Alex Nagy
2017-08-29 3:30 ` Johnson Lau
2017-09-04 13:51 ` Peter Todd
2017-08-28 21:33 ` Mark Friedenbach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CY4PR1801MB181583C344B0993205D4B6C8809E0@CY4PR1801MB1815.namprd18.prod.outlook.com \
--to=optimiz3@hotmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox