Alex Nagy [ARCHIVE] on Nostr: 📅 Original date posted:2017-08-28 📝 Original message:Let's say Alice has a ...
📅 Original date posted:2017-08-28
📝 Original 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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170828/9facf9a0/attachment.html>;
📝 Original 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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170828/9facf9a0/attachment.html>;