rpc+tapcli: Implement method to decode proofs into human-readable format #181

habibitcoin · 2022-10-25T22:06:06Z

Related to #180

Would be nice to be able to view proofs in human readable format (https://github.com/lightninglabs/taro/blob/main/proof/proof_test.go#L127); this will make it easier for individuals to wrap their mind around the mental model of proofs, and what they contain, and ideally accelerate universe development

Able to access some of the raw data!

edit: here is sample output as of now:

taro % tarocli proofs decode --proof_file habibtaro_usd_jan2.json
{
    "proof_index": "0",
    "asset": {
        "version": 0,
        "asset_genesis": {
            "genesis_point": "3dea4202dc504302a68fa598ed6ade31f83fdc3a58b095f4d6259587fa48dea0:1",
            "name": "habibtaro_usd_jan_noem23",
            "meta": "68616269627461726f2e636f6d5f6a616e5f6e6f656d3233",
            "asset_id": "8074f97dc3f2a5c3375ddaccf66ffc0bd1fbdd0b8261ee536a1bc9653c0d9f0b",
            "output_index": 0,
            "genesis_bootstrap_info": "a0de48fa879525d6f495b0583adc3ff831de6aed98a58fa6024350dc0242ea3d000000011868616269627461726f5f7573645f6a616e5f6e6f656d32331868616269627461726f2e636f6d5f6a616e5f6e6f656d32330000000000",
            "version": 0
        },
        "asset_type": "NORMAL",
        "amount": "21000000",
        "lock_time": 0,
        "relative_lock_time": 0,
        "script_version": 0,
        "script_key": "020c7b5c4abd3b7cbe48a1cb8193312233924f22cfdc07e9c64a7f867cca3b5a3e",
        "asset_group": {
            "raw_group_key": null,
            "tweaked_group_key": "0253c2de331021b68632d5cb76110d4a65e4436f7762e47b8af058641012694110",
            "asset_id_sig": "cb61c6c21047b288e116880cb6abf941c754127a113e081e14b65cf834f445325817c4be9cdd44703e05b3a0d60adf10392b454814f89635e9339ae0f55fced8"
        },
        "chain_anchor": {
            "anchor_tx": "02000000000101a0de48fa879525d6f495b0583adc3ff831de6aed98a58fa6024350dc0242ea3d0100000000ffffffff02e803000000000000225120593814466c8ae931db5a335f62737d1f5979f7f1fa0d3b75de38c1bc356b584927d2570000000000225120951d666ae736743e5dfe8eaeaad80039f689df429bf0220dd245d1938dc21cfb0140a392cedef28b6efdb26dc31f354a8633ca6301aef94e8f55ed772f6a2fbb9673735a0f80a68d10dc57980560f94a98d1fc2b480b447818a6039ac0229139eea500000000",
            "anchor_txid": "986c8f9263aa5a0d1d6733019bc8660216b3e6a3380c38b73e39811881c677bd",
            "anchor_block_hash": "000000000004479a4e6a788f3994069b2c15b3b61b00673fd8a099323f4f6e78",
            "anchor_outpoint": "986c8f9263aa5a0d1d6733019bc8660216b3e6a3380c38b73e39811881c677bd:0",
            "internal_key": null
        }
    },
    "tx_merkle_proof": "06912174fe872bb334e87038d02313e51f85e76442f79b73b04e0c10b3330c84c2b2dc73a43a0cadf17126b05122e6a54f2375572e5bb4f4d02b9fd7b2d3741ede711f85425cd99a2fd0a2b7b735de769274f44d3564105fc2829821c69f37e111be624fc946a60f91f90b4d7462581bca9790ad6099e1effb271733a9ec7231fbd04772186e38be31da8c88d457753455778ee96ab60a76f44c1e4065e374a3e06bfc6be5cc665baf7d81dd617ec34b0e6cd91252f8a46221763aedb35872fef738",
    "inclusion_proof": "00040000000001210285127fca8f36e75b0508e6a6a561ab5db97003523f227596bc4f7be436a9b7a402c400490001000120343934bd45c74d19ae43f6034b639f70232264ad03d7b02555b5a3f478cfbe9202220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0177000100017200026b9241c6ff865f4be097261e3a4170e7ceceb7e51e7565b9a5b692fc6a9ad3d80000000001406f40e62fa07552a32c0fc1179e234f024ed3d833b924c773810e649d3da1ebae8b8d000000000280de80ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff5f",
    "exclusion_proofs": [
        "000400000001012102c17d96c48980a0f48932ac66819e6ddc86cce68edaae0179d66d94326ce130160303020101"
    ]
}

Roasbeef · 2022-11-10T02:48:45Z

this will make it easier for individuals to wrap their mind around the mental model of proofs, and what they contain, and ideally accelerate universe development

Totally!

I think in addition to the basic decode method, it also makes sense to return this information (the last snapshot) from the verify proof command as well.

Roasbeef · 2022-11-10T02:56:37Z

Answering the questions you posted:

Should we only return the last proof?

I think so. It's also possible to pass in an index, then we can seek to the desired index using this method: https://github.com/lightninglabs/taro/blob/main/proof/file.go#L203-L205

Should we return any of the merkle trees/additional information? Block header? Additional inputs?

I think the block header/height information would be useful. Then maybe a verbose option to include the serialized Bitcoin merkle proof as well as the series of inclusion (and exclusion) proofs?

Is the anchor tx available in proofs?
Yes, it's this field: https://github.com/lightninglabs/taro/blob/77b69191fc60c57135c70e25b338d5d401bfbb2b/proof/proof.go#L40-L42

Am I supposed to commit the go.mod/go.sum files?

Yeah, this commits the set of dependancies.

Think I need to fix taro.swagger.json, maybe missing other generated files?
Am I supposed to update the protoc-gen-go and protoc versions or leave that out?

If you do make rpc, then it should handle creating all the auto generated file diffs.

I'd leave those versions the same, since we pin to the same version so everyone generates the same set of protos.

go.mod

cmd/tarocli/proofs.go

dstadulis · 2022-11-15T19:47:24Z

@habibitcoin Any update on when we can expect this?

habibitcoin · 2022-11-16T05:06:01Z

Thanks for the review @Roasbeef ! All makes sense

@dstadulis expecting to complete this over Thanksgiving holiday at latest

habibitcoin · 2022-11-27T17:58:07Z

@Roasbeef I'm having a bit of trouble on

Then maybe a verbose option to include the serialized Bitcoin merkle proof as well as the series of inclusion (and exclusion) proofs?

What is the serialized Bitcoin merkle proof?
Would these fields ideally be output as bytes? If so, is this the proper way to do so:

var inclusionProofBuf bytes.Buffer
	if err := decodedProof.InclusionProof.Encode(&inclusionProofBuf); err != nil {
		return nil, fmt.Errorf("unable to encode inclusion proof: %w",
			err)
	}

For the exclusion proofs, would that be an array of bytes? Would that be done by:

repeated bytes exclusion_proofs

I believe everything else is implemented!
Edit: Have a bug with block_height output*

Example output below:

guggero · 2022-11-28T09:07:22Z

What is the serialized Bitcoin merkle proof?

The field TxMerkleProof of type TxMerkleProof.

Would these fields ideally be output as bytes? If so, is this the proper way to do so:

Yes, that looks good. Seems like all the fields mentioned (TxMerkleProof, InclusionProof and ExclusionProofs) have an Encode method.

For the exclusion proofs, would that be an array of bytes? Would that be done by:

Yes, repeated bytes exclusion_proofs sounds good on the RPC level.

Have a bug with block_height output*

Yes, the block_height should be a simple block number. But that information is not included in the proof, so you can't print it.

habibitcoin · 2022-12-05T18:39:55Z

Latest output:

{
    "proof_index": "0",
    "anchor_outpoint": "e3dcdfe1f03821430a13742189af3a8c451635b113e852f690b4b59dd864a643:1",
    "anchor_tx": "063280c2cd2a1c1cf42cf2fc3fb21cd6660a097e22dadc8db5f733ce36216a3d",
    "block_header": "000000000000000d14419cb8be4dabdea503ed194be79e2c6063d2aefb1fb646",
    "block_height": "0000000000000015879d4297902849c42bd5f8b17cc48c43b9150321f7f845b2",
    "asset": {
        "version": 0,
        "asset_genesis": {
            "genesis_point": "e3dcdfe1f03821430a13742189af3a8c451635b113e852f690b4b59dd864a643:1",
            "name": "habibtaro",
            "meta": "68616269627461726f2e636f6d",
            "asset_id": "f30905681df0b8b6122ba38fbf3711d01ede2ba678cfbd4454486d7027972501",
            "output_index": 0,
            "genesis_bootstrap_info": "43a664d89db5b490f652e813b13516458c3aaf892174130a432138f0e1dfdce3000000010968616269627461726f0d68616269627461726f2e636f6d0000000000",
            "version": 0
        },
        "asset_type": "NORMAL",
        "amount": "21000000",
        "lock_time": 0,
        "relative_lock_time": 0,
        "script_version": 0,
        "script_key": "0206b93c43b8a85385e1f6021108901ef99eeb5a69378ec805dea8abc4a3fd868c",
        "asset_group": {
            "raw_group_key": null,
            "tweaked_group_key": "0337e043736df85040e97def7c8cdb55dc97f553348d24058167622b585630e178",
            "asset_id_sig": "a0e4d260effd6a4babaf8a00d6534e81a2801f6723d99af768cb1ca17202bf77525f16d04e70691bc8941fedf8bf06ba9f01ce95f19a19178ceaad39f8a29ba3"
        },
        "chain_anchor": {
            "anchor_tx": "0200000000010143a664d89db5b490f652e813b13516458c3aaf892174130a432138f0e1dfdce30100000000ffffffff02e803000000000000225120e1e23ab4aa5f26d54dd24be4401e8eb0e560a09a94a428481408fd53e404ae0bcdc1580000000000160014c7cfecd42c55786054ec4eaad71b2f62e68428fd024730440220321d45c17beb16a68f7ba8a23cf386de149f3b4b52082b58d555f2e08a9efbde02202a3ef23f5b1e8cd6241ae0ec3c922e48f858281cf7a9462d7e0bc4c218cff0350121030c999ac2ee7695f855f525b1a24e97d53ada26dfa4df83cbf40df173e38664d200000000",
            "anchor_txid": "3d6a2136ce33f7b58ddcda227e090a66d61cb23ffcf22cf41c1c2acdc2803206",
            "anchor_block_hash": "46b61ffbaed263602c9ee74b19ed03a5deab4dbeb89c41140d00000000000000",
            "anchor_outpoint": "e3dcdfe1f03821430a13742189af3a8c451635b113e852f690b4b59dd864a643:1",
            "internal_key": null
        }
    },
    "tx_merkle_proof": "038082936f2a9190fb7de3ef010e9a3354ca6e08aa2d88d1286c3a437b126084cfa3ab6bdd46c6fd76ebee5a65b106daf9acc26646299f4cf3468a49af16308d93d73b19aafc73920016b43b6458b9f63dfdd6329929052cf313817e9aeaf76f0d03",
    "inclusion_proof": "0004000000000121021b816b11a35a95aae3c59b314895ddd22e0f68ce6b1764b05d9f3928185672ad02740049000100012046690b2765ce8d60837116cd0150f6defd733b66df9f6d6caa47883fcd09bc7202220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff012700010001220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
    "exclusion_proofs": [
    ]
}

habibitcoin · 2022-12-05T18:45:42Z

Also thinking to just remove block height because there doesnt appear to be any easy way to extract this information

Roasbeef · 2022-12-06T03:46:46Z

Also thinking to just remove block height because there doesnt appear to be any easy way to extract this information

Should just be available as a field: https://github.com/lightninglabs/taro/blob/f6a581b6395fe779db7cbb5a4536a39bb0440dbe/proof/file.go#L317-L318

Roasbeef · 2023-01-11T01:10:40Z

Is this ready for another round @habibitcoin ?

habibitcoin · 2023-01-25T01:41:56Z

Same issue #230 for AnchorBlockHash. Included that.

Ready for final review @Roasbeef !

taro % tarocli proofs decode --proof_file habibtaro_usd_jan2.json
{
    "proof_index": "0",
    "asset": {
        "version": 0,
        "asset_genesis": {
            "genesis_point": "3dea4202dc504302a68fa598ed6ade31f83fdc3a58b095f4d6259587fa48dea0:1",
            "name": "habibtaro_usd_jan_noem23",
            "meta": "68616269627461726f2e636f6d5f6a616e5f6e6f656d3233",
            "asset_id": "8074f97dc3f2a5c3375ddaccf66ffc0bd1fbdd0b8261ee536a1bc9653c0d9f0b",
            "output_index": 0,
            "genesis_bootstrap_info": "a0de48fa879525d6f495b0583adc3ff831de6aed98a58fa6024350dc0242ea3d000000011868616269627461726f5f7573645f6a616e5f6e6f656d32331868616269627461726f2e636f6d5f6a616e5f6e6f656d32330000000000",
            "version": 0
        },
        "asset_type": "NORMAL",
        "amount": "21000000",
        "lock_time": 0,
        "relative_lock_time": 0,
        "script_version": 0,
        "script_key": "020c7b5c4abd3b7cbe48a1cb8193312233924f22cfdc07e9c64a7f867cca3b5a3e",
        "asset_group": {
            "raw_group_key": null,
            "tweaked_group_key": "0253c2de331021b68632d5cb76110d4a65e4436f7762e47b8af058641012694110",
            "asset_id_sig": "cb61c6c21047b288e116880cb6abf941c754127a113e081e14b65cf834f445325817c4be9cdd44703e05b3a0d60adf10392b454814f89635e9339ae0f55fced8"
        },
        "chain_anchor": {
            "anchor_tx": "02000000000101a0de48fa879525d6f495b0583adc3ff831de6aed98a58fa6024350dc0242ea3d0100000000ffffffff02e803000000000000225120593814466c8ae931db5a335f62737d1f5979f7f1fa0d3b75de38c1bc356b584927d2570000000000225120951d666ae736743e5dfe8eaeaad80039f689df429bf0220dd245d1938dc21cfb0140a392cedef28b6efdb26dc31f354a8633ca6301aef94e8f55ed772f6a2fbb9673735a0f80a68d10dc57980560f94a98d1fc2b480b447818a6039ac0229139eea500000000",
            "anchor_txid": "986c8f9263aa5a0d1d6733019bc8660216b3e6a3380c38b73e39811881c677bd",
            "anchor_block_hash": "000000000004479a4e6a788f3994069b2c15b3b61b00673fd8a099323f4f6e78",
            "anchor_outpoint": "986c8f9263aa5a0d1d6733019bc8660216b3e6a3380c38b73e39811881c677bd:0",
            "internal_key": null
        }
    },
    "tx_merkle_proof": "06912174fe872bb334e87038d02313e51f85e76442f79b73b04e0c10b3330c84c2b2dc73a43a0cadf17126b05122e6a54f2375572e5bb4f4d02b9fd7b2d3741ede711f85425cd99a2fd0a2b7b735de769274f44d3564105fc2829821c69f37e111be624fc946a60f91f90b4d7462581bca9790ad6099e1effb271733a9ec7231fbd04772186e38be31da8c88d457753455778ee96ab60a76f44c1e4065e374a3e06bfc6be5cc665baf7d81dd617ec34b0e6cd91252f8a46221763aedb35872fef738",
    "inclusion_proof": "00040000000001210285127fca8f36e75b0508e6a6a561ab5db97003523f227596bc4f7be436a9b7a402c400490001000120343934bd45c74d19ae43f6034b639f70232264ad03d7b02555b5a3f478cfbe9202220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0177000100017200026b9241c6ff865f4be097261e3a4170e7ceceb7e51e7565b9a5b692fc6a9ad3d80000000001406f40e62fa07552a32c0fc1179e234f024ed3d833b924c773810e649d3da1ebae8b8d000000000280de80ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff5f",
    "exclusion_proofs": [
        "000400000001012102c17d96c48980a0f48932ac66819e6ddc86cce68edaae0179d66d94326ce130160303020101"
    ]
}

habibitcoin · 2023-01-25T01:55:38Z

Also 1 last question, wondering if I should include this is the same or a new PR: meta should not be displayed as bytes. It is sent in via CLI as a string, so should be output as the string:

"meta": "habibtaro.com_jan_noem23",
versus
 "meta": "68616269627461726f2e636f6d5f6a616e5f6e6f656d3233",

String seems much more useful?

Roasbeef · 2023-02-02T00:41:05Z

Also 1 last question, wondering if I should include this is the same or a new PR: meta should not be displayed as bytes. It is sent in via CLI as a string, so should be output as the string:

I think for now can have it assume things are displayed as bytes, I'm making some changes to how the meta bytes are presented/transmitted in this PR: #249.

Roasbeef

Nice work! This should be super useful for future UIs and also general debugging and tinkering. I think the only thing this is missing is a basic integration tests, which can cover things like:

the error paths (no proof, index too large, etc)
proof matching up with the same proof decoded externally

rpcserver.go

tarorpc/taro.proto

rpcserver.go

cmd/tarocli/proofs.go

positiveblue

Looking good @habibitcoin 🎉

I left some doubts and a couple of nits

tarorpc/taro.proto

rpcserver.go

positiveblue · 2023-02-03T17:22:10Z

rpcserver.go

+		err          error
+	)
+
+	if index < 0 {


for "partially verified" we could do it in a reverse way

if len(proofs) >= index { // return err } // Proofs are store from older to newer. proofIdx := proofFile.NumProofs() - 1 - idx decodedProof, err = proofFile.ProofAt(proofIdx) if err != nil { return nil, err }

In that case you get by default the last proof, that is what you will usually want.

rpcserver.go

cmd/tarocli/proofs.go

tarorpc/taro.proto

dstadulis · 2023-02-07T13:47:27Z

@habibitcoin can you check positiveblue's comments? Would love to include your PR in the taro v0.2 release.

habibitcoin · 2023-02-07T16:06:11Z

@dstadulis almost done! Have addressed most comments locally. Mainly just need to add comments and tests now.

@positiveblue @Roasbeef any guidance on tests you can provide? My initial plan was to create a proofs_test.go file in itest and use assets_test as a bit of inspiration. Mint an asset, export it, verify the proof, and confirm the output matches that of the assets list CLI. Thoughts?

guggero

Nice, LGTM, just a couple of nits.

itest/assertions.go

rpcserver.go

jharveyb

Thanks for the contribution with this! left some notes re: metadata and input verification.

jharveyb · 2023-05-31T15:30:25Z

rpcserver.go

+	)
+
+	// Default to latest proof
+	index = int64(proofFile.NumProofs()) - 1 - index


Should check that index >= 0 && index < proofFile.NumProofs() if index is going to be an int, to reject invalid indexes and make sure this never goes below 0.

What would be a superior UX?

[tapcli] unable to verify file: rpc error: code = Unknown desc = unable to marshal proof: invalid index 4294967295

The above is the current error message returned. I modified it so it returns the index you actually input, and I think this is most helpful to the user instead of making any assumptions about the proper index:

[tapcli] unable to verify file: rpc error: code = Unknown desc = unable to marshal proof: invalid index 2 is greater than latest proof index of 1

I think it's okay the way it is, but maybe we should make the proof_at_depth field uint32 to avoid it being negative? And I don't think files with more than 2 billion proofs will ever exist, so 32bit should be enough.

taprpc/taprootassets.proto

dstadulis · 2023-06-06T23:23:10Z

@habibitcoin we're shaping the queue of PRs for tap-v0.2.1 do you think you can update this PR to make it in?

lightninglabs-deploy · 2023-06-14T00:24:42Z

@Roasbeef: review reminder
@positiveblue: review reminder
@habibitcoin, remember to re-request review from reviewers when ready

straumat · 2023-06-14T16:09:00Z

@habibitcoin sorry to bother you, do you think you will be able to finish it ? thx again for your great work !

dstadulis · 2023-06-15T16:06:10Z

Believe this PR is being worked on for v0.2.1

habibitcoin · 2023-06-15T22:20:25Z

@dstadulis ready for final review!

guggero

Thank you very much for the update!
Did a final pass, mostly nits, nothing major. So this is very close IMO.

rpcserver.go

guggero · 2023-06-16T08:09:44Z

rpcserver.go

+	)
+
+	// Default to latest proof
+	index = int64(proofFile.NumProofs()) - 1 - index


I think it's okay the way it is, but maybe we should make the proof_at_depth field uint32 to avoid it being negative? And I don't think files with more than 2 billion proofs will ever exist, so 32bit should be enough.

taprpc/taprootassets.proto

cmd/tapcli/proofs.go

rpcserver.go

habibitcoin · 2023-06-16T17:18:20Z

@dstadulis ready for review again 👍

positiveblue

Thank you for pushing this to the end @habibitcoin 🎉

LGTM. I see that you added some of the fields that @guggero proposed to the grpc messages but they are not used anywhere. Do you plan to populate the num_additional_inputs/challenge_witness fields in your responses too??

rpcserver.go

habibitcoin · 2023-06-17T01:49:27Z

@positiveblue thanks for the review! Not sure I understand your comment re; the addtl fields, they should be returned properly I believe, attached a sample output:

{
  "decoded_proof": {
    "proof_at_depth": 1,
    "number_of_proofs": 2,
    "asset": {
      "version": 0,
      "asset_genesis": {
        "genesis_point": "fde4b6b44df8e4bf8a8a48961d2a61f432146c7f742966945216208bda14dadd:1",
        "name": "Habibitcoins",
        "meta_hash": "49f7b90f9eefe6a5e5c6fe3e1317e1894ad721f9c9f2ac0070a631e7b3bf0302",
        "asset_id": "3c59caaeddd621f1b537d2329aebec2087c716623395a7b72cdcf4a96702b269",
        "output_index": 0,
        "version": 0
      },
      "asset_type": "NORMAL",
      "amount": "20999998",
      "lock_time": 0,
      "relative_lock_time": 0,
      "script_version": 0,
      "script_key": "02ebd16b59524d98be070002493c9724d03f68bc57c27176ac5cb1233d6c9b28ce",
      "script_key_is_local": false,
      "asset_group": null,
      "chain_anchor": {
        "anchor_tx": "0200000000010295bfdee8c817a893f6ad8af7a208e522325ffcb9a8ef6c041952e29b572894720100000000ffffffff95bfdee8c817a893f6ad8af7a208e522325ffcb9a8ef6c041952e29b5728947200000000000000000003e803000000000000225120a6a5e1a951faf32eba5592234343118a071f35dbeb1470a0cbf191fd00e730a2e8030000000000002251206e37557177f706b67fea6be30f4e6abec3fdd57358bcc67a5cd6fb30e496bc1811663900000000002251205d3bea984c8f60995b68a2533ac75ba1c1ae3f498f479c9804c9e0aa6b1e64d70140e5476d1c78d070c7cdb5ed331be125410bc9b75d8610092a9b64f146f2dffcac3e8406b930529d1f337fc5a9c22e8057f77e2398d950ce34ea6c3fcd6aec5206014037ce813bc7e3c51e260316835092d52e3a1a60f5337040470faebc86b0cbcb3e79f8cd2b81279091a28fac6206ec1eddf3892f1f5413fc8cf6a50fd157195f1a00000000",
        "anchor_txid": "d77db8788b2613882fc102eefb3971597398631b6928ba458b2791acef03c1c3",
        "anchor_block_hash": "00000000000092e4ac7e679a3bf8b43870bcf35cea0bcdf7e46f0531296f7e7b",
        "anchor_outpoint": "d77db8788b2613882fc102eefb3971597398631b6928ba458b2791acef03c1c3:0",
        "internal_key": "0256f3f99616e881163a6f6d15e6866a4800106523827c4649587d95b226e394a1",
        "merkle_root": "",
        "tapscript_sibling": ""
      },
      "prev_witnesses": [
        {
          "prev_id": {
            "anchor_point": "729428579be25219046cefa8b9fc5f3222e508a2f78aadf693a817c8e8debf95:0",
            "asset_id": "3c59caaeddd621f1b537d2329aebec2087c716623395a7b72cdcf4a96702b269",
            "script_key": "0243067fd2835d92360259c969a244e6b43bb57ee0a78fb0f250a123a915cb5cbe",
            "amount": "0"
          },
          "tx_witness": [
            "b9cf4f8c6fd1bdb0ae64bbd17d16ec23ae907a138439fcb0198fe7124348127ac3100ab71703c0b8a0471550e973d4788b47b8855aca0054e93ff2ff0e5922c5"
          ],
          "split_commitment": null
        }
      ],
      "is_spent": false
    },
    "meta_reveal": {
      "data": "89504e470d0a1a0a0000000d49484452000000100000001008060000001ff3ff61000000017352474200aece1ce90000023349444154384f6d534d6b1351143d6f32c94c1ac7a64d9a6ad52a6d3536a0e84610ec42dd88144137aedc0842a082a5a2d02269d21495508c15b10bc56edc29085d17c45d7f40408ad252544c3f4c88f9e84c66de3c9999269999f4aedeb91fe79d7bdfbb04fb184b829307cf2600bd1915efe4520460ee74e2762c4f9e0e8dc4f81d78796748d5e05bcaf1e423a83de02050de47197cdefd44b57caa0adfc6aa87242d794d02e5ed505bb1ac6810463f817e1d075fcfb748a80ee1ee2a07809904e74e04832b8948b19151557474c7bf9b70f3f5107aefff80b218752aab6b10e36bc420e0e537fdaabd674d07f44b5948b11b8e22e5dda0038bf7d678b29bed4b12919f76372ec4374c97bc701c5b158afe47bfb0337f0c926028b76c7d93cc9152a6272d74789fb4118cfd365dbbdf3ec33f7cd33c17b24710f0d932eb14a4f83494165d042a05a4893f589f89a052673833bb6da9993fecb8872914a43c1b4ef122976844e8f02d04ae2f98b03a77081ec2205f984270e401ca995e783d2d8e8b2f4ba78c210ab55448263eabb79f058a9399bfee8e4c5c7b160167fb39fec96db1017b6ae9f056a3aaa23288b73f408a5d43ee6137340a1cede410f0daaa551d1d3305f3190de3aa53418a3d15557f046a218fbee74554a64356426bf8006508a48b410025fb57eeaa3eee2cc0f64c869203f65b0d268d61254fbf5c5d2c5f31a07b990e9627a452631eee41b0ba0ee945390ca039a4b66ddc23edba3c209e5f1ae5970d92f0ab4a54018c65f8e726fd0f6306b7c385165e030000000049454e44ae426082",
      "type": "META_TYPE_OPAQUE",
      "meta_hash": "49f7b90f9eefe6a5e5c6fe3e1317e1894ad721f9c9f2ac0070a631e7b3bf0302"
    },
    "tx_merkle_proof": "070c09bbd9ca188bd8541b2de2945b90cd7f3b6ccd90223ef6b6cd11704c111d5031c054611c06bc4349e5f3f74a88df6adb8a76deadf6c045e2f2eacee03049354fb1377b7fa07a7b4f6b625a3733da0dbbb15f2560f961f94a79c814530e9515097bc160268b501230e07e8d0b79bcdeb0151825136aee74f2db70fe6657c38d1b95d11d96b440a961eb272471265dd7736ebd6e11faa7881513e80d60ba116fa5ece87e70abca83f8daa9fbe4be8fee9f2ea170a1f88e9160e415efd5c88e79aba8971a11505001629f96e2468f2b1b24e4e07ded0b8c3d486c850c30fbb1bc6c",
    "inclusion_proof": "00040000000001210256f3f99616e881163a6f6d15e6866a4800106523827c4649587d95b226e394a10274004900010001203c59caaeddd621f1b537d2329aebec2087c716623395a7b72cdcf4a96702b26902220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff012700010001220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
    "exclusion_proofs": [
      "000400000001012102e5a4da38c35ad44c0edcf1d007fd307584d02deb712347a3c8b356ec6264f27a029c007100010001203c59caaeddd621f1b537d2329aebec2087c716623395a7b72cdcf4a96702b269024a000140adb74259c2ab240034fcf23c67b111f21b82aefe04da57e35283612f12ef230000000000000002ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7f012700010001220000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
      "000400000002012102f59c2086590b3a04dcedd2c5a0b6565f17233abd84eab00ad382f9b6fb6508880303020101"
    ],
    "split_root_proof": "",
    "num_additional_inputs": 0,
    "challenge_witness": []
  }
}

