diff options
| author | Luke Dashjr <luke@dashjr.org> | 2020-03-04 14:35:16 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-03-04 14:35:48 +0000 |
| commit | c8645a0bf8f4baeb7b2aec980d15c2575259dda4 (patch) | |
| tree | a3b0fa108ee892597fb25094e0b0ce778dbc3857 | |
| parent | ac0f129d2485687ea05fe0800ca19ac7bf5b344f (diff) | |
| download | pi-bitcoindev-c8645a0bf8f4baeb7b2aec980d15c2575259dda4.tar.gz pi-bitcoindev-c8645a0bf8f4baeb7b2aec980d15c2575259dda4.zip | |
Re: [bitcoin-dev] RFC: Kicking BIP-322 (message signing) into motion
| -rw-r--r-- | c7/71cfbe43697c5324f7c3e3b2a1099c4032c87f | 150 |
1 files changed, 150 insertions, 0 deletions
diff --git a/c7/71cfbe43697c5324f7c3e3b2a1099c4032c87f b/c7/71cfbe43697c5324f7c3e3b2a1099c4032c87f new file mode 100644 index 000000000..fe7f52eb7 --- /dev/null +++ b/c7/71cfbe43697c5324f7c3e3b2a1099c4032c87f @@ -0,0 +1,150 @@ +Return-Path: <luke@dashjr.org> +Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 275B8C013E + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 4 Mar 2020 14:35:48 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by fraxinus.osuosl.org (Postfix) with ESMTP id 10E9384806 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 4 Mar 2020 14:35:48 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +Received: from fraxinus.osuosl.org ([127.0.0.1]) + by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 9ZDGzuCgA21J + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 4 Mar 2020 14:35:47 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) + by fraxinus.osuosl.org (Postfix) with ESMTP id 328DC8441C + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 4 Mar 2020 14:35:47 +0000 (UTC) +Received: from ishibashi.lan (unknown [12.190.236.222]) + (Authenticated sender: luke-jr) + by zinan.dashjr.org (Postfix) with ESMTPSA id 86E4238A0DB8; + Wed, 4 Mar 2020 14:35:21 +0000 (UTC) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan; + t=1583332543; bh=A9D3CiSlAHMeGFovogfacbxMdaVLkU7uiiGW+xjutTU=; + h=From:To:Subject:Date:References:In-Reply-To; + b=W8E0vtjUBGUahyMuVCQ90Ai5HALnDAOsRMNyY8oDDrd/W+07oY13S4wAE6E45mkO2 + yC/kOUdLmUgt/pqdNMET8VuUCbLh8jtG8ddEvmOd/i5hQtsQ5Wx74RJke5V+ZQoMFL + K7hN5n8MdFA8SD87ywiFxkSVuouVPvCTPF1Uo4UM= +X-Hashcash: 1:25:200304:bitcoin-dev@lists.linuxfoundation.org::tU8r8/2cxtXYRUCy:a/6G= +X-Hashcash: 1:25:200304:karljohan-alm@garage.co.jp::HBfXdtIZNQNuXzEc:QHHC +From: Luke Dashjr <luke@dashjr.org> +To: bitcoin-dev@lists.linuxfoundation.org, + "Karl-Johan Alm" <karljohan-alm@garage.co.jp> +Date: Wed, 4 Mar 2020 14:35:16 +0000 +User-Agent: KMail/1.9.10 +References: <CALJw2w4ENV3y3Ufu=YRquDNwvQnewcwGHOe1njw8-ztNXJF-XQ@mail.gmail.com> +In-Reply-To: <CALJw2w4ENV3y3Ufu=YRquDNwvQnewcwGHOe1njw8-ztNXJF-XQ@mail.gmail.com> +X-KMail-QuotePrefix: > +MIME-Version: 1.0 +Content-Type: Text/Plain; + charset="iso-8859-1" +Content-Transfer-Encoding: 7bit +Content-Disposition: inline +Message-Id: <202003041435.17644.luke@dashjr.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Wed, 04 Mar 2020 14:35:48 -0000 + +In addition to starting with proof-of-funds instead of proof-of-receiver, it +would be nice to integrate with Taproot somehow or another. Perhaps +OP_MESSAGEONLY is the most straightforward way to do this? It might be a good +idea to have a message type after the opcode too. + +On Wednesday 04 March 2020 06:23:53 Karl-Johan Alm via bitcoin-dev 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 <key_m> OP_ELSE <key_s> 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 +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + + |