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)

9ac1 54ed 09a2 6ae1 ab1d f250 25ce 603d 3e2f cee4 1b95 2086 625e 9981 d76b ba82 30be 8b18 eca7 1df5 fadf 4925 dd83 8858 bd71 a8a0 53f1 d6ab 87c4 5186 e41b 22a1

Witness Fingerprint (Witness Id)

d8e4 ac58 05dd ba4c ec43 1724 7952 8554 2d7c 2140 a901 b3be 8a76 201d 9e35 ab81 f7f1 3f9b 0fff 01b8 1c93 4e01 df5b 115f a5cf e248 68ff ada3 e56b 9f2b b6ac c00e

Timestamp

2020-09-09T18:37:52.0797094Z


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
51ab a202 960e cd26 bebb 658f 2836 1bb2 37c7 071f 0e02 ae4c c1b1 20e9 b2ab 87ae f487 de17 d01d cbf4 c6dd f8f2 87e6 b5f9 240e 016b 3615 6701 4438 76e5 1ddc 208e
Intermediate validation step 2, Direction: Right
daab 0103 5821 14f2 1853 4a2d f2e9 b444 761b 42f0 3e26 2eb9 5ca0 183e 07c2 70f8 5c99 aed5 5766 f4c8 99c2 979b 1e31 a7f5 fabb c8ad 8d28 fd1e 43ae 26e0 eab0 aaac
Intermediate validation step 3, 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 4, 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.657257080078125
Longitude
11.945832750793592
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
9ac154ed09a26ae1ab1df25025ce603d3e2fcee41b952086625e9981d76bba8230be8b18eca71df5fadf4925dd838858bd71a8a053f1d6ab87c45186e41b22a1#2020-09-09T18:37:52.0797094ZWitnusApp userUserIda8913545-1396-4bfc-b3bb-8cd7e6eedbacLatitude57.657257080078125Longitude11.945832750793592
Hash of Witness Id string
d8e4 ac58 05dd ba4c ec43 1724 7952 8554 2d7c 2140 a901 b3be 8a76 201d 9e35 ab81 f7f1 3f9b 0fff 01b8 1c93 4e01 df5b 115f a5cf e248 68ff ada3 e56b 9f2b b6ac c00e
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)
d8–e4–ac–58–05–dd–ba–4c–ec–43–17–24–79–52–85–54–2d–7c–21–40–a9–01–b3–be–8a–76–20–1d–9e–35–ab–81–f7–f1–3f–9b–0f–ff–01–b8–1c–93–4e–01–df–5b–11–5f–a5–cf–e2–48–68–ff–ad–a3–e5–6b–9f–2b–b6–ac–c0–0e
Intermediate step 1, Direction: Left
51–ab–a2–02–96–0e–cd–26–be–bb–65–8f–28–36–1b–b2–37–c7–07–1f–0e–02–ae–4c–c1–b1–20–e9–b2–ab–87–ae–f4–87–de–17–d0–1d–cb–f4–c6–dd–f8–f2–87–e6–b5–f9–24–0e–01–6b–36–15–67–01–44–38–76–e5–1d–dc–20–8e
Intermediate step 2, Direction: Right
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
Intermediate step 3, 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 4, 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:

d8–e4–ac–58–05–dd–ba–4c–ec–43–17–24–79–52–85–54–2d–7c–21–40–a9–01–b3–be–8a–76–20–1d–9e–35–ab–81–f7–f1–3f–9b–0f–ff–01–b8–1c–93–4e–01–df–5b–11–5f–a5–cf–e2–48–68–ff–ad–a3–e5–6b–9f–2b–b6–ac–c0–0e 51–ab–a2–02–96–0e–cd–26–be–bb–65–8f–28–36–1b–b2–37–c7–07–1f–0e–02–ae–4c–c1–b1–20–e9–b2–ab–87–ae–f4–87–de–17–d0–1d–cb–f4–c6–dd–f8–f2–87–e6–b5–f9–24–0e–01–6b–36–15–67–01–44–38–76–e5–1d–dc–20–8e
Result

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

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

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

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

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