guggero

Very nice! Just two more small nits then we're good to go.

taprpc/taprootassets.proto

rpcserver.go

taprpc: use string everywhere for blockhash itest: update for anchor blockhash given as a string

taprpc: create DecodeProofRequest and DecodeProofResponse objects rpc: Implement DecodeProof + include into VerifyProof

habibitcoin · 2023-06-19T15:54:10Z

@guggero think this should be ready!

guggero · 2023-06-20T11:27:45Z

taprpc/taprootassets.proto

+
+    // The merkle proof for AnchorTx used to prove its
+    // inclusion within BlockHeader.
+    bytes tx_merkle_proof = 5;


Not really, as we only have the block hash in there. But with the block hash someone wanting to verify the proof outside of tapd could fetch the whole block and do it that way, so I guess it's okay for now.

habibitcoin mentioned this pull request Oct 25, 2022

rpc+tarocli: Implement method to decode proofs into human-readable format #180

Closed

habibitcoin force-pushed the decode-proof branch from dbd8496 to 0a3cf18 Compare October 30, 2022 20:20

Roasbeef requested a review from jharveyb November 3, 2022 01:47

habibitcoin marked this pull request as ready for review November 6, 2022 12:57

Roasbeef reviewed Nov 10, 2022

View reviewed changes

go.mod Outdated Show resolved Hide resolved

cmd/tarocli/proofs.go Outdated Show resolved Hide resolved

habibitcoin force-pushed the decode-proof branch from 0a3cf18 to 29ff7db Compare November 27, 2022 17:49

habibitcoin requested review from Roasbeef and removed request for jharveyb November 27, 2022 17:58

Roasbeef removed their request for review January 13, 2023 00:02

habibitcoin force-pushed the decode-proof branch from 29ff7db to cbf1ef3 Compare January 25, 2023 01:41

habibitcoin requested a review from Roasbeef January 25, 2023 01:42

Roasbeef requested a review from positiveblue February 2, 2023 00:41

Roasbeef reviewed Feb 2, 2023

View reviewed changes

dstadulis assigned habibitcoin Feb 3, 2023

positiveblue reviewed Feb 3, 2023

View reviewed changes

habibitcoin requested a review from Roasbeef May 28, 2023 05:28

guggero self-requested a review May 29, 2023 07:32

guggero approved these changes May 30, 2023

View reviewed changes

itest/assertions.go Show resolved Hide resolved

rpcserver.go Outdated Show resolved Hide resolved

rpcserver.go Outdated Show resolved Hide resolved

rpcserver.go Outdated Show resolved Hide resolved

jharveyb self-requested a review May 31, 2023 15:27

jharveyb reviewed May 31, 2023

View reviewed changes

habibitcoin force-pushed the decode-proof branch from 409e7ce to ebe5717 Compare June 15, 2023 22:19

habibitcoin requested a review from jharveyb June 15, 2023 22:19

guggero reviewed Jun 16, 2023

View reviewed changes

habibitcoin force-pushed the decode-proof branch from ebe5717 to f51ce2d Compare June 16, 2023 17:17

habibitcoin requested a review from guggero June 16, 2023 17:18

positiveblue approved these changes Jun 16, 2023

View reviewed changes

rpcserver.go Outdated Show resolved Hide resolved

rpcserver.go Show resolved Hide resolved

rpcserver.go Show resolved Hide resolved

guggero approved these changes Jun 19, 2023

View reviewed changes

taprpc/taprootassets.proto Show resolved Hide resolved

rpcserver.go Outdated Show resolved Hide resolved

habibitcoin added 4 commits June 19, 2023 11:52

taprpc + itest: use string everywhere for blockhash

931ed75

taprpc: use string everywhere for blockhash itest: update for anchor blockhash given as a string

taprpc + rpc: implement DecodeProof methods and update VerifyProof

5104501

taprpc: create DecodeProofRequest and DecodeProofResponse objects rpc: Implement DecodeProof + include into VerifyProof

