Uncategorized

Bitcoin mixing, a catch-22?

Published by:

Due to that fact that the Bitcoin blockchain is a transparent ledger, one needs to take additional measures to acquire privacy and fungibility for their transactions. All these techniques are usually given the term “mixing”.

Bitcoin mixing, the act of trying to obfuscate your transactions on the bitcoin network, is an active field of research and seems to be heading into new directions in the coming years.

Early on there were only centralized mixers which could be risky to use due to possible exit scams which would result in losing the money you’ve put in. There was also the risk that the mixer could always be seized by TLA’s. There were also mixers that functioned as a honeypot which would render your privacy worthless. In more recent times new protocols were developed to make the mixing more decentralized and trustless.

In this article we won’t go into the implementation details of all these mixing techniques, we’ll on the other hand try to get a more general analysis of the properties of 2 types of mixing techniques.

First we need to distinguish between “privacy” and “fungibility”: these properties of cash are related, but aren’t the same. Transacting privately we’ll define as not standing out from the crowd. Ideally nobody is able to determine the origin, amount and destination of a transaction. Fungibility we’ll define as “all money is equal”. When you receive a transaction, the history of that money isn’t clear.

These 2 properties don’t necessarily always come together. An example of a non-fungible private transaction is art that is bought anonymously at an auction. An example of a fungible non-private transaction is donating money above the reporting threshold to a political campaign.

Cash transactions on the other hand are private and fungible by default: when you receive cash, you don’t know what the history is of that cash and nobody is able to observe the cash transaction so only the parties involved know the sender, amount and destination.

The first category of mixing I’ll refer to as “clearmixing”: you can easily identify the mixing transactions on the blockchain.

coinjointransaction

Example of coinjoin transaction (click image for link to full details)

The most popular protocol for this type of mixing is Coinjoin: basically a bunch of users cooperate to create one big transaction. This protocol is currently implemented in the Wasabi-wallet. The mixing protocol implemented in this wallet forces participants to receive equal 0.1 BTC outputs so all UTXO’s from the coinjoin-transaction look the same and you can’t determine which of the participating inputs is the origin of a certain 0.1 BTC output. [There are a lot of attack vectors though, to try to partly deanonymize a specific coinjoin-transaction, but we won’t cover that here]. The anonymity set is limited though to the participating UTXO’s. Still, this results in reasonable fungibility post-mixing as you can’t easily determine the origins of the money. The Coinjoin-transaction did effectively cut the history of the money loose from the now “brand new” 0.1 BTC UTXO.

The second category of mixing I’ll refer to as “hiddenmixing”: these types of mixing protocols try to hide the fact that they are mixing. It’s not easy to identify these transactions as mixing transactions as they look like regular transactions.

A popular protocol in this category that is already implemented in Samourai Wallet and BTCPayServer is “pay to end point” (P2EP) also known as “PayJoin”. With this protocol a payer and payee of BTC work together to create a transaction: both the payer and payee provide an input for the transaction, and both receive an output where the payer receives less money than he put in (this is the payment amount) and the payee receives the a bigger amount than he put into the payjoin. The result is that a regular payjoin transaction will be a transaction with 2 inputs and 2 outputs. A spectator of the blockchain can’t easily identify this transaction to be a payjoin, as a normal spending transaction often has 2 inputs and (almost) always has 2 outputs (payment and change).

Example of payjoin transaction (source: docs.wasabiwallet.io)

 

 

 

Another protocol in this category that is still being developped is CoinSwap: this protocol uses atomic swaps to exchange UTXO’s between the 2 participating users. Both parties send their UTXO(s) to a 2/2-multisig address and cooperate to release the coins to the other party. These transactions will probably look like regular “consolidation transactions” with 1 or more inputs and a single output that is locked in the multisig-address. This transaction will usually be followed by a “claim transaction” that moves the funds from the multisig address to the address owned solely by the participating party, so a 1input/1output-transaction. These types of transactions aren’t as common as normal spending transactions, but maybe with some improvements, it is possible to implement these coinswap transactions in a way that look more like normal spending transactions. There is still ongoing research happening by Chris Belcher, who is funded by the Human Rights Foundation.

There are some issues with both clearmixing and hiddenmixing though: while, as mentioned, clearmixing can provide a reasonable level of fungibility, it’s obvious that the resulting UTXO’s are mixed coins. Users of clearmixing stand out from the crowd. They didn’t mix in private. This behaviour can flag your UTXO’s and when you deposit them at a regulated entity, you may have some additional explaining to do about the origins of the money. It’s also possible that your deposit get rejected and your account will be closed. So clearmixing seems to have some privacy issues.
On the other hand, hiddenmixing seems to be able to hide the fact that a mix happened, which actually provides users of these protocols a good level of privacy. They hide in the crowd, they don’t stand out. But there exists a big fungibility issue: if you mix your coins with a counterparty that obtained his coins in an illegal way, your resulting outputs can become tainted. In the specific case of coinswap, you actually take over the whole liability, as the coins literally are swapped between you and your couterparty. When these tainted coins get connected with your real life identity, you’ll have a very hard time explaining to a judge that it wasn’t actually you who is the drug dealer, but that anonymous guy you swapped your coins with.

Protecting Consumers in the Digital Currency Economy | Center for Financial InclusionThe catch-22 is that you can’t have both: you can’t hide in the crowd and try to have no taint at the same time due to the fact that blockchain analysis companies have their heuristics. If you mix by mimicking regular behaviour, these companies will apply their anaylsis tools on your mixing transactions like any other transaction. With clearmixing you at least know your UTXO’s will be treated as mixed coins. With hiddenmixing this isn’t the case, it’s basically a gamble. Each user of mixing techniques should be aware of these trade-offs and chose the situation that likely will result in the most desirable outcome. In my opinion, it doesn’t seem possible for Bitcoin to function as digital cash.

There is one theoretical possibility to “solve” the catch-22: if (almost) everybody would use a form of hiddenmixing all the time, there would be too much false positives when flagging coins, so the heuristics by analysis companies would break. This doesn’t seem likely though for 2 separate reasons:
1) There will likely always be people who want to keep (a part of) their funds in a transparent way and won’t participate in mixing. If you’re just an investor, why risk mixing your coins with an anonymous counterparty? So if you do choose to use mixing techniques, you can accidentally make yourself suspicious.
2) While clearmixing can give you reasonable fungibility, the level of fungibility with hiddenmixing is lower, as there is only one counterparty for each mix. If you want to have a good level of privacy and fungibility, you’ll need multiple rounds of hiddenmixing. This will likely cost you a lot in bitcoin transaction fees over time. Certainly for smaller amounts, it seems that attaining a good level of privacy is not really feasible.

My conclusion is that, as long as mixing isn’t enforced by the Bitcoin network, which would require major code changes and likely a hard fork, bitcoin mixing will probably always have to deal with this catch-22.

Uncategorized

Preserving XMR privacy? Software implementation matters!

Published by:

This title and content of this article was changed because the developer of XWallet addressed the concerns raised by weuse.cash. I won’t remove it because it’s still an interesting case of chainanalysis on the Monero blockchain. We are thankful towards Justin that he eventually understood the issue and decided to change his software implementation in such a way that the privacy of the users of his app is preserved.

On jan 25 the source code for Monero XWallet for iOS was released. Justin Smith (rusticbison) said on different occasions that he wants to monetize this app. Let me be clear from the start: I don’t have anything against this model. If you want to monetize your hard work, you should! But there is an issue with the way Justin wanted to monetize the app. Monero’s core value is privacy. I had good reasons to assume that the way XWallet were to be monetized would have been detrimental for the users’ privacy. Let’s explore this in this article. Note that for the larger part of the article I try to simplify the explanation by ignoring the fact that ring signatures are being used.

This is what the source was telling us about how the app were to be monetized:

The wallet provider fee is a flat 0.0005 XMR per outgoing transaction.

This means that every transaction would usually have 3 outputs: “payment”, “change” and “wallet fee”, while a non-XWallet transaction would usually only have 2 outputs: “payment” and “change”. Let’s look at how a normal transaction would look like compared to an XWallet transaction. Note that the image only shows one input. In general a transaction would have one or two inputs. However, if a user would have a lot of small unspent outputs in their wallet and wanted to send big amount, it’s possible that a lot more inputs were present in this transaction.
afb_1

But this was not the whole picture… One could have expected that people using wallets would spend their change in the same way as they spent the original input. This is how in general normal user behavior would have looked like: (note that tx3, tx4 and tx6 have 2 inputs and the other transactions only have 1 input)

afb_2What’s clear from the image is that it would not at all have been obvious to see which output was the “payment” and which output was the “change” due to the fact that every transaction had 2 outputs. And due to the xmr stealth addresses, there wouldn’t ever be a reuse of the same (one time) address, making it nearly impossible to “cluster” certain txo’s. This means that the wallet privacy would be preserved.

Now let’s look at how an XWallet transactions looked like. Tx1 would be the first transaction using XWallet. It would have generated 3 outputs, as explained at the start. We see that tx3 and tx4 only would have had 2 outputs, so we can assume that these wouldn’t be XWallet transactions. Tx2 on the other hand would have 3 outputs! So the first obvious conclusion we can make is that tx2 would probably have been the XWallet user who sent out tx1 as well as using his change (o1) stemming from tx1. This means that we would have been able to cluster every transaction this user broadcasts using his XWallet.

afb_3
Let’s analyze this transaction graph a bit more: tx4 would very likely have been a transaction made by the XWallet company grouping a bunch of the 0.0005 XMR wallet fee txo’s and sending them to a another wallet. We already established that o1 would be the change, so this means that it would have been very likely that the payment output in tx1 is o2. This transaction analysis would have been very bad for your privacy. Let’s expand our transaction graph a bit to show why:

afb_4

In this example I’ve added 4 transactions. tx5 and tx7 would clearly be XWallet-transactions while tx6 and tx8 would not. Tx4 is still grouping wallet fees. It’s obvious using the same analysis techniques that tx1, tx2, tx5 and tx7 are would have been performed by the same user of XWallet. These transactions could be clustered. If tx1 would receive funds from an exchange wallet, this cluster of transactions would be identified and the user’s privacy would be at risk.

Imagine that a darknetmarket is taken down and they are seizing the wallets. Law enforcement has possession of the logs of outgoing and incoming transactions. A vendor has taken out XMR via tx6 and tx8 and received XMR from tx5 and tx7. If this vendor would perform a few successive transactions after tx6 and tx8, his funds would be anonymous. But… in this case there would have been a way to trace back the origin of the funds!

Tx6 gets input i1 from tx5o1. Note that this was received using a ring signature, so it’s either tx5o1 or one of the decoys in the ring signature. If law enforcement would visit the user of XWallet based on this information alone, he would still somewhat be able to plausibly deny that he send out tx5. Thanks to the ring signatures, it could have been one of the decoys. But…

Tx7 also shows up in the logs of the darknetmarket as an incoming transaction. i2 from tx8 originated from tx7o2! And this transaction is part of the cluster of the XWallet user! What are the odds that 2 times a transaction accidentally picked a decoy from the same cluster? This doesn’t really sound that likely. So now it would become almost a certainty that the suspicious user of XWallet did indeed performed tx5 and tx7, regardless of the use of ring signatures.

If the DNM buyer would have used a normal wallet (the GUI, Monerujo, …) the blockchain data wouldn’t contain any identifying transactions with 3 outputs and his privacy would be preserved. I think this example clearly shows why people needed to avoid the initial implementation of XWallet if they wanted to preserve their privacy using Monero.

XWallet original implementation would have weakened other people’s privacy as well!

We already established that when an XWallet user would have spent XMR he would be clustering his transactions. But this also means that certain txo’s would have been able to be marked as “spent”. In the above example all change outputs and wallet fee outputs from the cluster tx1, tx2, tx5 and tx7 would likely have been spent.

To be exact, this list of txo’s would likely have been spent: tx1o1, tx1o3, tx2o1, tx2o3, tx5o2, tx5o3 and tx7o3. Note that we can know this just by analyzing the blockchain.

Normally, thanks to ring signatures, we can’t really know if a certain txo is spent or not. But due to the fact that we can cluster the user behaviour, we can, with a very high degree of certainty “guess” that these txo’s are in fact spent.

This means that if your wallet picks a decoy from this set of outputs, chain analyzing software can just ignore this decoy. It was already spent in a previous transaction. So in case you’re using the default ring size of 5, your effective ring size is reduced to 4. So if people are using XWallet, it can actually weaken other people’s privacy as well!

Suggestions on how to monetize XWallet in a privacy-preserving way

XWallet eventually chose to become donationware.
I you use the app, please consider donating to the development:
48u79gBhhdo6Pts6daXfvn7fQ2QL9BhaqNfqTgzbgGu5fJVaX7zjTVjNXaHtj71w3y81cc9vcuH7rNiz37BC9hQuUKEcoiU

As I said, I am not against paying for software. But it’s important to note that the “3rd output model” is bad for privacy and should be replaced by something else. I have a few suggestions:

1. Paying for the app using the Apple Store. By doing this, only the credit card company knows you bought the app, but doesn’t know what you do with the app. But I can see why (for ideological reasons) XWallet wants to support payments in XMR

2. Wallet Deposit Fee System. When you deposit money to the app, the app could “lock” the money and could ask the user to send a certain percentage to the XWallet company in a separate transaction. Once this fee is paid, the wallet will add a “fee paid flag” to the txo. This flag will carry over to the change so your wallet won’t ask for a fee when you receive change. This would introduce a little inconvenience, but you will be able to pay for the app using XMR.
Another disadvantage is that when you receive a small amount of xmr (for example a payment for a beer) you will need to “unlock” this payment by sending an additional transaction, which will cost you not only the wallet fee, but also the miners fee. Maybe it’s a good idea that the wallet sums up incoming payments and only asks for payment of the fee once the total of incoming transactions reaches a certain threshold.
An additional benefit would be that the fee transaction would also function as an additional “churn” making your funds a bit more private if you received them from a KYC/AML exchange. Note that if the user doesn’t want to pay the fee, he can import his seed in another wallet.

3. Transaction credits or pay per x transactions. XWallet could have a built-in system of “transaction credits” where the user pays a certain amount so he’s able to send out a few successive transactions. He could buy “packs” of 10, 100 or 1000 transactions. The wallet can keep track of how many transactions the wallet sent out. Once all the credits are used, the user needs to buy a new package (or he can import his seed in another wallet and get his funds out).
Another option could be that XWallet would lock the wallet every x (10, 20, 50, …) transactions. If the user wants to continue to use his wallet, he’ll need to pay a fee. If he doesn’t want to pay the fee, he can import the seed in another wallet.

I think these 3 solutions are worth taking a look at.

This article clearly shows that the way how you implement things actually matters. In this case, the old implementation was dangerous  for the privacy (and maybe the life) of the users. I’m happy that, after the necessary feedback about the flaws, it’s fixed now and people can use XWallet in a privacy preserving way.

Support independent research:

ShapeShiftOpenAlias

Altcoins Bitcoin Ethereum smart contracts

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

Monero

How to generate secure offline Monero addresses

Published by:

This short article and video tutorial describes how to generate (extremely) secure monero addresses, for the paranoid people out there 😉

The obvious choice: linuxTux

I feel I don’t really need to argue this point: let’s not generate our monero address on a windows machine which is basically NSA spyware. It’s better to generate it on an open source OS and Linux is the obvious choice. Linux may scare some people, but nowadays it’s pretty user friendly. The only issue for most people is installing it.

Which hardware should I use?

We should avoid as much complicated steps as possible. Complication is a hurdle for people actually DOING the thing they want to do. You can use a normal windows machine to install Linux, but that’s not always easy (you need to mess around with UEFI settings etc).
Secondly, if we install Linux on a laptop, we should ask ourselves what we will do with the hardware after we generated the monero address. It doesn’t sound smart to reuse a laptop which you used for generating your seeds, let alone plugging in a USB stick or connecting it to the internet. But it’s maybe not justifiable to buy a new laptop for every monero address you want to create either.
A third issue issue with using an existing computer is the fact that the hardware isn’t “open source”. It’s entirely possible that backdoors exist in the hardware. So even if you use Linux, there is still a possibility you are being spied upon.

pi_angled_noobs-new
These issues can be solved by using a Raspberry Pi. This is a very small computer that runs on Linux. The OS is very quick and easy to install (check here for instructions). Although the hardware isn’t completely open source, it contains very few components, so the chance that it has backdoors is very small.
The Pi costs around 40 USD and you won’t need to throw away your device after you’ve generated an address: The whole memory of the Raspberry Pi is located on a SD card. After you’ve generated addresses, you take the SD card out, mark it and never bring it online again. You can reuse this specific SD card for generating more addresses in the future. By installing the OS on a new SD card, you can use your Raspberry Pi for other applications without worrying that your generated keys will leak.

Note: I purchased a PiTop which is basically a laptop with a Raspberry Pi inside. It’s very convenient because you don’t need to fiddle with cables for screen, keyboard and mouse and you can use it “on the go” (the PiTop has a battery).

Is random really random?

Random can’t be generated by a computer because a computer is a deterministic device. What computers do to create pseudorandom numbers is using user input, sensor inputs, timestamps, etc to generate numbers that appear to be random. In reality they aren’t though.
A normal PC has a lot of inputs so the pseudorandom created by the device is pretty reliable (if we ignore the possibility for backdoors). The problem is that a raspberry Pi has very little “intrinsic sources of random”. It’s a very basic device, certainly right after a clean install of the Operating System.
You can read more about pseudorandomness here.

