Summary of the QR/UR Signing Discussion 2023-02-24 #103
Unanswered
ChristopherA
asked this question in
Specifications
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
This is a summary of a special meeting of the Gordian Developer Community held on February 24, 2023 to discuss QR/UR signing. A video archive, audio archive, and raw transcript for this meeting is available on Github. See our meetings directory for a complete list of meetings.
Bitcoin wallet developers and other members of the blockchain community met to discuss requirements for a new specification for signing messages with Bitcoin keys.
Blockchain Commons' goal at the meeting was to discover pain points and ensure that their technology was addressing them; they wanted to understand the problems that users were trying to solve so that they could offer solutions that people would want to adopt.
Blockchain Commons shared their efforts to create a message-signing capability using crypto-request, crypto-response, and Gordian Envelope. Documentation was offered on how the capability would work, and Blockchain Commons was confident that it could support any functionality needed. However, they asked for help to ensure that with specific use cases from the rest of the community. Though a basic capability may replicate the signing of legacy Bitcoin message types, more complex things such as Jade Wallet's exfiltration signing requests and dealing flaws in Sign-in with Ethereum may require more work. The group agreed that they needed to understand the problem better before they could offer solutions.
Craig discussed the history of the use of animated QRs and how it had evolved from static QRs. He said that the PSBT format was still the dominant use case in Bitcoin wallets and did not need to be changed because it incorporates request and response into its core interface. However, there was an immediate need for legacy message signing, which is another request and response protocol, and could be a better use case for crypto-request and crypto-response.
Ken discussed their own use of signing, which included a cold-card ability to do a signing of an arbitrary message and the Casa health check, where you prove that you can sign for a hardware wallet to reassure users that they keys are safe. These are both done with a simple path for signing; they have a simple function that does the signing and returns the response. Right now, that response is done with ur:bytes.
The group also discussed the need to eliminate the complex details currently required for multi-sig self-custody scenarios. They could be made easier if some of the steps were done through some kind of crypto-request mechanism. This could help developers like Ken and Craig: instead of having a list of 50 different wallets and how each one does things differently, they could just tell a wallet what they wanted it to do using a crypto-request, and it would come back with a crypto-response answer.
The group agreed that the primary requirement was to meet the immediate need for single-round-trip singing, meaning a one QR sent request and a one QR received response. They discussed the level of complexity required and the need for more UR tags and binary values for efficiency.
The group agreed to work together to understand the problem better and to share information and collaborate to find the best solution.
In conclusion, Blockchain Commons said that they would come back soon with a proposal for initial single-round-trip signing with some future-proofing built-in. The larger Gordian Developer group is meeting again on Wednesday, March 1st 4pm PT, and Blockchain Commons will report their progress.
Beta Was this translation helpful? Give feedback.
All reactions