Menu

This is the next installment of my ongoing battle with Virgin Media, who appear to outdo themselves at sheer incompetence at every possible opportunity. Second complaint letter:

Dear sirs,

Further to my original complaint of September 5th: The broadband service was finally installed on September 19th.

Since then I have been without a landline number. The engineer who came to install told me that the number port had not been requested and so he could not give my my number, as you had promised to do. He said he’d give me a temporary landline number, which he did. That number worked for maybe a day. After that we have had no working landline, either on the original number or on any other number.
Your engineer also said that someone would come to bury the cable he extended through my front garden. That has not happened either.

So as far as I am concerned you still have not fulfilled your contractual agreement to me, since I currently don’t have a landline number. I hope you are not proposing to start charging me for the service you haven’t fully installed. From previous experience of your automated systems, I suspect that in their magical parallel reality everything is fine and all they have to do now is to start collecting money.

Your complaints procedure says you will resolve complaints within 28 days of receiving them. Those 28 days have passed and I still don’t have either a fully installed service or any type of response to my complaint. Or any kind of contact from you at all, actually, apart from your boilerplate response to my initial letter.

I would like to escalate this to the next level of your complaints procedure, which vaguely states that a “manager” will call me. I am not holding my breath for that call, as I am yet to see any evidence of sentient life within your complaints system, but your procedure appears to insist that I wait another four weeks before going to independent adjudication.

This is a totally off-topic post for this blog, but I am so outraged by the way Virgin Media have botched the installation of my broadband, that I just wanted to write it down somewhere on the Internet for others to see. Just shouting into the void to make me feel better! This is a transcript of the complaint letter I sent them today:

Dear Sirs,

I am writing to complain about your failure (twice) to honour your contractual agreement to install broadband and telephone at the above address.

Since August 6th, when I signed up to get your service and cancelled the service I had with my existing provider I have:

Twice had the same vacuous welcome email (“The adventure starts as soon as you e-sign your contract, Daniel”)

Twice signed and returned a contract that commits you to installing broadband on a certain date

Twice I have replied YES and got a reply (“Great! On the day we’ll need someone over 18 at home who’ll be able to advise on cable location”)

Twice I have had the same call from the same Indian call centre barely 12 hours before the installation date telling me that no one is going to come and giving me another made-up installation date two weeks in the future.

My conversations with your customer “service” have been nothing short of bizarre. Not only do you fail to honour your agreement, but your agents always manage to make it my problem to sort it out.

They have all suggested I call my current provider and ask them not to switch off my current service. This is clearly impossible at such short notice as well as an offensive passing of the buck.

One of them suggested that if I get cut off I should go out and buy a WiFi dongle. Thanks.

Another informed me that since the service had not started they were under no contractual obligation to me. For all I know, this is “technically” true but, really?

Having been round this roundabout twice I can see that you have a very well oiled automated system of emails and texts that is in no way related to what you are actually doing.

You also appear to find it an acceptable part of your automated workflow to cancel your commitments at the last possible moment, thereby giving yourselves maximum wiggle time and simultaneously causing your customers maximum pain.

From a purely transactional point of view, your late cancellations are a cost to me. I am a freelance consultant and I have (twice) had to clear my diary to wait for your installer. Less than 24 hours notice of cancellation is not acceptable in any transaction I have ever done (buying tickets or ordering goods, for example). Therefore I am attaching an invoice for two days of my time at my usual rates, which is the cost to me of dealing with your no-shows.

On a more personal level, I have to confess that I am struggling to think of any other situation when I have been treated so shoddily by any service provider. Even government bureaucracies are more responsive than you. I have been given a tour of your internal corporate silos: being passed around from one department to the other and knowing that there is not a single human being inside your company who cares or takes ownership of this. As long as they tick their box and pass their problem along, their job is done. At no point have a received anything other than your automated canned communications or any indication that anyone in there is actually responsible or accountable.

It has to be ironic that the great Richard Branson, who set out to disrupt monolithic behemoths like British Airways and British Telecom, has managed to create a carbon copy of the faceless, siloed, uncaring corporate bureaucracies he set out to destroy.

I look forward to hearing from you, but I am not exactly holding my breath, even if your complaints procedure says you will respond within 28 days.

One of the promises of the decentralised web (web3) is the idea that you will be able to harness all the idle power of computers all over the world and use that power to do amazing things that require lots of computational power. You will in effect be able to create huge supercomputers by aggregating the computing power of thousand or even millions of small ones.

in order to do this, so the theory goes, all you have to do is create a marketplace with the right incentives for people to make their computing power available, and others to buy it and pay for the privilege of running their computations on them.
In practice this is fiendishly complicated, but that hasn’t stopped people from trying to create such a marketplace with the correct incentives.

In this post I will review three outfits trying to create this World Supercomputer marketplace: Golem, SONM and Iex.ec.

I do not claim to have anywhere near enough technical knowledge to assess the merits or otherwise of these platforms. I am merely looking at it from a layman’s perspective, and from the perspective of someone who is trying to figure out whether or not to invest money in these tokens.

SO let’s start with the characteristics they have in common:

In all of them there is a marketplace where some users offer up resources and other users bid for and buy these resources. When the work is done (the computational task that was requested) the results are given to the buyer and the seller gets paid.

They all claim to be decentralised, i.e. there is no central authority deciding who can or cannot participate, the price of things or any kind of dispute resolution. It is all done in the code.

They each have created their own currency (token) that will be used to pay and get paid in their marketplace. If their marketplace is the one that succeeds, then their tokens will be in great demand and they will be rich!

All the tokens are tokens on the Ethereum Platform. Therefore transactions of their tokens are transactions on the Ethereum Network and the consensus mechanisms will be those of Ethereum. Ultimately, to a greater or lesser extent, their success is tied to the success of Ethereum.

In the Golem marketplace, as well as buying and selling computational resource, you can also buy and sell the software required to run various tasks. So in their marketplace there are “providers” or computational resource, there are “requestors” of resources, but there are also “software developers”, who can upload their software to an “Application Register” and charge people for using it. For example, and this is the first proposed Golem use case, someone who needs to do CGI rendering (special effects for movies, which is often computationally expensive) could upload software that does that and charge others to use it.
The Golem team recognises that the potential for defective or malicious code is high, so it introduces other concepts such as “validators” (who do QA on software) and whitelists and blacklists of applications that the validators (or others) have checked and used.

How much money did they raise?

Their ICO (Initial Coin Offer) happened in November 2016. They issued one billion Golem Network Tokens (GNT) and raised one million ETH (around US$10 million at the time)
According to their White Paper, “The supply of GNT will be limited to the pool of tokens created during crowdfunding period”, so no more will be issued, ever.

What stage are they at?

Their first iteration, Brass Golem, was initially scheduled for May 2017 (six months after crowdfunding). There have been some delays and now they are being more coy about a release date.

Who is the team

The team is based in Poland and composed largely of Polish professionals with backgrounds in Economics, Software Engineering and Mathematics.

SONM (Supercomputer organized by network mining) claims to be not just a marketplace for computational tasks but a whole “World Computer”. Its White Paper criticises Golem and Iex.ec for their lack of grand vision and explains in quite a lot of technical detail how its architecture in effect mimics, or accounts for, all the building blocks of a computer but in a distributed, mega-scalable, way.

Their use cases, interestingly, are not dissimilar to the Golem ones, one of them being “rendering video and computer graphics”. They also include scientific research like drug development and weather prediction, areas of research that traditionally require lots of number-crunching and computational expense.

But because it is more than computational marketplace, SONM also claims that you can run your applications (say, your website) on their World Computer.

The ICO happened in June 2017 and 331.360.000 SONM (SNM) tokens were issued. They say they raised US$ 42 million.
They also say that no more tokens will be issued.

What stage are they at?

They say version 0.1 (which they call an Alpha) is out and version 0.2 is due in June 2017. There appear to be some implementations using the current release, see here for example.

Who is the team?

According to their site the main movers are two Russian software developers, one of whom works for Yandex, the big Russian search engine and technology company. The SONM Platform as a Service (PaaS) relies heavily on the Yandex “Cocaine” framework.

Like SONM, Iex.ec claim that their solution is a distributed Cloud infrastructure that can provide distributed applications equally distributed access to all the resources they need, i.e. computation, data and other services.

At its simplest it is similar to the other two in envisaging a marketplace where some users will offer various infrastructure services and others will consume and pay for them. In the case of Iex.ec, they say the platform will take care of finding the most optimal resources given the needs of the application that wants them.

Like with the others, the platform will contain an Ethereum-based transaction model, as well as various consensus mechanisms like a “Proof of Contribution” to ensure trust and traceability.

What stage are they at?

Their first release (v1) is scheduled for 6 months after the ICO, i.e. towards the end of 2017. They claim to have demoed some proofs of concept here and here.