To solve this issue, we dismiss the random created by the device entirely, and we will generate the random ourselves by using hexadecimal dice. These dice have 16 sides with the 16 hex chars present (0, 1, …, 9, a, b, …, f).
A monero seed is 256 bits (zeroes and ones). A hexadecimal number is 4 bits so a monero seed is 64 hexadecimal numbers. This means you will need to throw 64 times with a hexadecimal dice to generate a completely random monero seed.

The video below shows the whole process on how to download the needed tool, how to generate the monero seed offline and how to export the address and viewkey without using a USB stick or mailing it to yourself. A big thanks to Luigi1111 for providing the needed tool to generate a monero address based on a hexadecimal seed!

thumbnail

Summary:

1) get yourself some hexadecimal dice
2) get yourself a Raspberry Pi (or PiTop)
3) Install Linux on SD card
4) Connect screen, keyboard and mouse to the Pi
5) Follow the Instructions in the video to generate the addresses
6) Store the addresses and viewkeys somewhere secure, or create a view-only wallet
7) Take SD card out and mark it. Never connect the contents of this SD card to the internet or plug a USB stick in the Pi after you’ve generated the addresses. If you want, you can reuse it to generate more addresses

Good luck!

ShapeShiftOpenAlias

Altcoins Bitcoin Monero Proof of Stake

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

fungibility Monero Privacy

Idea: Colored Coins on Monero

Published by:

While the main goal of Monero is obviously to be a fungible cryptocurrency, lots of cool things can be done with the technology. Recently I saw an article about “Confidential Assets” by a start-up called “Chain”.

The Confidential Assets that Chain is proposing are basically a form of issued tokens that can be transferred anonymously between parties on the same network. The issuance can be anonymous and the balances of the accounts are unknown to an observer. There is a downside however: the history of the assets/tokens can be tracked. This scheme can for example be used for creating virtual poker chips,  company shares or even cryptofiat backed by a reputable bank who holds the currency on balance.

While this is a cool idea, I don’t think it needs its own blockchain or other form of “decentralized” database with some weak consensus mechanism. If you want fungible assets however, then a different approach is certainly needed. Monero lends itself perfectly for this job because all transactions are untraceable, unlinkable and with RingCT the amount isn’t visible. In this small article I propose a system for building Colored Coins on the Monero network. These Colored Coins are fungible, the transactions use RingCT, the issuer can be anonymous and an observer who isn’t part of the CC-network doesn’t necessarily need to know the amount of Colored Coins in circulation.
Seems like a cool idea? 🙂

How does the Colored Coins on Monero looks like in general?

1) Monero is divisible into 1 trillion (10^12) atomic units (“etoj”). To create a specific Colored Coin, the Issuer needs to first define the amount of Coins he wants to issue. He also needs to take into account how much decimals the token can have. If a bank for example wants to issue 1 million USD on the blockchain with 2 decimals, then there are 100 million atomic units. To issue this particular Colored Coin, the Issuer will need 0.000100000000 XMR. Every eto will represent 0.01 USD.

2) Now that the Issuer defined the amount of atomic units, he can do the “Issuance Transaction”. The Issuer simply sends a transaction with the required output to an address he controls. There is no need for a paymentID. No special measures need to be taken. This transaction just looks like any other transaction on the blockchain.

3) The Issuer then needs to perform the Enabling Transaction: this is the first transaction which uses the full supply. Let x be the minimum Ring Size, then this Enabling Transaction needs to have at least x outputs.

4) From this point onwards, transactions which use this specific Colored Coin are required to only use txo’s that stem from the Issuance transaction in the ring sigantures. If any other txo’s are used in the ring signature, then all the outputs will lose their Color. These txo’s won’t be recognised anymore by the Colored Coin network.

5) There is one problem however with this scheme: monero transactions aren’t free. But to be able to pay for the fee, additional inputs in the transaction are needed and it will need to be possible to verify that all the additional real XMR is spent as a fee payment. This would require tweaks in the RingCT protocol, disclosing a lot of info about the transaction to the public, etc.
A more private solution is the following: when you spent a colored txo, you’ll usually have at least 3 outputs: the payment, the change and a 0-output. This 0-output will then be spent again in another transaction using a ‘Child Pays for Parent’ scheme. The result will be that this 0-output will lose its Color, but who cares? It was a 0-output anyway.
Note: currently CPFP is not yet possible on Monero. Maybe another solution for the fee problem is possible. But I suggest that this system would reveal as little data about the Colored Coin transaction as possible.

The result of this scheme is that someone is able to issue Colored Coins on the XMR blockchain. The transactions will use RingCT. The issuer can chose to disclose the amount of coins created, or not. The Colored Coins will be fungible. Downside: it will be pretty easy to spot colored coin transactions on the blockchain, even if an observer isn’t aware of the Issuance public key and/or or the Enabling transactionID. If regular Monero users use real XMR in a ring sig in combination with txo’s that are inside the Colored Coin system, an observer will be able to discard those Colored txo’s as real inputs of the transaction.

Assuming CPFP will be implemented, a practical implementation of this scheme seems pretty easy: what is needed?

A) a special wallet that is “Color Aware”. The user needs to be able plug the public key of the Issuance transaction (the key that contained the whole supply) and the txid of the Enabling Transaction into the wallet. By doing this, the wallet recognises that a certain transaction contains all issued tokens and that a specific transaction enabled the network. Note that the txid is needed, because nothing stops normal users of the Monero network to use the public key of the Issuance Transaction in a regular ring signature.

B) Optionally, the user can add more sets of public keys and txid’s later on. If the Issuer decides to create more tokens (for example new shares) then the user can decide to accept this new issuance.

C) The Color Aware wallet needs to be able to recognise incoming Colored transactions and check their validity.

D) The Color Aware wallet needs to be able to pick the txo’s from the approved list when creating Colored Coin transactions.

E) The Color Aware wallet needs to add a 0-output to every transaction and pay 0 fee when sending a Colored transacion

F) The Color Aware wallet needs to spend the 0-output with a “double fee” using CPFP to confirm the Colored transaction.

G) Optionally, a public database can be created that has the info of certain Colored Coins with the data needed to add it to the Color Aware wallet. The Issuer can decide to publish it or not. Optionally, he can also disclose the amount of tokens issued by disclosing the TX private key of the Issuance transaction and the originating address of the Enabling transaction.

ShapeShiftOpenAlias

Monero

Introduction to Monero

Published by:

1. Monero – a short history

Monero is a cryptocurrency, launched on april 18 2014 as a fork of Bytecoin. Bytecoin was the original coin that first implemented the Cryptonote protocol (more on that further down). Once it surfaced the Bitcointalk forums, people discovered all sorts of shady things, among it the fact that more than 80% of the coins were already mined. So the community decided to fork a new coin, starting with 0 coins in circulation. Monero was born.

In the first months, Monero was only usable with a “command line wallet”. Therefore, a lot of people kept asking the devs, who didn’t even completely understood the basics of the Monero code, to create a GUI (Graphical User Interface). They started working on it, but on september 4 2014 a sophisticated attack happened on the Monero Network, so the devs changed course and started prioritizing the underlying code, to make the Monero network more resilient (more details at lab.getmonero.org MRL-2)

At the end of 2014, a Monero webwallet was launched by Riccardo “Fluffypony” Spagni, called “MyMonero”. You can find it at mymonero.com. Meanwhile, nothing much seemed to be happening “on the surface” for most people looking from the outside. But a lot of important work was in progress, such as the creating of a database-system which enabled the wallet to operate with only a little bit of RAM in stead of Gigabytes of RAM. Other improvements were implementing mnemonics, for easy backup. A lot of new code and documentation was written to implement options for faster syncing, faster node operation, integration with I2P started, etc. And eventually the GUI project was picked up again at the start of 2016.

This all was done by crowdfunding which means that community members donated money regularly to the development team. There is no “premine” or “ICO”. Monero is launched in a very fair manner, it’s open source and clearly is a grassroots currency.

2. Fungibility

The purpose of Monero is creating a fungible currency network. What does fungibility mean and why is it important?
Fungibility is an important property of any functioning currency. It’s the property that makes one unit of a currency always 100% exchangeable for another unit of the same currency. There shouldn’t be differences. Every coin need to be worth the same as another coin.

In Bitcoin, every transaction is traceable. This can lead to problems when receiving coins from an unknown source and later spending them. You can be accused of crimes in which those coins were used. This effectively decreases the value of these “tainted coins”. Another problem with traceability is that people can try to figure out your account balance or know on what items you spend your money.

You can however try to hide the traces of your coins. These techniques are called “mixing” and can be done in different ways. Sometimes centralized, sometimes decentralized, but there is always a possibility to see that certain coins were mixed. This can still lead to problems though, because mixed coins are probably tainted as well. Optional privacy doesn’t solve the fungibility issue of a traceable currency. I suggest to read the first part of this article I wrote to understand more about this topic: http://weuse.cash/2016/06/09/btc-xmr-zcash/

You can try to hide the traces of your coins as much as you want, if you tried to mix your non-fungible coins using a mixer, coinjoin or another type of “anonymity enhancing feature”, these transactions can still be flagged as “possible suspicious activity on the blockchain” because they are mixed, even if you are anonymous. So don’t confuse fungibility with anonymity. This is why “mixing technology” only works if it’s “on by default”. If everybody is mixing all the transactions all the time, then you can’t say anything useful about the data in the blockchain.

3. Ring Signatures

Ring signatures are used for obfuscating the real input in a transaction so it’s impossible to tell what the history is of every output on the blockchain.

Definition by Wikipedia:
In cryptography, a ring signature is a type of digital signature that can be performed by any member of a group of users that each have keys. Therefore, a message signed with a ring signature is endorsed by someone in a particular group of people. One of the security properties of a ring signature is that it should be computationally infeasible to determine which of the group members’ keys was used to produce the signature. (…) Ring signatures were invented by Ron Rivest, Adi Shamir, and Yael Tauman, and introduced at ASIACRYPT in 2001.

Ring signatures are applied on every input in every transaction. The sender just randomly selects some other outputs with the same amount from the blockchain and signs it with his private spend key. He doesn’t need any approval from the owners of the other outputs. This can even be done offline, making it possible to do secure offline signing and broadcasting the signed transaction on an online computer.

Maybe you ask yourself by now how you can detect double spends when there is plausible deniability for every transaction output? The answer lies in the mathematics again. A “key image” is published alongside a transaction. The key image proves that one of the inputs in the ring signature is real and when sender tries to double spend the same input, the key image will be exactly the same. You can find out more about the cryptography behind the key image in the Cryptonote whitepaper.

Because ring signatures are enforced across the network, all coins are mixed all the time. This adds fungibility to the protocol level of Monero. If we compare this with privacy features implemented in Bictoin, ZCash or DASH, we can clearly see the difference: if traceable transactions are still possible on the network, regulation can force this traceability in certain circumstances so you can never have fungibility.

And last but not least, this is tested cryptography. It exists since 2001 so we can assume it’s pretty reliable. Unlike ZCash, which is new cryptography and still largely untested.

4. Stealth addresses

Monero implements ‘Stealth addresses’, which is one (public) address that you can share with anyone, without enabling spectators to know anything about the transaction history or balance of this address. The Monero addressing system uses 2 private keys: a private viewkey and a private spendkey.

