Category Archives: Bitcoin

Dumb Contracts and Smart Scripts

Published by:

The rise of Ethereum and other “Smart Contract” platforms like Waves or Neo was very confusing for Bitcoin maximalists. They missed out on huge gains, meanwhile new investors were (and still are) cashing in on the hype. With Rootstock around the corner, I want to explore what “Turing Complete Smart Contracts” actually achieve. Are there any applications or is it really all BS?

What is a smart contract?

Smart contracts were first proposed by Nick Szabo back in 1996. To be clear: this is before the Blockchain Era. He defined a smart contract as follows:

A smart contract is a set of promises, specified in digital form, including protocols within which the parties perform on these promises. (…) The basic idea of smart contracts is that many kinds of contractual clauses (…) can be embedded in the hardware and software we deal with, in such a way as to make breach of contract expensive (…) for the breacher.

So Szabo envisioned contracts that had some kind of self-execution that is costly to attack. Obviously, once blockchain came around, people tried to implement smart contracts that were self executing and costly to attack using this new tech. After all, reversing transactions on a blockchain is expensive (if PoW is used) and provide censorship resistant transactions which could guarantee the self-execution. Enter Ethereum et al. They promised us Turning completeness, which means that “anything can be coded”.

All these new Smart Contract platforms are promising the users a new decentralized world: it would become possible to write and execute “unstoppable code” which could result in all kinds of futuristic innovations, like “a decentralized uber“, “a decentralized Air BnB” or “a decentralized Darknet Market“. Or more in general: decentralized computing. Ethereum tries to become “the world computer”. You can check the official Ethereum video below for more claims on what the Ethereum tech is supposed to enable:

eth_world_computer(click on image to start video in a new tab)

ISSUE 1: Real world assets

But when reading Szabo’s article, it becomes apparent that he was aware of the fact that trusted people and notaries were needed to be able to connect real world assets and actions to the smart contract. You can’t force someone using blockchain to hand over his car through software. You can’t force someone using blockchain to build an certain app according to the agreed upon specifications through software. You can’t force your drug dealer using blockchain to send you the weed you’ve paid for. It’s just impossible. In these cases, an arbitrator is clearly needed. Both parties need to trust a 3rd party who will decide on the settlement of the contract in case the parties don’t agree.

In these cases, when real world assets or services are being exchanged for a digital currency, it’s clear that “smart contracts” can’t add a lot. The only thing they can do is provide the logic for some kind of joint account. In most cases, this will be a simple “2/3 multisig”: The buyer, seller and a trusted third party create a joint account. When the buyer received the goods, he signs the transaction. The seller will sign as well and the money will be sent. If the buyer doesn’t want to sign because -according to him- something is wrong with the product or service, the trusted third party can do arbitration and issue a (partial) refund if he deems this appropriate. If the seller can prove he did deliver as was agreed upon beforehand, the arbitrator can decide to bypass the buyer and send the money.

But wait… What are we doing here? Isn’t this possible on Bitcoin for several years? Yes! This means that this whole use case is possible on Bitcoin as well. In this regard, Ethereum and other “smart contract platforms” aren’t adding anything useful. No need for “Turing complete platforms” it seems.

ISSUE 2: Trusted nodes

And what about the running of  websites or platforms? No real world assets are used in these projects. For sure there is more to this than just monetary transactions, right? Well, let’s think this through… Say we want to run a website on the Ethereum World Computer. This would enable the website to be “unstoppable”. Governments can’t shut it down because, presumably, the whole network is executing the code for the website. This sounds pretty vague. What could this mean in practice? The creators of the website put their code on the blockchain and all nodes download the code to open the website. If every node needs to download every website, this will result in huge bandwidth and storage costs. This seems pretty inefficient. If you don’t need the website, why should you download all the code for it? Usually, a user just downloads the needed files from the website’s server and opens it in a browser. What “Turing complete smart platforms” try to do, is the other way around.

Ok, so let’s say only certain nodes download the website content, other nodes are pruning it. What we are getting now is some kind of distributed servers to which casual users can connect to access the website. The users themselves won’t run full nodes to connect to their own version of the website. But… what is the incentive to run a full node? You only get paid for executing code, not for storing and broadcasting huge amounts of data. Let’s say that somehow the Smart Contract platform manages to code up a contract that makes a user pay for each data request to the node. [Note that this also requires something called “sharding” because when only certain nodes can deliver the requested data, only these nodes can verify the validity of the smart contract.]How is the user certain that he gets the correct version of the website and not an outdated version or, even worse, a faked version? This can’t be solved unless the user verifies the data with the original service. So either the user blindly trusts the node he connects to, or…

he just connects to the original node that put the website on the blockchain. So we’re back where we started… It’s clearly more efficient to just connect to a central server that serves the website. If you want an unstoppable website, just run it as a hidden service on the Tor or I2P network. No huge bandwidth and storage costs for the network, no need to trust nodes, no need to pay for access, … People tend to forget that the internet is pretty decentralized by itself. If you run your own server, you are running your website in a decentralized manner. It’s however more efficient and reliable to use a hosting company for your website 😉

ISSUE 3: Oracles

This brings us to the concept of oracles. An oracle is basically a trusted service that provides data. It’s a less radical idea compared to the pruned nodes being used as website servers, as the sole purpose of an oracle is serving a specific data input for a smart contract. Imagine a binary option on the EURUSD exchange rate. You can bet that the EUR will drop below 1 USD by the end of the year. The smart contract handles everything. All the code is running on the blockchain: you deposit an amount in the contract address and when the contract detects that when a euro indeed became worth less than a dollar, the contract executes and you’ll get double your money back. If this doesn’t happen by the end of the year, you lost your bet.

This seems pretty straight forward and easy to code, right? One little problem though… Where does the contract gets the data feed needed to check the EURUSD exchange rate? That data isn’t on the blockchain. It’s external. You can use for example a free API like this one to track the exchange rate and code that into your “smart contract”. But there is still a (huge) problem though… what happens when the data feed craps out and accidentally displays 0 as the EURUSD exchange rate for a minute? The smart contract would be executed automatically. The transaction is valid and immutable. So the creator of the binary option lost his money due to a bug in the oracle. You can probably use different oracles to provide data and ignore outliers. For example you use 3 data feeds and the smart contract automatically ignores the one that’s the furthest from the average and recalculates the average based on the remaining 2 oracles. This seems to have fixed the issue. If there is an outlier, it won’t affect the data used in the smart contract. But the weakness is still there. What if it’s december 31 and you are about to lose 10 million USD because the EURUSD exchange rate still didn’t drop below 1 USD. You now have a very big incentive to bribe 2 of the 3 oracles to display 0.9 USD as exchange rate for a minute. You pay them both 1 million to do this. The result? You’ll win the bet and receive 20 million! Oracles can also create bets themselves and deliberately create bugs in their software to profit from them.

Clearly, blockchains doesn’t solve this oracle problem, it makes it worse. While a wrong data feed on the NADAQ can be fixed by rolling back some trades, smart contracts on a blockchain can’t be rolled back (unless you are friends with Vitalik Buterin). I hope you now understand why I’m very skeptical on this whole notion of trusted oracles. You can trust an oracle if the stakes are low. If an error happens you either lose a small amount of money. If you trust your counterparty you may even get your money back if he’s acting honestly. But I’m sure that large corporations dealing with big transactions won’t trust these oracles. They will require someone signing off on the transaction. Yeah indeed, we’re back at trusted third parties.

If you don’t trust the oracle, can’t we just use a simple multisig transactions to decide who won the bet? The implementation is very easy: you run a “Smart Script” on a server. This server uses the oracles as input to decide when to trigger an alert that is sent to the arbitrator. The arbitrator manually checks if the data is indeed correct and if that’s the case, he signs the multisig transaction. If the arbitrator confirms wrong data, you can sue him and get your money back. So the oracle has an incentive to act correctly. This system is also very efficient, as the blockchain doesn’t need to check every “smart contract”, it only needs to verify the validity of the multisig transaction. Everything else happens off chain. I won’t go into the “innovations” that pretend to be building “decentralized oracles”. I’m pretty sure those are gameable as well, but this is beyond the scope of this article.

ISSUE 4: Scaling

Still not convinced that there is no real use case for “unstoppable code”? I’ll provide another example which does not require trusted oracles. One can imagine a gambling “dapp” (decentralized app) where the previous block hash is used as random number generator. You can bet on the hash being even or odd. The owner funds the smart contract with a pool of money. The gambler sends money in advance to the smart contract and bets on “even”. If the hash is indeed even, he gets 1.98x his wager back. When it’s odd, he gets nothing, so the house edge is 1%. This can all be coded and executed automatically. There is no need for a website, all this can be done on the blockchain. Often you would provide a (centralized – lol) website as a GUI for the clients, but it’s not required. The problem is: all this gambling transaction data still needs to flow through the whole Ethereum network. Every node needs to check all the games started by the users.

In the past, Satoshidice used to operate in a similar manner on the Bitcoin Network. You could send transactions to fixed gambling addresses and if you’d won, the website would automatically send coins back. But… you needed to trust the website to actually act honestly. They could in theory take your coins and run. This is an advantage of Ethereum then! Wait wait wait, not so fast. Satoshidice USED to operated as an “on blockchain” service, but it doesn’t anymore. Any guess why? The answer is simple: congestion. All those little transactions needed to be stored and forwarded by all the nodes. When in the early days Bitcoin wasn’t used much, there was enough block space for these low value transactions. But currently the fees are so high that such a service isn’t possible anymore. Thus Satoshidice switched to a centralized model: you first deposit bitcoin at the website an then you can start gambling. When you’re done, you withdraw your coins. It’s way more efficient to do it this way compared to the decentralized model. Been there, done that. It was fun, but it’s not sustainable for the network health in the long run. So no, Ethereum also doesn’t add anything useful here. By the way, Etherdice is currently unavailable due to… network congestion. Need more proof? Check this article on Microsoft dealing with Ethereum: they won’t use the blockchain itself, they need a more scalable solution which is off chain.

ISSUE 5: Miner incentives

Going back to the previous example, there is a second issue besides scaling: the miners can manipulate the block hash. They can bet and then only publish blocks with the desired hash. Actually, that’s why Etherdice uses the external data (probably random.org)  for their source of randomness:

The only external dependency is a source of randomness, as the deterministic nature of blockchains make it difficult to come up with random data within the chain in a secure way.

So if even a simple small gambling “smart contract” can’t even rely on the blockchain, how will big companies ever use this tech to create important and complicated smart contracts?

Need another example? I heard this story from someone in the Ether mining community: during a popular ICO, “investors” compete against eachother to get their transactions in a block as soon as possible, to not mis out on the fantastic “investing oppurtunity”. Some miners are being paid through a side channel to get their transactions in the blockchain. These miners reject other transactions. Or miners just buy the whole ICO themselves and exclude other investors. So mining incentives can lead to miner censorship to gain financially.

Need another one? At the moment, a decentralized exchange isn’t implemented yet. But imagine for example a miner that is able to censor certain buy or sell orders on a decentralized exchange and front run it with his own transactions? He would be the first to dump a certain token and thus be able to exit before the price crashes. It’s all possible.

So imho, “smart contracts” are not safe on a blockchain. You will need an arbitrator and a “smart script” on an external server to do these kind of things in a reliable, scaleable and efficient way.