Who is the team?

It is a multinational team based in France. The founders are French and Chinese computer science professionals. As mentioned before, they have a background in developing Desktop Grid Computing software like XtremWeb-HEP, an open-source software solution for this.

Further Reading

The Golem whitepaper is here
The SONM whitepaper is here
The iex.ec whitepaper is here

So, now that we have a draw and a lottery orchestrator to keep track of it all, the next task was to put this all together so that, at regular intervals (say once a week), the draw is drawn and either winners paid or the pot rolled over to next week’s draw. To do that you have to execute the following actions in sequence:

Create a new draw for next week

Run the current draw, i.e. select a winning number and pay the winners if there are any

Transfer the pot (if there are no winners) to next week’s draw

Add the address of the new draw to the lottery orchestrator

Sleep until next week and do it all again!

All of the above are asynchronous operations on the Ethereum Blockchain, so it is necessary to wait for confirmation of one thing to execute the next one. In the following code, we do step 1, but only execute step 2 when the callback comes with confirmation that the contract has been created. And steps 3 and 4 are inside an Event callback that confirms that a winning number has been selected and the winners paid:

Automating it all

So how do you get this to happen without having to remember to do it yourself, and bearing in mind that it requires you to run code from within a geth console? To solve that problem we put all the code we wanted to run in a script and then used Expect to run it. Expect is a programme that “talks” to other interactive programmes according to a script. Our script is:

Finally, all you do is add a line to your crontab to execute the script once a week at midnight (or whenever)

0 0 * * 0 /home/path/to/weekly_deploy.exp >> /tmp/expect.txt

Why this is OK, but not perfect

This works fine but a confession is required: When we set out we wanted to create a totally trust-less lottery, i.e. one where you did not have to trust any third party to ensure that the lottery would run according to the rules.
By doing the above, you need to trust us that this script will run at the appointed time. And we need to trust that the people who supply the server where we keep the script will continue to supply it.
So it does somewhat break the rules.
But the alternative, to have contracts that knew when to run themselves and that knew how to spawn copies of themselves in order to transfer the pot and keep the thing going, was too hard for our current abilities. So it will have to wait, for now…
Once Lottereo is live we will run the scripts, we promise!

As mentioned before, randomness in a deterministic system like the blockchain is very hard to achieve and there is a lot of discussion on the Ethereum chats about how best to go about it.
In practical terms, this means that something that in any programming language is as simple as calling a Rand() function, in Solidity turns into a major headache.

Randao

In order to try to get a true random number for our draw, we had a look at Randao.

What is it?

Broadly speaking, it is like a way of crowdsourcing randomness! Here’s my understanding of how it works:

An instance of randao.sol (call it contract C) will exist somewhere in the blockchain.

Random Number Generation then happens in (block) cycles.

In the first cycle (within a certain period of time counted in mined blocks), people who want participate send a given amount of ETH (a pledge) to the contract along with a secure hash (sha3) of a number s.

In the second cycle, those same people have to send the actual number s to the contract. These are verified against their sha3 and stored.

After all secret numbers have been successfully collected, the contract will calculate the random number using all the values s1…sn that it has collected (so in effect s1..sn is a way of collecting entropic values). The result will be written to the storage of C, and the result will be sent to all other contracts that requested the random number.

Contract C will send back the pledge to the participants in the first phase, and the profit is divided into equal parts and sent to all participants as an additional bonus. The profit comes from the fees paid by all the other contracts that consume the random number.

We tried running a test using the instructions provided, but have to confess that we failed. I think it was partly because we were deploying it on the Morden network and not in a private testnet, so the block cycles happened too fast.

In any case, it appears to be a clever, but incredibly complex, way to generate a random number.

Oraclize

What is it?

Basically a pay-as-you-go service that claims to be a bridge between the Ethereum DApps and the outside world. In particular, for our present use case, they provide a link to Wolfram Alpha which, conveniently, is good at generating a random number.

Oraclize uses the ability of Solidity contracts to inherit from other contracts. All we had to do is import their usingOraclize contract into our own draw contract definition. Then it was just a matter of changing our contract from:

contract draw {

to:

contract draw is usingOraclize {

and voila, we had access to the outside world via Oraclize!

We then used this line (see full documentation here) to go out to Wolfram Alpha and get a random number for our draw:

oraclizeId = oraclize_query("WolframAlpha", "random number between 1 and 1000");

Is that it?

Not quite. What the above line does is to send a call to another Ethereum contract, owned by Oraclize. Oraclize do their magic, get you the random number and then have to call you back to give it to you. So you prepare for that by creating a __callback function in your code, ready to receive it:

And then, that is it! You have your randomly generated winning number and you are good to go.

In effect we have subcontracted the random number generation, for a price, to a third party who can be, at least in theory, audited and proved to be trustworthy for this.

Conclusion (or TL;DR)

Generating random numbers in inside the Ethereum blockchain is hard.
Randao looks clever but it is complicated.
Oraclize cost money, but works perfectly well for our use case. (And, incidentally, they also provide a solution for another problem that is trivial anywhere else but is not supported by Solidity – turning a string into an integer)

But there doesn’t seem to be a built-in string to integer converter. After much Googling and asking the folks at Oraclize for help on on another issue, we found a solution – there is a “parseInt” function built into the Oraclize library. The source code of the relevant function is reproduced here because the nice folks at Oraclize have allowed their code to be used freely:

This code looks through each byte of the string in turn, ensuring it is an ASCII digit and raising it to the appropriate power of ten to convert a string of digits into an integer.

If you are already using Oraclize in your Ethereum contract, then you should have “parseInt” built-in, otherwise you are free to use this code (with the copyright notice) in your own code.

I’ve been trying to figure out what Gas means in Ethereum. There is lots of information out there but I will add to it by describing what I found in my own words.

Gas is just a unit of currency, like a token. It is used to set a price on different types of code execution inside the Ethereum Virtual Machine (EVM). For example, saving a variable cost 100 gas; executing an IF statement cost 1 gas. There is a list of how much gas things cost here.

In a typical transaction you would say something like

method.sendTransaction({from:eth.accounts[0], gas:300000})

The gas part of that statement means that you are willing to spend up to 300,000 of these gas tokens in executing this method.
Now, there is another, optional, parameter in that statement, which is gasprice. This is the price in Wei that you are willing to pay for each gas token. If gasprice is not specified, then a default value is used. At the moment that value is 10 szabo, or 0.00001 Ether.

What is the point of all this?

Contracts on the Ethereum blockchain are of varying sizes and complexity. Therefore, a miner who is investing their computing power executing a method (a part of a contract) needs to be rewarded according to how much of that power they need to use. By inserting an amount of gas and a gasprice, you are signalling to the miner how much reward they can reap from running your code.

This is fundamentally different to the Bitcoin blockchain, where the vast majority of code executions are identical (transferring bitcoin from one wallet to another) and therefore miners can predict how much it will cost them to execute every transaction in a block.

So, going back to our example, when you send in the above transaction, the paying account (eth.accounts[0]) is deducted 300,000 * 0.00001 ETH, i.e. 3 ETH, and that value is sent in with the method call.

After that, one of two things will happen:

The execution requires as many or fewer of the gas tokens that you pledged. In that case the execution is succesful and you are refunded however much ether is unspent (e.g. if you said you were willing to use up 300,000 gas tokens at 0.00001 ETH each, but the execution only required 150,000 gas tokens, then you get refunded 150,000 * 0.00001 ETH. The miner keeps the rest as a reward for their efforts.

The execution requires more gas tokens that you are willing to spend. In that case, execution of the code is aborted when the gas limit is reached and the contract state goes back to whatever it was before your execution started, i.e. nothing actually gets done. BUT crucially you DON’T get your money back (because work was done by the miner, so they used up their computing power and electricity).

Some thoughts

The higher the gasprice you insert the more attractive it is for miners to process your transaction because they get paid gasprice for every gas token that they need to use in executing your transaction.

It seems almost impossible to be able to calculate how much gas a transaction will require. A dummy like me has to send a big number of gas to ensure execution. There are obviously ways of calculating this, because if you use the Mist browser to execute a method, it seems to have a way of forecasting the amount of gas you might need.

It is also very difficult to find out that your transaction failed because of lack of gas. It just dies and you are left to puzzle it.

Interestingly, blocks also have a gas limit. But that is probably for another post!

Useful links

In my previous post I described a instance of a single lottery draw. But how does a punter who wants to buy a ticket know where to buy it?

In the world of Ethereum that is not so easy. You can install geth on your computer and then create a wallet and put some ETH into it. After that, you would construct a draw object with the address and abi definition of the draw and then call draw.buyTicket with the right amount of gas to make sure your transaction goes through.
This is a process that excludes 99.99% of the population of the world!

There is a slighlty easier way, which is to use the Ethereum Mist wallet, which does most of the above for you. All you have to do is create your wallet and put ETH into it. You can then “follow” a contract (e.g. a draw) and call its methods (e.g. buyTicket).

But every instance of a draw will be at a different address on the blockchain, so how do you find the current one?

Enter Lottereo, our Lottery Orchestrator! Lottereo is basically a register of draws. It knows where the latest draw is and lets you buy tickets in the it. It will also give you information about the winners of previous draws. And all you have to do is follow the Lottereo contract in your Mist browser.

Let’s take it one step at a time. The contract defines a few variables to begin with, to hold draw information:

This allows us to define variables of this class that live at a specified address (i.e. a draw instance on the blockchain) and then call the methods that exist inside that specific instance (because they have the same name in the draw contract and in the Lottereo class definition). So, for example, this is how you buy a ticket through Lottereo for the current draw:

So now, a user only has to be able to install the Mist Browser and know the address and ABI definition of the Lottereo contract to play in whichever draw is the current draw. So maybe now we are only excluding 99% of the population instead of 99.99%

The Lottereo contract is here. Again, this is work in progress so things may change from what is described above.

Want to try it?

The Mist browser allows you to point to the real Ethereum blockchain or to the test blockchain, called Morden. If you point to Morden and create a wallet there, you can then get some fake ETH from here.

The Lottery Draw

Imagine a lottery where each “ticket” costs a certain amount of ether. When buying a ticket you are allowed to guess one number between 1 and 1,000. Your ticket “id” is simply the wallet address you use to pay the ether with, and it is associated with your guess. You can buy as many “tickets” as you like. Every time you pay and guess, your wallet address is entered again.
At the appointed time, the draw is made (a number is selected randomly) and the pot is divided equally between and paid to any addresses that correctly guess the number (minus a percentage commission for the organiser of the draw). If no one guesses correctly, then the pot (minus the commission to the organiser) gets transferred to the next lottery draw (a rollover) and the process starts again.

The “draw” contract

Each instance of the lottery we will call a “draw”. Our draw contract first declares a bunch of variables (see here for Solidity data types):

In our contract constructor we initialise all the variables, including setting the owner (who is the only one who can perform certain crucial functions later), the entry fee (i.e. the cost of each ticket), the address of the organiser (who will collect the commission fee) and the address of the previous draw (more on this later, but this is basically so that draws can be daisy-chained together). We also set the drawDate, which is the earliest possible date that the draw can be made.

Buying a ticket

The buyTicket function allows anyone who knows about this contract to buy a ticket:

If the value sent in by the ticket buyer is not the exact entry fee, then they will not be allowed to buy a ticket. Also, a ticket cannot be bought if the draw has already taken place!
If all conditions are met, the buyer's address and guess are entered in the draw by adding them to our tickets array.
The last line,

BuyTicket(ticketid);

is an Event trigger (Events are outlined here.). I won't go into detail on that because it is incidental to the rest.

Doing the draw

On or after the appointed time (drawDate) the draw can be made by calling this function:

The main thing to note here is that our "random" selection of a number between 1 and 1,000 is very crude. It is a massive problem with Solidity at the moment that it does not have a Rand() function. Almost anything about a blockchain is deterministic by design, so it is incredibly hard to generate randomness from things available from within the contract. We are going to be doing more work on this later, possibly integration this randomness contract. We will report back on that later. For now, let's assume that we have good randomness to generate a number between 1 and 1,000.

Crucially, any one could trigger the draw, not just the contract owner. So once a draw contract is out there on the blockchain and the earliest draw date has passed, even if he owners disappear the draw can still be held.

Once the winningNumber is obtained, we cycle through all the tickets to figure out if we have any winners, which are pushed into an array of wnningaddresses.

Paying out

The lottery pot is contained in the contract balance (this.balance).
A commission is calculated (10% of tickets bought), paid to the organiser. The remaining amount is assigned to a payout variable, divided between the winners and paid out to their wallets.

Note that if there are no winners, no more funds will be drained from the contract balance, which leads to....

The rollover

In the event that there are no winners, the pot gets rolled over into the next draw with this function:

This can only be done by the contract owner. It requires that a new draw contract be created that can receive the funds (_newContract). So basically the draws need to be daisy-chained so that one draw can send funds to the next one.

Other helpful functions

Additionally, we have a few functions that allow someone to query the contract to see if they have won: