Trust is Risk: A decentralized trust system

The FrostWire team cares deeply about the free and uncensored flow of information, this means helping solving one of the hardest computer science problems out there: creating a distributed reputation system in order to rid p2p networks from a great deal of issues created by Sybil attacks.

Once you have a way to trust the unknown peers on the network you can do things like decentralized e-commerce (think what digital goods you could sell on a P2P network), decentralized credit (think Lending Club without the central entity), or any other decentralized service where reputation is key (think decentralized Uber as another example).

Along with our friends at OB1 (creators of OpenBazaar a project which we’ve collaborated with in the past), we’ve helped sponsor and mentor a team of Ph.D students in Greece to work on a promising solution called “Trust is Risk”

The following is an explanatory post by  Dionysis Zindros

Image from Pixabay

Trust is Risk: A decentralized trust system

One of the foundational problems of a decentralized marketplace is that of trust. It’s an  inherently difficult problem: How can you trade with someone who could, in principle, be completely anonymous?

In this article, we provide a novel answer to that question, something we call Trust is Risk. It’s a new approach to solve the problem that we’re exploring and we’d like to illustrate our ideas to the community and solicit your feedback.

This post is going to give an explanation of what Trust Is Risk is and how it works with quite some detail. This post is accessible to anyone. We don’t have any math here. But if you’re interested in all the deep details, I’m providing links to our papers in the last section that you can look at.

This is novel research work we’ve been doing that has never been presented before outside of academic conferences. We’d greatly appreciate your feedback and constructive criticism of our ideas.

Before we begin, a disclaimer: Trust Is Risk is an exploratory subject.

OpenBazaar is considering it for research, but is not yet committed to adopting it. More work is needed to evaluate if this system can work in practice.

The problem and previous attempts at solving it

In a traditional brick-and-mortar store setting, you have certain insurances that will let you transact safely. If something goes wrong, for example the store rips you off, you have a whole legal arsenal that you can bring against the store. But we don’t have (and perhaps don’t want to have) that luxury in a decentralized marketplace when people can anonymously connect through Tor or use cryptocoins that ensure privacy such as monero or zcash  (which OpenBazaar already supports).

Besides, if we allowed people to be accountable towards traditional courts and law, we’re opening up pandora’s box in letting governments interfere by making their own laws about what’s “cheating in a transaction” and what isn’t, which leaves room for censorship, something OpenBazaar always wanted to avoid – which is why from OpenBazaar’s inception we considered malicious governments as part of our threat model.

Brick-and-mortar stores also have a certain cost to set up and you expect them to be there the next day for accountability. You can literally walk up to a store that sold you a faulty phone and ask for your money back. But OpenBazaar stores can appear out of nowhere and disappear in minutes. We gave a lot of thought to these features of the physical world during the first versions of OpenBazaar and came up with reputation pledges and implemented one of the first production proof-of-burn systems  or identity creation. But people feel very uncomfortable burning money to set up a  digital store and we discovered some alternative ideas like donating to charity or miners can’t work out securely.

Here are some critical questions: If you’re a buyer, how do you know that when you give them the money, they’re going to send you the product? Or if you’re a vendor, how do you know that when you ship them the product, they’ll give you the money they promised? Of course you can use transaction-based escrows such as 2-of-2 or 2-of-3 transactions or MAD, some of which OpenBazaar already implements. But the problem remains: What if as a buyer you use a 2-of-2 transaction and upon receiving the product you finalize your funds, only to find out days later that it was of bad quality and broke down?

Another idea is to use a web-of-trust and I wrote extensively about the potential of using it in OpenBazaar in my master thesis (of which the shorter version is much more palatable). But the problem there, as with GPG, is that trust is arbitrary: it’s just a number and everybody has a different idea about how much to trust others and what trust means. For example, some people are very diligent about giving out trust, while others aren’t. An arbitrary trust scale doesn’t mean the same to everybody. And so the problem remains unsolved.

Sybil attacks and stars

Currently OpenBazaar uses a reputation system which is based on ratings and stars. This is a system widely employed by centralized markets as well, from eBay to Facebook Marketplaces. The idea is to let other people rate you from 1★ to 5★ as a buyer or as a vendor after a transaction is completed. Then, an average can be extracted and displayed for everyone.

This star-based system is quite attractive due to its simplicity and ease of understanding. Centralized marketplaces can afford this system, because they can refactor it and censor users at will if they gauge that people are misbehaving. They can also employ secret heuristic mechanisms to detect and punish wrongdoing. However, a decentralized market does not have such an option, as the code and exact inner workings must be open.

This opens up a star-based system to Sybil attacks. In this attack, a malicious vendor works as follows: They create multiple fake “buyer” accounts which perform transactions with the vendor. They then have the buyer accounts positively rate the vendor, increasing their star rating. The fact that a transaction is required prior to rating someone does not help defend against this attack. The seller simply moves funds among different Bitcoin addresses all of which they control. As OpenBazaar does not require paying any fees this is essentially free (except for Bitcoin transaction fees).

Many naïve ideas can be proposed for avoiding Sybil attacks.

Here’s one: If a vendor receives many ratings simultaneously from users that all have newly created accounts, then these ratings can be discounted.

Here’s another one: A buyer must have made a minimum of 5 other purchases before they can rate this vendor.

Here’s yet another: A buyer must have already rated another vendor prior to having his ratings count. And one more: If the buyer and seller form an isolated strongly connected “island” of ratings (a so-called clique), then the ratings should be discounted. These proposals are lucrative, but can’t possibly work.

The rules for deciding which ratings are good and which ones are bad must be published in the open source code of the project. Subsequently, the malicious vendor can make sure they bypass such rules. For example, they will make sure they let their accounts “mature” before rating, they will create several fake vendor accounts so that their fake sellers can create ratings towards the fake vendors prior to making ratings to the real vendor and they will avoid forming a “clique” of ratings by not having everyone rate everyone, but rather mimic the way real people rate real vendors in terms of amount of ratings, connectedness, and so forth. The same problems arise if you try to filter by IP address or
require that people run a different OpenBazaar node version or OS version. It’s a futile cat-and-mouse game.

Trusting people

The core idea of Trust is Risk is quite simple. We believe this is the right approach for handling decentralized trust.

Here it is.

Suppose Bob shares a bank account with her friend Alice. He puts 10€ in it, which are his own, but just trusts Alice not to take it. Because Alice is his friend, she doesn’t take it. While Alice can always take it, she chooses not to. Even though it’s put in a shared account, Bob’s money is always Bob’s and he can always take it too.

In Bitcoin, we can do the same thing with a transaction that has a 1-of-2 multisig output. A 1-of-2 multisig output means that the money is spendable by either one of the two participants on their own, Alice or Bob. Alice doesn’t need Bob’s permission to spend and Bob doesn’t need Alice’s permission to spend.

Here’s what that looks like in the Bitcoin transaction graph:

A 1-of-2 multisig transaction

Here, Bob has created a transaction into which he pays 1 BTC so that the money can now belong to an account shared between Alice and Bob. Whenever we mention a “shared account” in this post, we mean such 1-of-2 multisig transaction outputs.

We call this a trust transaction, because Bob trusts Alice with his money. The use of such transactions, reminiscent of lines-of-credit in more traditional settings, for the purpose of establishing trust was a great idea invented by OpenBazaar co-founder Washington Sanchez in his post Peer-to-Peer Lending on OpenBazaar.

Suppose now, in this limited setting, that Bob wishes to purchase something from Alice, and that Bob has already entrusted Alice with 1 coin at an earlier moment in time. If what he wants to buy from Alice is worth 1 coin, then he can do it as follows: He takes the money out of the shared account and pays it directly to Alice’s account (or simply tells Alice that it’s fine to take it out of the shared account). Then Alice can get paid and ship the product.

That doesn’t sound like a big deal, because Bob and Alice were already friends, but think about what just happened: Bob was willingly trusting Alice with some money, a trust decision he took in the past. If that trust decision on Bob’s side was the right call, then Alice will not cheat on him and will not take the money out of the account. Therefore, merely by having the money in a shared account, Bob has established an amount of trust for Alice.

He can then use that money and buy something from Alice, knowing that Alice won’t steal from him in the product trade. Why? Because if Alice had wanted to steal from him, she could’ve done so previously anyway. We call this property risk invariance, because Bob’s risk exposure towards Alice does not change before and after the purchase. Before the purchase, Bob was willingly taking a risk of 1 coin, because it was in a shared account with Alice. After the purchase, Bob is again taking a risk of 1 coin, because he is waiting for a product worth 1 coin to arrive, but has removed the money from the shared account. In both cases, Bob was trusting Alice by risking 1 coin and nothing changed. When Bob receives the product, this closes the trade and he can replenish the trust by opening a new shared account with Alice, if he wants to.

The Trust is Risk wallet

