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)

a70e 1028 6635 5dc1 81c0 5f75 9515 c9a8 b72a 973a 050a 995e 03e2 72b3 fb21 864d 1953 2500 9732 2a20 3c5d 41fa 0400 2290 5919 058c d39c 131b bbc0 ab4c 4001 bfa4

Witness Fingerprint (Witness Id)

be79 8374 1514 56f8 51b7 ad06 3056 d1a9 5256 ffb1 0cc6 13df 65a2 3ae7 f523 7fd4 8489 25a5 e794 21d8 ab67 c8ee 578e e482 75a6 73e6 c736 c746 63b6 ea97 3398 c63d

Timestamp

2020-09-09T18:00:39.1792458Z


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
7384 7e2f 9e02 8419 a527 e33f c7a6 b0a3 18f9 a628 b4bb 4b66 11a2 77d8 090a ed7e 435c b0e6 17a7 7ce5 b063 b92a ff78 2be4 0ada afa1 20f6 c453 325b 895a 0177 f9e4
Intermediate validation step 2, Direction: Right
e740 7b6d af56 126c db32 e53f 92c4 cdde b1a9 62b1 8245 f01a 274f e170 132f 8577 5c0c de8d 8193 6c97 6df4 41d4 58a0 bbb1 49a7 f914 22bd c376 44f8 d806 2f49 015e
Intermediate validation step 3, Direction: Left
bed3 b842 832b 95a0 daa7 ec4e a443 92b5 4420 81df c7ac 8975 1eae f270 6b23 d083 1e43 53eb 8b40 852b 32fe 7997 62ca c101 9d5d d214 1639 8572 1535 6a9a 252a 0abb
Intermediate validation step 4, Direction: Right
aeff 61ae e39f 34ac cbab 2bad 6fe4 3cf4 91f6 0fed c17f f0e7 17cf dffd 7f57 359c 48b9 7e1f 9438 407c 4309 e72a 0f13 6ef5 f76c 31e6 f69e b7f2 7650 a0d7 a9ae 15bf
Intermediate validation step 5, Direction: Right
230b 9b85 4938 8cab be4c bd64 882a 4b77 7779 3c1c 26ff f72b c43d 15a9 2c93 1b7d 126a 0398 ecd9 39dc 126a 4345 854d 7eba 565f 711a fd88 d763 58c5 b41e 1ef9 39b0
Expected root hash
8fdf 1fa0 73b3 49d6 ae3b e36a 2242 69d5 135a 1859 5f64 c81c 346a d6de 28e1 4b9c 7088 d75e db25 7318 9f5a f952 1c06 41e6 de69 2e36 3ae7 c507 ee5c d840 175d 7062

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.65728759765625
Longitude
11.945792855833705
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
a70e102866355dc181c05f759515c9a8b72a973a050a995e03e272b3fb21864d1953250097322a203c5d41fa040022905919058cd39c131bbbc0ab4c4001bfa4#2020-09-09T18:00:39.1792458ZWitnusApp userUserIda8913545-1396-4bfc-b3bb-8cd7e6eedbacLatitude57.65728759765625Longitude11.945792855833705
Hash of Witness Id string
be79 8374 1514 56f8 51b7 ad06 3056 d1a9 5256 ffb1 0cc6 13df 65a2 3ae7 f523 7fd4 8489 25a5 e794 21d8 ab67 c8ee 578e e482 75a6 73e6 c736 c746 63b6 ea97 3398 c63d
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)
be–79–83–74–15–14–56–f8–51–b7–ad–06–30–56–d1–a9–52–56–ff–b1–0c–c6–13–df–65–a2–3a–e7–f5–23–7f–d4–84–89–25–a5–e7–94–21–d8–ab–67–c8–ee–57–8e–e4–82–75–a6–73–e6–c7–36–c7–46–63–b6–ea–97–33–98–c6–3d
Intermediate step 1, Direction: Left
73–84–7e–2f–9e–02–84–19–a5–27–e3–3f–c7–a6–b0–a3–18–f9–a6–28–b4–bb–4b–66–11–a2–77–d8–09–0a–ed–7e–43–5c–b0–e6–17–a7–7c–e5–b0–63–b9–2a–ff–78–2b–e4–0a–da–af–a1–20–f6–c4–53–32–5b–89–5a–01–77–f9–e4
Intermediate step 2, Direction: Right
e7–40–7b–6d–af–56–12–6c–db–32–e5–3f–92–c4–cd–de–b1–a9–62–b1–82–45–f0–1a–27–4f–e1–70–13–2f–85–77–5c–0c–de–8d–81–93–6c–97–6d–f4–41–d4–58–a0–bb–b1–49–a7–f9–14–22–bd–c3–76–44–f8–d8–06–2f–49–01–5e
Intermediate step 3, Direction: Left
be–d3–b8–42–83–2b–95–a0–da–a7–ec–4e–a4–43–92–b5–44–20–81–df–c7–ac–89–75–1e–ae–f2–70–6b–23–d0–83–1e–43–53–eb–8b–40–85–2b–32–fe–79–97–62–ca–c1–01–9d–5d–d2–14–16–39–85–72–15–35–6a–9a–25–2a–0a–bb
Intermediate step 4, Direction: Right
ae–ff–61–ae–e3–9f–34–ac–cb–ab–2b–ad–6f–e4–3c–f4–91–f6–0f–ed–c1–7f–f0–e7–17–cf–df–fd–7f–57–35–9c–48–b9–7e–1f–94–38–40–7c–43–09–e7–2a–0f–13–6e–f5–f7–6c–31–e6–f6–9e–b7–f2–76–50–a0–d7–a9–ae–15–bf
Intermediate step 5, Direction: Right
23–0b–9b–85–49–38–8c–ab–be–4c–bd–64–88–2a–4b–77–77–79–3c–1c–26–ff–f7–2b–c4–3d–15–a9–2c–93–1b–7d–12–6a–03–98–ec–d9–39–dc–12–6a–43–45–85–4d–7e–ba–56–5f–71–1a–fd–88–d7–63–58–c5–b4–1e–1e–f9–39–b0
Expected root hash
8f–df–1f–a0–73–b3–49–d6–ae–3b–e3–6a–22–42–69–d5–13–5a–18–59–5f–64–c8–1c–34–6a–d6–de–28–e1–4b–9c–70–88–d7–5e–db–25–73–18–9f–5a–f9–52–1c–06–41–e6–de–69–2e–36–3a–e7–c5–07–ee–5c–d8–40–17–5d–70–62

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:

be–79–83–74–15–14–56–f8–51–b7–ad–06–30–56–d1–a9–52–56–ff–b1–0c–c6–13–df–65–a2–3a–e7–f5–23–7f–d4–84–89–25–a5–e7–94–21–d8–ab–67–c8–ee–57–8e–e4–82–75–a6–73–e6–c7–36–c7–46–63–b6–ea–97–33–98–c6–3d 73–84–7e–2f–9e–02–84–19–a5–27–e3–3f–c7–a6–b0–a3–18–f9–a6–28–b4–bb–4b–66–11–a2–77–d8–09–0a–ed–7e–43–5c–b0–e6–17–a7–7c–e5–b0–63–b9–2a–ff–78–2b–e4–0a–da–af–a1–20–f6–c4–53–32–5b–89–5a–01–77–f9–e4
Result

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

31–10–c3–8e–33–1c–75–5e–f2–68–0c–f1–93–39–8e–7b–2a–c7–d7–22–29–0b–9c–7e–24–59–87–ec–de–1d–11–f8–b0–94–0c–63–9a–ee–5b–8e–6b–8b–1a–6e–1c–d1–08–36–37–b8–44–11–33–ec–e9–8d–79–93–c6–ff–64–5d–2f–a4
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:

31–10–c3–8e–33–1c–75–5e–f2–68–0c–f1–93–39–8e–7b–2a–c7–d7–22–29–0b–9c–7e–24–59–87–ec–de–1d–11–f8–b0–94–0c–63–9a–ee–5b–8e–6b–8b–1a–6e–1c–d1–08–36–37–b8–44–11–33–ec–e9–8d–79–93–c6–ff–64–5d–2f–a4 e7–40–7b–6d–af–56–12–6c–db–32–e5–3f–92–c4–cd–de–b1–a9–62–b1–82–45–f0–1a–27–4f–e1–70–13–2f–85–77–5c–0c–de–8d–81–93–6c–97–6d–f4–41–d4–58–a0–bb–b1–49–a7–f9–14–22–bd–c3–76–44–f8–d8–06–2f–49–01–5e (Download binary data)
Result

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

da–ab–01–03–58–21–14–f2–18–53–4a–2d–f2–e9–b4–44–76–1b–42–f0–3e–26–2e–b9–5c–a0–18–3e–07–c2–70–f8–5c–99–ae–d5–57–66–f4–c8–99–c2–97–9b–1e–31–a7–f5–fa–bb–c8–ad–8d–28–fd–1e–43–ae–26–e0–ea–b0–aa–ac
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:

da–ab–01–03–58–21–14–f2–18–53–4a–2d–f2–e9–b4–44–76–1b–42–f0–3e–26–2e–b9–5c–a0–18–3e–07–c2–70–f8–5c–99–ae–d5–57–66–f4–c8–99–c2–97–9b–1e–31–a7–f5–fa–bb–c8–ad–8d–28–fd–1e–43–ae–26–e0–ea–b0–aa–ac be–d3–b8–42–83–2b–95–a0–da–a7–ec–4e–a4–43–92–b5–44–20–81–df–c7–ac–89–75–1e–ae–f2–70–6b–23–d0–83–1e–43–53–eb–8b–40–85–2b–32–fe–79–97–62–ca–c1–01–9d–5d–d2–14–16–39–85–72–15–35–6a–9a–25–2a–0a–bb (Download binary data)
Result

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

7e–9b–4b–b8–09–d6–f8–57–ed–ce–90–44–96–a9–36–1e–f9–bd–a3–80–f2–29–11–c1–02–25–63–83–dd–9d–e2–03–a5–c3–24–aa–ed–75–fb–e6–5a–bf–40–7c–73–a8–81–7c–fe–30–6a–57–26–b0–04–c3–62–f0–bf–ec–4e–a8–9f–f9
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:

7e–9b–4b–b8–09–d6–f8–57–ed–ce–90–44–96–a9–36–1e–f9–bd–a3–80–f2–29–11–c1–02–25–63–83–dd–9d–e2–03–a5–c3–24–aa–ed–75–fb–e6–5a–bf–40–7c–73–a8–81–7c–fe–30–6a–57–26–b0–04–c3–62–f0–bf–ec–4e–a8–9f–f9 ae–ff–61–ae–e3–9f–34–ac–cb–ab–2b–ad–6f–e4–3c–f4–91–f6–0f–ed–c1–7f–f0–e7–17–cf–df–fd–7f–57–35–9c–48–b9–7e–1f–94–38–40–7c–43–09–e7–2a–0f–13–6e–f5–f7–6c–31–e6–f6–9e–b7–f2–76–50–a0–d7–a9–ae–15–bf (Download binary data)
Result

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

1b–eb–b4–53–a2–ff–fc–a7–b0–65–ee–55–74–c1–fb–34–49–35–62–f4–0d–f2–8a–c5–b0–d6–d5–73–88–99–4b–8d–f6–3a–5c–c6–f3–50–9f–c8–46–b5–49–0f–3e–da–a9–ff–01–96–0c–3d–eb–49–8d–d9–af–a1–cb–8c–4a–0e–89–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:

1b–eb–b4–53–a2–ff–fc–a7–b0–65–ee–55–74–c1–fb–34–49–35–62–f4–0d–f2–8a–c5–b0–d6–d5–73–88–99–4b–8d–f6–3a–5c–c6–f3–50–9f–c8–46–b5–49–0f–3e–da–a9–ff–01–96–0c–3d–eb–49–8d–d9–af–a1–cb–8c–4a–0e–89–d4 23–0b–9b–85–49–38–8c–ab–be–4c–bd–64–88–2a–4b–77–77–79–3c–1c–26–ff–f7–2b–c4–3d–15–a9–2c–93–1b–7d–12–6a–03–98–ec–d9–39–dc–12–6a–43–45–85–4d–7e–ba–56–5f–71–1a–fd–88–d7–63–58–c5–b4–1e–1e–f9–39–b0 (Download binary data)
Result

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

8f–df–1f–a0–73–b3–49–d6–ae–3b–e3–6a–22–42–69–d5–13–5a–18–59–5f–64–c8–1c–34–6a–d6–de–28–e1–4b–9c–70–88–d7–5e–db–25–73–18–9f–5a–f9–52–1c–06–41–e6–de–69–2e–36–3a–e7–c5–07–ee–5c–d8–40–17–5d–70–62
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
8f–df–1f–a0–73–b3–49–d6–ae–3b–e3–6a–22–42–69–d5–13–5a–18–59–5f–64–c8–1c–34–6a–d6–de–28–e1–4b–9c–70–88–d7–5e–db–25–73–18–9f–5a–f9–52–1c–06–41–e6–de–69–2e–36–3a–e7–c5–07–ee–5c–d8–40–17–5d–70–62
Calculated root hash
8f–df–1f–a0–73–b3–49–d6–ae–3b–e3–6a–22–42–69–d5–13–5a–18–59–5f–64–c8–1c–34–6a–d6–de–28–e1–4b–9c–70–88–d7–5e–db–25–73–18–9f–5a–f9–52–1c–06–41–e6–de–69–2e–36–3a–e7–c5–07–ee–5c–d8–40–17–5d–70–62
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–3e–1b–56–5d–9c–74–52–f8–18–19–88–44–e0–d5–c5–7f–0f–5a–1a–ef (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: 16fPeKxvJ2CLpZipRVeMnAxXvgyEiTaikZ
  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/16fPeKxvJ2CLpZipRVeMnAxXvgyEiTaikZ