RFC: Kicking BIP-322 (message signing) into motion [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2020-03-25T06:31:56+00:00


Summary:

In this email thread from the Bitcoin-dev mailing list, several proposals for improving the BIP-322 pull request are discussed. The first proposal involves replacing the signmessage system with a prove funds system to discourage the misleading use of signmessage as a way to prove funds. The second proposal suggests using a transaction instead of a new format and making the first input's txid the message hash to ensure that the transaction cannot be broadcasted. The third proposal involves using Trezor style, which has already been adopted but limits generic signing. The fourth proposal is to introduce OP_MESSAGEONLY, which would make "dumb" signers more difficult to support as they would have to do script interpretation to make sure they're not signing something real with funds. Finally, the email asks if anyone has any other suggestions for improving BIP-322.Karl-Johan Alm has reached out to the bitcoin-dev mailing list regarding his BIP-322 pull request, which aims to improve Bitcoin's signing message functionality. He notes that a similar pull request was merged into Bitcoin Core without considering BIP-322 compatibility, leading Karl-Johan to believe that people dislike BIP-322 in its current form. To make the pull request more appealing, Karl-Johan suggests several potential changes. Firstly, he recommends throwing out the sign message system entirely and replacing it with a proof-of-funds system. Secondly, he suggests using a transaction rather than a new format, with the first input's txid serving as the message hash to ensure the transaction cannot be broadcasted. Thirdly, Karl-Johan proposes adopting the Trezor style, which is already in use but limits generic signing. Fourthly, he recommends introducing OP_MESSAGEONLY to enable messaging purposes without consuming an op_code. Lastly, he invites suggestions for any other solutions. Karl-Johan encourages harsh criticism of these proposals if necessary so that he can improve or abandon the BIP-322 pull request accordingly.The author of a BIP-322 pull request has noticed that despite their PR being open for twice the time as another PR to Bitcoin Core, which touched on the same areas of complexity, the latter was merged without any consideration for BIP-322 compatibility. This leads them to believe that people dislike BIP-322 in its current form. They are seeking criticism to improve their PR and have listed several things that they can do to make it more appealing. Firstly, they suggest that the use of signmessage as a way to prove funds should be discouraged entirely and replaced with a prove funds system, which is an opinion shared by Luke-jr and Greg Maxwell. Secondly, they propose using a transaction rather than a new format by making the first input’s txid the message hash, which would ensure the tx cannot be broadcasted and could provide to an existing hardware wallet without modifications. Mark Friedenbach and Johnson Lau support this idea but Lau also suggests modifying the signature hash, which defeats the benefit above since now hardware wallets cannot sign. Prusnak is against this idea and proposes using the Trezor style instead. The Trezor style has already been adopted, but the drawback is that we would be stuck with the exact same limitations as in the legacy system, which we wanted to fix in the updated version. Lastly, the author suggests introducing OP_MESSAGEONLY, which means the script following the code would never be valid. For messaging purposes, OP_MESSAGEONLY is considered as OP_NOP and ignored. A message could be signed with either key_m or key_s, but for spending purposes, only key_s is valid.


Updated on: 2023-08-02T01:54:27.832496+00:00