Based on the very simple idea above, we know that people have friends that they are willing to trust financially. This is a very different situation from more traditional webs-of-trust, such as GPG, where trust is an arbitrary numeric value. Now trust is established as a monetary value, it is denominated in bitcoin, and everyone is equal in it. If Alice trusts Bob with 1 coin, and Charlie trusts Dave with 1 coin, that’s 1 coin everywhere. It has the same purchasing power. In this sense, we utilize money’s unit of account property to equalize what trust means for different people. Yes, maybe different people are less willing to trust others, but we now have a quantifiable means of establishing how much they trust each other without ever having to know their personality intricacies. We thus leverage the objective nature of money in order to “objectify” trust.

Imagine now that we provide a new generation of bitcoin wallets. This wallet is called the Trust is Risk wallet. You can move money back and forth between your traditional wallet and your Trust is Risk wallet to your heart’s content.

But your Trust is Risk wallet is different: In it, your money can be put in shared
accounts with your friends via trust transactions.

So, for example, if Alice has 60 mBTC stored in her Trust is Risk wallet, she could have allocated 36 mBTC of it to Charlie and 24 mBTC of it to Bob. That money is under risk: Alice is choosing her friends to put some of her own money under their control, and hopefully she’s choosing wisely. Here’s how her wallet could display her portfolio:

Pie allocation of funds

Here, she’s putting 36 mBTC in a shared account with Charlie and another 24 mBTC in a shared account with Bob, for a total of 60 mBTC.

Trust transactions have an additional cryptographic property: They can be used to prove to third parties that a trust relationship exists between two people.

Hence, if Alice and Bob maintain a shared account where Alice’s money is stored, they can publicize the respective Bitcoin transaction and everybody can know that Alice trusts Bob a certain amount of money. For reasons that will become clear below, we want to publicize all these trust relationships in OpenBazaar by default. One easy way to do that is to associate a fixed Bitcoin address with each OpenBazaar node and use that as-is in all trust transactions. There are also better ways of doing it using unique addresses that are verified to belong to their respective owners with a signature. Showing these transactions to third parties constitutes a proof-of-trust and is a powerful new primitive.

Trust transitivity

You may be asking: Why would I ever put my money in a Trust is Risk wallet? That sounds like a silly, unnecessary risk. But you get a unique benefit from that. If you’re willing to risk some money by having some exposure to known friends, then we can solve the decentralized trust problem. This is the crux of this reputation system.

Here’s how it works: You trust some money to each of your friends. They trust some money to their own friends and perhaps back to you. Their friends trust their own friends, and so on, forming a big network of trust similar to cryptographic webs-of-trust. However, this network is now associated with financial values.

Technically, we say that the web-of-trust forms a trust graph of people connected through lines-of-credit. Here’s how that graph looks like if Alice trusts Bob with 10 coins and Bob trusts Charlie with 20 coins:

A transitive trust relationship

Unlike the previous graph where we were showing a Bitcoin transaction with inputs and outputs, here the circles correspond to OpenBazaar accounts and the arrows correspond to lines-of-credit (also known as direct trusts) extended between them.

But now that we have two steps in the trust graph, something interesting happens: Alice not only trusted Bob with her money, but she also trusted Bob about his financial trust decisions. Imagine the following case: say Charlie decides to steal the money that Bob has deposited into their shared account. In this case Bob has incorrectly trusted Charlie by putting his money into their shared account. Then Bob has a spectrum of options with two extremes. In the first extreme, Bob can, in turn, take Alice’s money deposited in the account shared between Alice and Bob in order to replenish his loss. Of course, this is a worst- case scenario for Alice. The other extreme option for Bob is to decide to absorb the loss, which is a better scenario for Alice. Nevertheless, Alice is in practice exposed to some risk due to Charlie’s behavior through her trust in Bob. She not only has entrusted Bob with her money in good faith that he won’t steal it, but also gone a step further, trusting him with her money to make his own investments. But in any case, Alice’s liability is limited to the amount she has put in that account she shared with Bob. She can explicitly set a bound on how much Bob’s mishaps can cost her.

These two distinct options for Bob often arise in real-world economic scenarios. Suppose there is a client, an intermediary and a producer. The client entrusts some value to the intermediary so that the latter can buy the desired product from the producer and deliver it to the client. The intermediary in turn entrusts an equal value to the producer, who needs the value upfront to be able to complete the production process. However, for whatever reason, the producer eventually does not ship the product and neither reimburses its value. This could be due to bankruptcy or an illegal decision to exit the market with an unfair benefit. The intermediary can then choose either to reimburse the client and suffer the loss, or refuse to return the money and perhaps lose the client’s trust. Because losses can be passed down the line, we call this a transitive trust game.