Bearer assets only

So what we are left with are “smart contracts” that only use on chain data and don’t rely on the randomness of the block hashes, nor rely on the sequence of execution. The data that resides inside a blockchain is very limited in scope: transaction data, block hashes and timestamps. That’s it. So these “smart contracts” are actually just “dumb contracts”. They can’t do anything useful.

At the moment, the only on chain value is cryptocurrency. It’s impossible to blockchainify real world assets, as those assets are not digital in nature. Cryptocurrency is a so called “bearer asset”. The value is the token itself. You don’t need to trust an external platform. When you transfer the token, you transfer the value. There is a way in which we can broaden the scope of smart contracts: create new bearer assets.

At the moment this happens at a very high rate: the number of ICO’s on Ethereum is staggering. These tokens are representing the value itself. For most of them, trust in an underlying platform is needed, as the token will receive future profits as dividend. But the token still holds the (expected) value and should reflect the trust in the platform and the chances of ever receiving the dividend. So yeah, ICO’s are indeed a natural application of smart contracts. One could create a platform that has a revenue stream and the profits are automatically distributed to the token holders, without interference of the developers. This is a potential use case of smart contracts, but it’ll probably suffer from the same inefficiencies as we saw with the satoshidice example. It can’t operate at scale. If the owners/developers of the platform are manually approving dividend payouts, there is no advantage for using a “Turing complete smart contract platform”. This can be done on Bitcoin as well through the Colored Coins protocol. No need for Ethereum. Also consider the potential legal risk for these ICO’s. Most of them will be shut down by regulation. The remaining ones will be shady “decentralized companies” (darknet markets) and investing in them may by itself be a risk.

There is also a more interesting type of bearer assets: cryptofiat. If governments ever decide to issue fiat on the blockchain, then the token can represent the value itself. In that case in theory more interesting smart contracts will become possible. If you are able to create a decentralized exchange you could, theoretically, have on chain exchange rate data, removing the need for oracles. But as we saw blockchains can’t safely implement on chain trading. And again,  blockchains are very inefficient and any large scale trading won’t be possible anyway. It all sounds nice, but it’s not possible in practice. And besides that, I don’t think governments will ever put fiat on a blockchain. They dislike bearer assets and prefer registered value for tax purposes.

Turing completeness is adding more risk than benefits

So in my opinion, blockchains aren’t really useful for smart contracts. The (very limited) added benefits are not worth it because we also need to consider the risks. The fact that the platform is Turing complete, makes it very hard to build secure applications. We’ve seen this with the DAO fiasco. I rather trust a solid blockchain that focuses on being money than trying to apply “smart contracts” on a blockchain with in most cases no benefit at all and substantially more risk.

So “smart contracts” are possible…

… but only in very specific circumstances. Scaling issues prevent widespread use. The only “smart contracts” that can function on a blockchain are contracts that are easy to compute, don’t require much storage and bandwidth and aren’t executed very often. So in practice, this can only apply to large transactions. It’s economically infeasible to execute a lot of small value transactions using smart contracts on a blockchain. If you still want to scale the number of transactions, you’ll need to use “smart scripts” running on an external server and settling periodically to the blockchain. The smart contract also comes with a risk if you use oracles, so you are better off using multisig on chain and a “smart script” on an external server. If you don’t want to use oracles, you are limited to bearer assets using only data that is on chain, resulting in “dumb contracts”.

 

 

ShapeShiftOpenAlias

Thoughts on mining centralization and PoS weaknesses

Published by:

In this article I want to dig a bit deeper into how secure PoW and PoS really are. I start with PoW and describe why decentralized mining is important. Then I move onto PoS and will show it’s a fundamentally unsafe system to run a decentralized cryptocurrency. 

Proof of Work – importance of the decentralization of mining

In general, PoW makes sure that the network selects a validator of a block at random. This is a desirable feature so joining the network is permisionless which ensures decentralization. It’s also important for censorship resistance: if everybody has the ability to create blocks, then it’s very difficult for governments to forbid everyone to create a block which includes a certain undesirable transaction.

In this sense it’s also important to note that mining decentralization is desirable. the “1 CPU = 1 Vote” Satoshi envisioned is the only real guarantee that mining stays decentralized and thus censorship resistant. Sadly mining centralization is happening in most cryptocurrencies. There is still ongoing research for so called “asic-resistant” algo’s. ZCash uses Equihash (but as far as I know it’s mainly GPU mined) and Monero uses Cryptonite, which is partly CPU partly GPU mined due to optimizations for CPU AESNI operations (CPUs still have a decent hashrate compared to GPU’s).

So in my opinion, decentralization of mining is very important to avoid blacklists of txo’s. At the moment, just a handful of pools and mining farms are responsible for the large majority of the hashrate. These companies can easily be compelled to enforce blacklists. In this sense, botnet mining is a net positive for a currency: it makes it extremely hard to force miners to enforce blacklists or shut down the network.

I saw your counterargument in some older video: the hashrate increase per chip will slow down so ASIC chips will become more distributed again. Even if that happens, there is still the issue that only a few companies produce those chips. Peter Todd alluded to this in an interview a 2 years ago: he said the following: “The most fundamental way is for[governments] to regulate ASIC manufacturing, e.g. by forcing [manufacturers] to add ‘kill switches’ to the hardware, and/or require end-users to have licenses.”

I tend to agree with Todd on this: governments will find a way to regulate ASIC chips (either the production or the users) as long as chip production is centralized. If ASIC production would become more distributed in the future, this problem can become less important. But creating ASICs is a very specialized business, so I don’t see this happening any time soon.

Proof of stake – General thoughts on the weakness

With PoW, the hash puzzle is generated by the network. The difficulty is set by consensus rules and the randomness is set by the data in the previous block. The miner needs to generate a random nonce to find a solution to the hash puzzle.
The only way to do a double spend is by withholding blocks and secretly mining a longer chain than the entire network. this requires 51% of the hashrate (or a bit less if you’re lucky).

With PoS, there is no hash puzzle. This means that the validator whose turn it is to sign a block can easily create multiple blocks (and thus forks) to try to doublespend coins. Also there is no objective way to determine which chain is “the real chain”. With PoW this is determined by the chain with the most accumulative PoW, but this option (obviously) isn’t available with PoS.
There is also no real randomness. So it’s deterministic based on data in the blockchain which user/address will be allowed to sign the next block based on blockchain data which means that a signer can know in advance which user/address will be allowed to sign the next block based on the block data he is signing.

PoS reverts back to an unsafe version of PoW

If a signer knows which address will be picked as the next validator, it is (at least theoretically) possible for the current validator to manipulate the data in the block he’s currently signing in such a way that he’ll be the next signer.

Some examples on how block data can be manipulated:
* transaction malleability
* sending transactions to oneself
* dropping transactions from the block
* changing the order of the transactions within the block

This leads to a very dangerous attack: when a validator is picked by the network, he can then calculate (Proof of Work!) a lot of possible blocks and try to find a new block that will enable him to be the new validator. He can even try to find a series of blocks that will make him the validator for (for example) the next 10 blocks. Meanwhile he can publish another block for which he won’t be the next validator. By doing this, he has the abiity to double spend. Once he managed to pull of the double spend, he releases his other chain for which he’s the only validator. This chain will then become the longest chain and the attacker doubled spent successfully.

Note that if the validator didn’t manage to “attack” the network, he can try again when it’s again his turn to sign a block. One does not need 51% of the coins to be able to attack. This assumption made by proponents of PoS is -imho- false.
Also the cost of attacking is significantly lower compared to PoW. While for a 51% on PoW you need to spend a lot of money on electricity and you need to continuously spend that money, an attack on PoS can be done with a minimal amount of energy.

Reverting a transaction retroactively is nearly impossible with a PoW system, because you’ll need to have a lot of hashing power to “go back in time”. If you want to revert a transaction that has 1 confirmation, you need to mine 2 blocks while the whole network is searching for 1 block.
h^2  = (1-h) => h = 61.8%
You need 61.8% of the total hashrate to change a transaction with 1 confirmation, on average. Note that if a transaction has more confirmations, you need a larger share of the total hashrate of the network.

In the case of PoS, you can easily try to revert every transaction from a block height in the chain where you were a validator and you don’t need spend substantially more to revert a transaction that has more confirmations.

PoS attacks can be “solved” by centralization

This attack can be “solved” by having a limited number of “trusted” witnesses that keep track of which blocks they received first. If they then detect an alternative version of a block, it indicates a attempt to attack the chain. Then these witnesses can flag the attacker and he may be punished by loosing a part of his stake.
The problem with this is that this group of witnesses/people/nodes/validators/… need to be trusted. It’s not decentralized. Once the witnesses are in power, they can collude to attack the chain.
This witness system also raises a lot of questions surrounding reaching consensus:  what is a few witnesses disagree with the others? Who is right? The majority? It’s not as easy as it looks because an attacker can try to submit his block with the double spend to a majority of the witness nodes and the ‘fair’ block to a minority of the nodes. If he succeeds, the attacker “legitimately” double spend!

It is pretty obvious a currency doesn’t want to have anonymous witnesses. If they are anonymous, they have a very big incentive to attack the chain themselves and perform double spends. After all, there is no objective way to determine who “is telling the truth” when a double spend happens. So there will usually exist a process to appoint these witnesses. This will in practice often look like elections.
In Bitshares it’s quite literally that. they use “Delegated proof of stake” (DPOS) in which people need to be trusted community members to be able to raise enough stake votes to become a witness. In DASH the requirement to be a witness (aka masternode) is currently owning 1000 DASH, but this will change once the “evolution savings account” goes live which will be a variant of DPOS. The Casper system proposed by Ethereum will likely also be a variant of DPOS with a limited number of witnesses. So for currencies who have some kind of witness election, these public people who act as witnesses can be forced by governments to censor or even revert certain transactions.

Proof of stake – the choice between a  constant forking blockchain or centralized witnesses

To conclude, the a naive implementation of PoS will lead to a blockchain that is able to fork and do reorgs constantly, which is completely unworkable. Why didn’t we see this yet? My guess is because the on chain value never was high enough to be worthy of an attack.

The “solution” by centralization depends not on decentralized hash puzzles but on trusting individuals to not cheat. This is certainly not permisionless. These solutions aren’t decentralized and the government can thus easily try to force witnesses to censor certain transactions.

This leads me to the conclusion that PoS currencies can’t guarantee censorship free transactions, which is -imho- the only value behind a cryptocurrency. If we accept censorship, we can just start using Paypal. No need for an inefficient blockchain at all.

ShapeShiftOpenAlias

On Fungibility, Bitcoin, Monero and why ZCash is a bad idea.

Published by:

Screenshot from 2016-06-09 03:02:30

(This article was republished on steemit.com on 2016-07-12)

When bitcoin launched, a lot of people thought they finally had decentralised digital cash. We saw people using bitcoins for ideological reasons, but also for the presumed anonymous properties. You didn’t need to provide any identity information to create a wallet or send a transaction. Anonymous magic internet money. Cool, right?

Over the years, it became more clear that bitcoin isn’t anonymous at all. All transactions can be traced on the blockchain. If you transact with a stranger at a bitcoin meetup, he could start guessing your total bitcoin balance in your wallet. When you interact with regulated bitcoin businesses, you are required to provide ID information. And you can be sure that this company will couple your customer data to your blockchain fingerprint. This data can be handed over to law enforcement upon request, and be used to analyse the blockchain and associate more activity with you, or reveal connections with certain people, markets or online services.

A lot of bitcoin tracking companies started to deanonymize users by using this data and are actively trying to map the whole bitcoin blockchain.

Screenshot from 2016-06-09 03:09:12

So how can we avoid this bitcoin tracing?

Some people started to offer mixing services. These are centralised platforms where you send your coins to and you (hopefully) get coins back which aren’t related to your coins. The problem with this is that these platforms can be honeypots operated by law enforcement, or can just go offline and run with your money.

Another option is a form of coinjoin/joinmarket. This is a system where people let other people know they want to mix their coins. People eventually sign one big transaction with all the inputs of the people who wanted to mix at that certain point in time and get outputs from that transaction to a new address.
This somewhat breaks the link, but there is still a degree of traceability: once you get coins back in different outputs and you start transacting again, these outputs will probably be joined again and it’s possible some of the outputs can be linked to the inputs.
A sybil attack is also possible: when you mix with coinjoin, you assume these people are random, but these people could in fact all be law enforcement just waiting for the mixing transactions to happen. If you only “mix” with one party, that party knows your inputs and outputs, while you assume that you now own anonymous bitcoins. This is a very dangerous situation!

But the biggest issue isn’t even the centralized mixers running with your money, honeypots, or traceable coinjoins. It’s something that is -in my opinion- a very underestimated issue:
Enter fungibility.

digital-cash-702x336 (1)

Fungibility is a property of money that makes every unit if this money interchangeable: you can pay someone with a paper note and the receiver won’t care where it came from. As long as this note isn’t counterfeited, he will accept it and exchange goods or services for that paper note. This is how physical cash works.

But how do we enforce fungibility on a transparent blockchain where every transaction is visible?

All forms of mixing on transparent chains are active forms of mixing: if you want to mix coins, you need to find other people who want to mix as well. This makes the system vulnerable to sybil attacks/honeypots and, more importantly, people can see on the blockchain you tried to mix your coins. This act in itself could already be considered a crime: you are actively money laundering your coins.

Even if using a mixing service isn’t viewed as a crime, there are still a lot of fungibility risks associated with mixing. First and foremost, there is the possibility of blacklisting coins.
Even if you succeed in anonymizing your coins, there is still a trail. It’s pretty easy to know by analysing the blockchain that certain coins were sent to a darknet market for example. So if you try to mix your coins, you do that with coins from an unknown source (that’s the whole point, remember?).

Suppose that after mixing, you get coins back which were used in a drug transaction. Suppose the DEA busts a house of a drug dealer and follows the trail of the bitcoins that guy earned. The DEA may eventually find your wallet as the destination of the drug money. If you then spend these coins at a website that uses a payment processor, your customer data is connected with this drug money and you may get a knock on your door by law enforcement. If you try to sell these coins at an exchange, it’s possible your account will be blocked and your coins will be confiscated and sent to the government wallet. Certainly in the USA this is a risk because Civil Asset Forfeiture laws are broadly applied.

Another problem is mining censorship: miners confirm transactions. Up until now they seem to confirm any valid transaction. But what if law enforcement goes to the biggest miners in the world (representing at least 51% of the hashpower) and tells them that if they continue to confirm easily identifiable mixing transactions, they will be accused of money laundering. What if they aren’t even allowed to build new blocks on blocks containing such illegal transactions? It’s all possible in theory. Regulatory compliance by miners is -in my opinion- just a matter of time.

This is the fungibility problem that a transparent blockchain faces. Note that 99% of all cryptocoins are using a transparent blockchain, even the (in-)famous cryptocoin DASH, which just offers a form of CoinJoin that is built in the GUI wallet and mixes the coins on centralised “masternode servers” that can log every input and output.

monero

Enter Monero.
What makes Monero different from all other cryptocurrencies? Well, unlike Bitcoin, it uses a passive form of mixing.

How does this “passive mixing” work?
Monero uses ring signatures to obfuscate transactions. When you create a transaction, your Monero client randomly selects some transactions from the monero blockchain and signs a “ring signature”. Along with this ring signature, some kind of “fingerprint” is published, called the key image. This results in a transaction where an observer can’t know who is the real signer, but has cryptographic proof that it’s a valid transaction and no double spend happened.

Because your client picked the other transaction outputs randomly, those outputs are obfuscated even more. And this happens without them signing anything. Their coins can even be stored on a paper wallet and still be included in your transaction! So when sending a transaction, you not only immediately have plausible deniability about your own transaction history, but also obfuscate the blockchain even more. You generate positive externalities when you transact. The more people are using monero, the better its privacy will become.

In Monero, ring signatures are combined with stealth addresses to also make it impossible to identify the receiver of the coins. A transaction is sent to a “one time address”. The receiver needs to constantly scan the blockchain with his private viewkey to know which transactions are meant for him. With his private spend key he can then create a ring signature and spend his coins. Soon Confidential Transactions will be added to Monero with the goal of also making the transaction amount invisible. This will also solve some small issues with Monero privacy that now still exist.

But what has this fancy mixing system to do with fungibility? It’s still possible to track coins and see that certain coins are mixed, right?
Well, no: the use of ring signatures is enforced by the Monero protocol. Unmixed transactions aren’t allowed on the Monero blockchain. This results in every transaction being in a ring signature and obfuscating the chain even more. This guarantees fungibility on 2 levels: it’s impossible to track coins due to the default mixing and nobody can prove that you initiated the mixing thanks to the plausible deniability features of ring signatures.

The only exception to this are the newly minted coins: these coins don’t have inputs, so they can’t be signed with a ring signature. But this is actually an advantage, as it makes it possible to verify that the amount of newly minted coins is according the the emission scheme. However, other transactions can include these minting transactions in a ring signature. So when that happened at least once, the miner has plausible deniability on whether he spent his freshly minted coins or not.

This means that accepting or spending Monero doesn’t have any risks of being tracked, blacklisted or censored. You simply don’t know what is happening but you can verify that no double spends are happening and that the supply scheme is honoured. Some issues still exist, but these are minor and are actively being researched by the Monero Research Lab. See their research papers for more info. Monero is an (almost) perfect form of digital cash.

Note that Monero will only give you the full benefits of its technology as long as you stay inside the system. Once you start using Monero as some kind of mixer by buying XMR with BTC and spending your XMR immediately after that, some timing analysis can happen based on the bitcoin and monero blockchain. You shouldn’t enter and exit the Monero system every time you want to transact anonymously. This would diminish the privacy and fungibility aspects of your transaction. In stead, you should just use the funds you already have stored in the network. Monero as a sidechain to Bitcoin is therefore not a good idea. People who actually store a part of their wealth in Monero, will benefit from the obfuscation created by other people transacting. Monero is therefore only useful as a separate fungible network.

Screenshot from 2016-06-09 04:26:19So what’s all that buzz around ZCash?
Isn’t that coin claiming to be completely anonymous and better than every other anonymous cryptocurrency out there?

ZCash is a cryptocurrency project that originated from the Zerocoin/Zerocash idea, proposed back in 2013. Almost every “old time” bitcoiner knows about it. It was proposed to be integrated in the bitcoin codebase so that you would have the option to send a zerocoin-transaction using the bitcoin blockchain. You would need to “pour” your bitcoins in the Zerocoin mixer and from that point onwards, you could transact anonymously using the Zerocoin-protocol. When it became clear that Zerocoin wouldn’t be implemented in the bitcoin codebase any time soon, they worked for a while on implementing it as a sidechain.

But at some point the Zerocoin-team pivoted and decided to launch the altcoin ZCash. There is nothing wrong with trying to launch an altcoin, but, in my opinion, an altcoin can only survive long term if it actually offers something that is unique and probably can’t be adopted by bitcoin. The fact that it’s possible to add ZCash as a sidechain to bitcoin, should already raise some red flags.

The ZCash team decided to launch ZCash as an altcoin so they were able to fund the development: ZCash has a US-based company behind it and will tax 20% of the mining revenue during the first 4 years to pay off private investors. If ZCash were to succeed, the private investors will benefit greatly from the launch of this cryptocurrency. Although I don’t like ICO’s, a public coinsale (a form of crowdfunding) would have been a more fair and open way to fund development than seeking money from private investors.
This is in great contrast with the launch of Bitcoin and Monero, which were fairly launched, without “premine”, “mining tax” or some kind of company behind it. In my opinion, a successful large cryptocoin will probably be grass-roots, but it’s possible I’m mistaken here. Maybe some people actually prefer a corporate coin like ZCash. Time will tell.

But let’s dive into the tech a bit to compare its features with Bitcoin and Monero. The first thing that strikes me is the fact that ZCash allows transparent transactions: mined coins are bitcoin-like transparent “base coins”. When you want to spend them, you have the option to do an anonymous “pour” to enter them into the ZCash mixer. It’s basically the same idea as using Zerocoin as a sidechain.

This ZCash mixer functionsScreenshot from 2016-06-09 01:54:03 as a “black box”: you can see what is entering and what is exiting, but you can’t see what is happening inside the ZCash-mixer. This fact alone doesn’t magically make ZCash fungible: transparent transactions are still possible, so the mixing isn’t default.

It’s also an active form of mixing, not a passive form like on the Monero network. Because you need more than 8GB of RAM to do an anonymous ZCash transaction, it’s very likely that the mixing won’t be enforced any time soon and, what’s even more concerning, the large majority of transactions will probably just be transparent bitcoin-like transactions.  Another concern is “timing analysis”: if the ZCash mixer isn’t used much, you can try to connect coins entering the mixer with coins exiting the mixer. Certainly for larger transactions this is a real possibility.

The fact that transparent transactions are still possible, also makes your OpSec dependant on others: even if you try to anonymize your coins as much as possible, you can still be deanonymized if the people you transact with aren’t using the same standards. It’s even possible you’ll be forced to use transparent transactions if you want to use some kind of (regulated) service. This will result in the same issues as described on a transparent blockchain. Identities will be attached to addresses and this can eventually lead to blacklisting or even miner censorship. The fact that mixing isn’t enforced on ZCash is bad for fungibility and anonymity.

Another problem with ZCash is the fact that it’s brand new cryptography. Nobody can really guarantee that there aren’t some bugs in the system that will make it possible to deanonymize transactions or create coins out of thin air. What’s more, if coins are being created, it will not even be detectable because, unlike Monero, you can’t verify the total amount of coins in the ZCash blockchain. During the alpha test phase, they already found such a bug. Nobody can guarantee that similar bugs won’t exist when ZCash launches. It doesn’t seem a great idea to base a monetary system on brand new crypto. Accidents can happen, and when they happen, the value will plummet.

Related to this issue of brand new cryptography is that some features like multisig are not that hard to implement on Monero, while for ZCash this will require a lot of research. Meanwhile, ZCash will probably use the bitcoin-styled multisig on the transparent part of the network.

The ZCash extended paper also mentions a theoretical “poison pill attack” (section 6.4). This attack makes it possible to target a single user with the goal of deanonymizing him. It seems this attack is easier to perform when the targeted user uses an anonymous network like Tor. Monero, in contrast, is integrating with I2P.

toxicAnother problem ZCash faces is the “trusted setup”, the so called cryptographic “toxic waste” problem. This is some data that is needed when the initial parameters of ZCash are created, but needs to be deleted afterwards. If somehow someone gains access to this “toxic waste”, this entity can create coins out of thin air without anyone noticing. This is a serious problem because this makes a malicious backdoor in ZCash a real possibility.

The fact that ZCash is a US-based company, doesn’t really help with building confidence in this cryptocurrency. It’s not unthinkable some agency will require the ZCash team to make a copy of this “toxic waste” and hand it over to them. Just google what the US government did to the owners of e-gold, Liberty Reserve and the Liberty Dollar, and you’ll understand what kind of pressure they can exert on the owners of the ZCash company. If coins can be created at will, the inflation will diminish the value of the coin.

There is a clear trade-off between using Monero or Zcash: Monero is a usable and default fungible cryptocurrency based on solid cryptography without “trusted setup” by a company. The whole Monero blockchain becomes more and more obfuscated over time when people are transacting, which mitigates the “imperfect” anonymity. Meanwhile, the anonymity of Monero is also being improved on a technical level by the Monero Research Lab.

ZCash on the other hand has a different approach. They offer a completely anonymous mixer, but not by default, resulting in fungibility and anonymity problems. It has some serious issues related to the “toxic waste” during the “trusted setup” and has a lot of additional risks due to the brand new cryptography that is being applied.
Is it an interesting research project? For sure. Should it be applied in a cryptocurrency? No.

Sidenote: it’s perfectly possible to add a ZCash mixer to the Monero blockchain. In that case the “base coins” are the normal Monero-tokens that already are in circulation and people can choose to send their coins to a ZCash sidechain. The Monero network will need to check if the total number of XMR that goes into the sidechain is always larger than the total number of XMR that is exiting the sidechain.
Even if a hacker finds an exploit to create XMR out of thin air inside the ZCash mixer, he will only be able to drain the sidechain, not the mainchain. Use of the ZCash sidechain is then at your own risk. No additional Monero can be created on the mainchain, which is still perfectly fungible.

EDIT: Zooko reached out to me to point out he didn’t start the zerocoin/zerocash project. He became involved at a later point in time. Article changed accordingly.
EDIT2: Zooko asked me to be less speculative about the motives surrounding the launch. I linked to the article he provided.

 

ShapeShiftOpenAlias

Trezor firmware for Monero – First impressions!

Published by:

The Monero core team member NoodleDoodle recently released Firmware for Monero integration with a Trezor hardware wallet. It  still a beta so it’s not recommended to store large amounts of moneroj on it. I decided to give it a try so I could help to test this awesome piece of software 🙂

First some background on what a Bitcoin Trezor is and why it is useful:

What a Trezor does is making it safe to use cryptocurrencies.

A lot of bitcoins are lost because people are hacked. When a hacker gets access to you private keys, he can steal your money. Some people don’t want to take the risk to store their crypto themselves, so they leave it on the exchange. But that is also a big risk (do I need to remind you about Mt. Gox?)

This is the reason why in 2014 the guys from Satoshi Labs started selling the first ever Bitcoin hardware wallets. A Trezor locks your private keys inside the device. After initialization, it’s impossible to extract the private keys from the Trezor, so your bitcoins are stored securely.  They designed a protocol that makes it possible to communicate with your Trezor device securely.

Screenshot from 2016-03-07 19:54:37

When you create a bitcoin transaction in your Trezor compatible Bitcoin client (for example Electrum or MyTrezor.com) you send an unsigned (“raw”) transaction to your Trezor device. The Trezor will show the transaction details on his screen and you need to manually approve your transaction by pressing a button on your Trezor. When you confirmed the transaction by pressing the button, your transaction is signed by the private key in locked away in your Trezor and then send back to you client. The client then broadcasts your signed transaction to the Bitcoin network.

The Trezor protocol doesn’t allow extraction of the private keys from the device, so you can always spend your coins safely. By this time, you probably ask yourself what happens in case you loose your Trezor or in case it is broken. The answer is easy: during the initialisation of your Trezor, a 24 word seed is shown on the screen of the device. You need to write these words down. This is the backup in case something goes wrong. It’s a BIP32 seed, so you can import your backup in a lot of different wallets (blockchain.info, mycelium, electrum, …) or in a new Trezor device. Your Trezor is also protected by a PIN code, so in case someone steals your device, he can’t get his hands on your coins. Optionally, you can even set multiple passwords on your Trezor device. Every password crates a new account on your Trezor and provides plausible deniability: you can never see how much accounts are stored on the Trezor.

Back to Monero. What NoodleDoodle did was writing a piece of software that makes Trezor compatible with Monero. This makes it possible to securely store your moneroj on the Trezor hardware wallet. I tested this software, and the it functions in a similar way as the Bitcoin version of the software. You can’t send transactions unless your Trezor is plugged into your computer. Transactions are broadcasted after you confirmed it by pressing a button. You still need to perform all actions from the command line wallet. For usability, I hope the Trezor will be integrated in the “official” Monero GUI.

One minor catch: your private viewkey is sent to your Monero client. By default this information is deleted when you close your client (note that with the Bitcoin version of the software, your “master public key” is also shared with your client). I asked NoodleDoodle and it will optionally be possible to have a watch-only type of wallet in the future, so you can watch incoming transactions while your Trezor isn’t connected to your PC.

When you want to give this Monero firmware version a try, you can download it here. The download also includes a small manual on how to update your Trezor and on how to use it. It is possible NoodleDoodle will still change some features and user experience, so when the software considered “stable”, I’ll write a small manual with some printscreens to help you get started using Monero securely.

