Low-hanging fruit for the crypto community – Ethereum Meetup Berlin January 2017

Even though the scheduled talk about “Decentralised, Direct Democracy & Multidimensional Monetary System” didn’t take place, the January meetup at the Ethereum HQ in Berlin didn’t lack interesting topics and speakers. The night was comprised of four talks and went for almost three hours.

In my recap I want to skip the first talk about deckard.ai, because this development tool is not primarily focused on the crypto-space and therefore not really related to the topic of this blog. However you can watch a recording of the talk here: https://www.youtube.com/watch?v=Vgx56cpw-8U


Yann Levreau

The second talk was an update on the progress of the smart contract development enviroment Remix held by Ethereum’s own Yann Levreau. Remix was just last week merged with browser-solidity and focuses on giving fast feedback to developers while writing smart contracts in solidity.

The enviroment runs in the browser and lets you choose how to connect with an Ethereum node. The options are Javascript virtual machine (local and in memory), providers like Mist or Metamask and last but not least a node at localhost. A great strength of this tool is the ability to replay a contract execution and go through it step by step. Executed statements will be highlighted and state changes in the contract are displayed, which helps a lot in debugging smart contracts.

The developent enviroment doesn’t contain a testing framework and Yann Levreau recommends the use of either Embark or Truffle for this end. The speaker demoed how to use Remix when developing a frontend for dapps and hinted that project management tools might be on the roadmap for Remix in the future.


Ligi esPass

esPass stands for electronic smart pass and aims to bring the benefits of cryptographic tokens to the realm of tickets. Most tickets nowadays use QR- or barcodes. These codes just represent passwords that gains us access to concerts, conferences, airplanes, etc. They come with the big drawback that they can be copied. This constitutes a big problem when tickets need to be resold. There is no way for a potential buyer to verify that not other copies of the same ticket are in existence and that he will be the first person to try to enter with that given code. Luckily blockchains provide a solution for exactly this kind of problem. Presenter Ligi said that ticket systems therefore represent low-hanging fruit for the crypto community.

The creator of esPass put a lot of thought into the question of how to onboard users that don’t have experience in how to use public/private keypairs or digital currencies. His tenet is that the esPass tickets should gracefully degrade to the experience that users are already used to. That means that users who are not interested in the benefits of a blockchain-based ticket should just be able to print a PDF with a QR-code.

As the backend for esPass Ligi chose Ethereum. One of the reasons for this decision is ethereum’s determination to switch to POS in the not so distant future and thus become one of the most enviromentally friendly blockchains. However a problem with this is the lack of a proper light-client for ethereum, however progress on the light-client seems to be made and we can hope for a release sometime in the not too distant future.

Integrating ZCash with Ethereum

Dr. Christian Reitwiessner

As the last part of the evening Christian Reitwiessner gave a in promptu Q&A session about the effort to implement zkSnarks on the ethereum blockchain. However much better than any recap that I could write on this topic is his own blog post on the topic, which I highly recommend.

Videos of the talks are available on Adjy Leaks channel. However as of the time of writing there is no sound for the Remix and esPass talks, however Ryan indicated that he might reupload it later.

DAppHack Berlin 2016

On the last November weekend in 2016 the first DappHack Berlin took place. The event was focused on decentralized technologies. While the name suggests a hackathon, the actual event turned out to be more like an unconference. Johannes, one of the organizers, said that when the name was settled, the idea was to host a hackathon, but as more and more speakers came on board the event evolved into an unconference.

The line-up of speakers was pretty phenomenal for an admission free event. Core-devs of IPFS, the ethereum foundation and ethcore were present as well as many other very knowledgeable people. Among the recurring themes of the conference were distributed storage, distributed application (dapp) development and serverless pub/sub systems.

Fortunately there is no need to regurgitate here what has been presented, since you can watch all talks on Adjy Leak’s Youtube channel: https://www.youtube.com/channel/UCxfh-2aOR5hZUjxJLQ2CIHw, but I would like to point out some highlights:

Dapp Development Tools

David Roon @ DappHack Berlin

David Roon @ DappHack Berlin

On Saturday David Roon kicked off the event by introducing a java library for smart contracts. His talk was followed by Thomas Bertani’s presentation of Oraclize, a service that solves a very urgent problem that concerns almost all dapp developers: how to access external data from the context of a smart contract. A third talk that featured development tools was Tomasz Drwięga’s workshop about how to build an app with Parity. I

personally benefitted a lot from this session.

Distributed Storage

With IPFS and Swarm two of the big projects that promise distributed storage were present. Unfortunatly the IPFS talk was overshadowed by some technical problems. Those caused some interruptions which stretched the talk to almost 2 hours. The talk about Swarm (ethereum’s native distributed storage system) by Viktor Tron on the contrary is only snappy 16 min long. I got the impression from this event that Swarm differentiates itself from the already relatively widley deployed IPFS by it’s focus on incentivization of data storage.

A third project, that I had not heard about before is Datproject. Dat has the goal to become the “Better bittorent”. It makes it possible to not only share files but also folders and streams of data, which can make distributed live TV possible. Last but not least in this category was the presentation of the Alexandria project. It is a project that uses IPFS as backend to permanently provide content on the net. It has a well developed integration of bitcoin payments. A curious detail about this project is that they use the rather obscure blockchain Florincoin to publish metadata for the content.

David Dias IPFS @ DappHack Berlin

David Dias IPFS @ DappHack Berlin

Distributed Pub/Sub systems

There were two talks at DappHack that I would put in this category. OrbitDB, that is a sister-project to IPFS. (I have previously writte about OrbitDB here) and Secure Scuttlebutt. The demo of Secure Scuttlebutt made a deep impression on me, because they already realized several working applications including a Twitter-like social network and an app very similar to Soundcloud.

All in all this was a very interesting event. Kudos to the organizers Ksenia, Johannes and Sven (and Andreas who sponsored the beer!). Also a big thank you to the hosts of Agora Co-working, which was a wonderful venue for this event.

MTF-Labs Blockchain workshop recap

From May 23rd to 27th the Music Tech Fest Berlin held first blockchain workshop. It was attended by approximately 25 people and took place in the beautiful buildings of the Funkhaus Berlin. The event was attended by a host of different people: representatives from streaming services, labels and collection agencies, musicians, software developers and more.

On top of that there were a bunch of presentations held remotely through Skype or Google Hangout from people like Imogen Heap, Benjie Rodgers, Daniel Harris (the founder of KendraHub), and the singer of Edward Sharp and the Magnetic Zeros. In the days of the workshop I learned about a lot of ventures and projects in the realm of music and “blockchain technology” (for instance upcoming music streaming app Jaak, which has Viktor Tron from Ethereum as one of it’s founders.)

One of the most prominent topics discussed was the question whether blockchain technology could simplify the process how creators of music can be remunerated. Several employees of the streaming service Soundcloud reported how difficult it can be to determine who to pay what, because there are so many different collection agencies sometimes even giving conflicting information. However xkcd’s famous Standards comic was brought up several times and I believe most attendees will agree that blockchain royalty schemes will more likely than not complicate things even further (at least in the short and medium term) by adding another “standard” by which rights information can be published.

Another big issue that was brought forth by artists/creators is the meager recompensation of creatives. Blockchain technology certainly has the promise to increase the share that artists receive from the money that fans pay. This could work through elimination of layers of middle-men and by making the payment flows more transparent. However I imagine that a prerequesite for this happening would be that customers embrace digital, blockchain-based currencies. Furthermore these currencies first have to solve their capacity issues. Both are still quite uncertain.

In one aspect the week didn’t meet my expectations: there was no programming workshop / hackathon and too much thought was given on how to get big stakeholders (like major labels, collection agencies etc) on board. I believe that the music industry has a major disruption coming for it in the form of a decentralised publishing process. If I let the emergence of bitcoin form my opinion, this disruption will come about by somebody starting an open source project and writing some code and not by wooing the stakeholders of the predominant system.

I want to thank the organizers Petter and Peter (founder of resonate.is) for organizing this session and Music Tech Fest Berlin for providing the location. Also there is another blog post by fellow attendee Bas Grasmayer with his recap https://medium.com/music-x-tech-x-future/the-music-industry-isnt-ready-for-the-blockchain-2df4f2cf2e0c#.x93p4srig


Berlin Ethereum meetup March 2016 recap

I went to the Berlin meetup yesterday and even though I missed the talk by Afri Schoedon about the Ethereum Stackexchange, it was really worthwhile. The second talk was by a represantative of Nexus Development about their tool Dapple which is designed to help build contract networks comprised of many interacting contracts. In particular it is a package mangager and deployment tool for Solidity contracts.

In the last segment of the evening ethereum C++ team lead Christian Reitwiessner was answering questions about the Solidity contract language. For this purpose he showcased the online tool Browser Solidity, which simulates an ethereum blockchain. It is well suited to test out contracts and provides an easy to use interface to interact with contracts.

He explained the Solidity contract language using the royalty contract for Tiny Human, which I have taken an interest in lately, as an example. In the next paragraphs  follow my notes regarding this part of the talk.

The general layout of this contract is as follows: It starts with the definition of several Structs. Structs are custom groups of variables. Here is an example from the contract code. Owner is a structure that has two variables, the address and the name of a person that owns a share in this song (i.e. one of the creators).

struct Owner {
address addr; // Can be linked off-chain to a persona (like "Imogen Heap" or "Guitar Guy Bob")
bytes32 name;

After the structs come state variables, that are permanently stored in contract storage. An example is the price of the download.

uint public constant USDDOWNLOADPRICE = 60; //0.6 usd.

After this there are two events defined. As I understand it, events are the hooks that allow other applications to interact with the contract. For instance javascript applications can listen for these events and trigger other actions when they occur. I assume that this is the way the Tiny Human web application notices that a payment has occured and starts the download of the mp3.

event purchasedRight(address indexed payee, bytes32 right);

Then on line 72 of the contract begins the constructor. The constructor is only once executed when the contract is submitted to the ethereum blockchain. In it a bunch of properties are setup, which will be used later. This concludes the constructor.

Directly after the constructor starting on line 142 are the definition of two modifiers. These are used to amend functions, in our case to restrict access to certain functions. Here are the lines from the contract code:

modifier isAdmin() {
if (msg.sender == admin) {

After that follow function definitions. First off the purchase-function is public and thus can be called by everyone. Here and in it`s sub-functions is where the meat of the matter is. “purchase” compares the amount of money that was sent in (denoted with msg.value) with the price of the download. If the money is greater or equal the “addTransaction” (line 167) function will be called. Here the contract will iterate over the owners of the song and issue a payment to each of them. See here:

for (uint i = 0; i < ownersCount; i += 1) {
if (shares[owners[i].name][_right] > 0) {
(owners[i].addr).send(msg.value * shares[owners[i].name][_right] / TOTALSHARES);

After this step the “purchasedRight” event is triggered, which makes the download start in the accompaning web-application. The last part of the contract contains administrative functions. You will see that they use the modifer isAdmin() or isOracle() in the function definiton, which make sure that they can only called by persons with the correct private key. These functions are used to set the current exchange rate, etc.

After explaining these features of the contract, Christian Reitwiessner also said, that it is possible to inherit from a contract. So it is possible to create another mp3-download-contract by setting up the contract like so:

contract AnotherSong is TinyHuman {..

This makes it possible to reuse much of the code.

Thanks to the ethereum foundation for setting up these meetups! They are a great opportunity to learn and get in touch with the ETH community.

View the contract code for Imogen Heaps pioneering self-executing royalty contract

In October 2015 British singer Imogen Heap made headlines by publishing her song “Tiny human” with help of the Ethereum blockchain. A new website makes it now very easy to take a peak behind the scenes and see the contract code that governs the royalty contract. The website is called live.ether.camp and you can view the contract here.

This excerpt of the code for instance shows how the money from the sale of “Tiny human” mp3s is divided between Imogen Heap and her seven colaborators:

shares[“Imogen Heap”][‘DOWNLOAD’] = 912500; //91.2500
shares[“Stephanie Appelhans”][‘DOWNLOAD’] = 12500; //1.2500
shares[“Diego Romano”][‘DOWNLOAD’] = 12500; //1.2500
shares[“Yasin Gundisch”][‘DOWNLOAD’] = 12500; //1.2500
shares[“Hoang Nguyen”][‘DOWNLOAD’] = 12500; //1.2500
shares[“Simon Minshall”][‘DOWNLOAD’] = 12500; //1.2500
shares[“David Horwich”][‘DOWNLOAD’] = 12500; //1.2500
shares[“Simon Heyworth”][‘DOWNLOAD’] = 12500; //1.2500

The revolutionary thing about this contract is it’s self-executing nature. This means that the payouts to the musicians are automatically and immediately executed in the instant that a download is sold. Ever heard of musicians being ripped off by the evil music industry? Well, if this sort of music publishing would take over, being ripped off would be a thing of the past. If you look closely at the contract details, you will see that the big music companies like Sony, Warner and Universal have no part in it.

The process of buying the mp3 in my opinion could still be improved though. The website Ujo, which hosts the song, asks you to create a wallet on their site for which you then choose a password. In the next step you have to charge your Ujo-wallet with the necessary funds (the ether amount that corresponds to 0.60 USD) and then pay the song from your Ujo-wallet. This was not how I expected this to work and I would prefer to pay directly from my wallet. However we can hope that this might be further improved, if this way of publishing music gains traction.

© 2017 Propellah

Theme by Anders NorénUp ↑