Trust transitivity, especially in a decentralized financial setting, has been explored and supported by empirical sociological research of lending networks. They have independently discovered that our results, which we prove mathematically, empirically arise in real networks of people.

The flow of money

Just as an example, here’s what a slightly more complex trust graph looks like:

A trust graph

Here we have an interesting case of a trust cycle: A trusts D, who trusts B, who trusts A.

We’ve set up our trust graph. Now suppose you, the user of OpenBazaar, have a Trust is Risk wallet and some of your money is deposited to accounts shared with your friends. And, now, suppose you find some vendor who is also participating in the Trust is Risk network through his own wallet. Of course, you don’t trust that vendor directly. However, there may be indirect lines-of-credit extended to the vendor. Through your financial decision to trust your friends, a move you’ve made comfortably already knowing who they are, you have taken some calculated risk towards some pseudonymous vendor whom you’ve never met. In fact, since the trust transactions are public, your OpenBazaar node can calculate exactly how much this risk is. Calculating the exact risk value is not as easy as looking at each line-of-credit as we did in the simple case with just three people above, but regardless there’s a formula we can use to automatically evaluate it. This evaluation of risk exposure is performed using something we call the trust flow theorem. The risk is an exact value measured in bitcoin.

Here’s a fun trivia fact: The way we evaluate the total risk exposure of a buyer towards a vendor is using a fascinating classical graph theory algorithm from the 1950s called the maximum flow algorithm which was invented by Lester Ford and Delbert Fulkerson. They invented this algorithm to solve a completely different problem – the efficiency of the Soviet railway network.

Once we’ve calculated how much risk you already have towards a vendor, we can perform the same reasoning as we did previously:

  1. You willingly trusted money to your friends.
  2. This indirectly exposed you to a certain financial risk towards the vendor,
    which we calculated.
  3. If that vendor was evil and wanted to leave the market with an unfair
    advantage, which, in the worst case, could cost you your money, they could have already done so.
  4. You can now safely buy from that vendor up to a certain value without
    incurring additional risk – to pay for the product, just use some of your
    money from the account shared with your friend.

In order to buy from that vendor, you want to keep your risk the same prior to making a purchase and after completing a purchase. We have proven that this is possible in our risk invariance theorem, as long as your risk towards a vendor is higher than the price of the good you wish to purchase. Therefore, your Trust is Risk wallet will automatically pay the vendor by reducing some money you have deposited in the accounts shared with your friends and use that money to pay the vendor directly. The calculation of where to take money from in order to keep your risk constant is performed using a trust redistribution algorithm. For the user, it will be a simple matter of seeing the money leaving some shared friends’ accounts and paying the vendor.

One thing to understand is that this trust system is a new paradigm. It does not actively protect the user from mishaps in any way. There’s no way to flag the purchase as fake or talk to an escrow to have a conflict resolved. The only security insurance provided by the system is risk invariance: We’re only ensuring that the risk you were taking by trusting money to your friends is the same as the risk you are taking by making a purchase from an unknown entity. If (and that’s a big if) you have chosen to trust your friends with your money wisely, only then we make sure that the purchase is safe. But if the vendor decides to screw you, there’s nothing we can do about it, except show you a trace of why the vendor was deemed trustworthy, pointing exactly to whom of your friends you should stop trusting now (or whom of their friends they should stop trusting, and so on).

Unlike stars, the trust that the buyer is seeing for the vendor is personalized. We call this projected trust, a trust value that is potentially different when two different buyers are browsing the shop of the same vendor. This is a recurring theme in our work. We conjecture, although we have not proven, that secure decentralized trust systems must necessarily use some form of projected trust.

Putting it together

As you can see, we have approached the problem of trust, a broad and ambiguous concept, by mathematically defining it to be equal to financial risk. When Alice puts money in an account shared with Bob, we say that she directly trusts Bob. But we previously concluded that pseudonymous people far away in the network towards whom Alice has never extended any direct trust can still behave in a way that can cost Alice money – if she made a wrong decision when she decided to trust her friends. We call these indirect trusts.

This may all sound complicated, but the end user experience is simple. Let’s go through a purchase of some goods on an imaginary new version of OpenBazaar to see how this could work.

We’ll trace Alice’s steps from joining the network to successfully completing a purchase. Suppose initially all her coins, say 100 mBTC, are under her exclusive control in a traditional bitcoin wallet.

