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 97A20E20 for ; Fri, 9 Aug 2019 18:37:50 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CAE6D829 for ; Fri, 9 Aug 2019 18:37:49 +0000 (UTC) Received: by mail-ot1-f45.google.com with SMTP id d17so136403167oth.5 for ; Fri, 09 Aug 2019 11:37:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lifewithalacrity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=icC08GQqR+1hdf8baE+ChdQ/BXQhU5wpn32z9aJlsAs=; b=lraQ+OB06JgXs9HeP6oQpubnfF9wlFuGHPCN7YztG207Nuqkpfv1Wjf6bV6PkoAXKI QKa5MOuNaXWypnOGiQssV58G2hVCJun2A52iTd/x2R411zfUyjwHg72z4SCtvjQtHfRh p1JQ01PtQDOaaaVt2wfMsFvzTqkOy8efE0CHc8T3WGDqPn2ZDxxVip39wliDY4Nb7x3R hCsCsQ18S0N3TgLRQBre9SzNq5D+owV9fzDXkNYTPxXxCVIGu5mLaxdbTiX+xJqqjnAd Ibdjs2zgzUn80RSqKXNsgIZU5tWcqUFKLflfvMCcCNAoE1pB993QURbYowcc0jEqJl8w uusA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=icC08GQqR+1hdf8baE+ChdQ/BXQhU5wpn32z9aJlsAs=; b=Rfj7vJJI7lAJl7VbJAgQ3DTGCtZGwT2TNgdkqC8IRVnQpEuFaO07NpXU3b8FqlWJkk QHY2TrNAgFzJBIgr5GwFK0GMRAW6/A/vNyFY20WCv0H0tU3QrhZUAhG6fEA+sYrFZh4Y Xv4bW/92GltDkfBgxS6LYiF1fE1OuswPuRM/7rfW5+RaMK9bGDpuWY1hfq3z3wjyUk9Q /dwvXjfy8WQ1tszHnZOsM/N6dOwWw/MtF6nBSnUJIKvH2dhXTXFyVy9jns+dVamqibdL U50Mpj31SYbok+qvKk/3yPFTRsNE/P32qt+qy+dtE5G2ByXkI+1nVC4OVFyymvGfZpCa +Y8Q== X-Gm-Message-State: APjAAAVMFihBdzbZ6M1cI8LUNj2Y9SJD6gB3h4wq1+0ZakZOCCDgbIVF +NrAVZ5rzWrQPer/HUHuaXjN0y46RQxOcR1ENzw= X-Google-Smtp-Source: APXvYqw2sdcyJZ2I9iHEoN0exZrraH+1HCqHEEIhROpcDiwZdrBwuh7diVlJQ59WSEWs9qKaGO5FqNkshsHbee7J2QQ= X-Received: by 2002:a54:418b:: with SMTP id 11mr7712660oiy.40.1565375868936; Fri, 09 Aug 2019 11:37:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Allen Date: Fri, 9 Aug 2019 11:37:13 -0700 Message-ID: To: Pieter Wuille , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000009ba7f0058fb378c6" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, 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: Fri, 09 Aug 2019 18:55:11 +0000 Subject: Re: [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:37:50 -0000 --0000000000009ba7f0058fb378c6 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 9, 2019 at 11:17 AM Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > if we're going to change things, it's perhaps best to do it as cleanly as > possible and also drop that byte. > I personally lean toward just dropping the byte. I like the simplicity and I really like 32 bytes. 33 seems so over the edge and so odd ;-) Yes, there may be some prototype implementations out there that did some extra work, and will need to be revised, but that is always the risk developers take when writing code when the spec hasn't fully been implemented yet. If you do revise the spec, would you consider proposing a format for sharing public keys in a non-binary form, maybe using bech32? Given some of the protocols emerging that may use Schnorr public keys in novel ways, having a single encoding format for them would be useful. -- Christopher Allen --0000000000009ba7f0058fb378c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Aug 9, 2019 at 11:17 AM Pieter Wu= ille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
if w= e're going to change things, it's perhaps best to do it as cleanly = as possible and also drop that byte.

I = personally lean toward just dropping the byte. I like the simplicity and I = really like 32 bytes. 33 seems so over the edge and so odd ;-)
Yes, there may be some prototype implementations out there tha= t did some extra work, and will need to be revised, but that is always the = risk developers take when writing code when the spec hasn't fully been = implemented yet.=C2=A0

If you do revise the spec, = would you consider proposing a format for sharing public keys in a non-bina= ry form, maybe using bech32? Given some of the protocols emerging that may = use Schnorr public keys in novel ways, having a single encoding format for = them would be useful.

-- Christopher Allen

--0000000000009ba7f0058fb378c6--