If you don’t yet own a Trezor, you can buy one here. Note that this is my personal affiliate link. If you buy a Trezor through that link, I get a % of the revenue (but you just pay the regular price!).

If you buy through this link, I pledge to donate 5 USD per Trezor to NoodleDoodle for his awesome work. You can also donate to him directly by sending XMR to his address:

47AYtJeNKJjYNZLj71nBW938mbFSFwq1x4qVcNhBmdfUjhaqiGN7wqpVjH419eLYPzHFeF3TgzY2fDivz5EyGBYUSbAXwed

If you are waiting for the delivery of your Trezor device, you can enjoy these 3 pictures in the meantime 🙂

2016-03-08-134148monerotrezor2monerotrezor1

 

 

 

 

FFFFFF-1

Bitcoiners, why not hedge your position?

Published by:

Bitcoin is stagnating. There seems to be no consensus on how to scale bitcoin. Bitcoin blocks are almost full. Transactions are slow. On the regulation front, it’s possible that the traceability will be used to enforce blacklisting or whitelistingMining is centralized, this can lead to governments forcing mining pools or big mining farms to filter certain suspicious transactions.
Will bitcoin lose its monetary characteristics due to these issues in the long run?

If you answered this question with a “definitely not”, you are in denial. This is a threat to the future of bitcoin as money. There is always a chance that Bitcoin becomes obsolete. We saw Digicash, e-gold and Liberty Reserve also ceased to be money. So, my advice would be to find a good hedge for your BTC position.

What characteristics are needed for a good crypto hedge?

1. No Bitcoin copy

Most of the altcoins are forks of bitcoin with a minor tweak. Litecoin was popular in the past because the mining algorithm was GPU-friendly, and thus decentralized. Since scrypt ASICs exists, this unique selling proposition is gone. LTC is a very bad hedge against BTC because most of the code is identical.
LTC is exposed to the same issues as BTC: problems with scaling, a possible error in the BTC codebase, traceability of transactions, etc.

2. Unique features

The hedge should have some use case. If the only demand for the coin is to function as a hedge, then it probably won’t succeed because there is no market demand, unless BTC is in trouble. Once the issues are resolved, the value of the hedge would drop dramatically. There are some coins with a decent market cap who fit rule 1 and rule 2:

Ether: decentralized smart contracts
Ripple: different consensus model  (note: almost dead because no use case and considered a scam by many because not really decentralized)
Maidsafe: decentralized cloud storage
Peercoin: first Pow/PoS hybrid
Factom: notarizing on the bitcoin blockchain
NXT: decentralized asset exchange

3. No apptoken

However, most of these coins, with the exception of Peercoin, aren’t “coin-like coins”. They are apptokens and it is very likely that all features can be implemented with bitcoin as currency in the future (on a sidechain, or maybe just on top of bitcoin itself). There is a chance some of them (maybe Ether?) will survive on their own if the development is strong and the userbase is solid.
But even if an appcoin can stand on his own legs, this isn’t a guarantee that it will be valuable because there will only be demand for using the apptoken when using the application. There won’t be monetary demand., incentivizing to store a portion of your net worth in it. This gives these coins a very questionable long term value proposition, again with the exception of Peercoin (maybe).

Monero

I intentionally left out Monero. Currently it has a market cap above 10 million USD and I think this is the perfect hedge for your bitcoin position.

Why, you ask?

  • Monero has a different codebase: it is based on the “cryptonote protocol” and is building a lot of additional functionality, like RingCT (Ring Signature Confidential Transactions)
    resulting in default untraceable and unlinkable transactions. This makes monero real fungible and anonymous eCash. Browse this website for more information on this subject.
  • Monero uses a different elliptic curve. If the BTC curve is broken, the XMR curve could still be solid (and vice versa).
  • Monero also has a scaling solution baked in the protocol: it has a dynamic block size limit. If the demand for transactions goes up, the block size limit will scale. For this to work, it is necessary to have a “tail emission”. When the initial emission of 18.4 million moneroj runs out, a minimum block reward of 0.6 XMR / 2 minutes will  be given to the miners. This ensures long term incentives for the miners, even if a fee market doesn’t develop.
  • The mining algorithm is a different hashing function that is written to be CPU-friendly. The performance gap between CPU and GPU mining is small. A features called “smart mining” will probably generate more decentralized mining.
  • Last but not least, Monero isn’t an apptoken: it’s highly unlikely that the properties of Monero will be implemented in Bitcoin. Bitcoin is transparent by default, monero is private and fungible by default. Implementing ring signatures as a sidechain for example, isn’t sufficient:  the sidechain would function as a mixer, but transparent bitcoin transactions are still possible. Regulation could force services to only accept traceable bitcoin transactions, miners could be forced to not process anonymous bitcoin transactions, blacklisting of coins would still be possible, etc. If raising the bitcoin block size limit is creating a consensus problem, then  changing the core functionality of bitcoin transactions will not happen. It’s highly unlikely that bitcoin ever will be private and fungible by default.

So if you are looking to hedge your bitcoin position, maybe research Monero. The number of BTC and XMR in existence are comparable, so if you decide to buy a similar amount of XMR as you currently own BTC, you are hedged. Why not take a small insurance policy for you precious bitcoins? You can start researching here.

 

ShapeShiftOpenAlias

The Satoshi Nakamoto Quote

Published by:

Crypto may offer ‘key blinding’. I did some research and it was obscure, but there may be something there. ‘Group signatures’ may be related.

Satoshi Nakamoto, 2010
Source: https://bitcointalk.org/index.php?topic=770.msg9074#msg9074

Group signatures were introduced by David Chaum and Eugene van Heyst in 1991. This cryptographic signing technique is the predecessor of ring signatures as applied in Monero.

ShapeShiftOpenAlias