Our products

We are passionate about building niche multi-platform products that provide real utility to our customers.

Revision.net - social scheduling Revision
Tools to manage your social media presence(s). Schedule posts to Twitter and Facebook in a few simple clicks.
Anfield.com - Liverpool FC news from across the web Anfield
Keep up to date with Liverpool FC news from across the web.
Download the Anfield.com app on the App Store
DomainBites.com - Domain industry news Domain Bites
Domain name industry news and resources.
Download the DomainBites.com app on the App Store
PubReviews.com - Independent, social pub reviews Pub Reviews
Find the best pubs near you. Share your thoughts and photos.
Download the PubReviews.com app on the App Store Download the PubReviews.com app on Google Play


We like to blog about software. Our stack, engineering problems, open source developments.. you will find it all discussed here.

Taxation of cryptocurrency gains

This post is not explicitly related to Double Negative but rather to my own personal tax affairs. I am posting it here because:

  • Cryptocurrency is a hot topic right now
  • I think people will find this helpful
  • I have previously discussed tax and accounting on this blog
  • I have nowhere more suitable to post it.

Whilst the question is not particularly relevant a lot of the below was discerned after having read the answers to this Reddit post.

This is based on UK tax law.

Shares are fungible. Similar rules of identification apply to foreign currency (as made clear here).

As outlined by HMRC, Corporation Tax, Income Tax, or Capital Gains Tax are applicable depending on circumstances.

In my case the consideration is Capital Gains Tax as my Ether trades are conducted in a personal capacity and I do not regularly trade with a view to profit.

HMRC says that shares can be pooled. This applies to foreign currency too.

Other than consideration for "bed and breakfasting" rules (I.E. Obvious tax avoidance), chargeable gains are pretty obvious.

The "bed and breakfast" rules also provide some clarity on utilising an Exchange to buy cryptocurrency. Given that exchanges facilitate the purchase of 'coins' from other users who wish to sell them, one 'order' can often be 'filled' with multiple purchases.

The rules make clear that:

"All shares of the same class in the same company acquired by the same person on the same day and in the same capacity are treated as though they were acquired by a single transaction"

If the total of you sale exceeds £44,400 (for the 2016/17 tax year), you have to declare it in your tax return regardless of the size of your gain.


If you own cryptocurrency in a personal capacity, are UK based, and do not try to avoid tax..

Your purchases are pooled in a Section 104 holding.

When you sell you use the average cost of the pool as the cost basis. You pay Capital Gains Tax.

Here are some examples.

Ethereum Name Service (ENS) Integration

Today (Monday 8th May), I am able to announce some new functionality for EthTools.com - Accounts, and Ethereum Name Service (ENS) Integration.

Double Negative has always been a company created to build high utility web applications on top end domain names.

Having been personally invested in the Ethereum platform since the early days, it was only ever going to be of interest building on the Ethereum platform in a corporate capacity were there to be areas where we could add value in our niche.

We have quietly offered wallet management functionality, have been actively developing our chain explorer, and offer tooling pertaining to contracts as well as more 'tool-like' tools such as our unit convertor.

What are we releasing?

Today we are releasing EthTools.com accounts, and our ENS integration.


Popular web applications like Facebook and Twitter offer APIs which developers can integrate into their own offerings. The basic premise is that a user can login to a third party website using their Facebook/Twitter account. They do not need to fill in any long arduous forms, and can sign up in a matter of clicks.

Whilst there are more complex end-to-end identity offerings on the horizon (for example uport), we wanted to produce something more simple. Our offering allows you to simply authenticate (on the web) that you own a particular Ethereum address. No plugins, or third party applications are required.

Interface wise, we utilise our simple 'wallet flow' to allow you to load your account from a mnemonic or a Geth/Parity key file. You click submit, and you are logged in to EthTools.com. It really is that simple. Apart from your Ethereum address, we take no data from you.

In the future we will open up our API in a similar manner to how Facebook and Twitter have - you (as a third party web developer) will be able to direct your users to login using our tooling, and we will validate that information on your behalf.

Here is a picture.

It is that simple

Oh.. that really was easy.

Ethereum Name Service (ENS)

In a similar way to how there are multiple implementations of the Ethereum client (Geth, Parity etc), we felt that multiple implementations of the Ethereum Name Service contracts was imperative.

Given our domain name background, it has been extremely interesting to follow along with the development of the ENS. Massive thanks to the ENS team, especially Nick Johnson who has always been happy to answer my foolish questions.

On a personal level the ENS is essentially the meeting point of a number of my interests/knowledge areas. I have a degree in Economics, and actively follow the Behavioural Economics movement. Creating an implementation of the Vickrey Auctionr, and seeing it in action has been enlightening.

Unlike the 'official' client (which is mainly client side - that is to say everything runs in your browser), we offer an end to end ENS offering utilising both client and server side components. We interact with the ENS contracts (on the blockchain) to guide you through the whole process with a simple and easy to use interface.

Our offering allows you to:

Look up a name

Lookup a name

See name availability

See name availability

Choose a registration account

Choose a registration account

Submit a bid

Submit a bid

You can start/join an auction is as few as 10 clicks.

In addition to this we also keep track of your auctions and bids server side. We display details of your auctions, and their current status in a simple user interface.

Your auctions

From this platform you can reveal your bids (at the appropriate time), and finalise the auction (as appropriate).

Whilst in this 'soft launch' phase, why not also offer watch list functionality ;)

This is not my watch list. Honest.

This is not my watch list. Honest.

What we do not offer

Unlike MyEtherWallet, our codebase is not open source. We love open source, but given that our codebase includes a complex front end and back end set up, our tooling is not amenable to the 'Download a copy and run it on an airgapped computer' approach.

That is to say that if you use EthTools.com, we are asking you to trust us. In return we offer simple, end to end tooling for interacting with the Ethereum network.

We do not however ever transmit your private key over the network. If you have the time, you can monitor our requests to confirm that this is the case.

If you want to try out our offerings, and are (understandably) wary of a new player in the metaphorical game, why not transfer a small amount of Ether to a new account which you can then utilise with EthTools.com. It is a good idea to not use your 'main' account day-to-day anyway. You can create a new wallet here.

Unlike Metamask, we are a web application. Metamask is a browser extension.


We essentially wanted to begin to build the GoDaddy or Uniregistry (traditional domain name system registrars) of the Ethereum Name Service - a complete platform for the registration and management of ENS names. We have gotten the ball rolling, and hope that you will try out our offerings and let us know your thoughts.


I may as well take this opportunity to offer a disclaimer.

The Ethereum blockchain is big. Building our chain explorer was a fun learning experience in itself because it has to provide accurate data, in near realtime, from a huge data set. I learnt a lot building it, and will surely learn even more when something goes wrong.

The Ethereum blockchain is new. Whilst I have worked with Javascript and PHP for over a decade, I have worked with 'blockchain' for a year. If something goes wrong, let me know - I will fix it. Email me, phone me, tweet me.. whatever :)


Something specific that you would like to see? Same as above. Email me, phone me, tweet me.

Want to chat? Email me, phone me, tweet me.

I will stop now.

Verifying an Ethereum signature on the server - PHP

Ethereum has an extremely strong Javascript ecosystem. There are fantastic open source projects such as ethereumjs-util which provide out of the box functionality for signing messages with an Ethereum account.

One downside to Javascript is that in many areas it poses security issues. One such security risk became apparent as a result of my efforts to implement persistent authentication on EthTools.com (still a work in progress - you were warned).

It is fairly easy to utilise open source projects (like ethereumjs-util) to sign arbitrary data messages. What is less easy however is to tell a server that someone has successfully verified their ownership of account x.

Well.. that is not strictly true - it is really easy to do exactly that. Simply build a simple API endpoint and fire off a request to it upon successful authentication.

