Many of my students wishes to create their own blockchain applications. Many of them came from app and web development background, and while they are still highly motivated to learn how the blockchain itself works, their main goal is not purely academic. They want to see a product in action.
Yet, adjusting the course shouldn’t come at the price of marginalizing the blockchain architecture itself. At the end of the day, the thing that separates such a course from millions of other web/apps development courses is just it – the blockchain.
Bearing this in mind should be a at the heart of every decision taken when creating and conducting such a course. And there’s a very little place for compromises.
// This code represents a possible approach for teaching Keys
// Pay attention that even while still using a JS library such as bitcore.js
// The code still follows all the steps defined in the developers documentation.
bitcore = require("bitcore-lib");
privKey = bitcore.PrivateKey.fromString("8c5e5b37ebf1e7a274b9dff4910f9a2004868897f7d845802b77a1b245c26bc7");
pubKey = "04" +
pubKey = new Buffer(pubKey, "hex");
hashedPublicKey = "00" + bitcore.crypto.Hash.sha256ripemd160(pubKey).toString("hex");
hashedPublicKey = new Buffer(hashedPublicKey, "hex");
checkSum = bitcore.crypto.Hash.sha256sha256(hashedPublicKey).toString("hex").slice(0,8);
checkSum = new Buffer(checkSum, "hex");
binAddress = hashedPublicKey.toString("hex") + checkSum.toString("hex");
binAddress = new Buffer(binAddress, "hex");
address = bitcore.encoding.Base58.encode(binAddress);
The decision of when, and how to use these codes should be based on 2 main variables.
What the students need to know.
The first one refers to the main reason the students came to the course. The more interested they’re in the blockchain itself, the more they can gain by working with languages such as Python/C++/go etc’. On the other hand, if applications is what they want to create, they can benefit the most by using JavaScrip.
2. What the students already know.
I’m still checking it.
In the next few posts I hope to provide a more detail accounts on this project, in the hope that it might be more helpful to future students.
Mixing environments – Creating working environment for blockchain developers
This article is part of a series of articles depicting my experience with creating and conducting an 8 week long blockchain app development course in Brazil.
What tools should be used when teaching blockchain
The term blockchain is often misused. Very rarely do people use the term blockchain to describe anything beyond a chain of blocks. A lot of the time when people talk about the blockchain and its application, they basically refer to a somewhat wide variety of technologies, architectures, tools and protocols that, once properly combined and implemented, creates that “blockchain” they are referring to.
When I created the course, it was obvious to me that in order to properly teach the students how to work with “the blockchain”, I’ll first need to spend a lot time dealing with many different technologies and tools. There isn’t just one blockchain IDE or concept to examine; rather there are quite a number of them. Take key pair for example; private and public keys are some of the most crucial (and known) features in many crypto-currencies and blockchains, but they are by no means specific to blockchains. Many people use key pairs off chain. The same holds for many concepts that are highly integrated into the common view about blockchains – Hashing functions, signatures (and keys), scripts and stack architecture, byzantine general problem, bytes codes, merkle trees, DAGs and more.
Each feature in the list above represent another tool/approach/use case/concept that stands by itself but is also crucial to creating what is commonly known as “the blockchain”. This fact posed a great challenge for me when I tried to create the course. It was obvious to me that the course is aimed at people who want to learn how to develop their own blockchain applications and solutions, which meant that it will require the students to get their hands somewhat dirty in codes, command line prompt, and different computational tools.
The challenge here lay in choosing the right tools to work with while remembering that each item on the list should be taught in a manner that is adequate on the one hand, but without going to a level too deep and insignificant for the course on the other hand. It was also important that there should be a clear difference in the relations between the different and individual items. I knew I wasn’t hired to teach the students how to program or how to work with different environments. However, making the assumption that they had adequate programming knowledge, enough not to require any introduction to that programing language/ environment/ tools seemed quite optimistic at best, and downright stupid at worst. This is even more so when dealing with a variety of different tools and languages.
I decided to do my best to choose the most user friendly working environments – even at the cost of efficiency and future usability.
Numerous developers have their own working environment. However, I was convinced that every code, example and CLI command/tool should be properly tested and documented in a single uniform environment. The last thing I wanted to do was stand in front of the class while in the background, my code failed to compile. The result of this is that I tried a lot of different environments while always keeping in mind that the environment to be used should fulfill the following requirements;
It needs to support all the tools I require that my students use.
It shouldn’t affect in anyway the students’ computers, working environments, file systems, paths and/or jeopardizes their computer security in any way.
It should be uniform for all the students.
It should be easy and fast to set and reset whenever needed.
It should be as user friendly as possible.
After a few experimentations, I decided to work with the following configurations:
Cloud9 level 1 IDE environment with the following installations:
Virtual environments for Python 2.7 and 3.5
Tcpdump (for some reasons, not all c9 workspaces had it installed)
The following pip packages (base58, ecdsa)
Digital ocean Ubuntu 16.041 X64 droplet with the following installations:
The following changes were optional for a few students:
Installing ipfs and running ipfs daemon and adding ipfs-api package to their meteor app. (For those who wished to work with IPFS).
Adding swap file of 4 gb. (For those with memory issues).
Use openssh. (More IDE flexibility for advanced users).
Solidity browser compiler was mostly used for writing and deploying smart contracts. SOLC (installed on c9) was used by a few students who required some more advanced contracts (mostly when containing libraries).
The only 2 components the students were required to install on their own machines were:
Chrome/Chromium with metamask addon.
Cloud9 provided a well-tested and easy to configure working environment that was consistent for all students. It was used mainly to run the Python codes the students created, to compile some Solidity codes (using SOLC), to catch some packets using tcpdump (The tcpdump files were later downloaded and examined using wireshark) and to access digital ocean droplet using ssh.
I was very pleased with this working environment as it was quite robust, highly configurable, not local and easy to reset – Basically it was a great playground to get dirty with, without having to worry about damaging the students’ native environment.
There’s also another npm package for compiling Solidity (similar to SOLC), but unfortunately, I’ve experienced a lot of compatibility issues with that package and decided to ban the students from using it. IPFS-api is another useful tool for more advanced students who are interested in working with IPFS.
It is important to note that although I did discuss IPFS with some students, I didn’t consider it an important part of the course. First, the system is still in a very early stage. Secondly, the main goal of the course was to teach the students how to develop blockchain applications, and not necessarily decentralized applications (although the two might have a lot in common, they’re not mutually the same) and IPFS just didn’t really fit the slot. Besides, I already had an ample amount of topics to focus on and teach my students (And I must admit; I’m not that much of an expert in this platform myself).
Metamask and solidity browser were wonderful and very easy to use tools. In a manner of minutes, the student had yet another playground to play with Solidity and the Ethereum blockchain.
(It’s important to note that I took some time to make sure ALL of the students were using clean metamask installation WITHOUT any of their real wallets imported to it and only on the Ropsten testnet).
One last note about truffle
I also feel compelled to justify a little further my decision to exclude the use of truffle and/or embark (with testrpc) during the course and instead choosing to work with solidity browser compiler. The thing is, at the time, both truffle and embark had some memory issues that forced me to use another swap file (both when tested on Cloud9 and when tested on digital ocean droplet). In addition to that, most smart contracts required were easy to deploy from the Solidity web compiler. For specific ad hoc contracts that required the use of a more robust compiler, Ethereum SOLC was used on cloud 9 (SOLC didn’t had any memory issues). I do however recognize that truffle and embark are major tools in the industry and I’m defiantly planning to integrate them into future courses.
This article is part of a series of articles depicting my experience with creating and conducting an 8 week long blockchain app development course in Brazil.
The course as a mega structure
After I accepted to take on this challenge, the next logical course of action was to create the listof material I intended to teach the students. Originally, this list contained almost everything blockchain related – from bits, bytes and creating protocol messages all the way up to an overview of the history and politics of Bitcoin. The list was long, perhaps too long. I must admit my own limitations- I couldn’t see any realistic way to create such an extensive course by myself.
In addition, I had some doubts as to how many students can actually properly digest so much material, even when given 8 full weeks. (6 actually, if you count the time given to personal projects). I realized the list needed to be more focused – and that’s where my first major decisions were made.
Decision number 1: Focusing on the protocol itself. By deeply understanding the Bitcoin (and later the Ethereum) protocol, I believed the students will gain some clarity and very strong foundations upon which they can later build on and learn more extensively by themselves.
It was highly important to me to ensure they actually understand the protocol itself – how it developed, the tools it utilizes, and the logic behind choosing these specific tools and architectures and so on.
Once the students understood the intricacies of dealing with it, they will be better equipped to learn by themselves other things like how to use JS libraries in web applications; read and understand whitepapers and BIPs/EIPs, and create their own private chains and more. But how do I teach the protocol? That’s where my second decision was made.
Decision number 2: Bitcoin is the gold standard of blockchains and therefore, the go to chain when learning the basics of blockchains. This decision was a no brainer for me and represents a substantial chunk of my personal view on the blockchain ecosystem. The Bitcoin blockchain is the most widely used, heavily researched and extensively documented (albeit the documentation is somewhat lacking in my opinion). Every blockchain in existence this day stemmed from it and relies to a large extent on many of the concepts introduced by it.
It was clear to me that creating a blockchain course that isn’t based on the Bitcoin protocol will be a major breach of the faith the students reposed in me.
These two decisions brought with them peace of mind. Whereas before I was drowning in a pool of topics to cover – a list so long and chaotic, it was completely unmanageable, I now had a solid anchor to work with.
The four stages of mastering the blockchain
Once the list was completed, it became clear it could be divided into 4 main stages or phases:
From bit and bytes to protocol messages. The idea is that once completed, the student is able to send, receive and (maybe most importantly) parse a Bitcoin protocol message. In order to achieve this, the students will need to learn the basic mechanism of networking, create the byte code for a Bitcoin message – both payload and header, learn how to use one-way functions, hashing and how to read and understand the Bitcoin developers guide and protocol documentation.
Here, I held enlightening conversations with the students that revolved around keys. We went through the documentation together in a bid to learn about how to move seamlessly from private key to the public one and onto Bitcoin address.
The bread and butter of the Bitcoin protocol. Now that the students have the understanding of how to work with the Bitcoin documentation, the next logical step was channeling that documentation and using it in creating transactions.
Here, the students will garner all their knowledge about bits and bytes, hashing and keys (from the previous stage) and channel it into creating the raw Bitcoin transaction. After which, they will learn about the pkScript; scripting in Bitcoin (and scripting in general) plus stack architecture and how the pkScript is executed, which by the way is also a great opportunity to start the conversation with the students about Ethereum and its virtual machine.
Finally, the students will go on to elucidate on what type of transactions are considered standard.
After speaking with the students about all the basic components required in creating and transmitting a Bitcoin transaction, it was time to move on to talks about blocks and their architecture. I wanted them to have an understanding of what blocks really are. We were to create merkle trees (and merkle roots), blockheaders, calculate (mock) difficulty and target, and find the proper nonce. Along with that, it was also a great chance to have a chat with the students about DAG and consensus, mining algorithm, forks and altcoins.
In this phase, I was also afforded an invaluable chance to have a discussion with the students about contracts and secondary layers such as lightning network and BIPs (SegWit, addresses and other bips).
This is the second most predominant chain out there. It includes the wild west of consensus rules, mining algorithms and script (VM) playground. Many students want to understand how it works, and rightfully so. However, what most students want in learning Ethereum is how to actually use it – how to write smart contracts, and hence, how to use Solidity. This is where my previous decision to focus on Bitcoin as the gold standard for blockchain architecture became two opposite things; a blessing and a curse.
I wanted to spend as much time as I possibly could on Solidity, Web3 and Ethereum specific tools, and since I already spent more than half of the course talking about blockchain and Bitcoin, I was freer to talk about Solidity and web3 in this part of the course. However, a compromise was made and several unique architectural aspects of Ethereum were left out. I briefly talked about gas and the EVM by tying it to Bitcoin scripts and fees, and I glossed over block structure by simply stating that “merkle roots are also involved”. Mining and Ethereum attempts to move to POS were completely ignored – I think you get the picture.
The only architectural aspects of Ethereum I discussed in class were the ones that can be easily seen when playing with Solidity and smart contracts (Libraries and calls, Inline assembly, variables gas price, constant functions, variables scopes etc.)
A sense of achievement
All in all, I’m quite proud of this structure and the topics it included. I found myself with a solid and detailed road map of the course. It was clear to me and to a lesser extent my students where we are now, and what is yet to come. I also hoped to use these 4 stages as the basis on which I would create semi-official certificates for my students. The idea was that every 1.5-2 weeks or so, the students did manage to achieve something very meaningful.
On completion of the first stage, the student managed to establish connection to a remote node on the Bitcoin network, and created key pairs and Bitcoin address.
On completion of the second stage, the student proved that he/she possesses a deep understanding of how Bitcoin transactions work. Things like how to hash a transaction, how to deal with TXID, how fees are determined, how (and when and where) signatures are used in the protocol and how the Bitcoin scripting language works. All of these gave the students a platform to create the bytecode for their own transactions (P2PKH and OP_RETURN).
At the time the third stage was completed, the students had managed to create their own block by creating the merkle tree and finding its root, calculating (mock) target, creating the blockheader and eventually finding the right nonce (Important note: I didn’t ask the students to create a coinbase transaction, although we did talk about it and examine its structure, but I believed adding another type of transaction will only serve to confuse them).
The final stage, the Ethereum stage, was in fact more of free working sessions. As I mentioned earlier, one of the requirements was that the students will have time to create their own dApps. Each student was working on his/her individual projects and as long as they managed to get their smart contracts to work, they managed to complete this stage.
(More details on my experience with the certification system in the coming articles).
So how did it go?
The first part of the course went rather smoothly, either because the students were still very eager to learn or because it was truly well constructed.
However, owing to some technical problems, I did not receive the certificates on time which placed me at a somewhat awkward position. Not only did I make a promise to my students that I’d give it to them, I was also quite worried that in the absence of something more tangible, they might not properly appreciate their own progress during the course.
This fear continued to be my shadow through the duration of the course as I tried to motivate my students to continue their hard and not so rewarding work. Right at the end of the course, I did manage to receive some documentation I could give my students and the response was very positive indeed. I’m now more convinced than ever that providing a proper certification at the end of each step can reduce much of the stress and hardship associated with such a demanding course. As a matter of fact, one of the major decisions I made at the end of this course was regarding certifications.
There was a major criticism I received during the course in relation to the course structure. A good number of the students, while not showing any major problem understanding the granular topic of the day and implementing the codes did have a hard time seeing the bigger picture. The structure I created aimed to look at the blockchain from a very close distance while working with some of its finest components.
I did try to encourage additional “free conversations” in class, hoping that during these less formal chats the students will utilize what we learned But soon it became clear to me that the timing of these free conversations, their length and their focus (or lack of it), was quite counterproductive. Therefore, I needed to come up with more appropriate time slots for such informal class sessions, while making sure to be well prepared with case study in case the students will not be focused. . For example, it might have been productive to try and talk about SigWit during the transactions class instead of only at the end of the Bitcoin portion of the course, even though the students didn’t yet learn about merkle trees, blocks architecture and BIPs.
The students were vocal about their desire for me to focus more on the big picture. This was in addition to some external pressure placed on me to start working with the students on their own personal projects. All of these led me to the production of some minor (yet quite meaningful) changes to the structure, mid – course. Basically, the border between the third stage (Blockchain architecture) and the fourth (Ethereum) was less strict than I wanted it to be.
It is true I already planned to use the third stage as a transition stage (as mentioned above, a substantial part of the Ethereum architecture was glossed over by comparing it to the Bitcoin blockchain). I did plan to talk about Ethereum quite extensively at this point (Ethereum was supposed to be mentioned first at the end of the second stage- transactions stage- right when the students learned some standard pkScripts). I still wasn’t well prepared with a suitable road map to make this diversion from the predefined curriculum.
The final result was that the transition from Bitcoin to Ethereum was lacking at best, if not somewhat confusing. This experience, while being somewhat hard in real time, did help to solidify my own confidence in the structure of the course – at least in its higher level and I’m much less inclined to perform similar deviations in future courses.
Another veritable source of confidence is the progress many students showed. A small, yet substantial, part of the class came on board with little to literally zero experience in programming and blockchains. Yet, by the end of it, I did witness some highly impressive progress in their abilities and understanding while the more advanced students also managed to create some impressive codes, smart contracts and even to construct a few apps. Ultimately at the end of the day, that’s what matters the most.
A few months ago I was approached by the wonderful guys and girls from the Exosphere Academy with the offer to help them build a new blockahin course. They wanted to create a boot camp for people who are interested in blockchain, its implications and possible implementations. I liked the idea. For some time now I believed that one of the major obstacles for bitcoin, ethereum and other blockchain utilities to achieve their potential lies at the high learning curve new users and developers needs to climb. In this blog, and in other forums, I did my best to try and mitigate this learning curve and I was honored by the opportunity to construct a complete and cohesive course for other developers and enthusiasts.
After I took upon myself the task of creating this course, I was approached by a Brazilian magazine who asked me to describe how I became a blockchain developer. The result was the following article at carreirasolo.org. (The original article is in Portuguese). And right here is an English translation for all of those who’re interested in blockchain related carer.
The first time I heard about bitcoin.
Six years ago, I read a short article in a financial magazine about a new type of digital coin called bitcoin. Naturally, the article was completely misleading, which isn’t that surprising. At the time, nobody really understood bitcoin. I’m not even sure the article mentioned the word “blockchain”. But I will always remember this article and how I just skimmed it and completely disregarded the idea as just another scam – thus forfeiting my chance to become a millionaire by downloading a piece of software to my computer. A few years later, in 2012, when I was (slightly) older and wiser, I read another article about bitcoin, this time in a tech magazine. Although it wasn’t completely accurate, the article provided a great service to its audience. The reporter was not only informed about bitcoin, but he also put a lot of effort work into understanding his readers – their technical background and how well informed they were about economics, web architecture, computer science, etc. The result was the first ever bitcoin article I read that dealt with it in terms, analogies and examples that conveyed the actual ideas behind the coin.
After that, I was hooked. The protocol’s promise is one of the most ambitious projects I’ve ever encountered in the digital world. It’s not just another cool app, video game or social network where we can show off pictures to our friends and family. Bitcoin challenges us to literally rethink, remodel and rebuild some of the most central elements of human society – from financial systems, government bodies, bureaucracies, health care, sources of information and much more. All of these can benefit from implementing at least some of the tools presented in the bitcoin protocol. I knew that I wanted to be a part of it.
Initially, I didn’t have much coding experience. At the time I was finalizing my BSC in chemistry and environmental studies. I wrote some very basic Java code to help me in my work, but nothing more than that, so I knew I had to work on my coding skills – sooner rather than later. I decided to study Python for many reasons: it was easy to use, well documented, and already had a (relatively) large selection of bitcoin-related libraries and implementations. I was actually amazed at how well it went. Python turned out to be an extremely easy language to learn, but what was even more encouraging was that while learning the basic concepts of the programing language, I also gained many valuable insights into computer architecture and protocols. All this was very useful when I tried to figure out how Bitcoin worked.
By the time Vitalik Buterin – who, by the way, was already highly respected In the bitcoin community – introduced his vision for Ethereum, I was already head over heels into Bitcoin and blockchains. I found the approach presented by Vitalik very compelling and promising, and I discovered that by learning how Ethereum works, I could enhance my own understanding of the bitcoin protocol by comparing the similarities and differences between the two.
The big leap
Meanwhile, I started to work on my Master’s degree and took few more advanced courses in algorithms and machine learning to amp up my computer skills. But I wasn’t pleased with the courses. The level at which we learned was high, no doubt about that, but none of the courses offered me any truly useful tools to work with. So I started to study by myself again.
I looked into assembly code, which helped me a lot in my understanding of the Ethereum Virtual Machine (or EVM for short). At this time, I decided to take a leap of faith and turn my passion to blockchains into a full-time career. At first, I started by creating simple videos that explained the basics of bitcoin. Then I showed some implementations for key features using Python. The initial exposure I received was very modest – but it did the job, and almost immediately I started to receive calls from professionals from a variety of industries who asked for my help and advice. Many of them wanted to use the power of bitcoin and the blockchain in their respective industries, and I was thrilled to be at the epicenter of such a great revolution in so many different and unique fields. Many of the people I worked with were genuinely looking for ways to revise their services and models to accommodate the needs of the 21st century. Many have the potential to empower millions (if not billions) of people in developing countries that might finally get direct access to many of the services we take for granted, like banking, medical insurance, pensions, legal frameworks to settle disputes, transparent government … the list goes on and on.
In the meanwhile
Blockchain architecture and computer decentralization is really not the scary thing most people think it is. The protocols are quite well documented, and once you’ve made some mental leaps, it will all start to make sense. You just need to learn it in steps. First, you need to understand what really sets blockchains apart from many other solutions. Then, using some basic coding and IT skills, you can easily familiarize yourself with many of its features and inner workings. The next step is to create some basic code that mimics a few of the more common blockchain-related features. Finally, putting it all together, you can start to create your own blockchain applications and decentralized solutions.
I’m biased. I’m in love with the vision that Bitcoin, Ethereum and blockchain architecture bring to the world. My fingers itch, and my appetite is insatiable. For years I’ve been working diligently to see this revolution spread from the computer geeks and mathematicians to the masses, where it’s really needed. So you’d better take my enthusiasm with a pinch of salt and look for the many blockchain-related projects that will now start to grow – and watch how they’re planning to literally change our world. Then you’ll feel the same way I do. I’m sure of it!
Whenever a user deploys a new contract to the Ethereum blockchain, that contract receives its own Ethereum address.
User 0x0a Deploying contract Reclaim –> contract address 0x0a1
As it turns out, these contract addresses ARE NOT a random address. The address of every contract we’ll deploy depends on two parameters:
The Ethereum address from which the contract is being deployed.
The nonce of the transaction.
What do we mean by nonce
The nonce of the transaction! Not to be confused with the nonce used in the mining process. In Ethereum, every transaction have a nonce associated with it. The nonce is one of the tools that helps to index and process transactions in the right order. The nonce itself IS NOT a random value. It grows by scalar one with every transaction we transmit to the blockchain. For the Ethereum test-net, the nonce begins with 0x100000 (1048576).
Calculating the new contract address
The new contract address can be computed in the following way:
I can continue this way on and on till I cover all the address space for the sender address.
What does it mean?
The first thing I did was to try and send transactions to future address. I sent 0.01 Eth from 0x43cc... to 0x7d47... (nonce = 1048584. You can use the code above to calculate the full address). The ether was sent without any problem. I can easily send the ethers to any valid ether address. The ethers, of course, can’t be reclaimed at this point since there’s no private key or code that is associated with that address.
Then I tried to deploy a contract to a particular pre-determined address (0x7d47...). I’ve used a basic meteor app with web3 library to deploy the contract.
The contract is a simple contract that allows reclaiming the ethers stored at the address 0x7d47....
address public owner = msg.sender;
And I’m happy to say that the experiment went smoothly. As long as when deploying the contract to claim the coins, the nonce is set so that utils.mk_contract_address(sender address, nonce) = required address, the coins can be reclaimed!
That made me think about few ways in which this trick can be utilized. From sending funds with higher anonymity to issuing assets and token BEFORE their contract code was even completed and I guess there’re much more options.
But there are limitations
Since the nonce is correlated with the number of transactions (and increases by one with each transaction) we need to make sure that when we deploying the Reclaim contract, we’ll do so when the next nonce matches the required address. otherwise we might lose our window of opportunity and the coins might be lost forever! When I tried to send the coins and then claim them back using a contract with a too high nonce, I failed to do so. It seems that the transaction stays in the transactions pool for 50 blocks, if by the time 50 blocks have passed we won’t transmit enough transactions to cover the gap in the nonce, our transaction will be dropped out.
nonce1 = 1048578
nonce2 = 1048579
***This gap needs to be filled within 50 blocks or the transaction will be dropped***
nonce150 = 1048728
nonce151 = 1048529
Transaction part one – The misconceptions about the block chain
The are three level to understand the way the Bitcoin block chain works.
In the first level, we got those who just heard about Bitcoin for the first time. People usually thinks that the coins are just associated with the Bitcoin address. Whenever Alice sends Bob coins, she just place a statement (or transaction) in the block chain specifying that the X coins that were associated with Alice address, should now be associated with Bob address. This is of course wrong since this representation contains only 3 thing: the sender address, the receiver address and the amount of coins to be transferred. But this level of abstraction is usually the first thought most people have when first presented with the idea of the block chain.
In the second level, people starts to understand that each transaction also contains the origin of each coin. So if Alice wants to send 5 BTC to bob, she first needs to show where she got these 5 BTC from, That is, she also needs to provide a way to point to older translations on the block chain, transactions which proves that Alice is indeed the rightful owner of these five BTC. So now what we have starts to look more like a chain. It’s no longer just a table containing the address and the current BTC balance, rather the block chain needs to contain a list of all previous transactions. This depiction is more accurate, but still it isn’t complete – introducing the third level.
In the third level, people learns that a transaction is more then just a simple statement in the block chain. Transaction contains more then just information about the origin of the coins (the input), the address of the receivers (the outputs) and the amount of coins to be transferred. Rather, the transaction also contains a riddle in it, and only by solving this riddle, can the coins be claimed and transferred. So when Alice send 5 BTC to Bob, she doesn’t only pointing at the transaction from which Alice got the coins, it also solves the riddle specified in that transaction to prove that Alice is allowed to claim those coins, but that’s not the end of it, in the transaction that Alice publish on the block chain she’s also inserting another riddle, a riddle that only Bob can answer. So if Bob would like to use this coins in the future, he’ll have to solve that riddle which was provided to him by Alice. And the process goes on and on and on.
I love riddles! Or, how to solve the riddle and prove that I’m allowed to claim the coins?
A quick reminder. Signing messages and key pair.
In the previous post we’ve talked about mathematical trapdoors and hashing functions. We’ve saw how we can use these types of function so sign a message with a private key and how these signed message can be verified with the corresponding public key.
F("My name is Alice", Alice's_private_key) = signed message.
Verify(signed message, "My name is Alice", Alice's_public key) = true.
Change any component in the Verify statement, and we’ll receive false. This way we can easily prove that the message “My name is Alice” was indeed signed by Alice and that no one tempered with that message.
Pay attention! We cannot sign a message with the public key, it simply wont work! the public key can only be used to verify a message, not to sign it!
So, Alice can now publish a message in the block chain that contains the input (origin of the coins) and the output (the address of the receiver). This is the original message, public for anyone to see and check as he or she pleases. Alice can also now specify the following rules in that public message:
This message is the original message.
Within this message I’ve included Bob’s_public_key (In hashed format – We’ll get there in a second).
Take your public key and hash it. If your hashed public key matches the hashed public key from step 2, you may move to the next step.
Take this original message, and sign it with your own private key.
F(This message, Bob’s_private_key) = signed message.
The signed message should be verified only against the public key that is specified in this message.
Verify(signed message, This message, Bob’s_public_key) = true.
If the verification indeed yield true, you may claim the coins in this transaction
So basically, knowing Bob’s Bitcoin address is equal to knowing Bob’s hashed public key. All we need to do is to convert the address back from base 58, and remember that out of the 25 bytes of the binary address, we need to omit the first byte and the last 4 bytes.
Scrips – the beginning
As we’ve already saw many times in the past, Bitcoin message is no more then a string of bytes that follow a predefined order. That means that in order to specify conditions and rules like the one Alice is using in her transaction message, we also need all parties to agree on a predefined field that will contain the conditions, and we also need to agree on a way to translate the bytes in that field into a set of rules, or instructions. For this purpose, a scripting language was created for Bitcoin, this langue allocate predefined operation to a predefined byte. For example, the byte 0x8b means “plus 1”, the byte 0x8c means “minus 1”, the byte 0xa9 means “hash the public key. First with SHA-256 and then with RIPEMD-160”, and so on. There’re many more of these operators (also called OP-codes) and these OP-codes helps us to specify the rules that needs to be fulfilled. These rules are transparent and are publicly visible on the block chain. Whenever a node verify a transaction, the nodes follows these rules and make sure that they eventually do yield a true statement.
We’ll talk more about these OP-codes and scrips in the next sections, when we’ll also see a real example of valid transaction script.