hire someone that can do it 
But without jocking it depends what app and on what blockchain. You could use Scilla on zilliqa blockchain for example which i personally find easier than solidity. But for more better work and worked out developement anything that uses most common languages like solidity or javascript. Maybe in a few months cardano with shelly overcomes all 
1 Like
the hash function includes previous header of last known block which is the basis for the immutable consensus mechanism
1 Like
Hi All,
could someone please explain this bit:
If I understand it correctly, one private key/public key pair can generate many bitcoin addresses.
How is that possible when the process of going from public key to bitcoin address is firmly given (2 hashing algorithms). So that would mean that one particular public key gives the same hash (address) everytime ā¦ how is it possible to generate different adresses then?
1 Like
Looking forward to read more about what this Hash even means. Itās like learning a new language to understand what you guys even talking about. 
1 Like
If you are talking about the links in a bitcoin block then it goes as follow. In order for there to be a link, the previous hash has to be a part of the input.for the new hash. That way, if anyone changes the previous block, it will change its hash and ultimately be the breaking point of the chain. From that block on everything will be invalidated as the hashes will no longer match the difficulty.
1 Like
One private key can only control one address. Walletās usually generate a series of private keys giving you the option to have multiple addresses. The recovery seed words you get when generating a new wallet will recover all the private keys. Hope that helps.
1 Like
Feel free to do so. Hash is usually seen as a unique digital fingerprint of a file on your computer.
Digital fingerprints can be used to verify files that must be 100% correctly downloaded, otherwise a person or a company could lose money.
An example would be updating your BIOS. BIOS is the most basic program a computer has to have in order to boot up. Sometimes people would want to update it to add features it didnāt have before, such as a compatibility update for a new CPU. If anything goes wrong the motherboard will be bricked, and there is no easy way to fix it. Newer motherboards will download the BIOS update file and will check the hash of the file, and it if matches with the one stated on the official site it knows it is flashing a correct file. By comparing the hashes we can ensure we wonāt be flashing a bad file.
This is just one of the examples in which we can use hashing. Hashing in bitcoin is a whole other thing, which I assume you already know about.
2 Likes
ah, that makes sense ā¦ thank you
1 Like
No problem. If you have any more questions feel free to reply or DM me directly. I always recommend a hardware wallet, such as ledger or trezor. I think both of the generate a series of private keys for bitcoin.
2 Likes
No questions at this time, I am still reviewing the links and will be throughout the courseā¦ Iāll be back with questions for sure when in need.
1 Like
A Merkle tree is very interesting, first time iāve heard of it but what I got from it is that you take two transactions and hash them together, A & B or C & D and create a unique number. If any number is changed in part of the hash it would alter the entire transaction. Also only part of the Merkle tree is required to validate transaction A for example creating a tamper proof data structure that reduces storage. Iād like to look a little more into this later but I think I understand the basics.
Hello Ivan,
I have a number of questions concerning the reading on hash functions:
- If the input of a hash function is (as stated in the reading) a string of any length, then the set of input strings is infinite. Since on the other hand the output hashes all have the same length and therefore form a finite set, it seems natural to assume that hash functions are defined in such a way that the pre-image of any output hash is infinite. Is that correct?
- In order for the square-root formula associated with the birthday paradox to work, all output hashes, it seems to me, would have to occur with equal probability (in the same way that each day of a given year is equally likely to be the birthday of a randomly chosen individual). Is that indeed the case? And if it is the case then how is that probability computed in light of the fact that the set of input strings is infinite? How does the definition of the hash function guarantee that the pre-images of all its output hashes are all equal in size, so to speak, so as to make sure that the output hashes all have the same probability?
- Your explanation of the term āhigh min-entropyā appears to refer only to the number of choices that are available for k. If that number is large then the min-entropy is large and if that number is small, then so is the min-entropy. But if I understood correctly, the input of a hash function can be a string of any length. By implication, the set of input strings is infinite and so is as well the set of potential choices for k. But since your explanation of min-entropy refers to a large but still finite set of choices for k, it appears that you are restricting the original infinite set of choices for k to some finite subset. Exactly what is that subset and how is its min-entropy defined?
- In the text you use the symbol ā|ā to denote a concatenation, in the diagram directly following the header āWhat is a Merkle Treeā the concatenation is denoted by the symbol ā+ā, and in the diagram following the header āSo what does a Merkle Tree have to do with blockchains?ā the concatenation is denoted by a blank. Is that correct?
- In one of your diagrams the block header is shown to include the hash of the previous block header but in the text below that diagram it says that a block header contains the hash of the entire previous block rather than only the hash of the header. So which design description is the correct one? In both descriptions the header includes the root hash of the Merkle tree. So it seems to me that it should therefore be sufficient to include in the header only the hash of the previous header rather than the hash of the entire previous block because by including the Merkle root in the header, the entirety of the previous blockāincluding all transactions that are stored in itāwould be properly accounted for. Is that correct?
- In one paragraph you ask the reader to imagine an attack on block 3 and you go on to explain how such an attack would lead to a cascade of subsequent changes that would totally change the entire chain and would therefore be impossible. Why would it be impossible? First of all, in the corresponding diagram, block 3 appears to be the last block that is added to the chain. So it is obvious in light of the inclusion of the Merkle root in the header and in light of the requirement to store the hash of the header in the next block that a change in block 3 would necessitate changes in all the blocks that are added after it, but why would it necessitate changes in the blocks that were added previously? If that were the case, then the addition of a new block would always necessitate a reorganization of the entire chain. So did you mean to refer to an attack on block 1 or do I misinterpret the temporal sequence suggested in the diagram? Moreover, why do you say that the cascade of changes would be impossible? If one of the transactions in block 3 is changed, then the corresponding Merkle root in the header of that block is changed and so is the hash of that header in the header of block 4. In changing thus the header of block 4, the hash of the header of block 4 would be changed in the header of block 5 and so forth. It seems to me that these changes are not at all impossible and that what really is at issue here is the original double-spend problem addressed in the Satoshi whitepaper. According to that paper (if I am not mistaken), it is very well possible to create a competing fraudulent version of the blockchain (by modifying all subsequent headers in the manner described above) but since the process of implementing the necessary changes is time-consuming, this fraudulent version will tend to be shorter than the true version (because new blocks are added to the true chain while the fraudulent chain is being reorganized). So it is at this point, so far as I understand, that the probabilistic law kicks in which says that the chance for the shorter fraudulent chain to ever become longer than the true chain (and therefore be accepted, by definition, as the new true chain) is negligible unless there is a majority of miners conspiring to add blocks to the initially shorter fraudulent chain. Is that correct?
- I was trying to understand your explanation of the purpose of the Merkle tree. It makes perfect sense to me to represent the entirety of the transactions in a block by the root of the corresponding Merkle tree, to include that root in the header, and to then include in turn the hash of that header in the next header. But you refer, in your explanation of the purpose of the Merkle tree, to a search for a transaction (or piece of data) in a block. Exactly how is that search defined? You seem to be suggesting that one is given a piece of data (or a transaction) and that one is then trying to determine whether and where that transaction is included among the bottom leaves of the Merkle Tree. To make that determination, so you seem to be saying, one merely has to trace the corresponding branch of the Merkle tree. But each leaf is associated with exactly one branch and if I do not know the leaf because it is the leaf that I am looking for then how can I find the corresponding branch? If I do not know whether a certain piece of data is equal to one of the leaves then I also do not know whether that piece of data corresponds to one of the branches in the tree. What am I missing?
- As I was reading that blocks are added at intervals of ten minutes, it occurred to me that this restriction together with the restriction on block sizes might have been at the heart of the controversy that led to the creation of Bitcoin Cash. If blocks are limited in size and if they can be added to the bitcoin blockchain only at certain fixed intervals, then that blockchain is obviously severely limited in its transaction capacity. In other words, as more and more people are initiating transactions, the time that is needed to register these transactions on the blockchain will increase accordingly and eventually people will lose interest because the waiting time for the confirmation of transactions is simply too long. So thatās a problem even if bitcoin is used only as a trading vehicle and not as a means of exchange. In consequence, the crypto-trading platforms will be tempted to start trading virtual coins and traders who wish to withdraw the coins that they bought will be forced to wait until their virtual coins have been replaced with actual coins. So it seems as though the imposition of transaction limitations naturally leads to trading platforms becoming fraudulent. Is that correct?
Sorry for this very long post, but I was really just trying to properly understand the contents of the assigned reading.
Frank
2 Likes
Very insightful. Its good to eventually understand the addresses
1 Like
Know nothing about the subject, looking forward digesting this chunk of knowledge 
1 Like
I have no idea what this topic is about. I canāt wait to digest it right now.
1 Like
@Ivan youāre so inspiring.
Instead of money go brrr, brain go brrr.
So this tasing has got my thinking about identity and data on the web. I implement web analytics in my job. Iāve noticed thereās some companies out there already tackling this issue like https://datum.org
I was thinking about how this might work:
Any kind of data that is gathered is hashed onto the blockchain such as your web browsing history on apple.com.
Apple canāt unlock the data until you give them permission to do so by decoding the hashed data with your private key.
However, it must be done in such a way that your private key is not revealed.
Even though the data is stored on the public blockchain, itās encrypted and can only be accessed by those that are authorised to do so.
A company may even have to pay your for access to your data else access might be revoked therefore monetising your own data.
A smart contract on Ethereum would enable someone to choose the level of data they want to share with a company and could be paid more depending on what level of data they share.
For example, PII data would be more expensive than device model data or operating system.
This could be achieved by creating new private keys and hashing your data with the new key.
There could be different keys for different levels of consent and that is how you would control access in that way.
You could have different keys for different websites or companies so that enterprise organisations that own multiple websites have to pay you for your data multiple times.
If a company wanted to do a credit search on you, that would have to pay you for access to that data.
But letās not just focus on monetising peopleās data because that doesnāt target enterprise organisations
The benefit for enterprise is that the data is easily accessible with high availability. They donāt have to build their own data storage for it and deal with security, hacking attempts etc.
There is also no middle men, so theoretically a car company could do a credit search on you directly without going through Experian or Equifax.
4 Likes
Thank you so much Mauro! Itās a great definition for my brain to absorb. Itās always easier to understand when you compare it with something more familiar.
1 Like
Looking forward to learning the intracacies of the hash functions, cryptography, and functions!
1 Like
Hash functions i think of as similar to diodes or check valves one way function.
2 Likes
Hashing is a process of converting an input of any length into a fixed size string of text using a mathematical function. The hash output are then used for comparison purposes.
1 Like