proveownership and verifyownership don't work correctly yet?

[MegalithicBTC]

I have a concern about the tapcli commands proveownership and verifyownership.

These two commands are documented here:

https://lightning.engineering/api-docs/api/taproot-assets/asset-wallet/verify-asset-ownership
https://lightning.engineering/api-docs/api/taproot-assets/asset-wallet/prove-asset-ownership

I have two separate LND + TAPD instances running, and I'm testing how a two different users could validate ownership of an asset.

Both are running TAPD from the main branch, updated a few days ago, and LND from this docker container lightninglabs/lnd:v0.18.0-beta.rc1.

USER 1
This user owns an asset, and wants to prove ownership of the asset.

tapcli assets list

{
    "assets": [
        {
            "version": "ASSET_VERSION_V0",
            "asset_genesis": {
                "genesis_point": "77f867378b1879b7cb4d0b272ab95a66c9b0f76e03fcf31e5269f9beba0344b6:1",
                "name": "MegalithGenesisCoin",
                "meta_hash": "23ab9dbaf930ad82a9ee7400c36e7d875a2c5ec6f5c7186cd8ded08bda05a48c",
                "asset_id": "5eb3e9332e8b0d12d4831e26dd9c6553c2467b9a6927e7006953b33987ddcf1e",
                "asset_type": "NORMAL",
                "output_index": 0
            },
            "amount": "5",
            "lock_time": 0,
            "relative_lock_time": 0,
            "script_version": 0,
            "script_key": "020e6a67dc70939103b349f059af86ec6fb43cbb9b6eb9ad9c93f86619f6d8aa85",
            "script_key_is_local": true,

Then, using the asset_id and script_key, USER 1 constructs this command:

tapcli proofs proveownership --asset_id 5eb3e9332e8b0d12d4831e26dd9c6553c2467b9a6927e7006953b33987ddcf1e --script_key 020e6a67dc70939103b349f059af86ec6fb43cbb9b6eb9ad9c93f86619f6d8aa85 --proof_file this-proof-should-be-good.proof

This command generates this binary file (I have put in in ZIP so I could upload it here):

this-proof-should-be-good.zip

Then, USER 2 accepts the this-proof-should-be-good.proof file, and runs this command:

tapcli proofs verifyownership --proof_file ./this-proof-should-be-good.proof

Here is the response:

{
    "valid_proof": true
}

Good!

Now, back on USER 1, I construct another proveownership command:

tapcli proofs proveownership --asset_id c94553c9c6e2bae301e25d0f70a3720c060dd752d6bca384f87687b777805f6b --script_key 020e6a67dc70939103b349f059af86ec6fb43cbb9b6eb9ad9c93f86619f6d8aa85 --proof_file this-proof-should-be-bad.proof

Note I have made two changes to this command:
The asset_id is now an asset that is NOT owned by USER 1.

And I have changed the export filename to: this-proof-should-be-bad.proof

This command produces another file this-proof-should-be-bad.proof.

this-proof-should-be-bad.zip

And I have my first concern... shouldn't proveownership return an error if this user does not own this asset? It seems strange that tapcli would produce the proof without returning an error?

But.... moving on, on USER 2

tapcli proofs verifyownership --proof_file ./this-proof-should-be-bad.proof

Here is the response:

{
    "valid_proof": true
}

.... Shouldn't USER 2 get a message here that this is NOT a valid proof?

thanks

[guggero]

Thanks for the detailed report. This does look weird at first glance. But in order for me to attempt to reproduce, can you give me some additional details please?

For example, the two assets that exist (ID 5eb3e9332e8b0d12d4831e26dd9c6553c2467b9a6927e7006953b33987ddcf1e and c94553c9c6e2bae301e25d0f70a3720c060dd752d6bca384f87687b777805f6b) where were they minted and by which user?

Are you sure that user 1 doesn't also have an asset output of c94553c9c6e2bae301e25d0f70a3720c060dd752d6bca384f87687b777805f6b? Because the first thing the ProveAssetOwnership RPC does is to fetch the proof by the given asset ID and script key. So if that doesn't give you an error, then it means there is a proof for such an asset available for user 1.

Also, please note that ownership is defined by who owns the private key of the script key of an asset. So since you use the same script key for both commands with the same user, the proofs are both expected to be valid (and the unexpected behavior is about two assets with different IDs but same script key being available).

If you can reproduce, could you post the exact commands you used to mint and distribute the assets to the two nodes so we can reproduce?

[MegalithicBTC]

Thanks for following up about this. Let me answer your queries in detail.

The first asset in play here:

5eb3e9332e8b0d12d4831e26dd9c6553c2467b9a6927e7006953b33987ddcf1e

This asset was minted by USER 2 in a quantity of 100, a couple weeks ago.

A few days ago, I sent 5 of this asset to USER 1. To send 5 of this asset, I ran these commands:

USER 1 GENERATES ADDRESS TO RECEIVE ASSET

tapcli addrs new --asset_id 5eb3e9332e8b0d12d4831e26dd9c6553c2467b9a6927e7006953b33987ddcf1e --amt 5
{
    "encoded": "tapbc1qqqsqqspqqzzqh4nayejazcdzt2gx83xmkwx257zgeae56f8uuqxj5an8xramnc7q5ss9r9f97qyf50wehxdxulvxkxyc2pwal9qmyjc0yl75uyxc3dds5mmqcssyrn2vlw8pyu3qwe5nuze47rwcma58jaekm4e4kwf87rxr8md3259pqss8wrstgl6tl49k8d8t890efhrr2qcdhnys6gzymw47x5sa33d7ue2pgqs2rpww4hxjan9wfek2unsvvaz7tm4de5hvetjwdjjumrfva58gmnfdenjuenfdeskucm98gcnqvpj8ygnu69z",
    "asset_id": "5eb3e9332e8b0d12d4831e26dd9c6553c2467b9a6927e7006953b33987ddcf1e",
    "asset_type": "NORMAL",
    "amount": "5",
    "group_key": "028ca92f8044d1eecdccd373ec358c4c282eefca0d9258793fea7086c45ad8537b",
    "script_key": "020e6a67dc70939103b349f059af86ec6fb43cbb9b6eb9ad9c93f86619f6d8aa85",
    "internal_key": "03b8705a3fa5fea5b1da759cafca6e31a8186de648690226dd5f1a90ec62df732a",
    "tapscript_sibling": "",
    "taproot_output_key": "3c9f37efc85fc1a01cac71296a8d62387846aeda0e377dbb032142c89cb04833",
    "proof_courier_addr": "universerpc://universe.lightning.finance:10029",
    "asset_version": "ASSET_VERSION_V0"
}

USER 2 SENDS ASSET TO USER 1

tapcli assets send --addr tapbc1qqqsqqspqqzzqh4nayejazcdzt2gx83xmkwx257zgeae56f8uuqxj5an8xramnc7q5ss9r9f97qyf50wehxdxulvxkxyc2pwal9qmyjc0yl75uyxc3dds5mmqcssyrn2vlw8pyu3qwe5nuze47rwcma58jaekm4e4kwf87rxr8md3259pqss8wrstgl6tl49k8d8t890efhrr2qcdhnys6gzymw47x5sa33d7ue2pgqs2rpww4hxjan9wfek2unsvvaz7tm4de5hvetjwdjjumrfva58gmnfdenjuenfdeskucm98gcnqvpj8ygnu69z
{
    "transfer":  {
        "transfer_timestamp":  "1714841715",
        "anchor_tx_hash":  "92e78d4a9ee25ef1f4b813099b23067a23eeedf2dd77b1f4c1011e9b3bc67636",
        "anchor_tx_height_hint":  842083,
        "anchor_tx_chain_fees":  "7126",
        "inputs":  [
            {
                "anchor_point":  "8e4186ad5a269deff62c5c46f49e5233bcbc6e2deb5bde5f7744659c9931b2f2:0",
                "asset_id":  "5eb3e9332e8b0d12d4831e26dd9c6553c2467b9a6927e7006953b33987ddcf1e",
                "script_key":  "02eed99169730f23a7eb431c87fe98f4d3f963fa5825833d0fdbcf2405b0264be7",
                "amount":  "100"
            }
        ],
        "outputs":  [
            {
                "anchor":  {
                    "outpoint":  "3676c63b9b1e01c1f4b177ddf2edee237a06239b0913b8f4f15ee29e4a8de792:0",
                    "value":  "1000",
                    "internal_key":  "0293f64fc855dd8f1e6d016620f619ab1ff769d6869f3978a6226b22f65ef55283",
                    "taproot_asset_root":  "6991055e501e032f56a536e68cfe815468ba512185647fae4ab87d9b1a9c6e80",
                    "merkle_root":  "6991055e501e032f56a536e68cfe815468ba512185647fae4ab87d9b1a9c6e80",
                    "tapscript_sibling":  "",
                    "num_passive_assets":  0
                },
                "script_key":  "02a84d1ccb6a22c36cd7d4130c2c37a6c8ca5631f717b7534094cd2adfd41bd782",
                "script_key_is_local":  true,
                "amount":  "95",
                "new_proof_blob":  "544150500004000000000224f2b231999c6544775fde5beb2d6ebcbc33529ef4465c2cf6ef9d265aad86418e000000000450000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000096e88000000000000000006fd016302000000000102f2b231999c6544775fde5beb2d6ebcbc33529ef4465c2cf6ef9d265aad86418e0100000000fffffffff2b231999c6544775fde5beb2d6ebcbc33529ef4465c2cf6ef9d265aad86418e00000000000000000003e803000000000000225120cbe1e35f529034bcab5b030eb16448a36981ad83c00eefccd63a417ae7530e58e8030000000000002251203c9f37efc85fc1a01cac71296a8d62387846aeda0e377dbb032142c89cb04833509d02000000000022512029f5a64ed38e6ca78ac4dc55ea5289de44d3815aaa5b5993f14f2cd2a51cf02101400c86f873c8bac7bf12265a410e2317af8b1d09f5ac94b0cdb2dc841a4bbcd077867d41b5f5eacb9e5eaeca13d1c680e224391c79603ce988337bdbc3fa80980e01403551ce965fdb047c6ac0349c8697f70eef01c4612878317691a3bf87662c4b4ac3348d78acc3a8c81c0faaa316ce2074f94b21c5b987e01a72ba17f1712a58ed000000000801000afd018b000100025db64403babef969521ef3fc036ef7b0c9665ab92a270b4dcbb779188b3767f87700000001134d6567616c69746847656e65736973436f696e23ab9dbaf930ad82a9ee7400c36e7d875a2c5ec6f5c7186cd8ded08bda05a48c000000000004010006015f0bad01ab0165f2b231999c6544775fde5beb2d6ebcbc33529ef4465c2cf6ef9d265aad86418e000000005eb3e9332e8b0d12d4831e26dd9c6553c2467b9a6927e7006953b33987ddcf1e02eed99169730f23a7eb431c87fe98f4d3f963fa5825833d0fdbcf2405b0264be70342014085ed03b1f06f01bac170ec224dbabf86f7950872e6014037e79d4e3ef1faf96273dde745b9a14b5de7d8b9d4e137142d82b30cacbc8cc422ab792368df2dc3070d28b9061c17809094cbb31f312116c31efa4d672d567b3a1137cfb5c87a52aaeb7e00000000000000640e020000102102a84d1ccb6a22c36cd7d4130c2c37a6c8ca5631f717b7534094cd2adfd41bd7821121028ca92f8044d1eecdccd373ec358c4c282eefca0d9258793fea7086c45ad8537b0c9f00040000000002210293f64fc855dd8f1e6d016620f619ab1ff769d6869f3978a6226b22f65ef55283037401490001000220f71e9c9062bcd78304e9bf2ce1cf5feeb064dde71cba347c1e4c4d8a7b98a96504220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff022700010002220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0df802c7000400000001022103b8705a3fa5fea5b1da759cafca6e31a8186de648690226dd5f1a90ec62df732a039c01710001000220f71e9c9062bcd78304e9bf2ce1cf5feeb064dde71cba347c1e4c4d8a7b98a965044a0001f84e4c8d68bcd581bfd9f879ff03677bc34e91cdf1ca5cf03b892dfa8939556e0000000000000005ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7f022700010002220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff2e00040000000202210281d085a448a691e548109c665f95c9019ee68a0c1f6cab98bd9c0b04883260460503040101160400000000",
                "split_commit_root_hash":  "b9061c17809094cbb31f312116c31efa4d672d567b3a1137cfb5c87a52aaeb7e",
                "output_type":  "OUTPUT_TYPE_SPLIT_ROOT",
                "asset_version":  "ASSET_VERSION_V0"
            },
            {
                "anchor":  {
                    "outpoint":  "3676c63b9b1e01c1f4b177ddf2edee237a06239b0913b8f4f15ee29e4a8de792:1",
                    "value":  "1000",
                    "internal_key":  "03b8705a3fa5fea5b1da759cafca6e31a8186de648690226dd5f1a90ec62df732a",
                    "taproot_asset_root":  "1040aaecfc19ab30d332217b3c4f62685671e82828db057467ba215860642e20",
                    "merkle_root":  "1040aaecfc19ab30d332217b3c4f62685671e82828db057467ba215860642e20",
                    "tapscript_sibling":  "",
                    "num_passive_assets":  0
                },
                "script_key":  "020e6a67dc70939103b349f059af86ec6fb43cbb9b6eb9ad9c93f86619f6d8aa85",
                "script_key_is_local":  false,
                "amount":  "5",
                "new_proof_blob":  "544150500004000000000224f2b231999c6544775fde5beb2d6ebcbc33529ef4465c2cf6ef9d265aad86418e000000000450000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000096e88000000000000000006fd016302000000000102f2b231999c6544775fde5beb2d6ebcbc33529ef4465c2cf6ef9d265aad86418e0100000000fffffffff2b231999c6544775fde5beb2d6ebcbc33529ef4465c2cf6ef9d265aad86418e00000000000000000003e803000000000000225120cbe1e35f529034bcab5b030eb16448a36981ad83c00eefccd63a417ae7530e58e8030000000000002251203c9f37efc85fc1a01cac71296a8d62387846aeda0e377dbb032142c89cb04833509d02000000000022512029f5a64ed38e6ca78ac4dc55ea5289de44d3815aaa5b5993f14f2cd2a51cf02101400c86f873c8bac7bf12265a410e2317af8b1d09f5ac94b0cdb2dc841a4bbcd077867d41b5f5eacb9e5eaeca13d1c680e224391c79603ce988337bdbc3fa80980e01403551ce965fdb047c6ac0349c8697f70eef01c4612878317691a3bf87662c4b4ac3348d78acc3a8c81c0faaa316ce2074f94b21c5b987e01a72ba17f1712a58ed000000000801000afd02fe000100025db64403babef969521ef3fc036ef7b0c9665ab92a270b4dcbb779188b3767f87700000001134d6567616c69746847656e65736973436f696e23ab9dbaf930ad82a9ee7400c36e7d875a2c5ec6f5c7186cd8ded08bda05a48c00000000000401000601050bfd024801fd02440165000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005fd01d94a00014c1cc1a855d74598f8e4640269c013f2617e51a84f519f264317686277b3727b000000000000005fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7ffd018b000100025db64403babef969521ef3fc036ef7b0c9665ab92a270b4dcbb779188b3767f87700000001134d6567616c69746847656e65736973436f696e23ab9dbaf930ad82a9ee7400c36e7d875a2c5ec6f5c7186cd8ded08bda05a48c000000000004010006015f0bad01ab0165f2b231999c6544775fde5beb2d6ebcbc33529ef4465c2cf6ef9d265aad86418e000000005eb3e9332e8b0d12d4831e26dd9c6553c2467b9a6927e7006953b33987ddcf1e02eed99169730f23a7eb431c87fe98f4d3f963fa5825833d0fdbcf2405b0264be70342014085ed03b1f06f01bac170ec224dbabf86f7950872e6014037e79d4e3ef1faf96273dde745b9a14b5de7d8b9d4e137142d82b30cacbc8cc422ab792368df2dc3070d28b9061c17809094cbb31f312116c31efa4d672d567b3a1137cfb5c87a52aaeb7e00000000000000640e020000102102a84d1ccb6a22c36cd7d4130c2c37a6c8ca5631f717b7534094cd2adfd41bd7821121028ca92f8044d1eecdccd373ec358c4c282eefca0d9258793fea7086c45ad8537b0e0200001021020e6a67dc70939103b349f059af86ec6fb43cbb9b6eb9ad9c93f86619f6d8aa851121028ca92f8044d1eecdccd373ec358c4c282eefca0d9258793fea7086c45ad8537b0c9f000400000001022103b8705a3fa5fea5b1da759cafca6e31a8186de648690226dd5f1a90ec62df732a037401490001000220f71e9c9062bcd78304e9bf2ce1cf5feeb064dde71cba347c1e4c4d8a7b98a96504220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff022700010002220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0df802c700040000000002210293f64fc855dd8f1e6d016620f619ab1ff769d6869f3978a6226b22f65ef55283039c01710001000220f71e9c9062bcd78304e9bf2ce1cf5feeb064dde71cba347c1e4c4d8a7b98a965044a00016e0bb9a2ca72e477c95cc95c3a67e5792464e63a67091bac57ff1a3780aa2c10000000000000005fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7f022700010002220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff2e00040000000202210281d085a448a691e548109c665f95c9019ee68a0c1f6cab98bd9c0b048832604605030401010f9f00040000000002210293f64fc855dd8f1e6d016620f619ab1ff769d6869f3978a6226b22f65ef55283037401490001000220f71e9c9062bcd78304e9bf2ce1cf5feeb064dde71cba347c1e4c4d8a7b98a96504220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff022700010002220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff160400000000",
                "split_commit_root_hash":  "",
                "output_type":  "OUTPUT_TYPE_SIMPLE",
                "asset_version":  "ASSET_VERSION_V0"
            }
        ]
    }
}

At this point, although this was committed to the blockchain (https://mempool.space/tx/3676c63b9b1e01c1f4b177ddf2edee237a06239b0913b8f4f15ee29e4a8de792#vout=1 ) .... I did not find that the transfer successfully completed.... I ran tapcli assets list on USER 1 , but this did not show ownership of any assets.

I also found that there was not an .assetproof file in the folder where I think I think it should have been generated. So I ran this:

USER 2 EXPORTS PROOF

tapcli proofs export --asset_id 5eb3e9332e8b0d12d4831e26dd9c6553c2467b9a6927e7006953b33987ddcf1e --script_key 02eed99169730f23a7eb431c87fe98f4d3f963fa5825833d0fdbcf2405b0264be7 --proof_file ./5eb3e9332e8b0d12d4831e26dd9c6553c2467b9a6927e7006953b33987ddcf1e/02eed99169730f23a7eb431c87fe98f4d3f963fa5825833d0fdbcf2405b0264be7-8e4186ad5a269deff62c5c46f49e5233-0.assetproof

At this point, I think I somehow "synched" this proof with a universe... unfortunately I don't have the record of any command(s) I used to do this.... note that USER 1 has in its federation the universe assets.megalith-node.com, which is served by USER 2, so the asset may have "automatically" synched in this way.

But then I was able to run tapcli assets list on USER 1 and I could see that there were a quantity of 5 of this asset on the USER 1 node, so I assumed this was a success.

---

Next, regarding asset c94553c9c6e2bae301e25d0f70a3720c060dd752d6bca384f87687b777805f6b ... This is a random asset ID I pulled from the universe data. Neither USER 1 or USER 2 minted or owns any of this asset. I chose this at random to test the proveownership and verifyownership functionality.

Regarding this:

Also, please note that ownership is defined by who owns the private key of the script key of an asset. So since you use the same script key for both commands with the same user, the proofs are both expected to be valid (and the unexpected behavior is about two assets with different IDs but same script key being available).

I don't quite understand this. My guess is that tapcli proofs verifyownership --proof_file ./this-proof-should-be-bad.proof should return false since the this-proof-should-be-bad.proof proof was generated with an arbitrary asset ID which is not owned by either USER 1 or USER 2.

[guggero]

Okay, I've confirmed that this has nothing to do with the ownership proof by itself. It's a problem of how we fetch the initial proof file that is then signed to create the ownership proof.
Because in some parts of the tapd database the script key is the unique identifier for an asset output, the given value for the asset ID isn't even looked at, since a proof was found for the script key 02eed99169730f23a7eb431c87fe98f4d3f963fa5825833d0fdbcf2405b0264be7.
So basically the --asset_id 5eb3e9332e8b0d12d4831e26dd9c6553c2467b9a6927e7006953b33987ddcf1e argument is ignored if there is a proof to be found with just using the script key (which is, just for a different asset ID).

You can confirm this by looking at the ownership proof in a decoded format (tapcli proofs decode --proof_file :/this-proof-should-be-bad.proof), it will show you a different asset ID.

So if you want to confirm that you get an appropriate error, try using a script key the local node doesn't own (e.g. for USER 1 use a script key of USER 2).