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)

0401 42a9 1cb2 dd3e 1292 1fef 892d 656f 238c f71c 5674 b9f4 c2e2 6640 dc1a a142 2003 fd4c 7e1b ce31 ed63 d791 54b4 6158 9689 c1dd 09a4 a1f3 c426 084e 901a 3a93

Witness Fingerprint (Witness Id)

7789 fed8 9129 538d 15ad fc96 8e51 9edb 6f91 fba9 6933 933e 545e fa6d 53f7 b610 e95d b057 4bed 410a 8296 4b1d 3396 2e03 ca6a 68d9 fa6b c483 0f04 139c 6fdf 5733

Timestamp

2020-09-24T19:02:44.5846117Z


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
dfcf 36f5 2e4e 2746 bb37 bf11 f5f0 635b aa32 d458 1971 6c45 3a5e 4005 9be2 eb66 1ccd 1e6a 57de e288 70fb 4085 5dea b1b4 5f61 07ec c755 4d96 bf6c 9068 3356 5b8e
Intermediate validation step 2, Direction: Left
2969 a5c6 47d8 dbd7 a1b5 becb b590 8c93 270a 2967 572d e415 7db7 f382 5a8b 2bc7 99e9 4507 9fe1 0608 10b9 ddd8 6df3 87d4 f8f9 7ccd fab0 7952 6903 d2b1 f4b1 9e9c
Intermediate validation step 3, Direction: Left
b91f 07b5 c36e 61c5 03e1 dc62 3e36 abf6 f1b9 1282 c137 5d62 f0a2 cf45 2517 aba5 31eb 22b0 cc58 dee2 92ef 0b21 a580 3d2d b2b3 4658 989f f489 345a b6f5 aa85 b81c
Intermediate validation step 4, Direction: Right
dbb9 eca7 d576 89fa e4cd 4008 803b caa0 3893 1134 0690 dbc1 c58e 4ff6 06ac 616b dbb1 6077 24ac f6f9 2fbd e35c 735e 36bd 9dea da71 cd4c 62e0 e5c0 6b22 50da b96f
Intermediate validation step 5, 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 6, 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.73847508709878
Longitude
11.953345276415348
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
040142a91cb2dd3e12921fef892d656f238cf71c5674b9f4c2e26640dc1aa1422003fd4c7e1bce31ed63d79154b461589689c1dd09a4a1f3c426084e901a3a93#2020-09-24T19:02:44.5846117ZWitnusApp userUserId9ccdfb85-52ee-4215-9105-b898eb197883Latitude57.73847508709878Longitude11.953345276415348
Hash of Witness Id string
7789 fed8 9129 538d 15ad fc96 8e51 9edb 6f91 fba9 6933 933e 545e fa6d 53f7 b610 e95d b057 4bed 410a 8296 4b1d 3396 2e03 ca6a 68d9 fa6b c483 0f04 139c 6fdf 5733
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)
77–89–fe–d8–91–29–53–8d–15–ad–fc–96–8e–51–9e–db–6f–91–fb–a9–69–33–93–3e–54–5e–fa–6d–53–f7–b6–10–e9–5d–b0–57–4b–ed–41–0a–82–96–4b–1d–33–96–2e–03–ca–6a–68–d9–fa–6b–c4–83–0f–04–13–9c–6f–df–57–33
Intermediate step 1, Direction: Left
df–cf–36–f5–2e–4e–27–46–bb–37–bf–11–f5–f0–63–5b–aa–32–d4–58–19–71–6c–45–3a–5e–40–05–9b–e2–eb–66–1c–cd–1e–6a–57–de–e2–88–70–fb–40–85–5d–ea–b1–b4–5f–61–07–ec–c7–55–4d–96–bf–6c–90–68–33–56–5b–8e
Intermediate step 2, Direction: Left
29–69–a5–c6–47–d8–db–d7–a1–b5–be–cb–b5–90–8c–93–27–0a–29–67–57–2d–e4–15–7d–b7–f3–82–5a–8b–2b–c7–99–e9–45–07–9f–e1–06–08–10–b9–dd–d8–6d–f3–87–d4–f8–f9–7c–cd–fa–b0–79–52–69–03–d2–b1–f4–b1–9e–9c
Intermediate step 3, Direction: Left
b9–1f–07–b5–c3–6e–61–c5–03–e1–dc–62–3e–36–ab–f6–f1–b9–12–82–c1–37–5d–62–f0–a2–cf–45–25–17–ab–a5–31–eb–22–b0–cc–58–de–e2–92–ef–0b–21–a5–80–3d–2d–b2–b3–46–58–98–9f–f4–89–34–5a–b6–f5–aa–85–b8–1c
Intermediate step 4, Direction: Right
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
Intermediate step 5, 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 6, 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:

77–89–fe–d8–91–29–53–8d–15–ad–fc–96–8e–51–9e–db–6f–91–fb–a9–69–33–93–3e–54–5e–fa–6d–53–f7–b6–10–e9–5d–b0–57–4b–ed–41–0a–82–96–4b–1d–33–96–2e–03–ca–6a–68–d9–fa–6b–c4–83–0f–04–13–9c–6f–df–57–33 df–cf–36–f5–2e–4e–27–46–bb–37–bf–11–f5–f0–63–5b–aa–32–d4–58–19–71–6c–45–3a–5e–40–05–9b–e2–eb–66–1c–cd–1e–6a–57–de–e2–88–70–fb–40–85–5d–ea–b1–b4–5f–61–07–ec–c7–55–4d–96–bf–6c–90–68–33–56–5b–8e
Result

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

a7–1f–7b–a6–64–2f–64–ce–fa–fe–f9–e0–7e–55–90–9d–d7–3f–2a–d8–8f–3a–aa–68–c7–eb–0b–b1–0a–91–61–6b–8e–ca–c8–ff–5a–c9–41–e1–0b–81–bb–39–65–bd–04–8b–c0–f0–08–a2–d8–31–d0–58–57–43–81–96–45–0b–e7–6e
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:

a7–1f–7b–a6–64–2f–64–ce–fa–fe–f9–e0–7e–55–90–9d–d7–3f–2a–d8–8f–3a–aa–68–c7–eb–0b–b1–0a–91–61–6b–8e–ca–c8–ff–5a–c9–41–e1–0b–81–bb–39–65–bd–04–8b–c0–f0–08–a2–d8–31–d0–58–57–43–81–96–45–0b–e7–6e 29–69–a5–c6–47–d8–db–d7–a1–b5–be–cb–b5–90–8c–93–27–0a–29–67–57–2d–e4–15–7d–b7–f3–82–5a–8b–2b–c7–99–e9–45–07–9f–e1–06–08–10–b9–dd–d8–6d–f3–87–d4–f8–f9–7c–cd–fa–b0–79–52–69–03–d2–b1–f4–b1–9e–9c (Download binary data)
Result

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

de–f7–70–94–71–b2–73–ff–7b–4e–3f–d3–1d–54–38–ef–49–ba–6c–03–f8–b8–3f–e5–7a–6c–8a–ae–c7–64–28–c8–d3–be–ee–55–38–83–8a–b9–ed–4f–63–60–8b–3b–bc–80–f9–e3–ff–25–ee–f4–63–37–cd–89–59–c8–50–33–82–b2
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:

de–f7–70–94–71–b2–73–ff–7b–4e–3f–d3–1d–54–38–ef–49–ba–6c–03–f8–b8–3f–e5–7a–6c–8a–ae–c7–64–28–c8–d3–be–ee–55–38–83–8a–b9–ed–4f–63–60–8b–3b–bc–80–f9–e3–ff–25–ee–f4–63–37–cd–89–59–c8–50–33–82–b2 b9–1f–07–b5–c3–6e–61–c5–03–e1–dc–62–3e–36–ab–f6–f1–b9–12–82–c1–37–5d–62–f0–a2–cf–45–25–17–ab–a5–31–eb–22–b0–cc–58–de–e2–92–ef–0b–21–a5–80–3d–2d–b2–b3–46–58–98–9f–f4–89–34–5a–b6–f5–aa–85–b8–1c (Download binary data)
Result

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

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
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:

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 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 (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 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:

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 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:

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