From: Karl-Johan Alm <karljohan-alm@garage•co.jp>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] RFC: Kicking BIP-322 (message signing) into motion
Date: Wed, 4 Mar 2020 16:03:34 +0900 [thread overview]
Message-ID: <CALJw2w5h=rdzhy+uVFs6w5qLe4hT+hfkdqOz6QkW9+cx_pzkjg@mail.gmail.com> (raw)
In-Reply-To: <CALJw2w4ENV3y3Ufu=YRquDNwvQnewcwGHOe1njw8-ztNXJF-XQ@mail.gmail.com>
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
<karljohan-alm@garage•co.jp> 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
next prev parent reply other threads:[~2020-03-04 7:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-04 6:23 Karl-Johan Alm
2020-03-04 7:03 ` Karl-Johan Alm [this message]
2020-03-04 14:35 ` Luke Dashjr
2020-03-04 14:43 ` Greg Sanders
2020-03-25 6:31 ` Karl-Johan Alm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALJw2w5h=rdzhy+uVFs6w5qLe4hT+hfkdqOz6QkW9+cx_pzkjg@mail.gmail.com' \
--to=karljohan-alm@garage$(echo .)co.jp \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox