From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 528129D for ; Fri, 9 Aug 2019 18:16:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D7832829 for ; Fri, 9 Aug 2019 18:16:41 +0000 (UTC) Received: by mail-ot1-f43.google.com with SMTP id f17so647169otq.4 for ; Fri, 09 Aug 2019 11:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Qh99pT6+mqkKrAInGdHtU9PZ/v33DLuekNch+zg/hqE=; b=IUaWbrKwfcLhrjqzzk4n8SuZ0vIQkUDEeQM68UzWQ31yphb2Z1tMoIrEw3opQ2LoUn D0E9i82PfF5eMBoxKAlFFYlWAZ0I5wb33/fBGVCa44Vc1VVpKXs9+EcnKWX4M94c8h3l z6yFjYqG01KswE02bHLfX96nLhKzCS1rYy91Br3oiEdgkjfYAX9oDpwN9QuOcOssKWTy S2X7blycVdJw5BS3/0tKx4fRUAX5U6BIYASUFnfrPcXJW3qFlmzGE7fZIqfk+0N2EJTH W9jhu8BrC9HbTwtTCWw4XLsYd2dPoSMw4f43fW5cKal5buDaEE6f1EYhoWcJPtxwv9d2 h2ZA== 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=Qh99pT6+mqkKrAInGdHtU9PZ/v33DLuekNch+zg/hqE=; b=gZstqjqQ2X0C9R3J3tl01UkFfrDXlHWhKSfIvndAJB4+92giFN6prEBjsTDYTe+s9+ e2sEsjFr8wQh2wrCOOf+ZmgXBWYPVQzx43qkHp9LCSYE2F8MkRGc8GK3pZ/+1P3YWRfO VqKVXvADbv4nnAs0Zu09/72JjIwmMICnYonyb8GrqeXLW+XiGJHxv0dSP75OpQh+6/E2 4mYu+DVmD3A4oYStKUzpI0tUglU6A3vKYAJhjmIjQtZfctxWP/qMf/OzTXUTcV5UWuKJ oJLwR7ZN4CNRr5yASyKCOLlxA1nMMSOsEXr9aYopth+fo/0tSFN/ZIhU3A/s8tLfW3/v kWbQ== X-Gm-Message-State: APjAAAUvUzdXgjDNSsev/fndn4Mv9qVRWLosWcjfXhy52pRjFAOVvG2O io1Qd5mfdECf6uzkoLh5Wj73JkiT3/IPIgfYjvo/+rd1 X-Google-Smtp-Source: APXvYqzRYtfdHHQQ1ilLCAOSFW/N1md1exZaPRn37dm1NpBvgCmxfkgQcRFIzROG0lOF2JE8YUTTUdM6OMxvOMySuuM= X-Received: by 2002:a9d:6c54:: with SMTP id g20mr19676717otq.66.1565374600883; Fri, 09 Aug 2019 11:16:40 -0700 (PDT) MIME-Version: 1.0 From: Pieter Wuille Date: Fri, 9 Aug 2019 11:16:29 -0700 Message-ID: To: Bitcoin Dev Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 Subject: [bitcoin-dev] 32-byte public keys in Schnorr and Taproot 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: Fri, 09 Aug 2019 18:16:42 -0000 Hello all, It has been suggested [1] to drop the Y oddness bit in the witness program for Taproot outputs. This seems like a worthwhile change, as: * The bit doesn't actually contribute to security. * It avoids Taproot outputs from being more expensive to create than v0 P2WSH. * It doesn't preclude future changes that would still need the additional byte anyway. In exploring that option, Jonas Nick found that it seems cleanest [2] to actually introduce a type of 32-byte public keys (which implicitly have an even Y coordinate) in bip-schnorr, with associated signing and verification logic that are distinct from the 33-byte variant. This makes me wonder if we need 33-byte public keys at all. So I'd like to hear opinions about modifying bip-schnorr to only define 32-byte public keys. The implications of that would be: * bip-schnorr public keys wouldn't be exactly the same as ECDSA public keys, however all derivation logic would still apply (BIP32, mnemonics, xpubs, ... would still exist and be compatible - just the first pubkey byte would be dropped at the end). * The Q point in bip-taproot (the one going in the scriptPubKey) would just follow the 32-byte pubkey encoding, rather than needing a 33rd byte. * The P point in bip-taproot (the internal key revealed during script path) would become just a 32-byte public key (and we can drop the one bit in the control block to transmit the oddness of the Y coordinate of P). * In order to permit batch verification of the P to Q tweaking for script-path spending, another control block bit is now needed, namely one that indicates whether a negation was needed to make P+H(P||m)*G's Y coordinate even. * All public keys inside bip-tapscript would also become 32-bytes. If desired, the "upgradable public key" construction in bip-tapscript can be kept, by triggering based on the length of public keys (rather than based on their first byte). One question is whether it's worth such a change to bip-schnorr at this point. We've purposefully never progressed it past draft since publishing [3], but it has been a while. If necessary, it's possible to keep verification compatible by still hashing the implied "even" byte inside the scheme (which commits to the pubkey), but if we're going to change things, it's perhaps best to do it as cleanly as possible and also drop that byte. Opinions? [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016943.html [2] https://github.com/sipa/bips/pull/52 [3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html Cheers, -- Pieter