For what it’s worth, I think it would be quite easy to do better than the implied solution of rejiggering the message signing system to support non-P2PKH scripts. Instead, have the signature be an actual bitcoin transaction with inputs that have the script being signed. Use the salted hash of the message being signed as the FORKID as if this were a spin-off with replay protection. This accomplishes three things:
(1) This enables signing by any infrastructure out there — including hardware wallets and 2FA signing services — that have enabled support for FORKID signing, which is a wide swath of the ecosystem because of Bitcoin Cash and Bitcoin Gold.
(2) It generalizes the message signing to allow multi-party signing setups as complicated (via sighash, etc.) as those bitcoin transactions allow, using existing and future tools based on Partially Signed Bitcoin Transactions; and
(3) It unifies a single approach for message signing, proof of reserve (where the inputs are actual UTXOs), and off-chain colored coins.
There’s the issue of size efficiency, but for the single-party message signing application that can be handled by a BIP that specifies a template for constructing the pseudo-transaction and its inputs from a raw script.
Mark
> On Dec 19, 2017, at 1:36 PM, Pavol Rusnak via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On 08/12/17 19:25, Dan Bryant via bitcoin-dev wrote:
>> I know there are posts, and an issue opened against it, but is there
>> anyone writing a BIP for Sign / Verify message against a SegWit address?
>
> Dan, are you still planning to write this BIP?
>
> --
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> CTO, SatoshiLabs
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev