write unit tests

[gorazdko]

Abstract

Write more unit tests for UR serialization and deserialization.

First, there are small changes that need to be done to the UR test vectors (one has an incorrect depth and another is missing a parent fingerprint), see BlockchainCommons/Research#83. To correct these changes open a PR in Research repo. After approved, write unit tests for those test vectors in this repo.

Tag @wolfmcnally in BlockchainCommons/Research#83 to let him know you'll be working on the issue

You'll need the following tool:

• https://github.com/BlockchainCommons/bytewords-cli

And some general knowledge about:

• URs: https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md
• bytewords: https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-012-bytewords.md
• CBOR (http://cbor.me/)
• PSBT

[nochiel]

@gorazdko @wolfmcnally I'd like to start working on this.

[gorazdko]

Great. Only the test vector that has an incorrect depth should be fixed and a unit test written for that here. ("missing a parent fingerprint" test case is actually correct )

To give a little more context: in BlockchainCommons/Research#83 you can see depth is 4 ( 04 ; depth 4) which cannot be correctly reconstructed from the components length (which is 3, i.e. 44, true, 0, true, 0, true ; 44'/0'/0'). Therefore depth must be explicitly present in cbor notation.

[nochiel]

@gorazdko

To give a little more context: in BlockchainCommons/Research#83 you can see depth is 4 ( 04 ; depth 4) which cannot be correctly reconstructed from the components length (which is 3, i.e. 44, true, 0, true, 0, true ; 44'/0'/0'). Therefore depth must be explicitly present in cbor notation.

😁 A dumb question for which I need some clarification:

Am I understanding this case correctly?

• Given pkh([d34db33f/44'/0'/0']xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/1/*)
• m/44'/0'/0' => depth 2 from the master with the given fingerprint.
• the given xpub is derived at the 0 index at depth 2. However, it is not possible to derive private keys up to depth 2 using this descriptor because each of the derivation steps has been hardened.
• Therefore we consider the given xpub, which is at depth 2, as our 0th step for the purpose of using this descriptor to derive scripts.
• Then, xpub.../1/* is the set of all keys at depth 1 from the given xpub ( == depth 4 from the master with the given fingerprint).

[...] you can see depth is 4 ( 04 ; depth 4) which cannot be correctly reconstructed from the components length.

Given the components:

6: 304({ ; origin: crypto-keypath
			1: [ ; components
				44, true, 0, true, 0, true ; 44'/0'/0'
			],
			2: 3545084735 ; origin-fingerprint
		}),
		7: 304({ ; children: crypto-keypath
			1: [ ; components
				1, false, [], false ; 1/*
			]
		}),

Isn't the depth the (sum(length(components)) \forall components) - 1? Doesn't this mean that we can in fact correctly reconstruct depth from the components' length?

---

Therefore, you are saying depth is a required field (ref. cddl for key path) when components are present in crypto-keypath.

• In order for the crypto-keypath cbor to retain the self-describing property, depth of components must be specified.
• A test would check that (sum(length(components)) \forall components) - 1 == depth.

[gorazdko]

Therefore, you are saying depth is a required field (ref. cddl for key path) when components are present in crypto-keypath

No. I'm saying depth is required only when the components are not present or when the components are present and depth cannot be reconstructed from it. The latter is what the problem is here. This happens because we can come up with an xpub and derive a child from it. We can consider that child as a new xpub from which we can derive new children. If I hand you over that new xpub the information about depth may not be restored correctly from the component's array anymore.

A test would check that (sum(length(components)) \forall components) - 1 == depth

try to apply that formula to other test vectors and you'll see it doesn't work

[nochiel]

Therefore, you are saying depth is a required field (ref. cddl for key path) when components are present in crypto-keypath

No. I'm saying depth is required only when the components are not present or when the components are present and depth cannot be reconstructed from it. The latter is what the problem is here.

Got it! Thank you!