The private spend key pretty much works the same as in Bitcoin: you sign transactions with it. The private viewkey however is needed to search the blockchain for incoming payments. Only if you have access to that key, you can know a certain transaction output is associated with you Monero address.

In bitcoin (and most of the other cryptocurrencies) address reuse is often happening, which greatly decreases the pseudonimity of the network. Stealth addresses provide an easy way to protect and enhance your privacy. The blockchain data will not show any links between multiple transactions.

Although this isn’t perfect: if you use your address in multiple locations, there can be “off blockchain linking”. If you withdraw coins from an exchange and use the same address to withdraw funds from your webshop where you are selling plants, law enforcement is able to link your accounts based on the usage of the same address. Therefore, it is suggested to use a special kind of “one time address” for every service. All funds will enter the same account, but off blockchain linking won’t be possible.

5. RingCT

RingCT, short for Ring Confidential Transactions, is a new signature system proposed by Shen Noether in the MRL-5 paper. You can find it in the first edition of Ledger at ledgerjournal.org. It is based on the research by Gregory Maxwell on Confidential Transactions, but adapted to be able to work with Ring Signatures.

This technology enables users to hide the transaction amounts of transactions. It is “the last piece of the puzzle” for complete anonymity on the Monero network. It also solves some edge cases that could compromise the untraceability of Monero. RingCT is went live on the Monero main net on January 9 2016. At first, RingCT will be optional, but in the next hard fork (september 2017), RingCT transactions will be enforced by the network, without any option to “opt out”.

6. Kovri – I2P

Blockchain data is only one attack vector for the privacy of cryptocurrency users. It’s known that the Chainalysis company tries to identify users/nodes in the P2P network based on their IP address. The Kovri project tries to develop an I2P router in C++ that will eventually enable Monero users to hide their IP addresses when sending transactions. Kovri is not yet integrated with Monero and is still in a pre-alpha stage.

7. Conclusion

Monero is very important and revolutionary technology. It hides the sender, receiver and history of transactions. Soon the amounts will be hidden as well. It is pretty easy to deploy, doesn’t need a trusted setup (unlike ZCash) and it’s being tested in the wild for almost 3 years. The privacy features are enforced by the network which results in a much bigger anonymity set than bitcoin mixers or cryptocurrency with optional privacy features. It enables users to transact privately with a fungible currency in a decentralized network and therefore can withstand regulation from governments. Monero is true digital cash.

ShapeShiftOpenAlias

Altcoins fungibility Privacy ZCash

The Untrusted Setup – Why you shouldn’t trust ZCash

Published by:

Hidden inflation

ZCash will launch today. This is not a “normal launch” like any other altcoin, because ZCash required a so called “trusted setup”. During this setup, some secret (public) parameters were generated based on a “master private key”. These network parameters are needed to create the so called “zero-knowledge proofs”, which is the anonymizing mixer on the ZCash network. The “master private key”, referred to by Zooko as toxic waste, needed to be destroyed.  If this data is not destroyed, someone who has access to this key is able to generate an infinite amount of anonymous ZCash.

This is the so called “hidden inflation problem”; unlimited counterfeiting of coins while nobody is able to detect it. If this were to happen, it would undermine the value proposition of the ZCash cryptocurrency. ZCash would never be considered to be “sound money” where the emission scheme can be checked by all participants. The problem is that nobody can check if the setup actually did occur  in a correct manner. People who hold value in ZCash will need to trust the setup process from the genesis block onwards.

Setup of the setup

ZCash used a “multi party protocol” which means that, according to the team, as long as one of the participants in the generating process is honest and doesn’t keep a copy of his part of the “toxic waste”, nobody else will be able to get access to the full “master private key” that is needed to create counterfeit coins. Only 6 people participated in the setup. This is a very small group and thus creates a theoretical possibility that these people were conspiring or were being coerced by a TLA to keep a copy of the “master private key”. While this is a possibility (certainly considering possible involvement of the Israeli government), it doesn’t seem all that likely due to the involvement of Peter Todd, who isn’t a part of the ZCash team.

What’s more worrisome is the fact that the setup itself could have been compromised: think about hardware, network, software, operating system, binaries, etc. There are a lot of attack vectors. Governments had a very big incentive to compromise the setup of the setup. If successful, they are able to create free money without people noticing and meanwhile diluting the value of a potential powerful cryptocurrency. State sponsored attacks are known to be very sophisticated, like Stuxnet that sabotaged the Iranian nuclear power plants.  Is it therefore likely that governments were able to compromise this “trusted setup” as well? I my opinion it is. It’s impossible to prove that an unknown attack didn’t happen. You don’t know what you don’t know.

Sybil zk-proof attack

The ZCash team often repeats that even if the setup is compromised, the anonymity of the network isn’t at risk. However, I beg to differ. Due to the high RAM requirements to generate “jointsplits”, it’s unlikely that the anonymizing feature of the ZCash network will be used much in the first years of the existence of the coin. This leads to the possibility of “timestamp analysis attacks”. People tend to use new mixing technology as an “intermediate step” for obfuscating bitcoin transactions. But due to volatility risk, people tend to have their value for the shortest possible time in an altcoin. If people use the zk-mixer for obfuscating bitcoin transactions, it will be trivial to connect the transparent ZCash that enters the zk-mixer and the ZCash leaving the mixer again after only a few minutes or even hours. (Sidenote: this leads to fungibility problems within ZCash; you can read more about it here.)

Imagine an attacker counterfeiting a lot of fake zk-proofs. This could create the illusion of a liquid mixer. A lot of usage means that suddenly one can hide his transaction in this mixer with a lower (perceived) risk of being tracked. Timestamp analysis attacks become increasingly harder. But the attacker, who knows all the fake zk-proofs, can ignore his own counterfeited liquidity. He is still able to do the timestamp analysys based on the real (low) liquidity inside the zk-mixer. This leads to a very dangerous situation in which the user thinks he is transacting anonymously, but in which an attacker will still be able to track all transactions. Privacy theatre is a huge risk.

