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 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 (, 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:


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







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).


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.



Tying up loose ends with RingCT

Published by:

RingCT, as proposed in a paper by the MRL researcher Shen Noether, was announced just a few months ago and recently received enough funding for the implementation. Ring Confidential transactions is complicated new technology using math and cryptography to hide amounts in transactions using ring signatures. Not many people saw the implications of this innovation for XMR and even less people actually understood how it all works.

I can’t explain you how it works. If Shen’s paper will be published in Ledger, an academic journal on cryptocurrency and blockchain technology, RingCT will be subject to peer review. When the academic community decides it works, we’ll know for sure. But let’s just assume for now that it will actually work once it will be implemented.

What I can try to do is explain some of the implications of RingCT. Hiding amounts seems a nice feature to have, but why do we need it? After all, we have already the stealth addresses and ring signatures which provide us with privacy and fungibility.

If you read MRL-0004, you’ll notice that there are still some privacy concerns when using Monero. The issues raised in section 3.2 (Association by Use of Outputs Within a Transaction) can be solved by using RingCT.
In short, the problem is that when you want to spend 2 outputs that you received in the same transaction as an input for a new ring signature transaction, these outputs can be linked together. For an observer it’s very likely that these 2 outputs are the real inputs of your transaction, making your ring signature obsolete.

An example will hopefully clarify what I mean. I’ll ignore the fees for simplicity.
Transaction X: Alice sends 123 XMR to Bob with mixin 5.
This means that Bob receives 3 separate outputs: 100 XMR, 20 XMR and 3 XMR
Transaction Y1: When Bob wants to send 3 XMR to Charlie, he just chooses his 3 XMR output as the input for transaction Y1. He chooses a mixin level so Alice can’t trace the 3 XMR. She doesn’t know for sure that Bob actually spent the 3 XMR she sent to him. Oliver the observer just sees a regular private XMR transaction. He can’t determine identities.
Transaction Y2: When Bob wants to send 23 XMR to Charlie, he could choose to use the 20 XMR and 3 XMR outputs as inputs for Y2. But this would not be a great choice: even if Bob uses a high mixin level, it will still be possible for  Oliver the observer (and thus also for Alice) to see that 2 outputs who were both the result of transaction X are used together in a new transaction. Even if Bob used mixin 100, this is still visible. What a coincidence! Oliver will conclude that those 20 XMR and 3 XMR are the real outputs. Alice will know that it was Bob who spent 23 XMR.  The state of the outputs isn’t uncertain anymore: we know the 20 XMR and 3 XMR are spent.
Transaction Z2: Dave sends 3 XMR to Eve. Dave uses mixin 1* and by accident picks as a fake input to mix with the 3 XMR Bob received in transaction X. When Dave sends his transaction, Oliver can see the 3 XMR input received by Bob is already spent in transaction Y2. This actually means that Oliver now knows that this input in Dave’s transaction is fake. So Oliver immediately knows the real input that is spent in Dave’s transaction, revealing the state of Dave’s 3 XMR.
Also note that if transaction Z2 happened before transaction Y2, Dave will still be private when he sends his transaction, but his privacy will be weakened when Bob sends transaction Y2. So transaction Y2 creates a “chain reaction privacy problem”.
*the XMR protocol enforces a minimum mixin of 2, making this “chain reaction privacy problem” in transaction Z2 less likely.
Transaction Y3: Bob wants to prevent that the state of his 20 XMR and 3 XMR is revealed when he spends them, so he decides to spend the 100 XMR he received from Alice instead. Charlie will still receive a 20 XMR and a 3 XMR output, but a 70 XMR and 7 XMR output will be sent back to Bob. At this point, the situation is exactly the same as in Transaction Y1: Alice doesn’t know for sure that Bob actually spent the 100 XMR she sent to him due to the mixin. Oliver just sees a regular private XMR transaction. He can’t determine identities.
But… Charlie now knows something: he can see that 77 XMR used as change and that this change is probably sent to Bob. So Charlie knows Bob owns at least 77 XMR. Bob can attach an identity to both the 70 XMR and 7 XMR outputs.
Transaction Z3: Bob now wants to send 75 XMR to Eve. If Bob only owns the 77 XMR he received as change, he now faces an even bigger problem: he can’t select just one output as an input for his transaction to Eve! Bob has no choice but to use both the 70 XMR and 7 XMR as inputs for his transaction to Eve. Eve will receive 70 XMR and 5 XMR and Bob will receive 2 XMR as change. Sending this transaction does a lot of damage to Bob’s privacy:
– Charlie knows that Bob has sent 77 XMR and that it’s very likely the 2 XMR output in transaction Z3 is change to Bob.
– Eve knows that Bob received 2 XMR as change and can attach his identity to those 2 XMR.
– Oliver sees that the 70 XMR and 7 XMR are spent, making it not desirable for every XMR user to mix with those.
– If Oliver accidentally already mixed with the 70 XMR or the 7 XMR before transaction Z3 happened, his privacy is now weakened. This can create new “chain reaction privacy problems”.

In a nutshell, if 2 outputs who originated from the same transaction are used as inputs in a new transaction, we now can assume that those 2 outputs are spent. This has 2 main consequences:
– Some people can know in certain circumstances that you have spent a certain amount of XMR.
– It’s possible that by random chance some people’s ring signature is weakened when such linked outputs are used for mixing in a new transaction.

So how can the hiding of the amounts in a transaction with RingCT potentially solve the “association by use of outputs within a transaction” and the related “chain reaction privacy problems”?

Well, if you understood the example, this is quite easy: A RingCT doesn’t require to be mixed with outputs with the same denomination. So when you send a transaction using RingCT, you can use arbitrary amounts. This means that in general, you would only have 2 outputs in a transaction: one output is sent to the receiver and another one is the change that is sent back to you.

This obviously makes it impossible to use 2 outputs who originated from the same transaction as inputs for a new transaction which was exactly the issue described at the start of this article. It also hides the change amount for the receiver. the receiver only knows you received change, but doesn’t know how much.

As you can see, RingCT solves a lot of edge cases for XMR and adds additional privacy to the balance of your XMR account!


Reddit user /u/mWo12 found this transaction: txid ea8bca898505b0c4b2ee9ff08d44ff8a2d60f0d397d8987fb68cd0ff11a88a15.

If you expand the inputs and check from which blocks the inputs originate, you’ll see 4 “ring members” of the 4 inputs coming from block 1015051.
All the inputs seem to be outputs in this transaction: txid bb4d4142ede8e9b32d1d9b81274cfa9d934b9d931faa521d6e6eab1bf917fff4.

It is very likely that the 4 outputs in transaction bb4d…fff4 are spent in transaction ea8b…8a15.
This results in a “chain reaction”. We now for example can assume that the 100 XMR txo with public key e3a8ef35175c931ec811bcc1667e66ab691ed1ca2d971e044b394d02a24f38ad is spent.

All other people mixing with this txo are not adding any “real” plausible deniability to their 100 XMR, because we already know it is spent. If someone only used this txo in the ring signature, his txo can also be considered spent, and so on and so forth…



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

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.