Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 06AF81083 for ; Tue, 13 Mar 2018 13:26:22 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255038.outbound.protection.outlook.com [40.92.255.38]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 618FA8B for ; Tue, 13 Mar 2018 13:26:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+Zazh3ExM4tyhqaVqrsKC0PJHyJQCEugSU8FM6o3lVk=; b=U573qC+P7n190Tk9/wLVlWK9nFy7KkOPFol3k0Sr9IvaPOtl2ujyNezUm+kmvw52fK9gvXldCWJbT1LeDhHa7x/516B4tlTu+HCJANejlI6pqW1JPWnoRNS4Cnb0gAHc5l4F5ofb844oKxy2xmBwoNckba3vLytAmmVfdNOG6l1Eo0EA/jfhYCPWRi80GQwhaGVJUtG1N5jmFIpPC2ms3O/+SKJhF53W+OuBpKKY6ZdAA/yu5U3rRZg2j5bqarIPYoT2rej4waraW2isggkmusOlYPhKN7WO86xqoMRMwCryYa23T4S8NT8Q0mooroRMyre7+X4MNKT+Kk/afROrQA== Received: from PU1APC01FT053.eop-APC01.prod.protection.outlook.com (10.152.252.60) by PU1APC01HT079.eop-APC01.prod.protection.outlook.com (10.152.253.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.16; Tue, 13 Mar 2018 13:26:18 +0000 Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM (10.152.252.51) by PU1APC01FT053.mail.protection.outlook.com (10.152.253.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.567.16 via Frontend Transport; Tue, 13 Mar 2018 13:26:18 +0000 Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM ([10.171.225.19]) by PS2P216MB0179.KORP216.PROD.OUTLOOK.COM ([10.171.225.19]) with mapi id 15.20.0548.021; Tue, 13 Mar 2018 13:26:18 +0000 From: Damian Williamson To: "bitcoin-dev@lists.linuxfoundation.org" Thread-Topic: [bitcoin-dev] Sign / Verify message against SegWit P2SH and Bech32 addresses Thread-Index: AQHTus0axltfECZTu0GoJJnO+22Qvw== Date: Tue, 13 Mar 2018 13:26:17 +0000 Message-ID: Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:2C69444809BFAC23F07849FFCF6282ABFC27CB93772DCF61C018C1C7B6458DC1; UpperCasedChecksum:6205E2641490E582BA5CD640632C2EAA35943EEBFC05E7762AD307834909CFDD; SizeAsReceived:6954; Count:44 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [AI2/8KtEEnUyOYW0RxVToxWihtSnrqo5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; PU1APC01HT079; 6:wAX8DndB2ZAPgiqetJsae9bKzGFVreAdqZlh/1Hd/tii46FssGqP4ZLHRDTOh3Vji1nhrDJiqprYyY/uLKZhQHpDDgR4Evn7LVMWc63ClOLCbNKjvPhmiTDdcfvw7eksQBV+wKHvR+hn7REUpVptW4yz58Qw03OMfG/vNxeFSpWKAwAdJ41A60ow9/JBumGMbe1mzXBIs1+DRW+mfrmHkjnsm6FsUM7c22x5Atzasp6kT/7leQv9/tDaR+qJramegBsyTJq0KEfr55cOyR40sqnDHsvRR8QukcBEkVnkUPuFhaXf+OOsRPpFXFfq+riqfogfeyBeHhV0jEE7aqnWbk/Si1jiF5izNJweF2arEn8=; 5:GssxQ9TfrFrWulZX+MPTsIyD2YuHxNRm6qUGHKKSu8O+nSLeIOY2VstUMsWfYE53zKs5kQMCZuf11FnC2crj6YKyxSGg33t5K2Io0wDTjf3D7cj+NrwgY5qhilKYFZntq+wGWKUnP6T30u50vGtgo8Ia4bljeWoPJPRMrV9d8EY=; 24:kyjlb+CAomC6/lNzMdk8q9aeqsSjyR26dDLSdM3FoMrTvbfw2d5CVaHla1Ld5uQiUibbF/Rk6KI59mtOsN+yWIUWOIJ/QVfRkty9w2pc1TQ=; 7:IctNRNJ0XymETvlkmKvsP/RbRnBxjO7uVRj++9uwhVQXRuG9vwpM0ufI2SLr3LJlrg9tXxgHNtcqIG7dx8mJnbRipM0lwRrXPJf8E9CIAneYEP8W64koFp48DTMQNJJpGXUI4peZG3xrX7yPW1R037i5oM7XDA+q7ezzKD45J1kDk840GbRhQP1mTRZyNu/4qM5Z8lSdzhF0NTuUSUCIa/QAXabuPK9DQwWRmt08B2COH87visqfSqqeT7PRuLdE x-incomingheadercount: 44 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:PU1APC01HT079; x-ms-traffictypediagnostic: PU1APC01HT079: x-ms-office365-filtering-correlation-id: db232b18-e346-431d-f98c-08d588e600dd x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:PU1APC01HT079; BCL:0; PCL:0; RULEID:; SRVR:PU1APC01HT079; x-forefront-prvs: 0610D16BBE x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:PU1APC01HT079; H:PS2P216MB0179.KORP216.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:; x-microsoft-antispam-message-info: J8my2RcL4gEoF1D12/5R1H4EmwY1Ac9lR55iYrtijCmu+BEfVq3yAzMC7fuhWEX62n66YHSsd2hNa61L5Atvm1hqE5sPOx2e+W5yQnFew6VJVUOou4S2PBYTcoc7M8SWpey7CibpCmSAjtQgxekItPfJauzcK14XSybGMdVKZvnogMY8QW4eU+x/jFgBzrbS spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_PS2P216MB017926BA48E2A8E1B4E17BBE9DD20PS2P216MB0179KORP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: db232b18-e346-431d-f98c-08d588e600dd X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2018 13:26:17.8539 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT079 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 13 Mar 2018 13:50:45 +0000 Subject: [bitcoin-dev] Sign / Verify message against SegWit P2SH and Bech32 addresses X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 13:26:22 -0000 --_000_PS2P216MB017926BA48E2A8E1B4E17BBE9DD20PS2P216MB0179KORP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Current implementation of sign/verify is broken for SegWit and Bech32 addre= sses. Please add the following reference to the use cases: --- # Does blockchain.info show balances for addresses that are in cold storage= ? Yes. >... is there any way for me in another country to confirm that what my col= league views is actually accurate and correct? Since they use Bitcoin Core, yes, there is a way to verify that they hold t= he addresses that they claim. Have them sign a message with each address th= at they claim to have the holdings on, using Bitcoin Core you can verify th= at they indeed have those addresses and check them on blockchain.info to fi= nd the current balance. Only works in Bitcoin Core currently for addresses starting with a '1' (not= Segwit addresses starting with a '3' and not Bech32 addresses starting wit= h 'bc1' - the developers are aware of this and I will remind them shortly.) In Bitcoin Core, your transaction opposite goes to File -> Sign Message and= signs any message with one of the holding addresses. Copy the message, add= ress and signature and send to you via probably plain text format email is = the easiest. Repeat for each additional address holding the balance of BTC = that they are offering to sell. In Bitcoin Core, you go to File -> Verify Message and key the details provi= ded EXACTLY - spaces, new lines and all characters must be an EXACT match. = Click on verify and voil=E0. I prefer the form of signed message as follows (don't key the top and botto= m bar rows for the message, just the contents and you can check this yourse= lf, the bottom row is the signature). I like to key the address used for ve= rifying as a part of the message but that is not strictly necessary: ------------------------------ Something that I want to sign. bitcoin:1PMUf9aaQ41M4bgVbCAPVwAeuKvj8CwxJg ------------------------------ Signture: IGaXlQNRHHM6ferJ+Ocr3cN9dRJhIWxo+n9PGwgg1uPdOLVYIeCuaccEzDygVgYPJMXqmQe= SaLaZVoG6FMHPJkg=3D This contains all of the compact information necessary to verify the messag= e. Example of verified message: ![verified message][1] [1]: https://i.stack.imgur.com/zv1xq.png --- https://bitcoin.stackexchange.com/a/72281/75001 Solution seems to be straight-forward, as noted in Issue# [10542](https://g= ithub.com/bitcoin/bitcoin/issues/10542#issuecomment-306584383) >And it would in theory be possible to make signmessage work for a P2SH-P2W= PKH address, in cases where the verifier knows the embedded pubkeyhash alre= ady. But in that case you don't need "sign with a witness address" function= ality - *you could just sign with the embedded key (see validateaddress), a= nd have the verifier check that*. >The point is to not further the misunderstanding that signmessage signs wi= th an address - it never did. It signs with a keyhash, and verify with a ke= yhash. This is an important feature, there are few other ways to verify that an ad= dress is held. Note that the linked issue is not currently labeld GUI and p= robably could be - unless a new issue should also be opened? Regards, Damian Williamson --_000_PS2P216MB017926BA48E2A8E1B4E17BBE9DD20PS2P216MB0179KORP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Current implementation of sign/ve= rify is broken for SegWit and Bech32 addresses.


Please add the following referenc= e to the use cases:

---

# Does blockchain.info show balances for addresses that are in cold st= orage?

Yes.

>... is there any way for me in another country to confirm that what my = colleague views is actually accurate and correct?

Since they use Bitcoin Core, yes, there is a way to verify that they hold t= he addresses that they claim. Have them sign a message with each address th= at they claim to have the holdings on, using Bitcoin Core you can verify th= at they indeed have those addresses and check them on blockchain.info to find the current balance.

Only works in Bitcoin Core currently for addresses starting with a '1' (not= Segwit addresses starting with a '3' and not Bech32 addresses starting wit= h 'bc1' - the developers are aware of this and I will remind them shortly.)=

In Bitcoin Core, your transaction opposite goes to File -> Sign Message = and signs any message with one of the holding addresses. Copy the message, = address and signature and send to you via probably plain text format email = is the easiest. Repeat for each additional address holding the balance of BTC that they are offering to sell.

In Bitcoin Core, you go to File -> Verify Message and key the details pr= ovided EXACTLY - spaces, new lines and all characters must be an EXACT matc= h. Click on verify and voil=E0.

I prefer the form of signed message as follows (don't key the top and botto= m bar rows for the message, just the contents and you can check this yourse= lf, the bottom row is the signature). I like to key the address used for ve= rifying as a part of the message but that is not strictly necessary:

    ------------------------------
    Something that I want to sign.
    
    bitcoin:1PMUf9aaQ41M4bgVbCAPVwAeuKvj8CwxJg
    ------------------------------
    Signture:
    IGaXlQNRHHM6ferJ+Ocr3cN9dRJhIWxo+n9PGwgg1uPdOLVY= IeCuaccEzDygVgYPJMXqmQeSaLaZVoG6FMHPJkg=3D

This contains all of the compact information necessary to verify the messag= e.

Example of verified message:  
![verified message][1]

[1]: https://i.stack.imgur.com/zv1xq.png

---

https://bitcoin.stackexchange.com/a/72281/75001



Solution seems to be straight-for= ward, as noted in Issue# [10542](https://github.com/bitcoin/bitcoin/issues/10= 542#issuecomment-306584383)


>And it would in theory be pos= sible to make signmessage work for a P2SH-P2WPKH address, in cases where the= verifier knows the embedded pubkeyhash already. But in that case you don't= need "sign with a witness address" functionality - *you could ju= st sign with the embedded key (see validateaddress), and have the verifier check that*.


>The point is to not further the misunderstanding that signmess= age signs with an address - it never did. It signs with a keyhash, a= nd verify with a keyhash.


This is an important feature, there are few other ways to verify that an= address is held. Note that the linked issue is not currently labeld GUI an= d probably could be - unless a new issue should also be opened?


Regards,

Damian Williamson


--_000_PS2P216MB017926BA48E2A8E1B4E17BBE9DD20PS2P216MB0179KORP_--