Chain rollbacks

There is a (drastic) option to solve this issue. Zooko proposed recently to periodically force everyone to reveal their balance as a solution for the hidden inflation problem. At a certain block height all “anonymous” coins would become invalid and an observer would be able to sum up all “transparent” coins. If the total amount is equal to or less than the emission should actually be, the  system can be considered “sound” until that point in time.

If however an anomaly is discovered, then the ZCash community will face a difficult decision: continue with the inflated emission or rollback to the previous checkpoint. The network would also come to a halt until the bug is found. Trust in the currency would be lost immediately. If the community decides to do a rollback, this means that all transactions between the previous checkpoint and the detection of the hidden inflation will become invalid. Some people won’t like this rollback and maybe a non-rollback ZCash fork would emerge.  When people use the “rollback ZCash” however, one can only consider transactions to be “fully confirmed” after such a successful “emission checkpoint” happened.  Exchanges, users, merchants and wallet services should be aware of this serious risk.

Inflation bugs

ZK-proofs are very difficult to understand. Recently, Zooko even admitted he doesn’t understand the math. The ZCash team has some smart people on board, but even they can not guarantee that the network is free of bugs. During the test phase, a bug was discovered that made it possible to counterfeit coins. This attack had nothing to do with the “trusted setup”, but would cause the exact same problems as described in this article. Due to the fact that the ZCash protocol is very complex code, it’s not at all guaranteed that similar bugs aren’t still present in the protocol.

Conclusion

You shouldn’t trust ZCash.

zcash2

ShapeShiftOpenAlias

Monero

Trezoro – Trezor for Monero – video tutorials

Published by:

I created two tutorial videos for installing, configuring and managing Monero on Trezor.

Trezoro: The Basics

The first one covers just the basics and aims to get you up and running as fast as possible:

trezoro1

This is the shortlink: http://bit.ly/trezoro

Trezoro: Tups & Tricks

I created a second tutorial video for Trezoro. It will show you how to use multiple currencies, how to set up password accounts, it will suggest a Monero account strategy, it shows some useful CLI command and shows you how to run your own node.

trezor2
Shortlink to the video: http://bit.ly/trezoro2
Links to the different segments of the video:
1) multiple currencies
2) password accounts
3) Monero account strategy
4) CLI commands
5) Running your own node
useful links:
– Article on Trezor for Monero: http://weuse.cash/2016/03/07/trezor-for-monero-first-impressions/
– You can buy a Trezor here using my affiliate link: https://buytrezor.com/?a=2c001ae7165c

ShapeShiftOpenAlias

Altcoins DASH fungibility Privacy

Warning: DASH privacy is worse than Bitcoin

Published by:

This article analyses how DarkSend works and will explain why there’s absolutely no good  reason to use DASH for private transactions.

dash1

The cryptocurrency DASH (formerly known as Darkcoin, formerly known as XCoin) brands itself as a “Digital Cash”. When people promote DASH, they often claim that the PrivateSend (formerly know as DarkSend) feature makes DASH the “top contender in the realm of privacy coins”.

This recent steemit article by bravenewcoin is a perfect illustration of what I mean. There is zero critical thinking. Nobody seems to ask questions and do research. If there is no proof that these claims are correct, then it’s dangerous to use DASH in the first place. People who are not technically literate will use DASH while presuming that they are doing private transactions. They are exposed to some risky attack vectors, but think they are safe.

dash2

Let’s first look at how DASH describes the “Darksend” feature on their website:

Darksend is the feature that gives Dash users full privacy when they use it. It is an improved and extended version of the CoinJoin. In addition to the core concept of CoinJoin, we employ a series of improvements such as decentralization, strong anonymity by using a chaining approach , denominations and passive ahead­of­time mixing.

So DarkSend basically is a fork of CoinJoin. DASH added some things and claim these features are improving the privacy of the DarkSend user. We examine them one by one

 

1) Coinjoin basics

Darksend uses the fact that a transaction can be formed by multiple parties and made out to multiple parties to merge funds together in a way where they can’t be uncoupled thereafter. Given that all Darksend transactions are setup for users to pay themselves, the system is highly secure against theft and users coins always remain safe.

dash3

Coinjoin, as implemented in Joinmaket on Bitcoin, is a system that enables users to mix their coins in a decentralized way. As shown in the image above, users basically transact together in the same coinjoin transaction. By doing this, an outsider can’t really know which output belongs to which input.

Joinmarket is currently the only viable decentralized implementation of Coinjoin on Bitcoin. DarkSend is a different implementation of Coinjoin on the DASH network. We’ll compare these 2 implementations in this article.

 

2) Decentralized mixing

In Joinmarket, there is no central server to find counterparties to mix with. You just announce to the network that you want to mix and someone else can join your mixing proposal. Other implementations of Coinjoin, such as Sharedcoin by blockchain.info uses a central server to generate the coinjoin-transactions. It is possible that these servers log the different inputs and outputs so they can potentially deanonymize the coinjoin-users.

In DASH, the DarkSend-users connect to a masternode for mixing. This masternode enables the mixing proces in a similar way as the sharedcoin system. These masternodes can log the inputs and outputs and therefore deanonymize the users.

Note that you don’t need to be the owner of a masternode to see these logs. Most of the masternodes are hosted on cloudhosting services. If a government demands access to these logs, they will probably get it. It’s entirely possible that right now the NSA is spying on the majority of masternodes without the owners even knowing their masternodes are being spied upon.

The DASH website ignores this risk and tries to reassure us that by using “chained mixing”, you’ll be safe:

 At set intervals, a user’s client will request to join with other clients via a Masternode. (…) Each Darksend session can be thought of as an independent event increasing the anonymity of user’s funds. (…) To increase the quality of anonymity provided, a chaining approach is employed, which funds are sent through multiple Masternodes, one after another.

Stating that chaining mixings is more secure is just false: suppose an adversary has access to a large number of masternode logs. When someone does one mixing and then waits a day to do a second one, he’ll be more private than someone doing 6 mixings in a row. Why? If the adversary owns 2 of the 6 masternodes used in the mixing process, it will be easy to undo the mixing that happened in between due to the low liquidity in the DASH system (see next point).

DASH mixing is far from decentralized and it’s even worse than Sharedcoin: when using Sharedcoin, the user is aware that he’s using a centralized system. When using DASH, everybody pretends it’s a private decentralized system, but in reality, it isn’t.

 

3) Mixing liquidity

The advantage of DarkSend compared to JoinMarket, is that it’s implemented in the official DASH GUI, so it’s easily accessible. I assume the idea behind that was to encourage the use of DarkSend which would improve the liquidity in the DarkSend mixing system.

Liquidity is very important for any mixing system to function well. If only a few people are mixing, these systems are easily Sybil attacked: if some adversaries just try to mix with as much people as possible, they will be able to get a lot of info from their own mixings because they are in most cases the only counterparty of the people who want to mix.

So let’s compare the liquidity between DarkSend and JoinMarket:

Currently, according to JoinMarket.me, this bitcoin mixing system has 86 counterparties to mix with. This means that at any time, someone who wants to mix can choose one of those 86 people to mix with. He can even do multiple mixings (“chained mixing”) to improve his privacy: it’s possible that some of his mixing partners were adversaries, but chances are smal that all of the counterparties were.

A Sybil attack is more difficult to successfully execute when the number of counterparties grows. Bitcoin has the advantage that there is a lot of liquidity in the Bitcoin network. The market cap of Bitcoin is more than 10 billion and I estimate that the number of active bitcoin users is in the millions. If only a small percentage of those people started using CoinJoin, the liquidity in the mixing system would grow and Sybil attacks would be very hard to pull off.

It’s not possible to get exact data on how many counterparties are available in DASH DarkSend, but we know a few things: the DASH market cap is 50 million USD and I estimate the number of active users to be in the thousands. So by using DASH you already reduce the anonymity set you’re in by multiple orders of magnitude.
Due to the low liquidity on the DASH blockchain, it’s possible to attribute “chained mixings” to the same individual solely based on blockchain analysis.

But what’s even more telling is the fact that a lot of DarkSend users seem to experience a very slow mixing process. Check this subforum for their stories: http://dash.org/forum/topic/privatesend-questions-and-help.77/ 

DASH developers tried to improve the number of mixing participants compared to JoinMarket. Joinmarket usually only has 2 participants, DASH has t least 3 people mixing together:

Currently to mix using DarkSend requires at least 3 participants.(…)However each session is limited to three clients, so an observer has a one in three chance of being able to follow a transaction.

The DASH developers also noticed that mixing is slow, so they decided to pay 5 “liquidity providers” to constantly mix their coins. This probably increased the speed of the mixing a bit since this system was implemented, but it is also a very big risk: if these 5 people collude (or are being spied upon), it will be trivial to deanonymize every DarkSend transaction that happened on the DASH blockchain. This is a very unsecure system to depend upon for your private transactions!

 

4) Denominations

DASH added a denomination system to the coinjoin-implementation of DarkSend:

To improve the privacy of the system as a whole we propose using common denominations of 0.1DASH, 1DASH, 10DASH AND 100DASH. In each mixing session, all users should submit the same denominations as inputs and outputs.

Statistical research is needed to confirm the claim that denominations are actually better for privacy. If it were better, then joinmarket could easily implement it. But I think there are also some risks associated with using denominations: if you want to mix 987.6 DASH, you’ll end up with 30 outputs. When you want to spend 375 DASH, you’ll regroup at least 15 of those outputs. This could potentially lead to making your previous DarkSend privacy weaker. A better approach would be to conceal the amounts in the transactions by using Confidential Transactions combined with coinjoin.

 

5) Passive mode

With joinmarket, you have an incentive as a market maker to propose mixings to the bitcoin network. Joinmarket has an incentive to provide liquidity. Tis makes it easier for people who want a fast mixing to just ping the network and accept a mixing by one of the market makers.

The DASH developers correctly identified that timing attacks are an issue with mixing. But the fact that they promote the “passive mode” of  DarkSend as a feature is very telling: it’s turning a bug into a feature.

Darksend is limited to 1000 DASH per session and requires multiple sessions to thoroughly anonymize significant amounts of money. To make the user experience easy and make timing attacks very difficult, Darksend runs in a passive mode.

In DASH this “passive mode” is just your node waiting for other people to show up to mix with you through a masternode. There is no incentive at all to do this. It’s a necessity. It shows (again) that the DarkSend liquidity is painfully low.
Conclusion

DarkSend (now called PrivateSend) has some serious privacy issues. It’s risky to rely on this system and the liquidity is very low which makes it not really usable. If you need to choose between Bitcoin and DASH, it’s safer to rely on Bitcoin mixing systems and more specifically on JoinMarket.
PS: fungibility claims

dash4

DASH also claims to be a “truly fungible” coin:

By having a decentralized mixing service within the currency we gain the ability to keep the currency itself perfectly fungible. At the same time, any user is able to act as an auditor to guarantee the financial integrity of the public ledger without compromising others privacy.

There is a lot to say about this, but I’ll refer to a previous article of mine about fungibility. Basically bitcoin and DASH have the same fungibility issues. Coinjoin can’t “fix fungibility”. You can read that article here: http://weuse.cash/2016/06/09/btc-xmr-zcash/
PPS: Instamine scam

By the way, if after reading this article you somehow still regard DASH as a legit project, there is still the instamine you can look into…

Teaser: this chart shows the first 72 hours of DASH. At the moment there are about 6.5 million DASH in circulation. In the first 2 days 2 million coins were created. In the first hour more than 500000 coins were created.

dash5

 

ShapeShiftOpenAlias