Segwit message signing is not compatible with other software

[SomberNight]

AFAICT there is no clear consensus how to sign messages with segwit addresses (txin type of p2wpkh-p2sh and p2wpkh)

We do one thing, and Trezor does something else. Bitcoin Core so far has this disabled.
Maybe we could transition to what Trezor does, in a way that:

• signatures created by new Electrum
  • can be verified by new Electrum software, but not verified by old
• signatures created by old Electrum
  • can be verified by both new and old Electrum

---

Electrum issue/commit

• Message signing with bech32 addresses crashes Electrum #2977 (comment)
• e299df7

Bitcoin Core issue

• Signmessage doesn't work with segwit addresses bitcoin/bitcoin#10542 (comment)

Trezor issue/commit/tests

• SignMessage / VerifyMessage does not work correctly for Segwit addresses trezor/trezor-mcu#169 (comment)
• trezor/trezor-mcu@b5f9a57
• trezor/python-trezor@11b686a
• https://github.com/trezor/trezor-firmware/blob/2ce1e6ba7dbe5bbaeeb336fff0a038e59cb40ef8/tests/device_tests/bitcoin/test_signmessage.py

gribble PR doing what Electrum does

• SegWit address registration, authentication and switching nanotube/supybot-bitcoin-marketmonitor#80

[ecdsa]

I don't mind following what trezor does.
The only drawback is that we might have to change it again if Core introduces a new method

[matejcik]

at the moment Trezor-generated signatures will fail to verify in Electrum because how from_signature65 decodes it. That's probably worth fixing, without touching the other parts.

[Giszmo]

Is there any consensus yet on test vectors?

[SomberNight]

There have been two related new BIPs submitted in recent months:

• BIP-0322 which is a very generic scheme for which I don't foresee widespread support anytime soon (although there is a pending Bitcoin Core PR)
• BIP-0137 -- someone submitted what Trezor has been doing as a BIP

Do we know of anyone else that is compatible with Trezor? If so, maybe we should do that too to make some progress... :)

[brianddk]

Perhaps on verification, you can attempt the process on both forms of the signature header-byte. It is trivial to to determine if the address presented to verify against is P2PKH, P2SH, or P2WPKH.

If your verifying against a P2WPKH address with a signature header byte between 39-42, just subtract 8 from the header byte and do the verification as it exists today. If you have a P2SH address with a signature header byte between 35 and 28, just subtract 4 from the header byte and do the verification.

This would make your message verification both BIP-0137 complaint and backward compatible with messages already generated. Perhaps ask for similar flexibility of the Trezor FW then both BIP-0137 and non-BIP-0137 signatures can be interchangeable regardless of what standard is used in their generation.

[SomberNight]

Regarding BIP-0322, to me it looks really scary. I am not sure how we would implement that. It seems to properly implement it, we would need a full fledged consensus validator and a script interpreter. If you read the BIP, to me, it seems evident that it was written for Bitcoin Core.

Consider this quote for example:

Verify Script with flags=consensus flags (currently P2SH, DERSIG, NULLDUMMY, CLTV, CSV, WITNESS), scriptSig=script sig, scriptPubKey=scriptPubKey, witness=witness, and sighash=sighash

or this section: https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki#consensus-and-standard-flags

How are light clients supposed to implement this?

I guess we could conceivably implement signing support via hardcoded templates for the scripts we support. About validation... well not sure; but I expect we would return INCONCLUSIVE for anything we don't recognise.

[pinheadmz]

With the recent merge of bcoin-org/bcoin#802 into bcoin...

bcoin now supports Bitcoin Message Signing with bech32 addresses!

bc1q5gcvs0hq7hrtm5tt2ra3fq4jtt46f5n4t4zfn7

H+n6A3V2asu5fZ5nifIlleZvdJXPc+MiKghDgBjFPt6DcePVFEc6ZOxlhiF87oU/WxTj2uMX41uuPsFFP3qocJw=