[feature]: ownership/prove & ownership/verify should accept random challenge

[straumat]

Is your feature request related to a problem? Please describe. On Royllo, I have one page for each taproot assets. On that page I display all the information I could find about the asset. In the next release, peoples will be able to create a Royllo account and, there, they will be able to claim they created an asset. After validating that the user is really the owner, Royllo will let the user manage the public royllo page of its asset (add/remove content, add news, change alias...)

Describe the solution you'd like For an asset, I should be able to generate a challenge that only the person who created the asset could reply. I display this challenge on royllo. The user should be able, on his node, to enter the challenge and get the correct reply. He sends me the reply so I can be sure he is the owner.

(Like signmessage in bitcoin or k1 in lnurl auth)

Describe alternatives you've considered I've tried to implement wallet/ownership/prove and wallet/ownership/verify but something is wrong. Example: a user wanting to manage an asset page on Royllo will login on Royllo. There, he will find find an explanation : "call the wallet/ownership/prove method on your node, retrieve the proof_with_witness value and paste the proof_with_witness here". On royllo back end, I call the decode and wallet/ownership/verify methods to check if the ownership method returns true. But now that the user gave me its proof_with_witness, I can go anywhere else with it and pretend i'm the asset creator! Nobody can challenge me

[straumat]

For me:

• From the asset issuance decoded proof, anyone (Bob) can create a challenge.
• The user creator (Alice) should be able to call its node API with that challenge and get the response.
• Bob (who created the challenge) should be able to call its not API with the challenge and the response and get the verification (true or false).

[Roasbeef]

Sounds like you want that add that a unique challenge is bound to the prove/verify calls? So we'd add that hash/challenge value to the prove call, it's embedded to the proof created, then verify also spits that out for verification?

[Roasbeef]

Given the above, here's a rough implementation plan:

• Add a random challenge hash to the prove RPC call
• When we go to generate the ownership proof, if the challenge hash is present, we should use that instead of the NUMs key here: https://github.com/lightninglabs/taproot-assets/blob/main/tappsbt/address.go#L139
  • We can modify to bind something like NUMS + challenge*G
• Then verify will also accept tihs challenge hash as well.

With that you can create unique challenge hashes for a given context/action. It's still the verifies job to ensure that a challenge hash is never re-used.

[straumat]

Yes! I don't know yet all the details of taproot assets but from my point of view, I would like something like lnurl auth but I'm not sure exactly what is a scriptkey (it looks like a public key to me for now).

• Anyone having the issuance proof (bob) (retrieved from a universe server for example) can call wallet/ownership/prove with a parameter that is a random value he chose; The prove method returns a challenge (a bit like when lnurl auth generates an encrypted value of k1 with the user public key).

• The asset issuer (alice) uses the challenge as one of the parameter of wallet/ownership/verify method. The return value will contain the decoded random value chosen by the one asking for verification (bob).

This way:

• Anyone knowing the issuance proof can create a challenge.
• Alice could prove to anybody in the world that she is the asset issuer.

I liked the fact that wallet/ownership/verify returns a complete proof that can be decoded to get all the information about the asset. Maybe the method could still return a proof but with a new field challenge_result next to challenge_witness.

Last question. With tapli, when running tapcli proofs proveownership, only two parameters are available:

--asset_id value    the asset ID of the asset to prove ownership of
--script_key value  the script key of the asset to prove ownership of

When using the curl API, you have to set txid and output_index. Is there any reason ?

[Roasbeef]

@straumat so on the gRPC interface the outpoint field is also available. We require that if a user has multiple UTXOs as distinct outpoints for the same asset_id.

Overall though, I think this request makes a lot of sense. We'll work on prioritizing it, and it should be straight forward enough for an external contributor to implement as well.

[Roasbeef]

@GeorgeTsagk latest code link (the other one broke): https://github.com/lightninglabs/taproot-assets/blob/109d86f5763cfa412d4c05b98a02bf9eb4cef6c4/tappsbt/create.go#L140-L166