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)

01df 51ca 38e9 5728 e6a4 2ed8 e3be d08a 328d 2108 c515 09ee 38a7 2cb0 011a 51fd 95a8 3764 6d5d c1c3 18c8 d3fd e9b9 c252 cde9 fc8d 29f8 9507 7a6e 5746 0502 cdc7

Witness Fingerprint (Witness Id)

011f aefc 0b94 812d b5ed 740c 9bc2 acd7 7fb1 7013 a937 b42a bf15 ea43 5b64 68c6 06f7 12d9 4882 77a1 cc6e 909f cec2 d1a7 5d0a e827 5b9c 42d1 f40d cace 6e12 561a

Timestamp

2020-09-21T10:45:04.2420330Z


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
bcb5 bf11 5e43 6b13 bdf1 1efb a5df e656 c5dc 42e4 8f7d bd45 b927 b532 2a0d 81e0 3d3b 2d64 3c7d 9cb6 1a70 3065 c9e1 f0cd 15d8 df64 b2de 07be e143 8a16 6287 5db3
Intermediate validation step 2, Direction: Left
b6b1 ef74 c575 586c b00b f745 973b 815b e9cc 663e e2d7 933b a142 49af ba67 2a4e 4ba5 f245 65ab 16db 5fb9 f448 6977 7bdc b459 f3e1 3286 aa88 356b 71cf df4c 30e7
Intermediate validation step 3, Direction: Left
61ae 0a5c 48ba 2267 79c4 6c1c 148b d2b0 8e1e e9cd 6e75 16b0 c376 5ee0 c122 5eb7 2b3c a713 91e3 4d26 a9c6 e170 836d 07b3 5792 4cb5 cd91 b1f7 5016 c2e3 4ca0 1e54
Intermediate validation step 4, Direction: Right
9c16 90ed e032 aa52 2d9b cc59 0bae 8113 f55a 2507 0fcf 2c42 43f8 a9ec 13fa 7742 ba07 cbc4 3e87 a357 38ff 9dfb 398d 1cd5 920b e4d5 36cd 11c2 d13c d2b5 547f ecb5
Intermediate validation step 5, Direction: Right
11c2 8dd4 6636 c2d5 5e87 2a1f c407 21c8 dd15 e0cb 0f92 1c44 1cb3 462e baa8 a8d3 e50d 4170 ecc1 1a29 cd98 8284 64f1 8be9 1026 0100 bfe7 4ea0 c371 5892 a1d9 cfac
Intermediate validation step 6, Direction: Right
397a c106 affc e4f9 f7ac c1ae e412 0843 c211 b32c 5cad a672 350c 3b04 01f2 1b12 8584 440b 3105 dee9 5883 c120 e207 a1dd 7f18 3a42 00fe 3028 9a78 680d cc83 3673
Intermediate validation step 7, Direction: Left
2043 49ec 42c7 1d78 5928 27b1 5602 206d e5ed 7ba8 48a6 4ca2 c0d5 4bdd 0e57 df5e 9dbc 01fc 46ee c0fb 8f8e 9925 2946 c07a 938d a20a cca9 d123 7d7b 6ea4 315a 042e
Intermediate validation step 8, Direction: Right
2d23 779b ea91 4346 0237 29ec 9790 c8ef 0fe3 7960 ad3e fa1d 634a 4d44 c266 67d9 454b 3901 c7ee 33b5 00ab 3713 5a9f b2fb 5e5d eade 8fdf d6d8 ca69 562f d736 0f9f
Expected root hash
12a4 3837 af0e e465 f8fe c3e3 8370 dc40 0378 355a 767b ceb0 6fee 9c83 481f 46ea 5386 1976 b607 c055 17de e85d 3ca7 ab2f 2f02 1871 fb6a a699 88d3 a471 2a2f 04b0

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
a8913545-1396-4bfc-b3bb-8cd7e6eedbac
Latitude
57.657318115234375
Longitude
11.94504299853825
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
01df51ca38e95728e6a42ed8e3bed08a328d2108c51509ee38a72cb0011a51fd95a837646d5dc1c318c8d3fde9b9c252cde9fc8d29f895077a6e57460502cdc7#2020-09-21T10:45:04.2420330ZWitnusApp userUserIda8913545-1396-4bfc-b3bb-8cd7e6eedbacLatitude57.657318115234375Longitude11.94504299853825
Hash of Witness Id string
011f aefc 0b94 812d b5ed 740c 9bc2 acd7 7fb1 7013 a937 b42a bf15 ea43 5b64 68c6 06f7 12d9 4882 77a1 cc6e 909f cec2 d1a7 5d0a e827 5b9c 42d1 f40d cace 6e12 561a
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)
01–1f–ae–fc–0b–94–81–2d–b5–ed–74–0c–9b–c2–ac–d7–7f–b1–70–13–a9–37–b4–2a–bf–15–ea–43–5b–64–68–c6–06–f7–12–d9–48–82–77–a1–cc–6e–90–9f–ce–c2–d1–a7–5d–0a–e8–27–5b–9c–42–d1–f4–0d–ca–ce–6e–12–56–1a
Intermediate step 1, Direction: Left
bc–b5–bf–11–5e–43–6b–13–bd–f1–1e–fb–a5–df–e6–56–c5–dc–42–e4–8f–7d–bd–45–b9–27–b5–32–2a–0d–81–e0–3d–3b–2d–64–3c–7d–9c–b6–1a–70–30–65–c9–e1–f0–cd–15–d8–df–64–b2–de–07–be–e1–43–8a–16–62–87–5d–b3
Intermediate step 2, Direction: Left
b6–b1–ef–74–c5–75–58–6c–b0–0b–f7–45–97–3b–81–5b–e9–cc–66–3e–e2–d7–93–3b–a1–42–49–af–ba–67–2a–4e–4b–a5–f2–45–65–ab–16–db–5f–b9–f4–48–69–77–7b–dc–b4–59–f3–e1–32–86–aa–88–35–6b–71–cf–df–4c–30–e7
Intermediate step 3, Direction: Left
61–ae–0a–5c–48–ba–22–67–79–c4–6c–1c–14–8b–d2–b0–8e–1e–e9–cd–6e–75–16–b0–c3–76–5e–e0–c1–22–5e–b7–2b–3c–a7–13–91–e3–4d–26–a9–c6–e1–70–83–6d–07–b3–57–92–4c–b5–cd–91–b1–f7–50–16–c2–e3–4c–a0–1e–54
Intermediate step 4, Direction: Right
9c–16–90–ed–e0–32–aa–52–2d–9b–cc–59–0b–ae–81–13–f5–5a–25–07–0f–cf–2c–42–43–f8–a9–ec–13–fa–77–42–ba–07–cb–c4–3e–87–a3–57–38–ff–9d–fb–39–8d–1c–d5–92–0b–e4–d5–36–cd–11–c2–d1–3c–d2–b5–54–7f–ec–b5
Intermediate step 5, Direction: Right
11–c2–8d–d4–66–36–c2–d5–5e–87–2a–1f–c4–07–21–c8–dd–15–e0–cb–0f–92–1c–44–1c–b3–46–2e–ba–a8–a8–d3–e5–0d–41–70–ec–c1–1a–29–cd–98–82–84–64–f1–8b–e9–10–26–01–00–bf–e7–4e–a0–c3–71–58–92–a1–d9–cf–ac
Intermediate step 6, Direction: Right
39–7a–c1–06–af–fc–e4–f9–f7–ac–c1–ae–e4–12–08–43–c2–11–b3–2c–5c–ad–a6–72–35–0c–3b–04–01–f2–1b–12–85–84–44–0b–31–05–de–e9–58–83–c1–20–e2–07–a1–dd–7f–18–3a–42–00–fe–30–28–9a–78–68–0d–cc–83–36–73
Intermediate step 7, Direction: Left
20–43–49–ec–42–c7–1d–78–59–28–27–b1–56–02–20–6d–e5–ed–7b–a8–48–a6–4c–a2–c0–d5–4b–dd–0e–57–df–5e–9d–bc–01–fc–46–ee–c0–fb–8f–8e–99–25–29–46–c0–7a–93–8d–a2–0a–cc–a9–d1–23–7d–7b–6e–a4–31–5a–04–2e
Intermediate step 8, Direction: Right
2d–23–77–9b–ea–91–43–46–02–37–29–ec–97–90–c8–ef–0f–e3–79–60–ad–3e–fa–1d–63–4a–4d–44–c2–66–67–d9–45–4b–39–01–c7–ee–33–b5–00–ab–37–13–5a–9f–b2–fb–5e–5d–ea–de–8f–df–d6–d8–ca–69–56–2f–d7–36–0f–9f
Expected root hash
12–a4–38–37–af–0e–e4–65–f8–fe–c3–e3–83–70–dc–40–03–78–35–5a–76–7b–ce–b0–6f–ee–9c–83–48–1f–46–ea–53–86–19–76–b6–07–c0–55–17–de–e8–5d–3c–a7–ab–2f–2f–02–18–71–fb–6a–a6–99–88–d3–a4–71–2a–2f–04–b0

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:

01–1f–ae–fc–0b–94–81–2d–b5–ed–74–0c–9b–c2–ac–d7–7f–b1–70–13–a9–37–b4–2a–bf–15–ea–43–5b–64–68–c6–06–f7–12–d9–48–82–77–a1–cc–6e–90–9f–ce–c2–d1–a7–5d–0a–e8–27–5b–9c–42–d1–f4–0d–ca–ce–6e–12–56–1a bc–b5–bf–11–5e–43–6b–13–bd–f1–1e–fb–a5–df–e6–56–c5–dc–42–e4–8f–7d–bd–45–b9–27–b5–32–2a–0d–81–e0–3d–3b–2d–64–3c–7d–9c–b6–1a–70–30–65–c9–e1–f0–cd–15–d8–df–64–b2–de–07–be–e1–43–8a–16–62–87–5d–b3
Result

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

f8–4f–0d–d1–44–df–5e–aa–88–11–16–6c–e1–88–f1–70–6c–ae–51–9b–b4–eb–8c–15–e4–6e–92–60–f0–52–9e–8f–4f–66–56–e1–42–15–76–a2–df–95–b5–16–12–e6–cd–ee–bd–09–8e–3f–c3–8f–7c–1e–7e–2f–0b–b5–47–1b–73–49
Step 2
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:

f8–4f–0d–d1–44–df–5e–aa–88–11–16–6c–e1–88–f1–70–6c–ae–51–9b–b4–eb–8c–15–e4–6e–92–60–f0–52–9e–8f–4f–66–56–e1–42–15–76–a2–df–95–b5–16–12–e6–cd–ee–bd–09–8e–3f–c3–8f–7c–1e–7e–2f–0b–b5–47–1b–73–49 b6–b1–ef–74–c5–75–58–6c–b0–0b–f7–45–97–3b–81–5b–e9–cc–66–3e–e2–d7–93–3b–a1–42–49–af–ba–67–2a–4e–4b–a5–f2–45–65–ab–16–db–5f–b9–f4–48–69–77–7b–dc–b4–59–f3–e1–32–86–aa–88–35–6b–71–cf–df–4c–30–e7 (Download binary data)
Result

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

9b–7c–1f–95–40–57–b1–10–35–f5–08–05–d9–2b–84–e4–01–72–67–e4–f0–b1–2c–2f–e7–cf–ca–f5–be–0d–49–dd–49–10–40–d8–68–4e–f3–12–6e–99–f2–05–bf–48–08–ee–cb–f0–22–40–53–a1–5e–b0–04–2b–78–e6–22–db–ce–87
Step 3
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:

9b–7c–1f–95–40–57–b1–10–35–f5–08–05–d9–2b–84–e4–01–72–67–e4–f0–b1–2c–2f–e7–cf–ca–f5–be–0d–49–dd–49–10–40–d8–68–4e–f3–12–6e–99–f2–05–bf–48–08–ee–cb–f0–22–40–53–a1–5e–b0–04–2b–78–e6–22–db–ce–87 61–ae–0a–5c–48–ba–22–67–79–c4–6c–1c–14–8b–d2–b0–8e–1e–e9–cd–6e–75–16–b0–c3–76–5e–e0–c1–22–5e–b7–2b–3c–a7–13–91–e3–4d–26–a9–c6–e1–70–83–6d–07–b3–57–92–4c–b5–cd–91–b1–f7–50–16–c2–e3–4c–a0–1e–54 (Download binary data)
Result

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