The real problem is that it is really easy to create a 'fake' request and send it off to the aforementioned (easily discernible - just look in the console) endpoint. I could easily fire off a request saying that I had verified ownership of any account.

With cutting edge technology.. especially technology that 'handles' real value it is especially important that security is given the importance and respect that it deserves. The is especially the case in light of the various attack vectors that have historically been exploited.

Furthermore, in its infancy Ethereum has attracted the best of the best - the people that know what they are doing. If there is a security vulnerability, someone will find it.

Now.. whilst it is possible to secure AJAX requests and make forgery harder, it is nigh on impossible to make things 100% secure. I needed another way.

The way I eventually settled on was simple - server side authentication.

Everyone can see

One great thing about interacting with the blockchain in the client is that within reason anyone so inclined can see exactly what you are doing. They can feel confident knowing that you are not sending their private key to someone else. How? They can look in the console and see each and every outgoing request.

The console

If a service were POSTing my private key anywhere I would be extremely concerned.

Within our implemented authentication flow a user can see that we are not sending any data anywhere - everything is done in the client.

Sadly however my authentication resolution does require POSTing data.. but nothing important (some may disagree).

We POST the authenticated public key to our API endpoint. Whilst you can not verify what we do with your public key on the server, there is not really anything nefarious we can do with just your public key - that is why it is public.

On the server we utilise the submitted public key to verify that the submitted signature was created by someone with knowledge of the corresponding private key. To be explicitly clear here - we do not know your private key, yet elliptical curve cryptography allows us to verify that the signature was created using it by simply using the public key.

The is the premise behind the ecrecover methods in ethereumjs-util and Solidity except these work in the client and on the Ethereum blockchain respectively.

On the Ethereum forum chriseth gives the following useful explanation of ecrecover:

"The idea of ecrecover is that it is possible to compute the public key corresponding to the private key that was used to create an ECDSA signature given two additional bits which are usually supplied with the signature. The signature itself is the two (encoding of the) elliptic curve points r and s and v is the two additional bits needed to recover the public key. This also explains why the return type is address: It returns the address corresponding to the recovered public key (i.e. its sha3/keccak hash). This means to actually verify the signature, you check whether the returned address is equal to the one whose corresponding private key should have signed the hash."

We want the same functionality on the server.

Note: Solidity's ecrecover returns an address whereas ethereumjs-utils ecrecover returns a public key

Note: Whilst researching I found a number of interesting StackExchange questions on the subject matter. These are as follows:

The web3.js API docs also provide some insight into the parameters of ecrecover noting:

After the hex prefix, characters correspond to ECDSA values like this:

r = signature[0:64]  
s = signature[64:128]  
v = signature[128:130]

Note that if you are using ecrecover, v will be either "00" or "01". As a result, in order to use this value, you will have to parse it to an integer and then add 27. This will result in either a 27 or a 28.  


EthTools.com is built on the Phalcon PHP framework.

There is no real Ethereum PHP community, and PHP has its shortcomings when it comes to dealing with numerical representations.

Then of course there is the small issue of Elliptical curve cryptography being extremely complex, and me lacking any prior knowledge of its workings..

That said after a significant amount of research, and a significant amount of playing I managed to implement the ecrecover functionality in PHP.

Whilst discerning how to do this I wrote some 'notes' which I have tidied up and included below on the off chance they help someone else in the right direction.

My logic of action was to sign a transaction using ethereumjs-util using a known Ethereum private key. I would then mimic the code path of their ecrecover method in PHP and play until the outputted public key 'recovered' from the signature matched that of the original signing account.


Within Node, Buffers are arrays of unsigned 8 bit integers. The digits are their base 10 (decimal) representations.

With 8 bits there are 2^8 = 255 decimal options. These integers are the numeric code point representations of characters from the UTF-8 character set.

Node utilises these buffers for data manipulation of the sort required for doing these kind of computations.

