Expose method to sign arbitrary messages

[aulneau]

There will be times when an app needs to sign an arbitrary message. This functionality exists in wallets in Eth, but we don't currently expose a function to do this in stacks apps.

It's suggested that we should make an equivalent to https://eips.ethereum.org/EIPS/eip-712

from discord:

ok so in the Eth world there's tons of arbitrary message signing right, for DeFi and DeX and whatnot

It always used to be the case that you'd sign an order hash, but that's not very readable for the user. (MetaMask popup shows you just a hex string, you have no idea what you are really signing.)

EIP712 defined a structure (in json) that makes it possible to show what that order hash consisted of

so you see the actual fields that went into generating the hash that you are signing

[MarvinJanssen]

Thanks for posting this! I think such a feature is crucial.

[aulneau]

Thanks for posting this! I think such a feature is crucial.

I agree, and I think many on the team would agree, too 👍 I'll work to update this issue as we talk through it.

[markmhendrickson]

@MarvinJanssen Mind indicating the use case(s) you'd like to build in the short-term with this to help weigh priorities?

[MarvinJanssen]

@markmhx talking short-term, there is really only one reason why I need it.

I am creating a server-side component that tracks user app bucket URLs (for zonefiles). In order to secure this API, the user should sign his/her bucket URL with Connect. The server then resolves the user's reported BNS name via the BNS contract and uses the corresponding principal to verify the signature. I basically need to verify that a specific message actually came from a principal who owns a name on BNS. If you have alternative solutions, let me know. My backup plan was introducing simple Clarity contract and having the user submit a proof via contract call, but that makes it a workaround for a workaround for a workaround...

[psq]

there are 2 main other use cases I've seen signatures being used on Eth:

• prove you own an address and the site will reveal analytics only you can see about your address (which is nice)
• vote (unlike uniswap for example, which requires paying gas fee, synthetix only requires a signature per vote, costing you nothing, which sounds about right for governance voting)

[MarvinJanssen]

@psq yep long term we need it for DeFi and DeX, and platforms that do server-side matching that require user signatures. (Like 0x Protocol and Wyvern on Ethereum.)

[markmhendrickson]

Thanks for the additional context 🙏 I'm assigning to Jasper so he can design.

[GinaAbrams]

I see this is in the icebox @markmhx does that mean it will be considered in a later sprint? @MarvinJanssen is awaiting updates 🙂

[markmhendrickson]

I've moved back this issue back into the Kanban backlog.

Note that we're no longer working against 2-week sprints but rather incremental delivery of priorities as reflected in the backlog from top to bottom.

[hstove]

I am totally on board with evaluating a system for signed typed data structures, but that's a much bigger engineering task that I don't think we should take on first. The main benefit of the structured data is to fee-less on-chain transactions with logic tied to the data in that signature. However, two things:

• Sponsored transactions make it such that any contract call can be fee-less. The only downside here is that you can't do batched signatures
• The ETH spec is very tied to how this data format can be RLP encoded and used in the EVM. We'd have to do a lot of work around determining how that might work with Clarity, and then we can make a spec out of that, and then we can add it to the wallet

Strings are the most obvious use case for Stacks at the moment. It would allow for the very common use case of providing off-chain access to a user that can prove they own an STX address. For example, a web app that gives specific functionality if you own an NFT.

To be more concrete about use cases:

• Sign into web app and prove you own a STX address
  • not technically solved by auth right now, because it signs with a different key from pre-2.0, but we can/should change that
• Share a specific message for off-chain that proves you own a STX address
  • sign a string, the "easy" version of this issue
• Fee-less token approvals
  • solved by post conditions
• Fee-less DAO voting
  • solved by sponsored transactions
• Batched fee-less DAO voting, or other complex batched on-chain fee-less stuff
  • needs ERC712 equivalent

[markmhendrickson]

It was determined during a conversation with @MarvinJanssen and @GinaAbrams yesterday that the .BTC app won't have an urgent need for arbitrary message signing unless two things happen sequentially:

1. We're unable to deploy Atlas fixes to mainnet within the next couple of weeks.
2. He's unable to implement the zonefile reporting mechanism he needs as a workaround using a custom Clarity smart contract and transaction signing and broadcasting with the Stacks Wallet extension.

The arbitrary message signing route is basically a fallback to the above routes, which are preferable in the order listed. It would involve sending signed messages with zonefile data to a centralized server, which would save the end user the cost of having to sign a transaction but also incur the undesirable involvement of a centralized party.

@agraebe @diwakergupta I'll check in with splat next week to see how the Atlas deployment plans are going so we can provide @MarvinJanssen with an update here in regards to timing and how it impacts his options.

He's happy to wait a week or two to see if we can get the fixes live on mainnet and save him the work of either workaround.

[hozzjss]

This is an invaluable thing to have, using signatures from the identity would prove the ownership of a name and a whole lot of things, especially when it comes to off-chain operations, 100% for this

[MarvinJanssen]

See this feature request: stacks-network/stacks-core#2693. Clarity types are great for this sort of stuff as they are very readable. We could have a mechanism to hash a serialised CV and then sign it.

Here is a quick concept:

[2snEM6]

This would also be great for bitcoin transaction signing, it would allow pools to implement bitcoin wallet functionality on the web, for instance to withdraw payouts, without needing to instruct the user to user third party wallets or ask the user for the private key (this is a no go). Is there any way I can help speed up this?

Thanks.

[beguene]

@aulneau @MarvinJanssen @psq @fiftyeightandeight The PR is ready here #2350 If you can provide your feedback that would be great !
You can already use the build in the PR description and there is a test-app deployed here with a Signature button.
You can open the dev console in the test-app to see the result returned by the wallet
example

[Eshwari007]

Provided my test findings on #2350

[fiftyeightandeight]

Discourse sign-in with Hiro wallet:
https://www.loom.com/share/fe043802c4fe409a9b9bbbcae7b4eb58