00–00–e2–02–e9–11–83–0e–b4–db–9d–7a–39–86–20–3d–b3–46–3a–91–f6–d9–60–36–64–9b–5a–e5–f7–76–ff–5b–9b–6b–6a–01–fa–3d–6a–a6–3d–33–78–09–ad–18–47–a9–32–72–6c–5d–64–56–46–e1–6e–ee–f2–d7–97–90–e8–b8
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:

00–00–e2–02–e9–11–83–0e–b4–db–9d–7a–39–86–20–3d–b3–46–3a–91–f6–d9–60–36–64–9b–5a–e5–f7–76–ff–5b–9b–6b–6a–01–fa–3d–6a–a6–3d–33–78–09–ad–18–47–a9–32–72–6c–5d–64–56–46–e1–6e–ee–f2–d7–97–90–e8–b8 9c–16–90–ed–e0–32–aa–52–2d–9b–cc–59–0b–ae–81–13–f5–5a–25–07–0f–cf–2c–42–43–f8–a9–ec–13–fa–77–42–ba–07–cb–c4–3e–87–a3–57–38–ff–9d–fb–39–8d–1c–d5–92–0b–e4–d5–36–cd–11–c2–d1–3c–d2–b5–54–7f–ec–b5 (Download binary data)
Result

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

a4–b1–ff–6f–c7–d2–cb–91–8b–26–d7–46–bb–99–e3–59–94–9f–ee–d0–9e–e9–1c–bb–2c–82–c9–f1–9d–73–68–34–c6–81–b7–9e–0b–87–15–58–96–f5–1e–a9–67–0a–96–23–ff–10–b2–10–ce–ad–29–15–15–24–23–36–61–3a–14–e7
Step 5
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:

a4–b1–ff–6f–c7–d2–cb–91–8b–26–d7–46–bb–99–e3–59–94–9f–ee–d0–9e–e9–1c–bb–2c–82–c9–f1–9d–73–68–34–c6–81–b7–9e–0b–87–15–58–96–f5–1e–a9–67–0a–96–23–ff–10–b2–10–ce–ad–29–15–15–24–23–36–61–3a–14–e7 11–c2–8d–d4–66–36–c2–d5–5e–87–2a–1f–c4–07–21–c8–dd–15–e0–cb–0f–92–1c–44–1c–b3–46–2e–ba–a8–a8–d3–e5–0d–41–70–ec–c1–1a–29–cd–98–82–84–64–f1–8b–e9–10–26–01–00–bf–e7–4e–a0–c3–71–58–92–a1–d9–cf–ac (Download binary data)
Result

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

0b–ad–c6–8f–ec–81–41–eb–e1–92–4f–30–37–6f–fa–d8–00–14–16–34–75–6b–6a–c4–9a–4b–8b–32–77–ef–17–be–2d–44–21–a9–9b–8f–df–55–bb–47–00–2c–ad–25–a0–51–9c–c9–f6–d0–66–b1–43–11–32–a2–c5–33–34–66–83–6a
Step 6
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:

0b–ad–c6–8f–ec–81–41–eb–e1–92–4f–30–37–6f–fa–d8–00–14–16–34–75–6b–6a–c4–9a–4b–8b–32–77–ef–17–be–2d–44–21–a9–9b–8f–df–55–bb–47–00–2c–ad–25–a0–51–9c–c9–f6–d0–66–b1–43–11–32–a2–c5–33–34–66–83–6a 39–7a–c1–06–af–fc–e4–f9–f7–ac–c1–ae–e4–12–08–43–c2–11–b3–2c–5c–ad–a6–72–35–0c–3b–04–01–f2–1b–12–85–84–44–0b–31–05–de–e9–58–83–c1–20–e2–07–a1–dd–7f–18–3a–42–00–fe–30–28–9a–78–68–0d–cc–83–36–73 (Download binary data)
Result

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

15–83–c0–6d–84–76–0b–1d–75–eb–aa–62–e0–32–68–86–5e–52–81–96–2f–9c–db–69–24–6c–b8–95–96–13–5a–81–18–44–ce–cf–40–69–7e–c7–ae–97–27–ee–ba–d8–02–58–9c–c2–81–e8–7e–42–54–0a–32–74–9b–9a–2c–a9–d9–bc
Step 7
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:

15–83–c0–6d–84–76–0b–1d–75–eb–aa–62–e0–32–68–86–5e–52–81–96–2f–9c–db–69–24–6c–b8–95–96–13–5a–81–18–44–ce–cf–40–69–7e–c7–ae–97–27–ee–ba–d8–02–58–9c–c2–81–e8–7e–42–54–0a–32–74–9b–9a–2c–a9–d9–bc 20–43–49–ec–42–c7–1d–78–59–28–27–b1–56–02–20–6d–e5–ed–7b–a8–48–a6–4c–a2–c0–d5–4b–dd–0e–57–df–5e–9d–bc–01–fc–46–ee–c0–fb–8f–8e–99–25–29–46–c0–7a–93–8d–a2–0a–cc–a9–d1–23–7d–7b–6e–a4–31–5a–04–2e (Download binary data)
Result

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

44–e8–09–47–4c–74–64–ea–ad–38–c8–b4–5d–f7–c3–c9–ee–79–22–54–ba–2f–61–f4–c3–a2–25–91–81–e2–db–6f–e3–14–26–68–be–1c–4c–37–c0–10–d4–7b–92–d6–f4–f8–fa–b1–80–4f–ad–f1–bc–5f–e3–53–c0–29–22–92–c6–90
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:

44–e8–09–47–4c–74–64–ea–ad–38–c8–b4–5d–f7–c3–c9–ee–79–22–54–ba–2f–61–f4–c3–a2–25–91–81–e2–db–6f–e3–14–26–68–be–1c–4c–37–c0–10–d4–7b–92–d6–f4–f8–fa–b1–80–4f–ad–f1–bc–5f–e3–53–c0–29–22–92–c6–90 2d–23–77–9b–ea–91–43–46–02–37–29–ec–97–90–c8–ef–0f–e3–79–60–ad–3e–fa–1d–63–4a–4d–44–c2–66–67–d9–45–4b–39–01–c7–ee–33–b5–00–ab–37–13–5a–9f–b2–fb–5e–5d–ea–de–8f–df–d6–d8–ca–69–56–2f–d7–36–0f–9f (Download binary data)
Result

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

12–a4–38–37–af–0e–e4–65–f8–fe–c3–e3–83–70–dc–40–03–78–35–5a–76–7b–ce–b0–6f–ee–9c–83–48–1f–46–ea–53–86–19–76–b6–07–c0–55–17–de–e8–5d–3c–a7–ab–2f–2f–02–18–71–fb–6a–a6–99–88–d3–a4–71–2a–2f–04–b0
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
12–a4–38–37–af–0e–e4–65–f8–fe–c3–e3–83–70–dc–40–03–78–35–5a–76–7b–ce–b0–6f–ee–9c–83–48–1f–46–ea–53–86–19–76–b6–07–c0–55–17–de–e8–5d–3c–a7–ab–2f–2f–02–18–71–fb–6a–a6–99–88–d3–a4–71–2a–2f–04–b0
Calculated root hash
12–a4–38–37–af–0e–e4–65–f8–fe–c3–e3–83–70–dc–40–03–78–35–5a–76–7b–ce–b0–6f–ee–9c–83–48–1f–46–ea–53–86–19–76–b6–07–c0–55–17–de–e8–5d–3c–a7–ab–2f–2f–02–18–71–fb–6a–a6–99–88–d3–a4–71–2a–2f–04–b0
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–f0–76–f1–2a–70–33–67–7e–07–67–27–4b–3a–41–30–d5–58–82–98–66 (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: 1NvTfH8Tx5fwdRrL3gHcPRgGESnywz2Dum
  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/1NvTfH8Tx5fwdRrL3gHcPRgGESnywz2Dum