From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 34259C013E for ; Wed, 4 Mar 2020 07:10:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 2AD5F20415 for ; Wed, 4 Mar 2020 07:10:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJB1D2rRVnXc for ; Wed, 4 Mar 2020 07:10:14 +0000 (UTC) X-Greylist: delayed 00:07:34 by SQLgrey-1.7.6 Received: from mta65.mta.hdems.com (mta65.mta.hdems.com [3.112.23.32]) by silver.osuosl.org (Postfix) with ESMTPS id 9556A20404 for ; Wed, 4 Mar 2020 07:10:14 +0000 (UTC) Received: from mo.hdems.com (unknown [10.5.20.193]) by mta65.mta.hdems.com ('HDEMS') with ESMTPSA id 48XPvy2czPz2K1rWf for ; Wed, 4 Mar 2020 07:02:38 +0000 (UTC) X-HDEMS-MO-TENANT: garage.co.jp Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com. [209.85.167.70]) by gwsmtp.prod.mo.hdems.com with ESMTPS id gwsmtpd-trans-c18db0d8-909a-43ea-aed1-bd08585fad12 for ; Wed, 04 Mar 2020 07:02:36 +0000 Received: by mail-lf1-f70.google.com with SMTP id a1so370871lfr.16 for ; Tue, 03 Mar 2020 23:02:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=garage.co.jp; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=x/ms1XNUwm3ZxuKetZQJuckXpjnrpRBFqbykfIqm5ik=; b=oeKOZQ+1QMVVoH82okGnsUaFHzpDgkjJOJjcmR+2SY8mt+IvMMRkR98KrQOzkDfoVB GHrVvUtf/UZ7s7wXKEAWeOJxwEuQSC8TrrOAREq7FFNjmbKc/tHtJlVlaAC+EMM3HZGP cwlgASvjYg1lBgTK8CnVIpg/8WiLHJBUFPD/s= 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=x/ms1XNUwm3ZxuKetZQJuckXpjnrpRBFqbykfIqm5ik=; b=Tvbg7EeRAerEeV5pKGkgcxt4K5sXIZw4ZEauWauddMja0uCTK5K9MuOSIqP2E28tHR YvWlAr/K+B2aZslIeSq77Hd8iFtO56VFtaRfZTR9+9Af4S5kHKRTBK+jzRP20BYdtbez qR02GFGXUHJo2NCHbOlz3XWQZwrSZ4RCUqkYbL0GNYDS4J6Bu9MMN89wQWAJ1yQt8bh2 O0ZuCzn6MGpxRBNjXrN3p3i+oxX97/kw283Yb8JmTiB/UgQkagVAqiah4I7DFKdIEeNE 4YsiweESlJHiBWN2dyhTjSrg9occmNUqvC/sPJMFNz1pm0PoxkwHC3uOuzN3XwEa5s2D wspA== X-Gm-Message-State: ANhLgQ3gX+FotHp7qgehGgGWJKTKeP5nzZqTxrUs/QNz7LckKq5a4Caa 26wyiEOvWbc5vgMhFTjv0jI0d8ZLRHoQvjhPnaK3PTwNFcjywfyYP0sXyJKscXQza6YR52Lgua+ bu+mkXEuv3aqvfXOT9LF7D66AcHO+t1DKp62annRn5yeyigrn/fjZ5KYrGnAgcpvcMzAnWrJFxN w+jGVIXR5mH/87NUOZxgd9aplwsVllOCCK/wPVpC4pN566csuW8OlidGbNu1RNzZpNJSpBDibkn 4sCmyvkC/8Cjz3aVq15mFHMV7yWKgipaNHsHfXm+PraGf8GDXTFrCQZaq7+B8oa5qNY4A7TFsD7 6kk98tJ99UILX2pMSV087h+zBwER X-Received: by 2002:a2e:8651:: with SMTP id i17mr1079495ljj.121.1583305349182; Tue, 03 Mar 2020 23:02:29 -0800 (PST) X-Google-Smtp-Source: ADFU+vuh8GIfTbWnbZW1AIFduGwDkUiMiiAbqW2iaoaS6GeWiq4ouOOM/oeAsSqskDW/J6sTVj03YTWWQO6YiKAIJC4= X-Received: by 2002:a2e:8651:: with SMTP id i17mr1079476ljj.121.1583305348717; Tue, 03 Mar 2020 23:02:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Karl-Johan Alm Date: Wed, 4 Mar 2020 16:03:34 +0900 Message-ID: To: Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" Subject: Re: [bitcoin-dev] RFC: Kicking BIP-322 (message signing) into motion 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: Wed, 04 Mar 2020 07:10:16 -0000 I forgot one: ============= 5. The current BIP itself is poorly written and/or unnecessarily complex: e.g. remove the multi-proof support, and/or remove the extensibility stuff for a future proof-of-funds extension, and/or focus solely on the generic sign message stuff. ============= 6. Some other solution On Wed, Mar 4, 2020 at 3:23 PM Karl-Johan Alm wrote: > > Hello, > > I noticed recently that a PR to Bitcoin Core that pretty much touched > everything my BIP-322 pull request touches (around the same > complexity) was merged without a thought given to BIP-322 > compatibility, despite the BIP-322 PR being open for 2x the time. I > can only conclude from this that people dislike BIP-322 in its current > form, which the 9 month old pull request stagnating can probably > attest to. > > There are several things that I can do to make this a bit more > appealing to people, which would hopefully kick the progress on this > forward. I have already put in a non-trivial amount of energy and > effort into maintaining the pull request as is, so I'd prefer if > people were harsh and unfiltered in their criticism rather than polite > and buffered, so I can beat this thing into shape (or abandon it, in > the worst case). > > ============= > 1. People use signmessage as a way to prove funds. This is misleading > and should be discouraged; throw the sign message stuff out and > replace it entirely with a prove funds system. > > I know in particular luke-jr is of this opinion, and Greg Maxwell in > https://github.com/bitcoin/bitcoin/pull/16440#issuecomment-568194168 > leans towards this opinion as well, it seems. > > ============= > 2. Use a transaction rather than a new format; make the first input's > txid the message hash to ensure the tx cannot be broadcasted. This has > the benefit of being able to provide to an existing hardware wallet > without making any modifications to its firmware. > > I think Mark Friedenbach and Johnson Lau are of this opinion, except > Johnson Lau also suggests that the signature hash is modified, see > https://github.com/bitcoin/bips/pull/725#issuecomment-420040430 -- > which defeats the benefit above since now hw wallets can no longer > sign. > > Prusnak (I think he works at Trezor; apologies if I am mistaken) is > against this idea, and proposes (3) below: > https://github.com/bitcoin/bips/pull/725#issuecomment-420210488 > > ============= > 3. Use Trezor style > > See https://github.com/trezor/trezor-mcu/issues/169 > > This has the benefit of already being adopted (which clearly BIP-322 > is failing hard at right now), but has the drawback that we can no > longer do *generic* signing; we are stuck with the exact same > limitations as in the legacy system, which we kinda wanted to fix in > the updated version. > > ============= > 4. Introduce OP_MESSAGEONLY > > Quoting Johnson Lau at > https://github.com/bitcoin/bips/pull/725#issuecomment-420421058 : > """ > OP_MESSAGEONLY means the script following the code would never be > valid. For example, a scriptPubKey: > > OP_IF OP_MESSAGEONLY OP_ELSE OP_ENDIF OP_CHECKSIG > > For messaging purpose, OP_MESSAGEONLY is considered as OP_NOP and is > ignored. A message could be signed with either key_m or key_s. > > For spending, only key_s is valid. > > I don't think it is a big problem to consume a op_code. If this is a > real concern, I could modify it as follow: in message system, > OP_RETURN will pop the top stack. If top stack is msg in hex, it is > ignored. Otherwise, the script fails. > """ > > ============= > 5. Some other solution