Wouldn’t know too much about that. Sorry. 
1 Like
Done the first lot now hash starting the introduction.
1 Like
Really looking forward to this section, as it’s the area I probably know least about on this particular course 
here we go…
1 Like
How you make sure a smart contract is decentralized?
Looking forward to learn about Hash Functions, and enhancing my knowledge on Cryptography. 
2 Likes
Hi @globallyours if you think in terms does the contract has an owner that can change the contract parameters in malicious way, in the EVM itself its quite difficult, except if the contract is open source and verified on sites like Etherscan where you can check the code and know it is the same as the source.
There are also projects that decompile the contract on the blockchain but the output is usually hard to read. So it can be done, but its not that straightforward.
The 10 minute block interval is chosen as a trade off between fast transaction clearing and lower the possibility of accidental forks (stale blocks)
Increasing the block size leads to to much centralisation. This is only a temporarily fix. If we keep increasing the blocksize, eventually full nodes have to run on super computers and would take to much time validating each block. The barrier to run a full node will be to high.
Today, it’s impossible to scale on chain without trade offs between decentralisation, security and scalability (blockchain trilemma)
Thats why bitcoin implemented segwit and build the lightning network. In lightning, if you have enough channels to route payments, you have instant settlement. No need to wait for onchain confirmations. In the future, I think on the main chain will be used for saving and bigger transactions that require more security. and lightning for everyday small transactions.
It’s not practical to pay for coffee on the blockchain and wait 10minutes for confirmation.
PS. Soon I will check out your other questions.
Hey guys!
Got a question around digital signatures and private keys - I understand the most part but I think I’m missing something… here’s my notes:
- Alice sends message to Bob and Bob wants to verify the sender is actually Alice.
- Alice generates a private key, and then derives a public key from this.
- Alice uses the private key to sign the message, now has a digital signature
- Bob can verify Alice’s private key by mathematically formulating the signature and Alice’s public key.
If I understand and the above is correct, what does Bob see that’s different to the signature and public key, to verify Alice’s private key, without actually seeing Alice’s private key?
I hope this makes sense - I’m rather intrigued… 
Hello guys, I have a problem. After looking 2 days on a screen reading the article about hashing… I find out that the part with the birthday paradox is all hocus pocus for me. I tryed to use translate but this doesnt seem to work for me also. Stuff about the N and the Y i really really dont know what i read. Am i missing some important math here? Can someone please explain to me in verry basic language what the following means? I dont understand it.
What is the Birthday Paradox?
If you meet any random stranger out on the streets the chances are very low for both of you to have the same birthday. In fact, assuming that all days of the year have the same likelihood of having a birthday, the chances of another person sharing your birthday is 1/365 which is 0.27%. In other words, it is really low.
However, having said that, if you gather up 20-30 people in one room, the odds of two people sharing the exact same birthday rises up astronomically. In fact, there is a 50-50 chance for 2 people sharing the same birthday in this scenario!
Image credit: (YouTube)
Why does that happen? It is because of a simple rule in probability which goes as follows. Suppose you have N different possibilities of an event happening, then you need square root of N random items for them to have a 50% chance of a collision.
So applying this theory for birthdays, you have 365 different possibilities of birthdays, so you just need Sqrt(365), which is ~23~, randomly chosen people for 50% chance of two people sharing birthdays.
What is the application of this in hashing?
Suppose you have a 128-bit hash which has 2^128 different possibilities. By using the birthday paradox, you have a 50% chance to break the collision resistance at the sqrt(2^128) = 2^64th instance.
As you can see, it is much easier to break collision resistance than it is to break preimage resistance. No hash function is collision free, but it usually takes so long to find a collision. So, if you are using a function like SHA-256, it is safe to assume that if H(A) = H(B) then A = B.
Property 6: Puzzle Friendly
Now, this is a fascinating property, and the application and impact that this one property has had on cryptocurrency are huge (more on that later when we cover mining and crypto puzzles). First let’s define the property, after that we will go over each term in detail.
For every output “Y”, if k is chosen from a distribution with high min-entropy it is infeasible to find an input x such that H(k|x) = Y.
That probably went all over your head! But it’s ok, let’s now understand what that definition means.
What is the meaning of “high min-entropy”?
It means that the distribution from which the value is chosen is hugely distributed so much so that us choosing a random value has a negligible probability. Basically, if you were told to chose a number between 1 and 5, that’s a low min-entropy distribution. However, if you were to choose a number between 1 and a gazillion, that is a high min-entropy distribution.
What does “k|x” mean?
The “|” denotes concatenation. Concatenation means adding two strings together. Eg. If I were to concatenate “BLUE” and “SKY” together, then the result will be “BLUESKY”.
So now let’s revisit the definition.
Suppose you have an output value “Y”. If you choose a random value “k” from a wide distribution, it is infeasible to find a value X such that the hash of the concatenation of k and x will give the output Y.
Once again, notice the word “infeasible”, it is not impossible because people do this all the time. In fact, the whole process of mining works upon this (more on that later).
Examples of cryptographic hash functions
- MD 5: It produces a 128-bit hash. Collision resistance was broken after ~2^21 hashes.
- SHA 1: Produces a 160-bit hash. Collision resistance broke after ~2^61 hashes.
- SHA 256: Produces a 256-bit hash. This is currently being used by bitcoin.
- Keccak-256: Produces a 256-bit hash and is currently used by ethereum.
4 Likes
Thank you, Fabrice, that’s good information. I really appreciate your effort.
As I said in some of my recent emails, the question I am most interested in is the one concerning the Merkle tree.
1 Like
Haha, yeah it’s the Beauty of cryptography.
The public key is mathematically proven to relate to it’s private key. It uses Elliptic curve cryptography.
Bob will see a signature and he can verify the message + signature that has to be signed by some public /private key pair
Check out:
6 Likes
So Far So Good 
2 Likes
Hi, I’m trying to figure out your issue with merkle trees.
Merkle trees is just a way to bundle and hash all transaction ID’s together into 1 root hash. Just to be able to be able to verify that no transaction can be tampered with, because a 1 digit change would result in a completely different hash. Hashes are very small in size compared with the actual data. So it’s an easy way that doesn’t take lots of size to verify all transactions.
Can you please re-formulate your question? I’m sorry, but I’m not very good in ‘language’ 
I’m gonna leave you an awesome video about this topic.
And if you wanna have a private chat about it, don’t hesitate to contact me. (Fabrice Manzo #0007 on discord)
3 Likes
There is technically a limit, but it’s quite large. The padding scheme used for SHA-256 requires that the size of the input (in bits) be expressed as a 64-bit number. Therefore, the maximum size is (264-1)/8 bytes ~= 2’091’752 terabytes.
That renders the limit almost entirely theoretical, not practical.
Most people don’t have the storage for nearly that much data anyway, but even if they did, processing it all serially to produce a single hash would take an amount of time most would consider prohibitive.
Because the output has a fixed size, it is prone to hash colusions. In hashes, the smaller the output size is, the more likely you can have a collision, wich means that 2 different inputs can produce the same hash. In Sha256 this is highly unlikely (not impossible) because 256bits is a really large number and it would statistically be insignificant to have a collision.
1 Like
Thank you for your effort, Fabrice, I will definitely look at that video. My question was directly aimed at the explanation that was provided in the reading assignment. If you take a look at that reading assignment, you will understand what my question was about. I really tried to make sense of the remark—in the treading assignment—on using Merkle trees for efficient searches but I was unable to do so… I completely understand how Merkle trees can be used to encode information, but the claim—in the reading assignment—that they can make searches for transactions in a block more efficient is a mystery to me.
It’s not really to make it more efficient, it’s more to proof what’s happening without the need of big size information. Hashing is so easy to check and validate
1 Like
If that’s all there is to it—which makes sense to me—then it may be helpful to adjust the reading assignment accordingly. Other students may wonder as well about the search-efficiency explanation given in that assigned article. Thanks again for your help.
1 Like
You’ll find your answer in this one:
But with a merkle tree , if we want to check that a TXID is part of the merkle root, we would only need to know some of the hashes along the path of the tree :
You only need the right branches (the “merkle proof”) to reconstruct the merkle root
As a result, by using a merkle root as our fingerprint for the block header, we can later find out if a transaction exists in a block without having to know every other TXID in the block.
A merkle tree is just an efficient way to prove that something is in a set, without having to know the full set.
3 Likes
Thank you, Fabrice, I really appreciate your reply.
The article does indeed address the question that I was asking. So in reference to the diagram in the article, I will say that it is certainly true that I can find out whether a given string is equal to the turquoise leaf if only I know the black leaf and the black hashes because the Merkle root is uniquely determined by that leaf and by those hashes. But my problem somehow is that in choosing a particular leaf position (in this case the turquoise leaf) I already assume a piece of knowledge that I wouldn’t have if I simply asked the more general question whether my given string is equal to one of the leaves. If I focus my attention from the get-go on one particular leaf at one particular position, then, it seems to me, I may as well just look at that leaf itself and compare it to the given string. But if I don’t know which leaf to focus my attention on, then I also don’t know which hashes in Merkle tree I need to pick in order to re-produce the Merkle root and in order to verify thereby that my given string is equal to one of the leaves.
So my impression is that I do understand what the article is saying, but I still don’t see how the observation made in that article is practically helpful. But be that as it may, my impression also is that this search or verification problem is actually not very important for the use of Merkle trees in the design of Bitcoin. What matters for Bitcoin is the fact that the Merkle root uniquely represents all the leaves in a single hash, and that, it seems to me, is really all there is to it from a Bitcoin point of view.
Frank