Alex Nagy [ARCHIVE] on Nostr: 📅 Original date posted:2017-08-28 📝 Original message:Thanks Gregory - to be ...
📅 Original date posted:2017-08-28
📝 Original 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:gmaxwell at gmail.com]
Sent: Monday, August 28, 2017 10:04 AM
To: Alex Nagy <optimiz3 at hotmail.com>; Bitcoin Protocol Discussion <bitcoin-dev at 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 at 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.
📝 Original 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:gmaxwell at gmail.com]
Sent: Monday, August 28, 2017 10:04 AM
To: Alex Nagy <optimiz3 at hotmail.com>; Bitcoin Protocol Discussion <bitcoin-dev at 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 at 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.