Alright, so we want to have a digital money that people can transfer over the Internet between themselves directly, just like emails[1]. Most of us have already met with fake or spam emails pretending to be sent by someone else. Years ago when advanced AI-based anti-spam filters and other protection mechanisms (SPFor DKIM) were not widely available this used to be a bigger issue than it is now, but we all remember…
The easy part
Thanks to constantly growing adoption of new email standards (DKIM, S/MIME) leveraging electronic signatures to authenticate email messages it becomes harder or practically impossible to impersonate a sender[2]. Similarly, electronic signatures are slowly finding their way into legal recognition by governments as a trusted and bounding method of signing contracts between companies or individuals[3]. This has a potential to significantly speed up remote commerce and contract negotiation and execution. Moreover digitally signed documents can be used to prove an authenticity of a document to a third party or a general public, all remotely and via common electronic channels (email, website, or a specialized central registry).
Cryptocurrencies make use of the very same digital signature technology instead of re-inventing the wheel in order to prevent the fraud of impersonation. As we are about to see though, this is just one piece of the puzzle.
The hard part
Electronic money transactions, even when digitally signed by their senders, bring a new challenge that is not known from use cases mentioned above (email or document signing). On top of verifying the authenticity of the sender it is also equally important to agree on the global order of all transactions. This may not seem obvious at the first glance, but think about a potential scammer who owns $100 on his account and signs two transactions at about the same time, both spending full $100, but sent to two different parties[4] (this malicious practice is generally known as a double-spend attack). Obviously, we know that such two transactions may not be valid both at the same time; but which recipient should be the one that gets the money?
Let‘s evaluate the possible rules we could enact to solve this riddle once and for all:
1.) The first transaction gets cleared, the second (and all others) spending the same balance rejected
This is easy, right? So how can we determine which transaction was the first to occur?
a) require each transaction to carry a timestamp[5]
Think of a transaction as just a text message that contains some required information, like who is sending to whom and how much. It‘s easy to impose an additional requirement for transaction to carry an information about its exact time of creation.
Would this solve the problem though?
If the user is malicious and really determined to play the network or the recipients, what‘s stopping him from putting exactly the same time information to both transactions, which leaves us where we started? Or, he could send the first transaction out marked with current time on his computer, and then later send a second transaction that claims to be sent one second before the first one, according to the time information present in both of transactions. This is especially dangerous if the sender was paying for goods and the merchant already accepted the payment and let him go after seeing the first transaction, not expecting the buyer would sign a new transaction that invalidates the first one right after the order is processed, allowing him to walk out with the goods and not paying for it at the end of the day.
As we can see, if we can‘t trust the sender not to attempt the double spend attack, asking him to mark all transactions with current time does not help in any way.
b) make a note about current time whenever we receive a new transaction
This seems like a natural improvement over the previous mechanism — if the recipient marks the time himself instead of relying on sender‘s honesty, he can prevent being fooled with a trick described above.
What if the merchant wants to use this money later on though? He‘s got the digital signature of the original transaction which could serve as a proof of funds, but how does he prove to others that he really was the first one to receive these digital coins in an “unfortunate” situation when others have received them also (found themselves under an active double spend attack performed by the sender), without knowing about one another? Even if all „fooled“ parties were trying to be honest (not lie about the time they received the coins), which is already a far fetched assumption and definitely not something to be relied upon, they could still run into issue of comparing time stamps made at different physical locations, each one having its own clock skew (not to mention the theoretical limits of universal time in distant physical locations described by Einstein).
2.) If there are more transactions spending the same balance, they all should be rejected because the sender obviously attempted a scam
Now that we understand the issue with signing a late transaction that claims to be signed much earlier (and before another conflicting transaction), it’s straightforward to think of a similar scenario in the context of this new countermeasure. Under this rule a merchant would, in a good faith, confirm an order and consider it paid after receiving a signed transaction from the buyer, because there would be no conflicting transaction (one that spends the same digital coins) known for the merchant. Afterwards the buyer could maliciously create another transaction, just as described in the previous paragraph, which under this rule would nullify the first transaction which credited the merchant’s account, leaving the merchant fooled and without due payment for his goods or services.
You may think of many similar countermeasures to tackle this problem but the truth is that most of them go round in circles and are ineffective or outright useless at the end. For a long time this used to be considered an unsolvable problem, until the concept of Blockchain was introduced in Bitcoin.
Conclusion? Not yet…
What is it that makes Blockchain immune against all aforementioned attacks though? How is the universal consensus regarding the order of transactions reached in a huge network of people that don’t know each other and thus can’t blindly trust everybody not to attempt to carry out the double-spend attack? And does it really need to burn gigawatts of electricity power or can we do better? Let’s take a look at the most interesting technical concept that answers all these questions in the next post!
— — — — — — — — — — — — — — — — — — — —
[1]Technically emails can be exchanged directly between the sender and the recipient even though nowadays it is more common to route them through centralized services (big email providers like Google or Yahoo).
[2]It is only possible when these mechanisms are not in place yet or not configured properly.
[3]Recognised in UAE since 2006 under federal eCommerce Law, but also regulated all around the world including USA and EU.
[4]On the technical level it’s easier to think of cryptocurrency transactions as shares ownership transfers rather than a transfer of fungible coins. Each digital coin can be uniquely identified and thus you can’t just spend some generic $100 from your balance — you are always spending a specific coin(s) or bill(s).
[5]Timestamp is commonly used word in computer science, meaning the information about exact time (with precision down to microseconds).
Jozef Knaperek, Head of Development
