Digital Witness

Issued to: WitnusApp user

In witness of the fact that data with the following digital fingerprint existed at the point in time below


Digital Data Fingerprint (Content ID)

99a7 bb9f 1244 d276 53da a500 91f0 c4ff 47a7 bb77 e666 61f7 0fdd dd0e 3798 5dc4 ecd9 9a01 648d eab7 975c 380d 3d79 6000 34c0 2c4a f05a d2dc 4f9a 89ed 2ae7 29ef

Witness Fingerprint (Witness Id)

788e c17c d64c 6e45 a339 de78 e9ff 16ed 2fb6 6556 1df3 3635 b037 b9e6 b17b 07f3 c388 2956 84b8 52e8 e6ef e020 7798 f260 de44 6222 b516 29fa 0474 4b90 60c0 d544

Timestamp

2020-09-24T13:46:53.2262357Z


To validate the Content Fingerprint you need access to to the original data that produces that hash when used as input for the SHA-512 hashing algorithm, plus optional ”salt” and "auxiliary data" values, if they were used when the Witness was created. To validate the Witness Fingerprint you need the Content Fingerprint, the Issued To signature and the Timestamp listed above. To validate the timestamp of the witness you need the Witness Fingerprint and the data for the intermediate validation steps and the expected root hash listed below. See here for more in-depth information about how to validate Digital Witnesses.


Intermediate validation step 1, Direction: Left
3458 ec55 b20e f15a 03e8 6f4d cd8d 666c 48d7 9550 9533 459a 56ec a5e1 3479 d643 552b f380 b874 6794 7c17 6d29 4769 98bb 866c 1586 2f4c 39d3 8cef 0f46 074a 93bc
Intermediate validation step 2, Direction: Right
c756 69de 3702 c0ff 2671 f660 de0c 0d4a ebdf 93fb f0f5 061c 7cd6 650f 46fb c1c9 e76e 45e6 8f6b 1d3a f66e 37b9 5f56 fedc e896 c2cc 7d42 6545 b584 eb60 641e 5b10
Intermediate validation step 3, Direction: Right
e1fc f056 6478 1105 3383 e50b c268 faf2 e956 33c5 32b2 e70d e4da 5f4f 0b12 e09b f61d 705c 3959 64e5 0c06 5402 0595 945d f19a 7cf5 39ba 8c34 5665 8f0d 812b b79b
Intermediate validation step 4, Direction: Right
f6dd 7448 aebf 2a87 00d7 b607 5bee d1f6 4337 d3dc 1b8e 72ff 3de5 5b75 dd37 7aee 79d3 12ce ffa9 03ce 37c5 54a5 09d2 f1e9 5a8e bb42 e19e f337 9b3b fb3e 9a9e cdfc
Intermediate validation step 5, Direction: Left
f05f e105 6a11 7fb9 7c2d 855d c61a 11ea 5cb4 e3f7 c03e 3b3c 2dc8 183f fa21 2a74 65f2 20ea 478e a5e7 f827 f138 b571 d3da 31ca 79bd 8837 c170 756f 32dd 8799 d841
Intermediate validation step 6, Direction: Left
66c2 01a4 5959 8716 30f5 d6c2 d367 d7d1 0211 d358 f950 a750 2a37 bfdf fca7 1e34 0285 20a6 f793 92b8 558a 6be9 ea4d fdcb f6b8 ff59 dd63 5ff4 06f6 c28c 014b 3d21
Intermediate validation step 7, Direction: Right
0c7b 6784 b405 25f1 637d 88a3 61a1 8527 5f27 c376 3f04 049a b023 50b2 9837 75f3 d21b 2497 5e32 d57d b5f2 8b4f 3236 b930 bb5d 0c72 b9f9 e841 ef9e ee5b c3ff caa5
Intermediate validation step 8, Direction: Right
43e2 d601 97a6 903d adeb 9f70 9e20 e837 40db c091 4947 5a41 a796 4f19 e065 928c a55a 01ef d3b6 8273 42e8 bd7c dfd4 29ca d37d 697b dca0 55f6 05d3 609d f978 eb4d
Expected root hash
5545 c173 67d3 203f 4df6 0fd1 174a adcf 2995 6cce dde0 eb7f f8b3 75ed 2936 5892 7d66 d9c5 efd3 be25 cc5d c4c4 6664 6a80 d0a5 62d3 fed8 6e87 f518 05ad 9b45 8dff