Two trustworthy friends, Bob and Charlie, persuade her to try out Trust Is Risk. She installs the Trust Is Risk wallet, perhaps even shipped as part of the OpenBazaar program, and migrates 60 mBTC of her 100 mBTC from her regular wallet, entrusting 24 mBTC to Bob and 36 mBTC to Charlie. She now exclusively controls 40 mBTC. She is risking 60 mBTC to which she has full but not exclusive access in exchange for being part of the network. Alice’s wallet is represented by the pie chart we went through above.

A few days later, she discovers an online pepper shop, Pepper Palace, owned by Dean, also a member of Trust Is Risk. She finds a nice Carolina Reaper pepper that costs 6 mBTC and checks Dean’s trustworthiness through her new wallet. Suppose Dean is deemed trustworthy up to 20 mBTC. Since 6 mBTC ≤ 20 mBTC, she confidently proceeds to purchase the pepper with her new wallet.

A pepper shop

We call these “20 mBTC” the allowance our system gives to Alice for making purchases from Dean. If she spends any money up to that amount, we can give risk invariance insurances. Spend money beyond that point and she incurs additional risk, which she can of course choose to take.

Hey, by the way, if you’re into peppers, this is a real product you can currently buy on
! 🌶

She can then see in her wallet that her exclusive coins have remained 40 mBTC. But the coins from her shared account with Charlie have been automatically reduced by 4 mBTC and are now down to 32 mBTC. And the coins in her shared account with Bob have been reduced by 2 mBTC and are now down to 22 mBTC. Dean has been paid 6 mBTC, equal to the value of the pepper. Also, her purchase is marked as pending. Under the hood, her wallet redistributed her entrusted coins in a way that ensures Dean has been paid with coins equal to the value of the purchased item and that her risk towards him has remained invariant. The “risk invariance” property is what her wallet has tried to maintain by redistributing the funds in this particular manner – always making sure she’s not exposed to more risk than before.

 Redistributed trust is risk wallet

Eventually all goes well and the pepper reaches Alice. Through her wallet, she marks the purchase as successful.

This lets the system replenish the reduced trust to Bob and Charlie, setting the entrusted coins to 24 mBTC and 36 mBTC respectively once again by moving funds from Alice’s exclusive account into the shared accounts. Alice now exclusively owns 34 mBTC. Thus, she can now use a total of 94 mBTC, which is expected, since she had to pay 6 mBTC for the pepper.

Sybil resilience

The careful reader will have noticed that this system is no longer Sybil-attackable. This  stems directly from the fact that indirect trust is projected and is based on risk.

What this means in short is that if I am a prospective buyer and have a certain amount of indirect trust (or risk) towards a certain group of malicious vendors, there is no way they can cooperate to increase the total trust I see towards them.

Regardless of how many fake trust connections they make between each other and towards others and regardless of how many new fake accounts they create, the trust I will have towards them will be the same and bounded by a specific value.

To see why, think about how it works in a simple situation with just a single step. Each trust transaction creates a limited liability. If Alice directly trusts Bob with 1 coin, there’s no way he can increase that by trusting others or creating fake accounts. He can’t create a fake shop that Alice trusts more than 1 coin, unless he solicits others to really trust the new shop more. It doesn’t matter how many good transactions he makes with himself using his fake buyers and sellers. It doesn’t even matter how many lines-of-credit he extends to himself. Adding more accounts and trust transactions himself will do him no
good. We formalize precisely what this means and prove this fact in our sybil resilience theorem. Intuitively, the only way to increase Alice’s trust towards him is to persuade people Alice trusts (or Alice herself) that he is trustworthy. He can achieve this for example by building a valid and dependable business.


This concludes the two pillars of security in our system: On the one hand, we give the user risk invariance, the insurance that they’re not exposed to any more risk than they were willingly exposing themselves to. On the other hand, we give the whole system sybil resilience, meaning there’s no benefit in creating fake accounts.

To summarize, we have proposed a new form of bitcoin wallet where people use shared accounts to take calculated risk towards their friends. This augments the OpenBazaar user interface with showing an “allowance” amount calculated behind the scenes using trust flow algorithms. If the user respects our recommendations, they incur no additional risk from making a purchase. For the completion of a purchase, the wallet automatically redistributes the funds in the Trust Is Risk wallet. The user can always replenish their wallet by putting in more money. The system remains resilient to Sybil attacks.

We hope one day a system like this can be made part of OpenBazaar and used by people worldwide to make safer trades in a decentralized manner without having to worry about their money being lost or stolen.

More resources and acknowledgements

We’ve been working on these concepts for quite a long time now.