itest: Update verifyProofBlob() to include DecodeProof() assertions

c05ad13

tapcli: implement proof decode command

dc1f762

habibitcoin force-pushed the decode-proof branch from f51ce2d to dc1f762 Compare June 19, 2023 15:53

habibitcoin requested a review from guggero June 19, 2023 15:54

guggero approved these changes Jun 20, 2023

View reviewed changes

guggero added this pull request to the merge queue Jun 20, 2023

Merged via the queue into lightninglabs:main with commit 012554c Jun 20, 2023
11 checks passed

rpc+tapcli: Implement method to decode proofs into human-readable format #181

rpc+tapcli: Implement method to decode proofs into human-readable format #181

Conversation

habibitcoin commented Oct 25, 2022 • edited Loading

Roasbeef commented Nov 10, 2022

Roasbeef commented Nov 10, 2022

dstadulis commented Nov 15, 2022

habibitcoin commented Nov 16, 2022

habibitcoin commented Nov 27, 2022 • edited Loading

guggero commented Nov 28, 2022

habibitcoin commented Dec 5, 2022

habibitcoin commented Dec 5, 2022

Roasbeef commented Dec 6, 2022

Roasbeef commented Jan 11, 2023

habibitcoin commented Jan 25, 2023

habibitcoin commented Jan 25, 2023