iDefendo Digital Witness Validation

A Digital Witness from iDefendo helps you prove that any arbitrary piece of information existed as early as a specific date and time, and it logically binds that information to the signature that was used to immutably sign the witness at the time it was created. This information is then inserted into multiple blockchain databases, to make it immutable. Read more...

To create evidence that the witness itself is reliable and that it has not been tampered with in any way, newly created witnesses are periodically and automatically "locked" by use of blockchain technology.

To validate that this Digital Witness existed at the stated date – and thus that the information that the information it bears witness of also must have existed since at least that point in time – each witness are registered in the Bitcoin blockchain database. This database is the immutable record of every transaction that has ever been performed on the Bitcoin network. Any piece of data in that database is mathematically guaranteed to not having been tampered with since it was inserted.

This specific Digital Witness is part of a batch of witnesses that were collectively registered in the Bitcoin blockchain at the date and time specified below. All witnesses in this batch were added to a structure called a hash tree (or Merkle tree, named after Ralph Merkle who patented it in 1979) and the root hash of this tree is used to create a Bitcoin Wallet ID. A transaction is then performed on the Bitcoin network with this new wallet as recipient, and as a consequence of this transaction, a record is created in the Bitcoin blockchain database, stating that the new wallet ID was the recipient in the transaction.

To validate that this witness was indeed part of the batch, something called a hash-tree traversal can be performed. A traversal uses a number of intermediate steps that "walks the tree" from the outermost leaf (an individual Digital Witness) to the root. Each step in this walk combines the hash of the steps taken thus far with the next intermediate step. If, at the end of the walk, you end up at the expected root value, that signifies that your witness MUST have been part of the original batch. Otherwise the original batch would not have generated the specific root hash that it did, and which is the basis for the wallet ID to which funds were transacted.

Below is the list of hashes that you need if you want to verify that all steps in this traversal are correct, and that the traversal leads to the expected root hash value. Please note that the hash values are presented as string representations of hexadecimal byte values. To validate a hash you need to first convert the string value to a corresponding array of bytes, and validate THAT, instead of the string value itself.

The list of hashes starts with the hash of your witness (the Witness ID) and ends with the tree root hash value. In between these two values are nestled a number of intermediate values, the so called trail, that lets you traverse the tree. The number of intermediate steps needed to complete a traversal varies with the number of witnesses that were registered during the period in the batch where your witness was included.

Metadata and auxiliary data

This digital witness has auxiliary data stored. Auxiliary data becomes a part of the Witness Id, and is thus used in validation. Please note that the auxiliary data is noncommutative; the order of the fields and their values matter.

UserId
9ccdfb85-52ee-4215-9105-b898eb197883
Latitude
57.7385892
Longitude
11.9531966
Witness Id validation