These results have been developed at the Decrypto Lab, a loosely connected decentralized lab which bridges the Crypto.Sec group at the University of Athens, the Blockchain Technology Lab at the University of Edinburgh, the Department of Computing at Imperial College London, Corelab at the National Technical University of Athens and other schools and laboratories with interest in the subject.

A lot of work remains. The question of whether these security properties can be achieved without disclosing the whole trust graph to everyone is a burning open research challenge. A formal game theoretic analysis of the system would also be a much appreciated addition.

This is collaborative work with my colleagues:

  • Orfeas Stefanos Thyfronitis Litos, currently a PhD student at the University of Edinburgh worked on Trust Is Risk for completing his master thesis at the National Technical University of Athens. You can read his whole thesis [PDF]
    (of more than 70 pages), which goes in a lot of depth about all the theoretical material I presented here. He worked on most of the formalisms of the proofs and he developed all the trust redistribution algorithms. He also has a presentation of his thesis [ODP].
  • Christos Porios, currently a Software Engineer at Google Zurich worked on an implementation of Trust Is Risk as his Bachelor thesis for his graduation from Imperial College London. His whole thesis [PDF] (of 50 pages) is on the implementation of Trust is Risk and contains all the little details of how to get it done on top of Bitcoin. He also has a presentation of his thesis [PDF].

I was greatly honored to work with both of them.

I’m Dionysis Zindros, currently a cryptography/blockchains PhD student at the University of Athens and one of the original OpenBazaar co-founders.

Don’t take my word for all our claims and theorems. You can read all the formal math and proofs in our paper, Trust is Risk: A Decentralized Financial Trust Platform [PDF]. We also have a more concise proceedings version [PDF].

The paper was peer-reviewed and published in the Financial Cryptography and Data Security 2017 conference in Malta. The slides of our presentation are also available. We work in an open research setting. All our new experimental attempts at extending our theory are available on our theory GitHub repository where you can participate.

We have started working on a first version of a node.js implementation in our implementation GitHub repository, although most of the code is currently in pull requests. We’re also actively working on an SPV implementation.

All of this work was made possible through some very generous financing of our research by our partners, OB1 (the OpenBazaar company) and FrostWire – both have provided continuous support both financially but also technically. The whole team has inspired us with their work towards making trade free.

Brian Hoffman‘s, Sam Patterson‘s and Angel Leon‘s valuable input has helped us focus our research on applied topics that can be used in the real world to solve real problems. And of course our work is based on the great ideas by Washington Sanchez without whom this project wouldn’t have been born. We’re honoured to have Aggelos Kiayias as our PhD advisor, who has always encouraged us to become better scientists by understanding the problem and all the formal details behind it. Finally, this work was also made possible with the generous financing by IOHK and ERC.

Featured image from Pixabay, distributed under the Pixabay license.

Happy Valentine’s Day!

We want to wish you a very Happy Valentine’s Day. If you don’t know what to do today, we propose you these ideas:

  1. Watch a romantic movie on FrostClick

    We recommend you Time Travel LoverTime Travel Lover transcends the Hollywood formula of romantic comedy, creating a punching unromantic comedy that’s simple, entertaining, and incredibly brilliant, all packed in approximately ten minutes. The short is directed by Bo Mirosseni, written by Elisha Yaffe, and presented under Partizan Films.

  2. Create a Playlist of your favorite songs on FrostWire and share it with your true love!


  3. Invite your partner home, turn off the lights, have a glass of wine, light up candles, play a romantic song on FrostWire, and dance!

    romantic dance

How to save mobile data downloading torrents?

There are some moments —some sad moments— when you are away from home/work/school and you don’t have wi-fi to connect. If that’s the case, maybe your mobile phone will start consuming data. And if you run out of mobile data without realizing it, you may be in trouble.

So today we are going to explain how to save mobile data. Sometimes, you only to change a few settings on your Android in order to not use mobile data. For example, if you don’t want to use your mobile data downloading torrents. We made a very useful video explaining how to save mobile data downloading torrents from BitTorrent with FrostWire.

Did you like this video? Subscribe to our channel on YouTube.

Tips to save battery on Android

Do you get angry when your cellphone is running out of battery? Do you want to learn how to save battery on your Android device? We made a video that can help you! Sometimes you just need to do some little things in order to save battery!

This video will show you how to save battery when downloading files from the BitTorrent Network and YouTube when using FrostWire Plus for Android

Did you like this video? Subscribe!

How to fix ‘Can’t Open File’ error on Chrome for Android

Do you want to install FrostWire Plus on your Android and you’re getting the error:
“Can’t Open File”?

Screen Shot 2015-10-10 at 11.21.39 AM

We’ve made this video to show you how to fix the ‘Can’t Open File’ error on Google Chrome when downloading .apk files on Android.

This tutorial works not just for the FrostWire installer but for any app installer (.apk file) you may have had to download from a website, and it works for every Android phone or tablet.

There’s no reason why Google Chrome should be blocking the installation of .apk’s with their browser which happens to be the default of most phones out there, any app can handle opening .apk files, Google has simply decided to have more control of the android ecosystem and is trying to force everyone to use their Google Play market.

If things keep going this way, Google will be able to censor app developers completely if apps don’t follow their whimsical market rules, eventually they’ll turn Android into an iOS like environment where you can’t simply install apps without using the official store, the biggest bait and switch in the history of personal computing. Google, don’t be evil.

Do you like this video? Subscribe FrostWire on YouTube and watch all our how to videos.

FrostWire for Desktop’s Lines of Code Count

    8724 text files.
    8237 unique files.                                          
    8917 files ignored. v 1.60  T=121.17 s (65.3 files/s, 14184.1 lines/s)
Language                      files          blank        comment           code
Java                           7591         300370         340020        1033777
HTML                            192           2811           2130          21190
C++                              12           1337            510           3207
XML                              17            178            101           1632
C/C++ Header                     20            562           1623           1188
Ant                              19            289            136           1124
Maven                            10             66             20           1073
JSP                              16             64            606            777
Objective C                       7            184            100            675
Objective C++                     1            138             71            583
Javascript                        5             58             25            361
SQL                               1             34              7            288
CSS                               2             63             13            274
Bourne Again Shell                3             45             25            229
XSD                               2             28             57            187
C                                 2             58             14            134
PHP                               1             18              0             73
Bourne Shell                      4             13              1             45
DOS Batch                         7              8              4             41
make                              1              9              0             21
SUM:                           7913         306333         345463        1066879

Help us over a million lines of code at

New FrostWire 5.7.2 with uTP support

Download FrostWire 5.7.2 for Windows (Bitcoin, Litecoin, Dogecoin enabled .torrent)
Download FrostWire 5.7.2 for MacOSX (.torrent)
Download FrostWire 5.7.2 for Debian/Ubuntu (.torrent)

This release is all about performance and stability.

Some users have complained about what happens to their internet connection when using FrostWire heavily, so we’ve finally added uTP support to solve these issues.

FrostWire can now deal with bandwidth congestion issues in a way that won’t compromise your internet experience while you use it.

You can, for example, see how FrostWire will automatically adjust its transfer speeds to cede network resources to other programs in your computer, like your web browser while surfing the web or streaming a movie from Netflix.

If the connection is not being used by any other software FrostWire will automatically use as much bandwidth as it can, and you don’t have to do this manually using the existing throttling controls, and all this while not clogging up your router’s memory.

Another benefit of having added uTP is that some WiFi/DSL/Cable routers won’t have issues with packet data overflow when torrenting with FrostWire, which in some cases can completely drop the internet connection forcing you to restart your router to reconnect to the Internet.

We’ve also taken care of very important user experience details, that should make FrostWire easier to understand for new users, as well as smaller usability bugs and crashes that have been fixed.

Here’s the full list of changes.

frostwire (5.7.2) stable; urgency=high
  * uTP support enabled.
  * Multiple crash fixes.
  * UX: playable single file torrents now can be played from transfer list.
  * UX: Fixes UI Thread freeze when opening Options > Search.
  * UX: Better error reporting when a torrent can't be fetched from a
        magnet connection.
  * Spanish translation update by @dennistobar.
-- FrostWire Team <> Fri, 11 Apr 2014 14:22:10 -0500

Love FrostWire?
Consider donating. 
bitcoin – dogecoin – $1 – $5 – $10 – $25 – paypal

uTP support is here for Desktop and Android

Just wanted to let everyone know that as of the next FrostWire release, for both Desktop and Android, we’ve added uTP transport support.

uTP transport is a clever way to handle packet congestion in a way that:
1. Won’t mess most Wi-FI routers after doing a lot of BitTorrenting.
2. Won’t choke your internet connection.

Some users often complain that when they’re using FrostWire their entire internet connection gets really slow, or pretty much can’t use anything else. With uTP support this should not happen anymore, so great news!

We’re currently testing internally, in the next hours we’ll be releasing beta installers for desktop and android. Beta installers for desktop will be available on the official download page, and beta installers for android will be available for Google Play beta testers.

OSX Mavericks users, How to Prevent App Nap on FrostWire

Screen Shot 2013-10-31 at 1.33.04 PM

Go to Applications (or wherever you have installed FrostWire)

Right click on the the FrostWire Icon > Get Info (or just Press Cmd+I after you’ve selected)

Make sure FrostWire won’t nap when it’s in the background.

Otherwise, you may start a long running transfer and OSX Mavericks will put FrostWire to sleep and your transfer won’t finish.

This is only a temporary work around to this new issue introduced by Mavericks and its awesome power saving tactics, we’re working on an update so that you don’t have to do this in the future.

How to help translate FrostWire for Desktop (Windows / Mac / Linux)

Help us translate the FrostWire user interface, be part of an open source project, learn new things.

0. Get a account and sign in
Go to and sign up for a free account unless you have one already.

1. Download and install Git on your computer
If you don’t have git installed on your computer, here are instructions on how to install.

git, is a version control software which helps us keep track of all the changes on every file that belong to the FrostWire project. is a site where we host our source code and its origin git repository (the official one), think of the repository as a database to keep all those file versions.

GitHub is really helpful because it makes colaboration very social, we can comment and review each other’s changes before merging them into the origin repository.

2. Fork us on github.
Go to, this is the page for our origin repo. Forking means you will be making a copy of your own inside your github account. You will wok on that one, and when you are done you will send the changes to the origin repo.

For us by clicking on the button that says “Fork” on the top right.

Once the fork is done, you can go to your github personal page, and in the list of your repositories you should have your frostwire-desktop fork.

As of now, that copy lives only at, you could try and edit the files up there, but it’s very uncomfortable working that way, the text editor can be quite slow sometimes, so …

3. Clone your forked repo to your computer
Go to a command line, or with your favorite git client make a clone of YOUR repo (not ours).
If you use the command line git client, you should issue the following command

git clone

wait a few seconds and all the source code and assets that belong to the frostwire-desktop project will be downloaded to a folder called “frostwire-desktop” on your computer.

change directory to it…
cd frostwire-desktop

4. Create a branch for your translation
Create a branch with a name that will help us understand that this is a translation update you’re sending us, it could be named something like
“translation-french-2013-november-myname”, so that we can easily see what language you are translating, on which date you were working on it, and your name so we can give you credit for it.

You create a branch on the git command line like this (just remember to put the name of YOUR branch instead)

Create a branch locally
git branch translation-french-2013-november-myname

Push it to your remote repository
git push origin -u translation-french-2013-november-myname

now your branch lives both on your computer and at your github repository.

Switch to that branch
git checkout translation-french-2013-november-myname

Now you’re ready to start working on your branch.

After we’ve accepted your changes, next time you want to help us do another update of the translation you will have to create a new branch.

5. Make sure the latest english strings have been put into your language.po file
enter the following command to sync strings

ant gettext-extract

(this could take a while to finish as it goes through every line of code looking for translatable strings.)

6. Translate, translate, translate
Now you get to do the actual translation. Translation files are in the following folder inside the frostwire-desktop project
cd lib/messagebundles

If you’re going to translate say to arabic, you will edit the ar.po file, it should be easy to find the language file for the language you intend to work on. We recommend that you use a PO Editor software to make things easier, and always make sure to save the file using UTF-8 encoding.

7. Test your translation
To test your translation, you will need to recreate the message bundle file, for this you will need to invoke the following command

ant gettext-bundle

assuming you didn’t mess up anything in the format of the .po file this should finish after a few minutes of bundling every language file.
If you see any errors you should try to fix them, if you don’t know how to fix them you can reach us on the FrostWire forum, or right here for help.

once the bundle is built, you need to test your translation, for this you will need to build FrostWire, you can do this in one step, from the root frostwire-desktop folder type:


after a couple minutes it should be done compiling everything, and then you can invoke the “run” script right there if you’re on Linux or Mac, if you’re on windows, go to gui/ and invoke the run.bat file.

FrostWire will open, switch to your language and make sure your translations are fine.

8. Time to commit and push your changes

Once you are finished, commit your changes, make sure you don’t make changes in other files than the .po of the language you are working with.
So if you’re working say with italian, you would do (from the frostwire-desktop root directory)

git commit lib/messagebundles/it.po -m "my translation update for italian users"

and then push it to your fork up on github

git push

9. Submit a pull request

Once you see your last commit on github and you are sure you’re finished, it’s time to let us know, so you will submit what’s called a “Pull Request”.
If there are any special notes please let us know, we’ll review your changes, and if everything is good to go, we’ll merge them, and you will make open source history 🙂