<div dir="ltr">OP_MESSAGEONLY would make "dumb" signers like HWW more difficult to support. They'd have to do script interpretation to make sure they're not signing something real with funds.<div><br></div><div>Just FYI.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 4, 2020 at 9:35 AM Luke Dashjr via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In addition to starting with proof-of-funds instead of proof-of-receiver, it <br>
would be nice to integrate with Taproot somehow or another. Perhaps <br>
OP_MESSAGEONLY is the most straightforward way to do this? It might be a good <br>
idea to have a message type after the opcode too.<br>
<br>
On Wednesday 04 March 2020 06:23:53 Karl-Johan Alm via bitcoin-dev wrote:<br>
> Hello,<br>
><br>
> I noticed recently that a PR to Bitcoin Core that pretty much touched<br>
> everything my BIP-322 pull request touches (around the same<br>
> complexity) was merged without a thought given to BIP-322<br>
> compatibility, despite the BIP-322 PR being open for 2x the time. I<br>
> can only conclude from this that people dislike BIP-322 in its current<br>
> form, which the 9 month old pull request stagnating can probably<br>
> attest to.<br>
><br>
> There are several things that I can do to make this a bit more<br>
> appealing to people, which would hopefully kick the progress on this<br>
> forward. I have already put in a non-trivial amount of energy and<br>
> effort into maintaining the pull request as is, so I'd prefer if<br>
> people were harsh and unfiltered in their criticism rather than polite<br>
> and buffered, so I can beat this thing into shape (or abandon it, in<br>
> the worst case).<br>
><br>
> =============<br>
> 1. People use signmessage as a way to prove funds. This is misleading<br>
> and should be discouraged; throw the sign message stuff out and<br>
> replace it entirely with a prove funds system.<br>
><br>
> I know in particular luke-jr is of this opinion, and Greg Maxwell in<br>
> <a href="https://github.com/bitcoin/bitcoin/pull/16440#issuecomment-568194168" rel="noreferrer" target="_blank">https://github.com/bitcoin/bitcoin/pull/16440#issuecomment-568194168</a><br>
> leans towards this opinion as well, it seems.<br>
><br>
> =============<br>
> 2. Use a transaction rather than a new format; make the first input's<br>
> txid the message hash to ensure the tx cannot be broadcasted. This has<br>
> the benefit of being able to provide to an existing hardware wallet<br>
> without making any modifications to its firmware.<br>
><br>
> I think Mark Friedenbach and Johnson Lau are of this opinion, except<br>
> Johnson Lau also suggests that the signature hash is modified, see<br>
> <a href="https://github.com/bitcoin/bips/pull/725#issuecomment-420040430" rel="noreferrer" target="_blank">https://github.com/bitcoin/bips/pull/725#issuecomment-420040430</a> --<br>
> which defeats the benefit above since now hw wallets can no longer<br>
> sign.<br>
><br>
> Prusnak (I think he works at Trezor; apologies if I am mistaken) is<br>
> against this idea, and proposes (3) below:<br>
> <a href="https://github.com/bitcoin/bips/pull/725#issuecomment-420210488" rel="noreferrer" target="_blank">https://github.com/bitcoin/bips/pull/725#issuecomment-420210488</a><br>
><br>
> =============<br>
> 3. Use Trezor style<br>
><br>
> See <a href="https://github.com/trezor/trezor-mcu/issues/169" rel="noreferrer" target="_blank">https://github.com/trezor/trezor-mcu/issues/169</a><br>
><br>
> This has the benefit of already being adopted (which clearly BIP-322<br>
> is failing hard at right now), but has the drawback that we can no<br>
> longer do *generic* signing; we are stuck with the exact same<br>
> limitations as in the legacy system, which we kinda wanted to fix in<br>
> the updated version.<br>
><br>
> =============<br>
> 4. Introduce OP_MESSAGEONLY<br>
><br>
> Quoting Johnson Lau at<br>
> <a href="https://github.com/bitcoin/bips/pull/725#issuecomment-420421058" rel="noreferrer" target="_blank">https://github.com/bitcoin/bips/pull/725#issuecomment-420421058</a> :<br>
> """<br>
> OP_MESSAGEONLY means the script following the code would never be<br>
> valid. For example, a scriptPubKey:<br>
><br>
> OP_IF OP_MESSAGEONLY <key_m> OP_ELSE <key_s> OP_ENDIF OP_CHECKSIG<br>
><br>
> For messaging purpose, OP_MESSAGEONLY is considered as OP_NOP and is<br>
> ignored. A message could be signed with either key_m or key_s.<br>
><br>
> For spending, only key_s is valid.<br>
><br>
> I don't think it is a big problem to consume a op_code. If this is a<br>
> real concern, I could modify it as follow: in message system,<br>
> OP_RETURN will pop the top stack. If top stack is msg in hex, it is<br>
> ignored. Otherwise, the script fails.<br>
> """<br>
><br>
> =============<br>
> 5. Some other solution<br>
> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
> <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>