Roasbeef commented Feb 2, 2023

Roasbeef left a comment

Choose a reason for hiding this comment

positiveblue left a comment

Choose a reason for hiding this comment

positiveblue Feb 3, 2023

Choose a reason for hiding this comment

dstadulis commented Feb 7, 2023

habibitcoin commented Feb 7, 2023

guggero left a comment

Choose a reason for hiding this comment

jharveyb left a comment

Choose a reason for hiding this comment

jharveyb May 31, 2023

Choose a reason for hiding this comment

habibitcoin Jun 15, 2023

Choose a reason for hiding this comment

guggero Jun 16, 2023

Choose a reason for hiding this comment

dstadulis commented Jun 6, 2023

lightninglabs-deploy commented Jun 14, 2023

straumat commented Jun 14, 2023

dstadulis commented Jun 15, 2023

habibitcoin commented Jun 15, 2023

guggero left a comment

Choose a reason for hiding this comment

guggero Jun 16, 2023

Choose a reason for hiding this comment

habibitcoin commented Jun 16, 2023

positiveblue left a comment

Choose a reason for hiding this comment

habibitcoin commented Jun 17, 2023 • edited Loading

guggero left a comment

Choose a reason for hiding this comment

habibitcoin commented Jun 19, 2023

guggero Jun 20, 2023

Choose a reason for hiding this comment

habibitcoin commented Oct 25, 2022 •

edited

Loading

habibitcoin commented Nov 27, 2022 •

edited

Loading

habibitcoin commented Jun 17, 2023 •

edited

Loading