From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2B1E3C0051 for ; Thu, 1 Oct 2020 09:05:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 0AE5E86B96 for ; Thu, 1 Oct 2020 09:05:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1Y6Wi+L6EHR for ; Thu, 1 Oct 2020 09:05:18 +0000 (UTC) X-Greylist: delayed 00:08:39 by SQLgrey-1.7.6 Received: from mta54.mta.hdems.com (mta54.mta.hdems.com [3.112.23.21]) by whitealder.osuosl.org (Postfix) with ESMTPS id 16E2D86B83 for ; Thu, 1 Oct 2020 09:05:17 +0000 (UTC) Received: from mo.hdems.com (unknown [10.5.20.53]) by mta54.mta.hdems.com ('HDEMS') with ESMTPSA id 4C26S505nwz2K1rZy for ; Thu, 1 Oct 2020 08:56:37 +0000 (UTC) X-HDEMS-MO-TENANT: garage.co.jp Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com. [209.85.208.200]) by gwsmtp.prod.mo.hdems.com with ESMTPS id gwsmtpd-trans-c00ffdb9-fcaf-4d37-9273-678747fc6508 for ; Thu, 01 Oct 2020 08:56:35 +0000 Received: by mail-lj1-f200.google.com with SMTP id o13so1038043ljp.18 for ; Thu, 01 Oct 2020 01:56:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=garage.co.jp; s=google; h=mime-version:from:date:message-id:subject:to; bh=otk0mgXoh9m/VQT4FZ/+SDm+7EwlvBrep/OyMoKXUXI=; b=PC5acFafhPwjVgaxXGWOKEd9CMBbFN6x5OEBT45F+Nd0STYny+1HjSCevfQz0C2hkx nKc/pA5ITUTr0u98/qPSNj7d5Wz0OLfvsbXxQ+ZmPTDF9GLQ38JDohbFHK86pwQLQeqX 8vD6oZeDLc9tcmMt1MN6QtDHk7u+ZxR4P977E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=otk0mgXoh9m/VQT4FZ/+SDm+7EwlvBrep/OyMoKXUXI=; b=eGfnhV5IQdVvrx6njrG97OaDl2YBsOiD0aZU8gV5JgoXGWpXq41S7/cTC2rlceex6u 2W6BwA1E4ddeKyzloinEyjSxqYZC98H29NzaDHOZE2ZwMxmR0Oo7m9qdjuTmhtdX1dyN CDVcNKsva+ZeDC/rEnFBL5/gDVwc+lJfd5hTsG9BvpjTFQqF8pTDdbcRdshmnZMdnmqd u1balnaTl2coMXEtrOHxDdbGpZftpHP83a6CRkNLjyBmDk7oDtYMFTZWBfYg3iQGicC4 tQJzDDH0syl99GfDa1wLthUWV/cRy7RqbY3Au/pr1cMu5oAK04g4GhwLQQWUVtkbzKtj O9cg== X-Gm-Message-State: AOAM532ojbbWc+M4xWEhXzGcFDsYMpmZjDd1QgUzpS0L2RkpL/0Qpi/T NfNt0FGsQaHyUDrUMhQMMmgP8OHr/oLb3vcvJaINMQgUlYTktoTNzvIkxOG+PeQ3ddZpXRpAv/J 1aZeaSQJHfF2vFACGpM2XTdbhmtkSCdjPZkecAHzBTOPIXIcjI6zvWN7pxBK6InoCGwK/lF6f3u KxQoey6lAqkxvKY4vTuobU8Dn6c+ox3W2Hi9l09RVpCGOeOj7QhPJNTyFcDsE/OLxngg31gNGJ0 ffY4sMii/DJ0pdT1OTCdvUbkWY52tOvsatEKEtGuU9HmsvyYtcPktWElt1/vMypV843gLv2KbRe 9x1Uo0TfSrHtc+C47tBmsObFqzI5 X-Received: by 2002:a05:6512:2107:: with SMTP id q7mr2446069lfr.63.1601542592306; Thu, 01 Oct 2020 01:56:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzwqyOb+Y9P+D03ALi2iCheIjMsNPZvalPAHNSMLK34rTkQKDL9ksCKB5+o8rwQ6FyCKMeJwPg+TsJQicOBaO0= X-Received: by 2002:a05:6512:2107:: with SMTP id q7mr2446053lfr.63.1601542591772; Thu, 01 Oct 2020 01:56:31 -0700 (PDT) MIME-Version: 1.0 From: Karl-Johan Alm Date: Thu, 1 Oct 2020 17:56:15 +0900 Message-ID: To: Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" Subject: [bitcoin-dev] Message signing (again) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 09:05:22 -0000 Hello, I have updated the signmessage proposal (BIP-322) to use the same approach as signet uses, which brings out of the box support for psbt and such, and removes the need for a custom signer and validator (well, sort of anyway). In the process, I've also replaced the concatenation approach (hash("Bitcoin Signed Message || ")) with a BIP340-tagged-hash approach (h/t @ajtowns). Not much remains of the old BIP, so I am tentatively submitting this as a replacement proposal. I'd be totally fine with submitting this as an updated BIP-322 though, if people prefer that. Pull request is here: https://github.com/bitcoin/bips/pull/1003 Viewable version: https://github.com/bitcoin/bips/blob/ce60832ef41301105a95c15dcd854d8ecbc53e00/bip-signmessage-redone.mediawiki Inline version: 
BIP: ????
Layer: Applications
Title: Generic Signed Message Format
Author: Karl-Johan Alm 
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
Status: Draft
Type: Standards Track
Created: 2020-10-01
License: CC0-1.0
Replaces: 322
== Abstract == A standard for interoperable generic signed messages based on the Bitcoin Script format. == Background == * Assume two actors, a prover P and a verifier V. * P wants to prove that they own the private key k associated with a given address A (which in turn is derived from the pubkey kG). * Let V generate a message M and hand this to P. * P generates a signature S by signing the message M using k. Given S, V can prove that P has the private key associated with A. The astute reader will notice that the above is missing a critical part, namely the pubkey kG, without which the verifier cannot actually verify the message. The current message signing standard solves this via a cryptographic trick, wherein the signature S above is a special "recoverable signature" type. Given the message M and the signature S, it is then possible to recover the pubkey kG. The system thus derives the address for the pubkey kG, and if it does not match A, the proof is deemed invalid. While this is a neat trick, it unnecessarily restricts and complicates the message signing mechanism; for instance, it is currently not possible to sign a message for a P2SH address, because there is no pubkey to recover from the resulting signature. == Motivation == The current message signing standard only works for P2PKH (1...) addresses. By extending it to use a Bitcoin Script based approach, it could be made more generic without causing a too big burden on implementers, who most likely have access to Bitcoin Script interpreters already. == Specification == This BIP follows the specification of BIP-325 challenges and solutions. Let there be two virtual transactions to_spend and to_sign. The "to_spend" transaction is: nVersion = 0 nLockTime = 0 vin[0].prevout.hash = 0000...000 vin[0].prevout.n = 0xFFFFFFFF vin[0].nSequence = 0 vin[0].scriptSig = OP_0 PUSH32[ message_hash ] vin[0].scriptWitness = [] vout[0].nValue = 0 vout[0].scriptPubKey = message_challenge where message_hash is a BIP340-tagged hash of the message, i.e. sha256_tag(m), where tag = "BIP????-signed-message", and message_challenge is the to be proven (public) key script. The "to_sign" transaction is: nVersion = 0 nLockTime = 0 vin[0].prevout.hash = to_spend.txid vin[0].prevout.n = 0 vin[0].nSequence = 0 vout[0].nValue = 0 vout[0].scriptPubKey = message_signature It may include other inputs, to facilitate a proof of funds. A message signature is considered valid, inconclusive, or invalid based on whether the to_sign transaction is a valid spend of the to_spend transaction or not, according to the following steps (also see Consensus and standard flags section further down): 1. Valid, if it is a successful spend according to the current consensus rules (sometimes called "policy"). 2. Inconclusive, if it is a successful spend according to consensus rules, but NOT according to policy rules 3. Invalid, if it is not a successful spend according to consensus rules A proof is the base64-encoding of the message_signature as is. A validator takes the to be proven pubkey and the proof and transforms it to virtual transactions as described above. == Legacy format == The legacy format is restricted to the legacy P2PKH address format. Any other input (i.e. non-P2PKH address format) must be signed using the new format described above. === Signing === Given the P2PKH address a and the message m, and the pubkey-hash function pkh(P) = ripemd160(sha256(P)): # let p be the pubkey-hash pkh(P) for the pubkey P, contained in a # let x be the private key associated with P so that pkh(xG) = p # let digest be SHA56d("Bitcoin Signed Message:\n"||m) # create a compact signature sig (aka "recoverable ECDSA signature") using x on digest The resulting proof is sig, serialized using the base64 encoding. === Verifying === Given the P2PKH address a, the message m, the compact signature sig, and the pubkey-hash function pkh(P) = ripemd160(sha256(P)): # let p be the pubkey-hash pkh(P) for the pubkey P, contained in a # let digest be SHA56d("Bitcoin Signed Message:\n"||m) # attempt pubkey recovery for digest using the signature sig and store the resulting pubkey into Q ## fail verification if pubkey recovery above fails # let q be the pubkey-hash pkh(Q) for the pubkey Q # if p == q, the proof is valid, otherwise it is invalid == Compatibility == This specification is backwards compatible with the legacy signmessage/verifymessage specification through the special case as described above. == Reference implementation == TODO == Acknowledgements == Thanks to David Harding, Jim Posen, Kalle Rosenbaum, Pieter Wuille, and many others for their feedback on the specification. == References == # Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015818.html == Copyright == This document is licensed under the Creative Commons CC0 1.0 Universal license. == Consensus and standard flags == Each flag is associated with some type of enforced rule (most often a soft fork). There are two sets of flags: consensus flags (which result in a block being rejected, if violated), and policy flags (which result in a transaction being accepted only if it is contained within an actual block, and rejected otherwise, if violated). The policy flags are a super-set of the consensus flags. This BIP specifies that a proof that validates for both rulesets is valid, a proof that validates for consensus rules, but not for policy rules, is "inconclusive", and a proof that does not validate for consensus rules is "invalid" (regardless of policy rule validation). The ruleset sometimes changes. This BIP does not intend to be complete, nor does it indicate enforcement of rules, it simply lists the rules as they stand at the point of writing. === Consensus rules === * P2SH: evaluate P2SH ([https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki BIP16]) subscripts * DERSIG: enforce strict DER ([https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66]) compliance * NULLDUMMY: enforce NULLDUMMY ([https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki BIP147]) * CHECKLOCKTIMEVERIFY: enable CHECKLOCKTIMEVERIFY ([https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65]) * CHECKSEQUENCEVERIFY: enable CHECKSEQUENCEVERIFY ([https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP112]) * WITNESS: enable WITNESS ([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) === Policy rules === All of the above, plus (subject to change): * STRICTENC: non-strict DER signature or undefined hashtype * MINIMALDATA: require minimal encodings for all push operations * DISCOURAGE_UPGRADABLE_NOPS: discourage use of NOPs reserved for upgrades * CLEANSTACK: require that only a single stack element remains after evaluation * MINIMALIF: Segwit script only: require the argument of OP_IF/NOTIF to be exactly 0x01 or empty vector * NULLFAIL: signature(s) must be empty vector if a CHECK(MULTI)SIG operation failed * LOW_S: signature with S > order/2 in a checksig operation * DISCOURAGE_UPGRADABLE_WITNESS_PROGRAM: v1-16 witness programs are non-standard (i.e. forbidden) * WITNESS_PUBKEYTYPE: public keys in segregated witness scripts must be compressed * CONST_SCRIPTCODE: OP_CODESEPARATOR and FindAndDelete fail any non-segwit scripts == Test vectors == TODO