The Witness Id fingerprint is the hash of a concatenated string comprising the Witness Content (above) plus a pound sign (#) plus the Witness Timestamp plus the Witness Signature. Also, if the Witness has auxiliary data attached to it, the key and value of each item of the auxiliary data (in the original order) is added to the string.

Witness Id string
99a7bb9f1244d27653daa50091f0c4ff47a7bb77e66661f70fdddd0e37985dc4ecd99a01648deab7975c380d3d79600034c02c4af05ad2dc4f9a89ed2ae729ef#2020-09-24T13:46:53.2262357ZWitnusApp userUserId9ccdfb85-52ee-4215-9105-b898eb197883Latitude57.7385892Longitude11.9531966
Hash of Witness Id string
788e c17c d64c 6e45 a339 de78 e9ff 16ed 2fb6 6556 1df3 3635 b037 b9e6 b17b 07f3 c388 2956 84b8 52e8 e6ef e020 7798 f260 de44 6222 b516 29fa 0474 4b90 60c0 d544
Witness Id validation result
Witness Id validates OK; the stored hash is identical to the calculated.
Validation data

The following validation data is embedded within the witness, and was created when the validation tree was first created. It is used in the process outlined below the list to validate that the witness was part of the tree, and thus has existed for at least as long as the tree itself.

Hash to validate (Witness ID)
78–8e–c1–7c–d6–4c–6e–45–a3–39–de–78–e9–ff–16–ed–2f–b6–65–56–1d–f3–36–35–b0–37–b9–e6–b1–7b–07–f3–c3–88–29–56–84–b8–52–e8–e6–ef–e0–20–77–98–f2–60–de–44–62–22–b5–16–29–fa–04–74–4b–90–60–c0–d5–44
Intermediate step 1, Direction: Left
34–58–ec–55–b2–0e–f1–5a–03–e8–6f–4d–cd–8d–66–6c–48–d7–95–50–95–33–45–9a–56–ec–a5–e1–34–79–d6–43–55–2b–f3–80–b8–74–67–94–7c–17–6d–29–47–69–98–bb–86–6c–15–86–2f–4c–39–d3–8c–ef–0f–46–07–4a–93–bc
Intermediate step 2, Direction: Right
c7–56–69–de–37–02–c0–ff–26–71–f6–60–de–0c–0d–4a–eb–df–93–fb–f0–f5–06–1c–7c–d6–65–0f–46–fb–c1–c9–e7–6e–45–e6–8f–6b–1d–3a–f6–6e–37–b9–5f–56–fe–dc–e8–96–c2–cc–7d–42–65–45–b5–84–eb–60–64–1e–5b–10
Intermediate step 3, Direction: Right
e1–fc–f0–56–64–78–11–05–33–83–e5–0b–c2–68–fa–f2–e9–56–33–c5–32–b2–e7–0d–e4–da–5f–4f–0b–12–e0–9b–f6–1d–70–5c–39–59–64–e5–0c–06–54–02–05–95–94–5d–f1–9a–7c–f5–39–ba–8c–34–56–65–8f–0d–81–2b–b7–9b
Intermediate step 4, Direction: Right
f6–dd–74–48–ae–bf–2a–87–00–d7–b6–07–5b–ee–d1–f6–43–37–d3–dc–1b–8e–72–ff–3d–e5–5b–75–dd–37–7a–ee–79–d3–12–ce–ff–a9–03–ce–37–c5–54–a5–09–d2–f1–e9–5a–8e–bb–42–e1–9e–f3–37–9b–3b–fb–3e–9a–9e–cd–fc
Intermediate step 5, Direction: Left
f0–5f–e1–05–6a–11–7f–b9–7c–2d–85–5d–c6–1a–11–ea–5c–b4–e3–f7–c0–3e–3b–3c–2d–c8–18–3f–fa–21–2a–74–65–f2–20–ea–47–8e–a5–e7–f8–27–f1–38–b5–71–d3–da–31–ca–79–bd–88–37–c1–70–75–6f–32–dd–87–99–d8–41
Intermediate step 6, Direction: Left
66–c2–01–a4–59–59–87–16–30–f5–d6–c2–d3–67–d7–d1–02–11–d3–58–f9–50–a7–50–2a–37–bf–df–fc–a7–1e–34–02–85–20–a6–f7–93–92–b8–55–8a–6b–e9–ea–4d–fd–cb–f6–b8–ff–59–dd–63–5f–f4–06–f6–c2–8c–01–4b–3d–21
Intermediate step 7, Direction: Right
0c–7b–67–84–b4–05–25–f1–63–7d–88–a3–61–a1–85–27–5f–27–c3–76–3f–04–04–9a–b0–23–50–b2–98–37–75–f3–d2–1b–24–97–5e–32–d5–7d–b5–f2–8b–4f–32–36–b9–30–bb–5d–0c–72–b9–f9–e8–41–ef–9e–ee–5b–c3–ff–ca–a5
Intermediate step 8, Direction: Right
43–e2–d6–01–97–a6–90–3d–ad–eb–9f–70–9e–20–e8–37–40–db–c0–91–49–47–5a–41–a7–96–4f–19–e0–65–92–8c–a5–5a–01–ef–d3–b6–82–73–42–e8–bd–7c–df–d4–29–ca–d3–7d–69–7b–dc–a0–55–f6–05–d3–60–9d–f9–78–eb–4d
Expected root hash
55–45–c1–73–67–d3–20–3f–4d–f6–0f–d1–17–4a–ad–cf–29–95–6c–ce–dd–e0–eb–7f–f8–b3–75–ed–29–36–58–92–7d–66–d9–c5–ef–d3–be–25–cc–5d–c4–c4–66–64–6a–80–d0–a5–62–d3–fe–d8–6e–87–f5–18–05–ad–9b–45–8d–ff

Validation part 1: Validate tree of hashes

By following the steps below, one can validate that a specific hash – the Witness ID – is part of a list of hashes that makes up a tree of hashes. The technique used is called a tree traversal, and, if successful, proves that there exists a path from one individual node (the Witness) to the root of the tree. That, in turn, proves mathematically that the node was part of the list that once created the tree, and thus that the witness existed when the tree was created.

First step
Concatenation: Witness + first validation trail hash

The byte array value of the Witness ID hash is concatenated with the byte array value of the first validation trail hash, with the witness hash on the left side, resulting in the following byte array:

78–8e–c1–7c–d6–4c–6e–45–a3–39–de–78–e9–ff–16–ed–2f–b6–65–56–1d–f3–36–35–b0–37–b9–e6–b1–7b–07–f3–c3–88–29–56–84–b8–52–e8–e6–ef–e0–20–77–98–f2–60–de–44–62–22–b5–16–29–fa–04–74–4b–90–60–c0–d5–44 34–58–ec–55–b2–0e–f1–5a–03–e8–6f–4d–cd–8d–66–6c–48–d7–95–50–95–33–45–9a–56–ec–a5–e1–34–79–d6–43–55–2b–f3–80–b8–74–67–94–7c–17–6d–29–47–69–98–bb–86–6c–15–86–2f–4c–39–d3–8c–ef–0f–46–07–4a–93–bc
Result

This byte array, when hashed, results in the following new intermediate hash:

e0–7d–31–04–89–b2–bf–42–e3–bd–c3–f4–71–c7–89–d8–b1–c5–7c–3a–5c–ea–08–15–a0–4e–b3–32–89–84–59–50–7c–db–d8–d2–13–61–a2–e9–13–db–cb–d6–b4–40–2c–e5–8a–e9–49–f4–92–8a–2b–09–77–a5–a9–fc–a0–d4–ec–e0
Step 2
Concatenation: Next validation trail hash + intermediate hash

The resulting intermediate hash from the previous step is concatenated with the byte array value of the next validation trail hash, with the intermediate hash on the right side, resulting in the following byte array:

e0–7d–31–04–89–b2–bf–42–e3–bd–c3–f4–71–c7–89–d8–b1–c5–7c–3a–5c–ea–08–15–a0–4e–b3–32–89–84–59–50–7c–db–d8–d2–13–61–a2–e9–13–db–cb–d6–b4–40–2c–e5–8a–e9–49–f4–92–8a–2b–09–77–a5–a9–fc–a0–d4–ec–e0 c7–56–69–de–37–02–c0–ff–26–71–f6–60–de–0c–0d–4a–eb–df–93–fb–f0–f5–06–1c–7c–d6–65–0f–46–fb–c1–c9–e7–6e–45–e6–8f–6b–1d–3a–f6–6e–37–b9–5f–56–fe–dc–e8–96–c2–cc–7d–42–65–45–b5–84–eb–60–64–1e–5b–10 (Download binary data)
Result

This byte array, when hashed, results in the following new intermediate hash:

9b–96–bf–d7–0f–9b–be–65–7a–e0–fd–63–1b–1b–2d–57–50–a7–54–2c–80–84–b7–c5–0f–24–55–41–df–92–f4–f3–45–4b–1f–a7–43–c9–60–5b–56–1e–0d–dd–88–0c–15–ff–5c–69–d0–87–20–e7–0c–8c–77–9f–d7–0d–b2–f6–99–a4
Step 3
Concatenation: Next validation trail hash + intermediate hash

The resulting intermediate hash from the previous step is concatenated with the byte array value of the next validation trail hash, with the intermediate hash on the right side, resulting in the following byte array:

9b–96–bf–d7–0f–9b–be–65–7a–e0–fd–63–1b–1b–2d–57–50–a7–54–2c–80–84–b7–c5–0f–24–55–41–df–92–f4–f3–45–4b–1f–a7–43–c9–60–5b–56–1e–0d–dd–88–0c–15–ff–5c–69–d0–87–20–e7–0c–8c–77–9f–d7–0d–b2–f6–99–a4 e1–fc–f0–56–64–78–11–05–33–83–e5–0b–c2–68–fa–f2–e9–56–33–c5–32–b2–e7–0d–e4–da–5f–4f–0b–12–e0–9b–f6–1d–70–5c–39–59–64–e5–0c–06–54–02–05–95–94–5d–f1–9a–7c–f5–39–ba–8c–34–56–65–8f–0d–81–2b–b7–9b (Download binary data)
Result

This byte array, when hashed, results in the following new intermediate hash:

f3–98–b8–14–3b–b5–c5–98–a2–3e–d1–5d–a9–03–4b–e4–e5–85–95–85–ad–3a–9c–8f–62–24–10–9e–fe–6c–29–f3–e0–8d–69–3d–7c–3c–a5–86–23–00–dc–51–c6–2d–5a–f9–49–d6–84–c6–f5–f9–8f–37–ed–41–9b–20–9c–20–15–28
Step 4
Concatenation: Next validation trail hash + intermediate hash

The resulting intermediate hash from the previous step is concatenated with the byte array value of the next validation trail hash, with the intermediate hash on the right side, resulting in the following byte array:

f3–98–b8–14–3b–b5–c5–98–a2–3e–d1–5d–a9–03–4b–e4–e5–85–95–85–ad–3a–9c–8f–62–24–10–9e–fe–6c–29–f3–e0–8d–69–3d–7c–3c–a5–86–23–00–dc–51–c6–2d–5a–f9–49–d6–84–c6–f5–f9–8f–37–ed–41–9b–20–9c–20–15–28 f6–dd–74–48–ae–bf–2a–87–00–d7–b6–07–5b–ee–d1–f6–43–37–d3–dc–1b–8e–72–ff–3d–e5–5b–75–dd–37–7a–ee–79–d3–12–ce–ff–a9–03–ce–37–c5–54–a5–09–d2–f1–e9–5a–8e–bb–42–e1–9e–f3–37–9b–3b–fb–3e–9a–9e–cd–fc (Download binary data)
Result

This byte array, when hashed, results in the following new intermediate hash:

e1–45–6f–7c–fc–38–12–6f–5e–36–c7–dc–25–b8–da–5c–38–4d–59–06–51–c9–5a–d9–2c–29–a4–54–35–d0–62–ed–19–f4–b5–75–f2–d1–0d–72–e1–5d–89–3e–5c–8c–b1–e9–7c–01–6a–0a–c9–af–b3–ce–09–1a–2b–84–6e–b3–6b–a2
Step 5
Concatenation: Intermediate hash + next validation trail hash

The resulting intermediate hash from the previous step is concatenated with the byte array value of the next validation trail hash, with the intermediate hash on the left side, resulting in the following byte array:

e1–45–6f–7c–fc–38–12–6f–5e–36–c7–dc–25–b8–da–5c–38–4d–59–06–51–c9–5a–d9–2c–29–a4–54–35–d0–62–ed–19–f4–b5–75–f2–d1–0d–72–e1–5d–89–3e–5c–8c–b1–e9–7c–01–6a–0a–c9–af–b3–ce–09–1a–2b–84–6e–b3–6b–a2 f0–5f–e1–05–6a–11–7f–b9–7c–2d–85–5d–c6–1a–11–ea–5c–b4–e3–f7–c0–3e–3b–3c–2d–c8–18–3f–fa–21–2a–74–65–f2–20–ea–47–8e–a5–e7–f8–27–f1–38–b5–71–d3–da–31–ca–79–bd–88–37–c1–70–75–6f–32–dd–87–99–d8–41 (Download binary data)
Result

This byte array, when hashed, results in the following new intermediate hash:

db–b9–ec–a7–d5–76–89–fa–e4–cd–40–08–80–3b–ca–a0–38–93–11–34–06–90–db–c1–c5–8e–4f–f6–06–ac–61–6b–db–b1–60–77–24–ac–f6–f9–2f–bd–e3–5c–73–5e–36–bd–9d–ea–da–71–cd–4c–62–e0–e5–c0–6b–22–50–da–b9–6f
Step 6
Concatenation: Intermediate hash + next validation trail hash

The resulting intermediate hash from the previous step is concatenated with the byte array value of the next validation trail hash, with the intermediate hash on the left side, resulting in the following byte array:

db–b9–ec–a7–d5–76–89–fa–e4–cd–40–08–80–3b–ca–a0–38–93–11–34–06–90–db–c1–c5–8e–4f–f6–06–ac–61–6b–db–b1–60–77–24–ac–f6–f9–2f–bd–e3–5c–73–5e–36–bd–9d–ea–da–71–cd–4c–62–e0–e5–c0–6b–22–50–da–b9–6f 66–c2–01–a4–59–59–87–16–30–f5–d6–c2–d3–67–d7–d1–02–11–d3–58–f9–50–a7–50–2a–37–bf–df–fc–a7–1e–34–02–85–20–a6–f7–93–92–b8–55–8a–6b–e9–ea–4d–fd–cb–f6–b8–ff–59–dd–63–5f–f4–06–f6–c2–8c–01–4b–3d–21 (Download binary data)
Result

This byte array, when hashed, results in the following new intermediate hash:

db–26–c9–ea–e3–d0–07–14–ea–7b–4d–47–c4–8b–1f–d6–b2–ef–82–0e–7d–5a–69–9a–a5–e2–7f–88–fa–a9–9c–e7–c8–15–90–9a–55–52–c0–7d–cc–e5–b0–40–57–57–84–79–e4–5b–45–3d–22–bc–a6–4b–6f–77–5b–60–9f–1a–7b–d4
Step 7
Concatenation: Next validation trail hash + intermediate hash

The resulting intermediate hash from the previous step is concatenated with the byte array value of the next validation trail hash, with the intermediate hash on the right side, resulting in the following byte array:

db–26–c9–ea–e3–d0–07–14–ea–7b–4d–47–c4–8b–1f–d6–b2–ef–82–0e–7d–5a–69–9a–a5–e2–7f–88–fa–a9–9c–e7–c8–15–90–9a–55–52–c0–7d–cc–e5–b0–40–57–57–84–79–e4–5b–45–3d–22–bc–a6–4b–6f–77–5b–60–9f–1a–7b–d4 0c–7b–67–84–b4–05–25–f1–63–7d–88–a3–61–a1–85–27–5f–27–c3–76–3f–04–04–9a–b0–23–50–b2–98–37–75–f3–d2–1b–24–97–5e–32–d5–7d–b5–f2–8b–4f–32–36–b9–30–bb–5d–0c–72–b9–f9–e8–41–ef–9e–ee–5b–c3–ff–ca–a5 (Download binary data)
Result

This byte array, when hashed, results in the following new intermediate hash:

43–8a–6d–bf–6e–52–fd–cf–dc–1e–00–27–81–0c–1e–f1–fd–df–c2–28–0e–a3–5e–8f–93–ab–c4–4f–84–02–9f–ed–c4–43–1f–7a–21–dc–85–03–9f–02–b0–fa–dd–11–c3–be–85–3c–b2–89–97–ba–1b–06–3d–c7–85–34–a2–5e–a4–bc
Step 8
Concatenation: Next validation trail hash + intermediate hash

The resulting intermediate hash from the previous step is concatenated with the byte array value of the next validation trail hash, with the intermediate hash on the right side, resulting in the following byte array:

43–8a–6d–bf–6e–52–fd–cf–dc–1e–00–27–81–0c–1e–f1–fd–df–c2–28–0e–a3–5e–8f–93–ab–c4–4f–84–02–9f–ed–c4–43–1f–7a–21–dc–85–03–9f–02–b0–fa–dd–11–c3–be–85–3c–b2–89–97–ba–1b–06–3d–c7–85–34–a2–5e–a4–bc 43–e2–d6–01–97–a6–90–3d–ad–eb–9f–70–9e–20–e8–37–40–db–c0–91–49–47–5a–41–a7–96–4f–19–e0–65–92–8c–a5–5a–01–ef–d3–b6–82–73–42–e8–bd–7c–df–d4–29–ca–d3–7d–69–7b–dc–a0–55–f6–05–d3–60–9d–f9–78–eb–4d (Download binary data)
Result

This byte array, when hashed, results in the following new intermediate hash:

55–45–c1–73–67–d3–20–3f–4d–f6–0f–d1–17–4a–ad–cf–29–95–6c–ce–dd–e0–eb–7f–f8–b3–75–ed–29–36–58–92–7d–66–d9–c5–ef–d3–be–25–cc–5d–c4–c4–66–64–6a–80–d0–a5–62–d3–fe–d8–6e–87–f5–18–05–ad–9b–45–8d–ff
Last step, validation: Are we at the expected root?

If the initial Witness hash was present in the list of witnesses that constituted the tree at the time it was created, we now expect to have found the same tree root hash value as the initial hashing found. If that is the case, it proves that the Witness was part of the initial tree. If we ended up at some other root hash value, the Witness was NOT part of the initial tree.

Expected root hash
55–45–c1–73–67–d3–20–3f–4d–f6–0f–d1–17–4a–ad–cf–29–95–6c–ce–dd–e0–eb–7f–f8–b3–75–ed–29–36–58–92–7d–66–d9–c5–ef–d3–be–25–cc–5d–c4–c4–66–64–6a–80–d0–a5–62–d3–fe–d8–6e–87–f5–18–05–ad–9b–45–8d–ff
Calculated root hash
55–45–c1–73–67–d3–20–3f–4d–f6–0f–d1–17–4a–ad–cf–29–95–6c–ce–dd–e0–eb–7f–f8–b3–75–ed–29–36–58–92–7d–66–d9–c5–ef–d3–be–25–cc–5d–c4–c4–66–64–6a–80–d0–a5–62–d3–fe–d8–6e–87–f5–18–05–ad–9b–45–8d–ff
Tree traversal result
Tree validates OK; the Witness WAS part of the initial tree

Validation part 2: Blockchain verification

Now that we have validated that the Witness exists in the tree, we also want to make sure that the tree itself has not been modified since it was created. That's achieved through a Bitcoin transaction. Read more...

Since a tree consists of the digital witnesses that makes up the tree, it follows that each witness in a specific tree must have existed when the tree was created. From that it also follows that each data point (document, file or other data) that the witnesses bear witness of also must have existed at that point in time, since it is not possible to create a witness for data that does not yet exist. For the same reason, the tree itself must have existed at the time it was registered in a blockchain, because it's not possible to register a tree that does not exist.

To generate a timestamped evidence of the age of the tree, each tree is registered in the Bitcoin blockchain database. That's achieved by first creating a so called Wallet in Bitcoin, and then transact money to that wallet. Each wallet in the Bitcoin network has an "address", and that address is itself a RIPEMD160 hash. We create the wallet address by hashing the tree root and prepending it with a "version byte", according to the Bitcoin specification.

The wallet address is then encoded using Base58 Checked Encoding, again according to the Bitcoin specification, and is then ready use.

Lastly, a transaction is then initiated where a small sum of money is transferred to the new wallet address. Since all transactions on the Bitcoin network are handled through the underlying blockchain database, this transaction is forever fixed in that database with a corresponding timestamp, and that, in turn, provide proof that the specific data that this witness bear witness of also existed at that point in time.

Convert hash to wallet address
  1. First, the RIPEMD160 hash of the root hash is calculated, and the resulting byte array is prepended with a zero value "version byte": 00–1e–5d–91–71–80–31–e0–ac–05–bf–79–6e–4d–e8–ed–10–99–7f–db–06 (Download binary root hash) / (Download prepended binary RIPEMD160 hash)
  2. Then, a wallet address is created by converting the resulting byte array into a Base58Check-encoded string: 13mZMz2EMe14Q7EdSDEf3VJXxSqQn4EYt3
  3. Lastly, any commonly available blockchain explorer tool that can be used to inspect transactions on the Bitcoin network can verify that this wallet address has been involved in a transaction, and when that transaction took place. Since the wallet address is based on the tree hash, all previous steps must have been performed before the wallet address could be created, and that proves that all data that the digital witnesses in the tree that was the basis for the wallet address must also have existed at the time the transaction happened. Important: You want to make sure the that number of transactions listed for the address is greater than zero (generally it's 1) when clicking on the link below, because that's how you know that a transaction really has been recorded for the address. https://www.blockchain.com/bch/address/13mZMz2EMe14Q7EdSDEf3VJXxSqQn4EYt3