Browsed by
Tag: blockchain education

How to be blockchain compatible. part one

How to be blockchain compatible. part one

Tl;dr: Don’t try to move your existing organization to be a “decentralized/ blockchain based” look at the cases in which your organization might implement some blockchain based solutions and start making the necessary changes in-house to allow future integration.

Seeing how new technologies are changing our world, and change it fast, makes many entrepreneurs twist and itch. It’s in the blood of most of them to try and incorporate this new technology as soon as possible. However, most are failing to properly understand what the blockchain (it’s more than just a chain of blocks) is and how it can affect their organization. Many want to completely redesign their business model and organization architecture to migrate entirely to the blockchain.
I find this approach to be counterproductive (and in most cases, outright ludicrous). Instead, I’m trying to help them to consider the need of their business, to map their current application and its architecture and to educate themselves on what the blockchain really is, and what it isn’t. Then we can look at ways in which existing organizations might make their systems more compatible with current blockchains. That way these organizations are both going through and internal (and valuable!) process of learning how to work with the blockchain, create a list of cases in which the blockchain might be beneficial to them.

In the next few posts, I’ll expand on it and try to give a general review of how a business owner might start remodeling their systems to be blockchain compatible.

The Database. Part one.

Many considering the blockchain storage features to be similar to those of a legacy database systems. However, the blockchain differs from such architectures in many aspects. In this article, I’ll try to give a general review of the things legacy databases and blockchain have in common, and of course, of the things that separate them from each other.

  1. Writing and reading is extremely more expensive than in legacy systems
  2. The array is an append only array. That means that data cannot be delete or update
  3. Most current languages cannot work with blockchain
  4. A substantial amount of the information stored on the blockchain is irrelevant for most users

Study case

Let’s consider the following case. A social network app wants to migrate its database onto the blockchain. That social app probably contains a multitude of data entries. Our social network app might be using a rational database (must commonly SQL), or non-rational database (NoSQL).

If our app uses a rational database, it might look something like this:

Table – users:

User id User name User email Number of articles published by user
1 Shlomi Zeltsinger [1, 5]
2 John Doe [2,3,4,6]

Table – articles:

Article id Created by user id body title
1 1 Story number one Good title
2 2 Story number two Better title
3 2 Story number three Best title
4 2 Story number four Excellent title
5 1 Story number five Stolen title
6 2 Story number six Bad title

In the case of NoSQL database, we will have the following structure:

Whenever our social app wants to update its legacy database, it uses the TRANSACTION.

      INSERT INTO articles VALUES (
                  7, # Article id 
                  1, # User id
                  "story number seven", # Body
                  "title number seven" # Title )

Transactions in this sense have the following four characteristics:

Atomicity − ensures that all operations within the work unit are completed successfully. Otherwise, the transaction is aborted at the point of failure and all the previous operations are rolled back to their former state.

Consistency − ensures that the database properly changes states upon a successfully committed transaction.

Isolation − enables transactions to operate independently of and transparent to each other.

Durability − ensures that the result or effect of a committed transaction persists in case of a system failure.


Now let’s see what a transaction in the meaning of the blockchain is. First of all, it does possess some of the characteristics described above. Each transaction is atomic – either it was valid and accepted into a block, or it’s not. There’s no gray area. Each transaction is also isolated from the other, at least when looking at systems like the current Bitcoin and Ethereum blockchains (Some advance research is done on a new architecture that might change this propriety a little). Also, once a transaction was accepted to the blockchain, its effect is durable, and even if my own personal server falls, the result of that action is still available.  When it comes to consistency, transactions that are transmitted to the Bitcoin/Ethereum network will be verified and examined using various tools (scripting language, cryptography, EVM) that force consists result across the network.

So, if all four characteristics are the same, then what’s the difference?


Some of you might have looked at the above example, the one in which we’re adding article number seven, and asked yourselves “what is going to happen to the user’s table”? We specifically asked to update the article table, but now – the user table should also reflect the changes made (now user id 1 have 3 articles [1,5,7] ). To update this field, we’ll either add the command UPDATE to our TRANSACTION code:

      UPDATE users
      SET articles = [1, 5, 7]
      WHERE user id = 1;

Or transmit this UPDATE command as a second transaction. In both cases, we’re adding extra work to our database both in computational cycles or in physical storage place (now we need to store the number Three in out database). But in the case of Bitcoin and Ethereum, we’re using the blockchain to store the information, and we’re asking the other nodes on the network to validate our transactions constantly. And this has a much higher price than doing so locally.

How high? Well, in the case of Ethereum, every 256 bit that is stored, requires 20K of gas unit (that’s the minimum storage space for words). At a current gas price of 0. 00000005 Ethers per 1 gas unit that amounts to: 20,000 * 0.00000005  = 0.001 ethers per 1 Byte.

Therefore storing one kilobyte will cost you: 0.001 Ether * 31 = 0.031 Ethers.

At current market price of 350 USD per ethers, that means that one kilobyte of data should cost 10.85 USD. That’s 10,850,000 USD for one Gigabyte.

Bitcoin prices aren’t much more competitive. And what is worse, currently each transaction cannot contain more than 40 bytes of added information – our articles will be very short.

This raises the questions:

  • What type of information should be stored on the blockchain? Will it be more cost effective to reconstruct some of it on demand? (For example, whenever someone looks for the number of articles that were published by user number 1, the server will consult its own local copy of the blockchain, and count only the articles that were written by that user)
  • Can we index our array in such a way that two modification be efficiently made at the same time?

Variables state

The truth is that the information that is stored on the blockchain doesn’t look at all like the table shown above. The blockchain maintains a list of its valid transactions (in the case of both Bitcoin and Ethereum) and in the case of Ethereum only, a tree of states in which indexed variables are stored.

TX 1 Add user (1, “Shlomi Zeltsinger”,
TX 2 Add article (1, 1, “story number one”, “Good title”)
TX 3 Add user (1, “John Doe”,
TX 4 Add article (2, 2, “story number two”, “Better title”)
TX 5 Add article (3, 2, “story number three”, “Best title”)

The fact that the blockchain is a list of transactions and not a real scheme (table/objects) based database have some interesting implications. First, to interpret this list of the transactions to something of value to use, we’ll need to parse the blockchain and reconstruct our database from scratch.

Someone would need to sit with a pen and paper, read through the list of the transactions and write down the desired information.

For example, if we’re looking for all the articles that were created by John Doe, that someone will first have to look for a transaction that begins with “add users” and contains the name “John Doe” (tx3). When the right transaction was found, that someone will write down the user id of John Doe (2) and then he’ll need to look for all the transactions that begin with “Add article” and count only the ones that have that number that matches John Doe user id (2). Tedious work, no doubt.

In the case of Ethereum we’re giving an extra tool to help us a little. That is that instead of looking at one transaction after the other, we can look at the “state tree” (sometimes “state trie”) of each block. In Ethereum, once we paid the high fee of storage, each variable is indexed. Whenever a change is made to that variable, a new state will be added to the “state tree”. That means that by knowing the index of the said variable, I can find the said indexed variable.

This raises the questions:

  • Can we construct our transactions in a manner that will make it easier to read through?
  • Is it possible to “point” from one transaction to the other?
User id User name User email Number of articles published by user
TX 1 Shlomi Zeltsinger [TX 2, TX 7]
TX 3 John Doe [TX 4,TX 5,TX 6, TX 8]

Table – articles:

Article id Created by user id body title
TX 2 TX 1 Story number one Good title
TX 4 TX 3 Story number two Better title
TX 5 TX 3 Story number three Best title
TX 6 TX 3 Story number four Excellent title
TX 7 TX 1 Story number five Stolen title
TX 8 TX 3 Story number six Bad title

(Maybe instead of “User Id” field to identify user we’ll do better to point to the transaction at which the user was created?)

  • If were storing the information on the Ethereum network, perhaps it will be easier to treat it as objects (NoSQL) rather then as information that should be stored in rational tables?

Append only

We just saw that both Ethereum and Bitcoin, maintains a list of ALL of their transactions and that we can reconstruct our database by following each transaction. One after the other. As we know, once transactions make it to the blockchain, they stay there. That means that I have no way to change (UPDATE) the information that was already stored. However, by properly constructing my transaction, I can add a comment for future users noting a distinct change. For example, I can create a transaction for changing the user email address

TX 1 Add user (“Shlomi Zeltsinger”,
TX 2 Add article ( TX 1, “story number one”, “Good title”)
TX 3 Add user (“John Doe”,
TX 4 Add article (TX 3, “story number two”, “Better title”)
TX 5 Add article (TX 3, “story number three”, “Best title”)







TX 500 Update user (TX 1, email: )

Pay attention that now, if I want to find all the articles that were created by the user with the email just iterating through the “add users” transactions will simply won’t do. I will also be required to look for the UPDATE transaction.

This is a great example of a case in which the Ethereum state tree is far superior because once the user is indexed, I can check his or hers email by checking the state of that proper variables.

This raises the questions:

  • What can we do when a node isn’t fully synced. There might be some changes to the data that we have that we’re not yet aware of?
  • If John Dow will add a new article, should this article point to TX 3 or the newer TX 500?
  • Is all the data that is stored on the blockchain is relevant for us? How can we quickly identify the pieces of information that are relevant?

The blockchain probably isn’t the place to store your data. Yet.

As you can see, there are some major issues that need to be solved and considered before you could move your data to the blockchain. It is my recommendation for those who wish to arrnest its power to first try and mimic some of its working architecture principals in-house. Prepare your database both regarding design and structure and make sure that the architectural differences (and the reasonings behind them) clear to you and your team. That way you’ll in a much better position that will allow you to start and slowly integrate some of your business with either Bitcoin or Ethereum (or both) in a way that is truly advantages.

In the next parts, I’ll be talking about some specific codes and architectural tricks that will help us to implement some of the principles mentioned above.

The blockchain developer path – Blockchain at Berkeley

The blockchain developer path – Blockchain at Berkeley

Mapping the blockchain education ecosystem

When I created my first tutorials almost two years ago, there were very few educational resources about blockchains. The ecosystem was sorely lacking in good courses, tutorials and guides to ease the learning curve for newcomers. I remember the many days I’ve spent reading raw codes and technical documentation until I was finally able to manually connect to the Bitcoin network, create keys, sign transactions, etc.

But two years is forever in the world of blockchain, now many companies, universities, and individuals are flooding the market, offering their services as educators and validators.

The thing is that this ecosystem is still kind of a wild west. There are very little standardization and collaboration between different players in this ecosystem. And the final result is sub-optimal, both for those who wish to educate themselves and for those who want to work with them (future employers/potential business partners).

But fear not, I’ve taken upon myself to try most of the major courses available and to receive as many certifications as possible. And I’ve got some interesting insights on the right route an aspiring blockchain developer should take.

I the following posts I’ll review the following courses and certification process:

  • Princeton University – Bitcoin and Cryptocurrency Technologies. Available as a full course at Coursera
  • Berkely University – BLOCKCHAIN at Berkely.
  • Stanford University – Bitcoin and Cryptocurrencies.
  • Multiple Youtube channels and videos (including my own)
  • Book – Mastering Bitcoin: Unlocking Digital Cryptocurrencies by Andreas Antonopoulos (1st Edition)
  • Book – Bitcoin and Cryptocurrency Technologies by Princeton University (Draft version)
  • Udemy Ethereum: Decentralized Application Design & Development
  • Diginomics – Ethereum developers course (Created by myself more than a year ago)
  • IBM – Blockchain Essentials for Developers (Includes certification)
  • C4 – Certified Bitcoin Professional.



Made with love

Blockchain at Berkeley

From the oldest to the youngest. Blockchain at Berkeley was created just short of a year by a group of (mostly) undergrads from Berkeley University. Don’t let it fool you. The fact that these students are undergrads is nothing short of a plus for this program. It’s fresh, created with love, well paced, publicly available and highly recommended.

The full program is currently only available as a course (Academic credits) at Berkeley University. The program publishes its materials online. As I never had the pleasure of participating in the live program, my review refers only to what is available online.


The program structure – Beginners

The program website might be somewhat confusing at first. Some of the links are circulars, and it’s hard to find the main Education page. Pressing on the Education tab will circulate you between different live programs, workshops, and resources. The DECAL tab, which contains the (live) course assignments, reading materials, and webcasts is where you should start as it organize all of the material and resources in chronological order.

It’s my view that to understand the blockchain; one must first understand Bitcoin as it is the most researched, documented, robust and stable example of the blockchain out there. Berkeley does just this; they’re making sure that the students first understand what the blockchain Is, how it was created, how it works, and what it’s not, before moving to other implementations of the blockchain (mostly Ethreum, although hyperledger and zcash are also mentioned in later lectures).

The programs begin with the history of Bitcoin and digital money, moves to a high-level view of the protocol – from the consensus point of view and then gives a brief introduction to the crypto aspects of Bitcoin by introducing ECDSA. Once ECDSA is presented the lecture starts to get somewhat technical for many casual users (ECC properties), but not too technical that it might prevent those who are committed to start and understand how the concept of signing and asymmetric encryption. That’s by far one of the best examples I’ve seen for “mitigating the knowledge gap.” The terms are technical and well explained in a slow and forgiving pace without dummying it down.

The good work doesn’t stop with ECDSA. The next lecture: “Bitcoin Mechanics and Optimization” is another great example of how to teach some technical aspects of the Bitcoin blockchain such as double spend, transactions, and scripts (only P2PKH so far), Merkle trees, UTXOs vs. Accounts (Another great little detail that sets the foundations for the advanced Ethereum part of the program). All is presented in a professional, yet chewable way.

The program also provides an excellent top down review of mining, game theory and potential attacks. All was wonderfully constructed with a top-down view of all the relevant concepts and interesting and thought-provoking examples.  This part is also used as a bridge to introduce other blockchains (mainly Ethereum that is also the star of the next lecture)

Ethereum received only one lecture in this program, and that’s a shame. I feel as if the Ethereum lecture is the weakest one in the batch, but it’s evident that this is only due to the time limitation. The top-down review of Ethereum was good for the casual user/learner, but not on par with what the program offered so far. Many aspects of the Ethereum blockchain architecture and of the VM were completely omitted from the presentation. The decision to talk about the considerations in creating smart contracts was counterproductive, and the result is a jumble of terms and concepts that are explained in too much haste. It’s important to notice that there’s another presentation on EVM that wasn’t mentioned in the lecture

Once Ethereum is out of the way, the program focusses again on Bitcoin and presents many future ideas about it: Federated chains, switching hashing algorithm, PBTF and more. I mostly enjoyed the part about payment channels and lightning network which, together with Aaron van Wirdum’s Understanding the Lightning Network on Bitcoin Magazine, is the best resource for non-coder who wants to know how LN should work.


All of the lectures and presentations are available online at the DECAL tab. However, it’s clear that the presentations weren’t created to be a standalone learning material. It’s almost impossible to make much sense of them without watching the video, which is weird because the videos are no more than a live recording of the instructor, reading from the board. The class noises might be somewhat distracting, and it’s a shame that it’s impossible to hear the questions from the audience.


The program structure – Advanced

The materials in the DECAL tab are providing an excellent review of the blockchain with a mix of technicality and causality that can appeal to a broad audience. But for the more technical students, a more technical information is required. That is the WORKSHOP tab comes to play. Over here stored the more advanced presentations. Dealing extensively with the EVM, smart contract coding (Solidity), data architecture, math, etc.

However, as mentioned before, it’s clear that the presentations weren’t meant to stand alone. Someone needs to explain them. And unfortunately, the workshop doesn’t contain any videos. That makes most of the workshop material somewhat useless for students (but an excellent resource for educators/teachers).

Another great aspect of the program is the “Whitepaper circle.” Once in a while, the students upload their technical review of a relevant whitepaper. The videos are highly recommended.



Unfortunately, it’s impossible to participate in any way in the program (unless of course, you’re currently in Berkeley). It might have been nice to have a forum/slack for the program. I’m sure many would’ve appreciated the ability to interact with the other students and instructors directly.


Assignments and Certification

As mentioned before, there’s no way to interact with the program. You cannot participate in any way. No assignments, no certification. Only nothing. Shame.


Final thoughts

Blockchain at Berkeley was created by a group of enthusiasts undergrad students – and that only means good things about the taught material. Concise, useful, up to date, and the precise blend to appeal both to highly technical and to the more general audience.

The fact that this program was created almost as an independent side project of the said students is noticeable in its presentation. The website and presentations are beautifully done but poorly integrated into a coherence experience. I understand that when something as useful as this is giving to the public for free, it’s almost rude criticizing the way it is wrapped, but I feel as is the creators really did wanted to have something useful – a place for developers from all over the world to learn the secrets of the blockchain – the love and effort is evident to see, but in order to achieve it, some work need to be put into packaging the program.

Final note – The best program out there for technical people (coding is not a must) who wants to really understand what the blockchain is. A bit hard to find your way around it – but worth it.


Commit yourself to this program if: ·       You’re a tech-savvy person taking is first steps into the world of blockchain AND willing to put some effort into understanding the technicality of it.
Time to complete the course: ·       Thirteen weeks. Previous classes are all available on youtube and can be watched in one go
Interaction: ·       None. Too bad

·       YouTube channel. Contains all lecture videos and some whitepaper circle videos.

·       Presentations

·       Some code examples from the workshop

·       Their resource page is also worth checking out

Certification: ·       None. Too bad


The blockchain developer path – Princeton University – Bitcoin and Cryptocurrency Technologies

The blockchain developer path – Princeton University – Bitcoin and Cryptocurrency Technologies

Mapping the blockchain education ecosystem

When I created my first tutorials almost two years ago, there were very few educational resources about blockchains. The ecosystem was sorely lacking in good courses, tutorials and guides to ease the learning curve for newcomers. I remember the many days I’ve spent reading raw codes and technical documentation until I was finally able to manually connect to the Bitcoin network, create keys, sign transactions, etc.

But two years is forever in the world of blockchain, now many companies, universities, and individuals are flooding the market, offering their services as educators and validators.

The thing is that this ecosystem is still kind of a wild west. There are very little standardization and collaboration between different players in this ecosystem. And the final result is sub-optimal, both for those who wish to educate themselves and for those who want to work with them (future employers/potential business partners).

But fear not, I’ve taken upon myself to try most of the major courses available and to receive as many certifications as possible. And I’ve got some interesting insights on the right route an aspiring blockchain developer should take.

I the following posts I’ll review the following courses and certification process:

  • Princeton University – Bitcoin and Cryptocurrency Technologies. Available as a full course at Coursera
  • Berkely University – BLOCKCHAIN at Berkely.
  • Stanford University – Bitcoin and Cryptocurrencies.
  • Multiple Youtube channels and videos (including my own)
  • Book – Mastering Bitcoin: Unlocking Digital Cryptocurrencies by Andreas Antonopoulos (1st Edition)
  • Book – Bitcoin and Cryptocurrency Technologies by Princeton University (Draft version)
  • Udemy Ethereum: Decentralized Application Design & Development
  • Diginomics – Ethereum developers course (Created by myself more than a year ago)
  • IBM – Blockchain Essentials for Developers (Includes certification)
  • C4 – Certified Bitcoin Professional.

Princeton University – Bitcoin and Cryptocurrency Technologies

The oldest one still open to the public

Princeton University created one of the first blockchain courses out there, and because of that, they are the first one to be covered in this series. The course is offered since early 2015 (Some of the videos were created in mid-2014). The course is instructed mostly by Arvind Narayanan, Assistant Professor at Princeton computer science department, with few guest appearance by Joseph Bonneau, PostDoc at Princeton, Prof Edward W. Felten, Professor of CS and public affairs at Princeton University.

The course is publicly available on the Coursera platform, and while it might seem as if there is a time limitations, a new class starts every week. Princeton also offers to the public its book “Bitcoin and Cryptocurrency Technologies” (the draft version is free) that follow up the course nicely.

The course is divided into 11 weeks. All weeks are available since day one and there’s nothing that stops you from going through all of the course in one go. Each unit contains few videos, with a simple quiz at the end of each video. You don’t have to solve the quiz to complete that lecture. You’re free to watch the lectures in any order you might want. You don’t have to watch all the videos in order to complete the course.

In order to complete the course, you’ll need to complete three programming assignments.

Course structure

The first three weeks are dealing with the basic aspects of Bitcoin and the blockchain.

It starts by exploring the hash function, and continue to data structure where the hashes are keys. The concept of DAG is hinted in the videos but isn’t entirely covered although Merkle trees are mentioned. A simple Introduction to Asymmetric (Key) cryptography is given but in a very shallow way. ECDSA is also mentioned – ECC is almost completely ignored. RSA isn’t even mentioned. The first week ends with a demonstration of mock cryptocoin (Scroogecoin, we’ll get to that soon).

In the second week, we’re giving a simple introduction to some concepts of decentralization and return to hashes in the context of POW.

The third-week deals with transactions in Bitcoin. The first couple of videos deals with P2PKH and P2SH transactions. The first video also introduce many concepts that are relevant to Bitcoin transactions (UTXO, scripts, inputs, etc.) Scripts are then explored in greater detail. I find the scripts part to be quite well explained. This week ends with an introduction to the concept of blocks and the basics of networking architecture in bitcoin.

All in all, I found the first week to be the weakest in this batch. While the jargon used is aimed at people with background in computer science, many terms were merely glossed over. It made it hard to determine who the course is aimed at – beginners? Individuals with background in computer science? Mathematics? Also, the first assignment (Scroogecoin) requires the students to continue watching all the lectures in week 2 & 3 before being able to solve it. I believe that students taking the course for the first time might try to complete the assignment before moving on, which is another source of frustration.

Week number 4 is kind of stand by itself as it deals mostly with how to store and use bitcoin by looking at wallet types, exchanges and so on. The jargon in this part is more mathematical/technical then week 2-3. Some of the material feels somewhat outdated, but other parts like the way to split and share keys and fees calculation were quite simple and satisfying. However, seeing as most topics during this week might appeal to the more general user, one with little to no background in CS or another related field, I find the return to the more technical jargon being quite counterproductive.

Week four also ends with another assignment. As before, this assignment can’t be solved just by watching the lectures, but I guess that by now most students have already realized it, and won’t postponed watching the rest of the lectures for a time after they’ve managed to solve the assignment.

Week 5 – 11 deals with many different aspects of Bitcoin. Mining, anonymity, legal, and bitcoin as a platform. Each lecture is good by itself as a mean of introducing the students to the basic concepts, but it never goes further than that. In that regard, I see little value in following the structure of the course. It would have been better to just provide the students with a simple glossary/list of topics to cover with links to external resources. Still, some of the lectures were highly enjoyable. In this units I’ve enjoyed the lectures on mining algorithm, which starts to show a simple introduction to the way the hashing functions work, the zerocoin introduction was also useful in providing the foundations for newcomers. Bitcoin as an append-only log especially resonance with my ideas on the blockchain and its use case.

Week 7 (deals mostly with the inner politics of Bitcoin) ends with the last assignment that the students are required to submit. Once again, the assignment has little to do with the lectures themselves.

The assignments:

As mentioned before, the course contains three assignments. All three are in Java and deals with validating a transaction, validating a block, and reaching consensus.

This three task represents a substantial part what is required from a bitcoin node. All three are graded by the use of very impressive test engine that runs multiple test cases on your code and validates the results. The amount of effort placed in creating these assignments is visible and because the course is giving for free, online, and bears the Princeton University name with it, makes these assignments even more valuable.

Which makes it even harder for me to say the following. While I can appreciate the effort putting into these assignments, they feel much more like homework on Java and OOP with a Bitcoin “theme” than a real Bitcoin coding exercises.

The first assignment requires the students to prove some understanding to the way Bitcoin transactions are validated and chained to each other. This is the most Bitcoin-related assignment of them all as it requires some understanding of how bitcoin transactions work. Still, at the end of the day, the real task here is to create an algorithm that will return a specific set of valid transaction and it feels as if a substantial part of the time placed into solving this assignment is spent on recursive loops and working with sets and hash tables rather than working with more aspects that are unique to bitcoin.

Assignment 2-3 were completely off. The second assignment required the students to reach a consensus between nodes in a way that has nothing to do to with how blockchain works. This assignment feels like a pure algorithm task. It’s clear that the creators of the assignment thought carefully about it and worked hard to create fair and interesting tests. After all, more than one algorithm can be implemented to reach a consensus. But at the end, it turns out that the task can be solved by using a ridiculously simple algorithm. I could almost imagine the creators of this assignment slap themselves on the back for managing to create assignment so well though that it can be tested and passed by multiple algorithms with a variety of complexity levels. It is impressive, but have very little to do with the way bitcoin works.

Assignment three starts to focus again on Bitcoin. It requires the students to validate blocks and constructing the blockchain. This assignment is somewhat more realistic and more connected to the way Bitcoin works. But it still requires the students to spend to much time constructing classes, methods, loops and sets – and too little time to really understand how the blockchain is constructed.

The assignments can be submitted as many times as you like, and I highly suggest to try and submit even half-baked codes. The automated grader will run the test engine on your code and might provide you with some interesting insights regarding your codes. For the “less honest” students out there, the code for the test cases (and more) is just a short google away.

The grader engine provides useful information. You can resubmit your files as many time as you like

The course forum

The course has a forum which goes all the way back to 2015. It’s not limited just to the current course timeframe. In this forum, some interesting discussions are taking place, and I highly suggest to join the course if only to read some of the conversations taking place there. These forums also contain a lot of information regarding the assignments which I also suggest looking into.

Graduating and certifications

The course can be completed by submitting the three assignments and receiving a grade of 60 and above. There’s no need to watch all the videos or taking the quiz at the end of each video to complete the course. The assignments can be submitted as many time as you like so that you’re giving the chance to improve your grades.

Upon completion, you’ll receive an email congratulating you for completing the course. You can also verify your identity at Coursera by uploading your current photo plus an office identification (passport or driver license). Once Coursera verifies your identity, you can share your achievement online on Facebook, Linkedin, etc.

The certification issued by Courera and doesn’t bear the Princeton Univesity name. Knowing that the course is free, the assignment has little to do with Bitcoin (and can be easily cheated), this certification carries little to no weight.

You can share your achievement online. No other recognition is provided

Final thoughts

The beginning of the course (weeks 1-3/4) is its the weakest part. Students who want to understand how transactions, keys, hashing, POW, etc. works, will be better to look for it in other places. After that, the course becomes somewhat less technical. This is a welcome change as it allows it to provide a basic introduction to many different aspects of the blockchain.

In this regards, when ignoring the first few weeks, this course might appeal to students who already understand some of the basic concepts of the blockchain and Bitcoin and are just looking for a good source to review as many aspects of it. Each video is no more than 20 minutes. And the list of topics that are covered is quite impressive.

The assignments are wonderful as an exercise in Java and OOP but provide very little extra value for those who are interested in the blockchain. It’s obvious that one can pass the course just by utilizing his/hers experience in OOP while having little understanding of the Bitcoin works.

Completing the course can be achieved in a single day if one chooses, and being able to share your achievement online is a nice bonus, especially when Princeton University is mentioned.

Take this course if:

·       You understand Java and OOP

·       Have some backgrounds in how bitcoin works regarding transactions, keys, blocks, etc. and want to enrich your knowledge of other aspects of it

Time to complete the courseYou can complete the course in one day or eleven weeks. It’s up to you
InteractionThe course forum contains some interesting conversations

·       Videos mostly

·       The draft of the book Bitcoin and Cryptocurrency Technologies si also available

·       Three programming assignments

CertificationYes, limited. Provided by Coursera for those who complete the three assignments
Certification, The ends justify the means.

Certification, The ends justify the means.

The wild west of certificates

Blockchain education is a growing ecosystem with very few players. Most courses and training programs are trying to create their certification program, tailored specifically to their self-construct program. This is a major issue for anyone involved in this field: the students, the course/program instructors and creators and future employers/customers.

My experience in this ecosystem has let me consider few approaches regarding certification, especially my eight weeks live course which provided me with numerous insights and made me examine ways to evaluate the topics that the students are learning/need to learn, the exercises that they’re performing and the benchmark on which they’re tested.


The basic badge system I created for my course

Knowing that there’s a lack of standards in the ecosystem, I decided to create a badge system that will provide my students with some tangible results that are not necessarily tied to the course itself. If a student wants to prove to a future employer his or hers achievements, they can just show them the codes they’ve created and/or the transactions they’ve pushed to the Ethereum/Bitcoin blockchain.

Having that in mind, I created a certification system that was aimed to draw the students to achieve a specific goal. A goal that was set at the end of 4 “progression trees” where each tree was build to reflect the chronological/difficulty order in which the course topics should be taught.

The four trees are:

  1. Establish a connection to remote Bitcoin node –  Understanding the basics of working with the Bitcoin network.
  2. Transmit a Bitcoin transaction (p2pkh and op_return. p2sh transactions were considered for bonus) –  Mastering the concept of transactions, scripts, op_codes, utxo, fees, inputs/outputs, etc.
  3. Create a mock Bitcoin miner (build a mock block) – Consensus rules, Merkle trees, proof of work, difficulty/targets.
  4. write and deploy Ethereum smart contract.

However, while I’m highly confident that having a final product to show for is more valuable than (most) current certifications, I did want to provide my students with some more “traditional” certification, but still, one that directly reflects the students’ accomplishments.

The badge system as a map

The badges I created were used mainly as a top-down map helping the students (and myself) to keep track of our progress during the course and in that they’ve achieved their goal. However, these maps, being the top-down maps they’re didn’t gave much in what is it that the students actually know from a technical point of view (the codes that they’re using, the tools, the mathematical background, etc.) and in that regard, they’ve lost a substantial level of depth that might’ve been useful for potential future employers. At the end of the day, it’s not just enough to provide proof that you’ve managed to write and transmit a transaction to the Bitcoin testnet, it’s also important to have proper documentation on how you did so.

Another thing that was somewhat lacking is the finer way to assess students progression during each step because the final goal was the primary benchmark on which the students were tested against. If a student managed to reach the goal, he received the badge – no matter how he or she got there. Without going into the fairness of the process (Which btw, I consider entirely fair), it’s important to create a way to also evaluate students proficiency in each step leading to that final goal. This is particularly the case when not all of the steps are equally important in academic terms (e.g., If the goal is to create a mock block, then understanding how to build Merkle trees and finding their root is more important than just populating the block header, especially when we’ve created protocol messages in previous classes).

Another thing to consider is the importance of the tools that were used in the process. Creating, signing and transmitting a transaction is, of course, a great way to prove ones’ proficiency in Bitcoin and blockchain in general, but it is hugely different between doing so using JS libraries, python code with ECDSA and C. And the trees I’ve created don’t reflect that.


Open call for the ecosystem

At the end of the day, it all boils down to the fact that there’s very little cooperation between different blockchain educational institutions – both with each other and with the rest of the ecosystem. That leads to multiple certifications being issued without properly addressing the need of the rest of the ecosystem, and of the students themselves.

Those who are working on educating young programmers and developers should aspire to achieve a standard working conventions on which to build their courses. They should create a uniform benchmark on which to examine the student’s knowledge and a clear way to present it to future employers in a way that is meaningful. Claiming that the student completed course ETHD-15 should carry some extra information for future employers. They should know what is that the student learned, what tools did they use, how was the student tested etc.

I’m currently working to better define the topics that required from each type of developer/programmer, and the ways they can prove their skills in that topics and I hope that more will join me in this effort.

ICO – Simple. Too simple.

ICO – Simple. Too simple.

important notice, please read!

This post blog is for educational purposes only. Solidity and Ethereum are bleeding edge technologies and should be treated with respect. Make sure to properly educate yourself before attempting to implement any code you might find online. I can attest that the code provided here is without a doubt not secure. It’s (at the very least) susceptible to overflow attacks, short address attacks and transferFrom double spend attacks. This is actually a very good example to my point because, while being open to such attacks, my code does adhere to the ERC20 standard. Use this code to get yourself familiarized with the basics, and then keep on learning.


All that glitters is gold.

As of April 2017, there’re 161 ICOs listed on TokenMarket, one of the leading token platforms. Of these 161 ICOs, 118 were still active. Almost every new company in the blockchain ecosystem choose ICO as its main source of fund raising.

Offering shares in the form of coins is a great way for raising funds and for potential investors to invest in many of the new and exiting new projects out there. But here’s something most don’t know: Most ICOs are nothing more than copy-past of the same code that was used in a dozen of previous ICOs – AND RIGHTFULLY SO.

The reason the same code is used again and again (with moderate variations) lies at the fact that this code was developed and tested by professionals, and it provides many useful features both to the creators of 3rd party apps (like wallets and exchanges) but also to the end users, who can be somewhat assured that the tokens they’ve just bought can be used and exchanged with relative ease.


So what’s the problem?

It seems as if many of these companies also promise (or at least gives the vague impression) that the coins that they’re offering represents a substantial part of the final product. “Buy PizzaCoin at only 57 PZC per 1 ETH and you’ll be able to use these 57 PZC in our PizzApp store.” This promise alludes to the fact that such smart contracts/apps are already developed (or at the very least are in a finale stage of development). Which is usually not the case. While I can understand those who buys tokens in the hope that in the future they might be worth more on the market (speculates) I also believe that a substantial part of the investors in ICOs hope to utilize these coins in their respective apps. They just don’t know how generic the coin really is.

Also, many of these generic contracts sometimes issue coins in a rate that has very little economic reason behind it (what does it mean to get 57PZC? Is that mean that each coin will be equal one pizza in the future? Will the price of future pizza will be determinate in a coin exchange? How do you calculate the cost of operating and maintaining a smart contract that doesn’t exist yet?).

I have absolutely no doubt that many companies actually using the raised funds in a responsible manner. They’re working hard to deliver a real final product, and I’m sure that there’re also many investors who understand that these ICOs tokens are usually nothing more than a financial assets (at least at this early stage) and the fact that they’re issued using a generic contract is not a surprise to them, but there are many others who don’t. And for them, I dedicate this post.

I hope you’ll find it useful.

ERC20 Tokens


Step one – Secure operators

Ethereum Virtual Machine (EVM) is susceptible to overflows and memory offsets. Fortunately, that can be solved quite easily by implementing some simple function to perform basic operations. Zeppelin team provided us with the SafeMath contract that provides us with the functions safeAdd, safeMul, safeDiv, safeSub and assert (The other functions are not relevant for this tutorial). Using the assert function, the SafeMath functions results are checked to make sure that they adhere to what is expected of them. For example: The function safeAdd receives two unsigned integers (a, b) and sum them together to get the result c. While both a and b are uint (not negative numbers) there’s still a chance that due to an overflow, the final result c will be lower than the sum of its components. That’s why the SafeMath function also checks to make sure that c is indeed larger then a.


Step two – ERC20 functions signatures

In late 2015 Fabian Vogelsteller, one of the mist wallet developers, suggested the creation of a unified token template called ERC20. The idea was that by providing a unified architecture for tokens – wallets creators, exchanges, and other service providers could produce a product that will support these token right out of the box, without having the need to recreate a unique wallet for each new token that is issued over the Ethereum protocol. It was suggested that the following functions will become the standard for every new token contract.

function totalSupply() constant returns (uint256 totalSupply) {}
function balanceOf(address _owner) constant returns (uint256 balance) {}
function transfer(address _recipient, uint256 _value) returns (bool success) {}
function transferFrom(address _from, address _recipient, uint256 _value) returns (bool success) {}
function approve(address _spender, uint256 _value) returns (bool success) {}
function allowance(address _owner, address _spender) constant returns (uint256 remaining) {}

event Transfer(address indexed _from, address indexed _recipient, uint256 _value);
event Approval(address indexed _owner, address indexed _spender, uint256 _value);


While this standard isn’t fully accepted (and enforced), many token developers adhere to it as it provides them with many benefits, especially regarding interacting with other Ethereum services.

The functions signature suppose to match the basic functionality that is expected from every token smart contract.

  • function totalSupply: Display the total supply of your tokens.
  • function balanceOf: Display the amount of tokens each account has.
  • function transfer: Send value (amount of tokens) to address (recipient). The sender address is usually msg.sender.
  • function approve: Give permission to another account to trade tokens on your behalf. Used mostly when splitting your tokens to multiple wallet accounts and/or exchanges.
  • function transferFrom: Just like transfer, only in this case the user needs to specify the sender address as well.
  • function allowance: Display the amount of tokens that can be spent on behalf of the token owner by each approved address
  • event Transfer: Indexing all transactions by sender and recipient, also specify the transferred amount of tokens.
  • event Approval: Indexed all approved accounts by owner and spender account address, also specify the amount of tokens the sub spender can spend.


Step three – write your functions

Simple and straight forward. We need to start to populate our functions. Pay attention that these functions need to match the function signatures mentioned above.

mapping(address => uint256) balances;

uint256 public totalSupply;

function balanceOf(address _owner) constant returns (uint256 balance) {
    return balances[_owner];

function transfer(address _to, uint256 _value) returns (bool success){
    balances[msg.sender] = safeSub(balances[msg.sender], _value);
    balances[_to] = safeAdd(balances[_to], _value);
    Transfer(msg.sender, _to, _value);

mapping (address => mapping (address => uint256)) allowed;

function transferFrom(address _from, address _to, uint256 _value) {
    var _allowance = allowed[_from][msg.sender];
    balances[_to] = safeAdd(balances[_to], _value);
    balances[_from] = safeSub(balances[_from], _value);
    allowed[_from][msg.sender] = safeSub(_allowance, _value);
    Transfer(_from, _to, _value);

function approve(address _spender, uint256 _value) {
    allowed[msg.sender][_spender] = _value;
    Approval(msg.sender, _spender, _value);

function allowance(address _owner, address _spender) constant returns (uint256 remaining) {
    return allowed[_owner][_spender];

The totalSupply function was replaced by a simple uint public totalSupply.


Step four – Finalizing the token

Add the following parameters to your token contract:

string public name = "ShlomiCoin";
string public symbol = "SCO";
uint public decimals = 3;
uint256 public INITIAL_SUPPLY = 10000;
uint256 totalSupply;

Insert the token constructor function:

function ShlomiCoin() {
  totalSupply = INITIAL_SUPPLY;
  balances[msg.sender] = INITIAL_SUPPLY;  // Give all of the initial tokens to the contract deployer.

And finally mash it all together to get your token contract. (Full code on Github).


Make sure your token works correctly

Check your contract by opening your mist wallet, or go to (Web interface for your ethereum node). Under CONTRACTS you should see TOKENS. Just press WATCH TOKEN and insert your token address into the popup window. You should now see that you’re indeed the proud owner of 10,000 Shlomi coins.

Pay attention, this is a standard ERC20 token, but it’s not supporting crowd-selling yet. However, making sure that your token is working and is on per with the latest standard is a significant step on the way to create a stable ICO.

Add the token address to your “watched tokens” list


Under the Send tab, you can access your tokens and send them almost as if they were regular ethers



Get yourself a cup of coffee and get ready to offer your contract to the public.


The offering

Now that we know that we have a smart contract that works and is on per with modern standards, it’s time to offer it to the public.

This step is slightly less rigid than the previous one as there’re many ways and parameters in which one ICO is different from the other. Some might place a cap on the sale; some might have a time limit on the coin offering or have a different price for each step of the sell, some might send the etheres directly to the company issuing the ICO while others might split the ethers or freeze them or even destroy them. Sometimes the buyer might get the token immediately and sometimes only after a certain time passed – You get the picture. While ERC20 attempts to provide a uniform token standard, ICOs are the wild west.

But for this example, I decided to create an ICO which:

  1. Have uniform price throughout the sell.
  2. Stays open for exactly one week since being deployed.
  3. Immediately issue the tokens to the buyers.
  4. Sends the etheres to the owner (deployer) of the ICO contract (only one address).


Step one – Creating tokens function

A simple createTokens function will:

  1. Make sure that the transaction value isn’t empty (the buyer added ethers to the transaction).
  2. Calculate the amounts of tokens to be issued (price * amount).
  3. Update the new totalSupply variable with the new amount that was recently created.
  4. Adds the new tokens into the buyer (msg.sender) balance.
  5. Send the ethers to the owner of the ICO contract.


function () payable {

function createTokens(address recipient) payable {
	if (msg.value == 0) {

	uint tokens = safeDiv(safeMul(msg.value, price), 1 ether);
	totalSupply = safeAdd(totalSupply, tokens);

	balances[recipient] = safeAdd(balances[recipient], tokens);

	if (!owner.send(msg.value)) {

This function will be called automatically when ever someone sends money to the ICO contract by using the fallback function (function ()).


Step two – Create a modifier to prevents buyers from sending ethers after the offering period ended.

uint256 public endTime;

modifier during_offering_time(){
	if (now >= endTime){


Step three – add time limit, owner address and price to your token constructor

function ShlomiICO() {
	totalSupply = INITIAL_SUPPLY;
	balances[msg.sender] = INITIAL_SUPPLY;  // Give all of the initial tokens to the contract deployer.
	endTime = now + 1 weeks;
	owner = msg.sender;

And finally mash it all together to get your token contract. (Full code on Github).

You can now launch your ICO token and interact with it using mist (or any other compatible wallet). This token will work just like any other ERC20 token with one exception if during the time of offering someone will send it one ether, which senders will receive 500 tokens into their account, while the owner of the ICO contract will get that one ether into his/hers ether account.


Simple too simple.

Two points that I want to emphasis here, the first one is that this code is extra simplistic. There’re many more features, security mechanism, distributions schemes and functionalities that can be incorporated into both ERC20 contracts and ICOs. I don’t want to disparage anyone who issues tokens and offers them to the public. This is indeed hard work that requires a lot of research, careful planing and high level of expertise. IT REALLY ISN’T MEANT FOR ANYONE!

However, the code presented here is the real thing, it’s not the best example, but that’s the scaffolding on which most ICOs are based upon. Usually, there’s no actual mechanism that will incorporate these coins into a working application/smart contract – at least not at the time of ICO.

Bitcore.js keys for zeros and ones.

Bitcore.js keys for zeros and ones.

Bitcore is an excellent JavaScript library that is in use in many Bitcoin-related websites. Using the tools in this library one can easily achieve almost every Bitcoin functionality. Creating key pairs, parsing blocks, creating and signing transactions and more. In this post, I’ll focus on the use of Bitcore when dealing with key pair.


The zero

A beginner web developer can create a simple key pair by just using:

bitcore = require("bitcore-lib");
privateKey = new bitcore.PrivateKey // Generate a random private key
>> "23bc740f87bd68729e794eb48b5137150f17109f855a34512c3c5f93d7498291"

The privateKey comes with ample of build in methods, most of which are more than enough for basic Bitcoin implementation in many web applications.

>> "1LY75mCpuD3xPfLLFwbWccBNoQQY4VBeQj"
>> "0379d42509499082436c89a4e1637ed14a27e56174843bddb980ab6f155f82431c"

This codes can be implemented in a manner of minutes. Bitcoin can be incorporated into many web applications in less than a day. However, those of you with a keen eye to Bitcoin protocol probably noticed that the public key comes in its compressed format. The uncompressed public key will be twice as long (64 bytes + 1 byte) and will have 0x04 as their leading byte.

This is, of course, a non-issue for most use cases, but it might be somewhat counterproductive when learning the relations between private keys, public keys, and address.

To truly understand something, there’s no better way than to get your hands dirty. And when we’re referring to something as crucial to Bitcoin (and blockchains in general) as key pairs, no shortcuts should be made.


To one.

During my first experimentation with this library, I received the impression that, as good as this library is, it might not be sufficient to teach and learn the underlying mechanism of the Bitcoin blockchain itself.

However, after more careful examination I came to realize that this library provides much more granular tools than what I expected. In fact, it seems that I can use it in conjunction to the developer documentation on Bitcoin addresses.

This is done thanks to one specific method that returns the numeric value of each point in the public key (don’t forget, the uncompressed public key is just a set of x-y coordinates).


This is highly useful method for a number of reasons:

  1. It creates a big number object in JavaScript, thus saves us from the hassle of working with 32+ bytes (A big drawback in JavaScript is the lack of native support for any number that is 32 bytes and above).
  2. Each point is given independently; as a result, the students are more aware of the real meaning of what a public key is really is (in terms of x-y coordinates). It’s also an excellent opportunity to show the students how one coordinate can be dropped to achieve the compressed address.

Another two very useful methods are:

The first two methods makes the hashing process really easy to execute. The Bitcoin protocol requires double hashing to be executed at two different locations in order to turn the public key to Bitcoin address. In many other languages (such as Python, which I've been using extensively when teaching this subject), there's a need to import and define each hash function. The process is tedious, and at the end of the day, somewhat messy.

By having these two methods, we save almost 40% in code space, and the students can focus on what’s really important in this lesson.


And here’s the final result:

// This code represents a possible approach for teaching Keys
// using JavaScript. 
// 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 = bitcore = require("bitcore-lib");

privKey = bitcore.PrivateKey.fromString("8c5e5b37ebf1e7a274b9dff4910f9a2004868897f7d845802b77a1b245c26bc7");

pubKey = "04" +
        privKey.publicKey.point.x.toBuffer().toString("hex") +

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)


Now compare to what we might see in Python:

Private_key = bytes.fromhex("BF9795D3FCB4E2181B7B536C2247EA0001397C99BA94D4D4DD62801BB151B091")

import ecdsa

signing_key = ecdsa.SigningKey.from_string(Private_key, curve = ecdsa.SECP256k1)

verifying_key = signing_key.get_verifying_key()

public_key = bytes.fromhex("04") + verifying_key.to_string()

import hashlib

sha256_1 = hashlib.sha256(public_key)

ripemd160 ="ripemd160")

hashed_public_key = bytes.fromhex("00") + ripemd160.digest()

checksum_full = hashlib.sha256(hashlib.sha256(hashed_public_key).digest()).digest()

checksum = checksum_full[:4]

bin_addr = hashed_public_key + checksum

import base58

FINALE_BTC_ADDRESS = base58.b58encode(bin_addr)

In this instance, we can see that the code created with bitcore js is much more straightforward and readable than even the simplest Python code.
This is a clear indication that using JavaScript can be a useful tool when teaching the basics of blockchain development.
The libraries can be used when teaching both web developers as well as more protocol oriented students. The code can be presented in highly simplified manner for beginners while still alluding
to its origin and the logic behind it.

Blockchain architecture and JavaScript

Blockchain architecture and JavaScript

Why (and why mot) using JavaScript

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.

When catering for such students, it’s important to adjust the course material to their own background and goals. Mainly it means to provide them with as many JavaScript tools as possible, as it’s the main engine behind many modern websites and apps.

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 stunt approach led me to prefer teaching the students using more general programming language (mainly, python) while shy away almost completely from using JavaScript, which is fundamentally flawed for teaching protocols such as Bitcoin and the blockchain.

However, when done properly, a substantial part of the Bitcoin protocol can be explained, examined and tested using JavaScrips. And it’s important to develop the proper toolbox of JavaScript codes for that purposes.


// This code represents a possible approach for teaching Keys
// using JavaScript. 
// 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" +
        privKey.publicKey.point.x.toBuffer().toString("hex") +

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);


When to use JavaScript

The decision of when, and how to use these codes should be based on 2 main variables.

  1. 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.

Using JavaScript can be a great experience for them as they’ll both learn how to incorporate many robust libraries into their projects, but (maybe even more important), they’ll understand many of the limitations that surrounds JavaScript and its impact when creating a blockchain app. Limitations such as working on the client side, storing keys, accessing ssl, working with large numbers etc’.

2. What the students already know.

This one is quite simple, what’s the student background. If the student is more competent in JavaScrip, he/she might benefit more from adhering to JavaScript instead of learning another programming language.


Can blockchain really be taught using just JavaScript?

I’m still checking it.

I’m trying to migrate as many of the codes that are used for teaching the blockchain itself from Python (most can be found here) to JavaScript.

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

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;

  1. It needs to support all the tools I require that my students use.
  2. It shouldn’t affect in anyway the students’ computers, working environments, file systems, paths and/or jeopardizes their computer security in any way.
  3. It should be uniform for all the students.
  4. It should be easy and fast to set and reset whenever needed.
  5. It should be as user friendly as possible.


After a few experimentations, I decided to work with the following configurations:


  1. Cloud9 level 1 IDE environment with the following installations:
    1. Python-pip.
    2. Python-virtualenv.
    3. Virtual environments for Python 2.7 and 3.5
    4. Ethereum SOLC
    5. Tcpdump (for some reasons, not all c9 workspaces had it installed)
    6. The following pip packages (base58, ecdsa)
Cloud 9 was used for running python files and as a uniform terminal.
  1. Digital ocean Ubuntu 16.041 X64 droplet with the following installations:
    1. Nodejs 6
    2. Meteor Javascript framework version 1.3.4 with web3 and bitcore-lib packages.
    3. The following changes were optional for a few students:
      1. Installing ipfs and running ipfs daemon and adding ipfs-api package to their meteor app. (For those who wished to work with IPFS).
      2. Adding swap file of 4 gb. (For those with memory issues).
  • Use openssh. (More IDE flexibility for advanced users).


  1. 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).


  1. The only 2 components the students were required to install on their own machines were:
    1. Chrome/Chromium with metamask addon.
    2. Wireshark.


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.


Digital ocean droplets were used to provide the students with a uniform platform on which they can create their apps. Meteor is a well-documented JavaScript framework. It was obvious to me that if the students were expected to create applications, they should also have access to some JavaScript tools as both Bitcoin and Ethereum have some very powerful tools for app developers – mainly web3 for Ethereum and Bitcore for Bitcoin.

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).

Another point to consider is that in a future course, in the case where there’s no promise to create apps, digital ocean might still be used. In this case, JavaScript libraries can be taught by using clean nodeJS interface.


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.

What to teach when teaching blockchain

What to teach when teaching blockchain

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:

The basics

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.


Blockchain architecture

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.)


I used this general scheme to select the topics to be covered in the Bitcoin part of the course


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.

Teaching blockchain in Brazil

Teaching blockchain in Brazil

What is it all about

A few months ago, I received an interesting email from a company I didn’t know at the time. What was the content? I was asked to create and conduct a full fledge, 8 weeks long, blockchain development course in Brazil that would involve students from all walks of life.

Blockchain education is something I am passionate about, so this offer immediately struck a chord in me. In the past, I have talked a little on how I got into this field and given some insights on my views about the current ecosystem in terms of education. To sum it up; there’s an existing huge knowledge gap that serves to keep many talented people from properly contributing and utilizing numerous blockchain based solutions.

The deep-seated desire to bridge this gap is a major part of my personal agenda. For that reason, in the past, I created a few videos and tutorials (which owing to the fast paced nature of technology are in sore need of an update, I know) that were aimed at mitigating this gap in knowledge and making blockchain codes somewhat more reachable for developers and tech people who are new to this ecosystem. In addition, I was looking for other ways to bring Bitcoin and Ethereum to the people. In line with this, a creating/conducting course seemed like the logical next step.

In the early chats that transpired between me and the Brazilian company, I was offered the freedom to construct the course as I see fit, without any restrictions.  There was one specific request – that when the duration of the course comes to an end, the student will create their own apps. Considering the proposed length of the course (8 weeks), I believed  it would be quite easily achievable simply by allocating the last 2 weeks of the course to exclusively working with the students on their personal projects.

As we talked about the projects the students might create during the course, we also discussed the lack of needed quality in many of the current blockchain related projects out there.  I gave my impression that it was due to a dearth of understanding of blockchains. Most projects are nothing more than basic apps that have very little to gain from using the blockchain and are either utilizing it for marketing reasons – basically to draw more investors’ money owing largely to a lack of understanding on the investors’ side.

But this is not all; it could also be as a result of a serious flaw in their understanding of how to use the blockchain from the creators’ side. I wanted to ensure the students really have an understanding of what the blockchain is, and equally important, what it isn’t.

My counterpart was impressed by this approach and it became clear to the both of us we were seeing eye-to-eye on what our vision for the course was.


Getting ready

Working on the course took a substantial part of my time for the better part of 2-3 months. I basically started creating a course from scratch as there were very limited resources and existing courses to draw from. I created a course structure, list of topics, codes and other teaching aids. The task was a hard one, harder than I initially anticipated. I basically, single handedly tried to create one of the most ambitious courses using nothing but my own means and with literally no support of any kind. But I made it!

Slowly but surely, I managed to create a list of working codes to teach my students. I had a solid course structure, the basic infrastructure for a certification system, few assignments, list of resources, presentations and a lot of notes – all corresponding and completing each other, tested and organized for maximum effect.


In Brazil

It was finally the moment of truth. I arrived in Brazil with my course (mostly) neatly organized and prepared. The time for theory was past and it was  time to see it in real action and put my work to the ultimate test.


Some curious Brazilian horses that participated my class.


The final experience in Brazil was much more challenging than I thought it would be. Some of the difficulties I encountered were related to the technical background and level of the students (the class was very heterogeneous). While some had extensive experience, others had absolutely zero previous experience.  A number of the challenges were related to my own preparation for the said course.

Still, when the course winded to an end, I was highly pleased and proud to see how ALL of the students managed to show great advancement.

I’m very grateful for this experience. I had the opportunity to create a full fledge course, a unique and solid one that provides substantial blockchain education, an element that is sorely lacking outside of very specific programs in selected universities. The challenges I encountered during the course were also a great blessing; my course (and by extension, my whole approach to blockchain education) was tested rapidly and almost every aspect of it was subjected to stress test, and it made it through!

Additionally, this course was a great learning experience for me. As a matter of fact, I’m already working on implementing some of the things I’ve learned in order to provide even better learning resources and courses in the near future.

Now, almost a month after the course, I decided to sit down and articulate my thoughts and experiences. It is my wish to share what I did and what I learned. It is my hope that by doing so, I might be opportune to effect some positive impact on the blockchain education ecosystem and that these articles will be helpful to many.

The articles are currently divided into 7 major categories:

  1. Course structure.
  2. Choosing the working environment.
  3. The codes that were presented and exercised.
  4. Certifications and accreditation.
  5. Teaching aids.
  6. Assignments, homework and evaluation.
  7. Others (students’ background, learning environment, marketing and setting expectations, class size, after class meetings etc.).

These articles will be published in parts in weeks to come.