On the server we have various strings (the message hash, and the signature), but PHP does not know that the characters in these string are base 16 numerical representations (hexadecimal).

Each character is a 'nibble' which requires 4 bits of data to represent (allowed hexadecimal characters are 0-9 and A-F).
As such 8 bits of data is two hexadecimal characters.

In Node, the string '61bf09' is converted into a Buffer by taking each set of two nibbles and converting it to its decimal form.

  • 61 becomes 97
  • bf becomes 191
  • 09 becomes 9

To do the equivalent in PHP we execute something like the following:

$r_byte_array = unpack('C*', hex2bin($r));

We call hex2bin which converts the hexadecimal string (without 0x) to its binary representation (base 2). By calling this method we are implicitly stating that the initial format is hexadecimal.

unpack then converts the string to an array of code points - our Buffer equivalent.

Initially PHP just thinks the string is UTF-8. If we dont call hex2bin first the first int is 54.

unpack without hex2bin

This is because unpack simply converts the first character (6) to its binary code in utf8 (54). 64 characters = 64 code points.

When we tell unpack that we are dealing with hexadecimal, it converts each two character hexidecimal set (each character representing 4 bits of data) to its decimal representation. 61 (0x61) becomes 97. Our 64 character hexadecimal string becomes 32 8 bit integers.

unpack with hex2bin

You can see these different representations by having a play with this convertor.

Now that you have an appropriately formatted representation of the message hash and the signature you can cheat..

I like to think myself relatively intelligent. That said trying to fully understand, appreciate, and implement the 'secp256k1' elliptical curve is simply not going to happen. Furthermore.. why bother? It is another case of not reinventing the wheel.

I found a few libraries pertaining to secp256k1 in PHP. For example:

I ended up using a combination of bits from all three libraries - I like to know what I am using, and have a basic (at least) understanding of what I am pushing to our servers. Given that the above libraries are fairly feature rich/complex it seemed pragmatic to simply extract what I needed for my relatively simple functionality.

After spending a significant amount of time getting my head around what is going on I have finally managed to achieve what I was trying to achieve - I have managed to verify that a signature created in the client was signed my a particular private key.

I will now move forward with implementing the functionality that I had in mind when I first climbed into this rabbit hole.

Shimming dependencies of dependencies when working with Browserify

This post details as to why I wanted to implement Semantic-UI-React into our Revision.net project.

It was not however as simple as I would have liked as a result of our build process.

Such that heavy Javascript (that is regularly utilised across the site) can be cached (and served from a CDN) we build the libraries on which the site depends into a separate 'libraries' Javascript file.

Our Reactive components which depend on these libraries then utilise them. We achieve this by utilising browserify-shim within our build process.

Essentially when we require('React'), the browserify-shim transform tells browserify (executed as part of the build process) that React is defined on the window object.

When building an individual Reactive component, it does not need to include the React codebase within the built Javascript. Instead we tell browserify that it will be available globally. This makes on the fly builds significantly quicker, and makes the product much quicker (from a user experience point of view).

Usage of Semantic-UI-React is pretty straight forward. Unfortunately however I was encountering issues whereby Semantic-UI-React was not playing nicely with the build process - React was being built into the components output Javascript. As React was already included in the aforementioned 'libraries' Javascript this was causing issues as a result of the presence of multiple instances of React.

The problem was that the dependency of the project (Semantic-UI-React) also depends on React, yet was not utilising the shim configuration.

After a little research I stumbled upon this StackOverflow answer which outlines how simple it is to resolve this issue. It is simply the case of specifying the global option when calling browserify.

Now, it seems to be the case that you can not specify options from within your package.json file. It is however super simple to call the shim transform from your build script.

const bundler = browserify(file.path, {debug: true});

bundler.transform('browserify-shim', {global: true});  

With this change I was able to build Semantic-UI-React into my project 'libraries' and utilise it within my React component classes. Awesome !