Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clean up #893

Closed
wants to merge 2 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 13 additions & 12 deletions syllabus/1-Cryptography/5-Basic_Signatures-slides.md
Original file line number Diff line number Diff line change
Expand Up @@ -46,9 +46,9 @@ See the Jupyter notebook and/or HackMD cheat sheet for this lesson.

## Hash Functions

There are two lessons dedicated to hash functions.<br />But they are used as part of all signing processes.
There are two lessons dedicated to hash functions.<br />But they are used as part of all signing processes.<!-- .element: class="fragment" data-fragment-index="0" -->

For now, we only concern ourselves with using Blake2.
For now, we only concern ourselves with using Blake2.<!-- .element: class="fragment" data-fragment-index="1" -->

---

Expand All @@ -58,12 +58,11 @@ As mentioned in the introduction,<br />it's often more practical to sign the has

Therefore, the sign/verify API may be _used_ like:

<pba-flex center>
- `fn sign(sk, H(msg)) -> signature;` <!-- .element: class="fragment" data-fragment-index="0" -->
- `fn verify(pk, H(msg), signature) -> bool;` <!-- .element: class="fragment" data-fragment-index="1" -->

- `fn sign(sk, H(msg)) -> signature;`
- `fn verify(pk, H(msg), signature) -> bool;`

</pba-flex>
Notes:

Where `H` is a hash function (for our purposes, Blake2).<br />
This means the verifier will need to run the correct hash function on the message.
Expand All @@ -83,7 +82,12 @@ Signatures provide many useful properties:

Notes:

If a hash is signed, you can prove a signature is valid _without_ telling anyone the actual message that was signed, just the hash.
Question what do each of these mean?

- Confidentiality - If a hash is signed, you can prove a signature is valid _without_ telling anyone the actual message that was signed, just the hash.
- Authenticity: Authenticity assures that the data comes from a verified source.
- Integrity assures that the data has not been changed in an unauthorized manner.
- Non-Repudiation provides evidence that can be used to prove the involvement of parties in a communication, preventing them from denying their actions.

---

Expand Down Expand Up @@ -118,12 +122,9 @@ Note that signing and encryption are _not_ inverses.
Replay attacks occur when someone intercepts and resends a valid message.<br />
The receiver will carry out the instructions since the message contains a valid signature.

<pba-flex center>

- Since we assume that channels are insecure, all messages should be considered intercepted.
- The "receiver", for blockchain purposes, is actually an automated system.

</pba-flex>
- Since we assume that channels are insecure, all messages should be considered intercepted. <!-- .element: class="fragment" data-fragment-index="0" -->
- The "receiver", for blockchain purposes, is actually an automated system. <!-- .element: class="fragment" data-fragment-index="1" -->

Notes:

Expand Down
39 changes: 30 additions & 9 deletions syllabus/1-Cryptography/7-Hash_Based_Data_Structures-slides.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,9 +10,13 @@ duration: 1 hour

## Comparison to<br />Pointer Based Data Structures

- A hash references the _content_ of some data;
- A pointer tells you where to find it;
- We can not have cycles of hashes.
- A hash references the content of some data <!-- .element: class="fragment" data-fragment-index="0" -->
- A pointer tells you where to find it <!-- .element: class="fragment" data-fragment-index="1" -->
- We can not have cycles of hashes. <!-- .element: class="fragment" data-fragment-index="2" -->

Notes:
- Q: point 3 why cant we have a cycle of hashes?
- Answer: Properties of the hash function as long as we hash different stuff we will always reference something specific and different.

---

Expand Down Expand Up @@ -64,6 +68,7 @@ Collision resistance: we reasonably assume only one preimage for each hash,<br /

Notes:

What could happen if the hash function breaks in this structure?
Explain what could happen when this fails.

---
Expand Down Expand Up @@ -172,10 +177,14 @@ Additionally, if the size of a value is particularly large, it is replaced with

## Hash Trie

- Inserting arbitrary (or worse, user-determined) keys into the Patricia tree can lead to highly unbalanced branches, enlarging proof-sizes and lookup times.
- Solution: pre-hash the data before inserting it to make keys random.
- _Resistance against partial collision is important._
- Could be a Merkle trie or regular.
- Inserting arbitrary (or worse, user-determined) keys into the Patricia tree can lead to highly unbalanced branches, enlarging proof-sizes and lookup times.<!-- .element: class="fragment" data-fragment-index="1" -->
- Solution: pre-hash the data before inserting it to make keys random.<!-- .element: class="fragment" data-fragment-index="2" -->
- Resistance against partial collision is important.<!-- .element: class="fragment" data-fragment-index="3" -->
- Could be a Merkle trie or regular.<!-- .element: class="fragment" data-fragment-index="4" -->

Notes:
- Q: Why would pre-hashing the data make the keys random? A: Because each piece of data should be unique! it is a good selection scheme.
Talk about how to determine keys in bitcoin state tree

---

Expand All @@ -188,8 +197,12 @@ What radix $r$ is best?

...but:

- Higher branching at high levels of the tree can give smaller batch proofs.
- For storage, it is best to read consecutive data so high $r$ is better.
- Higher branching at high levels of the tree can give smaller batch proofs. <!-- .element: class="fragment" data-fragment-index="0" -->
- For storage, it is best to read consecutive data so high $r$ is better. <!-- .element: class="fragment" data-fragment-index="1" -->

Notes:
Q: Why would higher branching at high levels of the tree give smaller batch proofs?
A: Less nodes are needed in order to prove various parts of the tree

---

Expand Down Expand Up @@ -227,6 +240,14 @@ Notes:
- Not as balanced as a binary tree but close
- Can update the peak nodes alone on-chain


Applications:

- Stateless Client can very efficiently prove the end parts of the tree allowing for a client which doesnt need to store the whole blockchain just a few latest nodes.
- Look at the structure if each leaf is a block then if previous stuff is pruned that is fine because you still carry around the hash or peak of a selection of blocks
- Lightclients, efficiently see whether a transaction is included in a block without needing the entire the entire blockchain history
We use this in polkadot for our bridging!!

---

<!-- .slide: data-background-color="#4A2439" -->
Expand Down