FrostWire 6.8.10, our last desktop release for 2020, Cheers to 2021.

Bundle Free, 100% Free Installers

macos: frostwire-6.8.10.dmg

ubuntu/debian: frostwire-6.8.10.amd64.deb
redhat/rpm: frostwire-6.8.10.amd64.rpm

anything with a Java10+ runtime: frostwire-6.8.10.amd64.tar.gz

If you find this free software useful and you can contribute to keep it free, please make a donation, but best of all tell your loved ones about it, the more people on the network the better it works.

This is our last desktop release for 2020, and it’s a big one to get 2021 started.

It includes loads of libtorrent fixes and optimizations from libtorrent

A fresh new build of the Telluride Cloud Video Downloader which includes all the fixes from youtube-dl all the way to Dec 29th 2020.

We’ve fixed some bugs that would cause errors downloading video from the cloud, more videos will be downloaded and archived from hundreds of video hosting websites.

New Transfer Detail Popup Menus

We added a couple of tiny UI features for Torrent Transfer Details.

Open the OS’s file explorer on a transfer’s file


Copy IP,Addresses from Peers into clipboard


frostwire (6.8.10) stable; urgency=high

  • Fixes file naming issues that would cause errors in cloud video downloads
  • jlibtorrent- update
  • jaudiotagger 2.2.5 to 2.2.6 update
  • Telluride Cloud Video Downloader build 8
  • lt: upgraded to openssl 1.1.1l
  • Fixes issue with Telluride results and emojis in filenames
  • Fixes bug where transfer file detail actions would go blank when left clicked. (74291c0)
  • New File Transfer details popup menus: FIles > Explore, Play
  • lt: fix issue with moving the session object
  • lt: deprecate torrent_status::allocating. This state is no longer used
  • lt: fix bug creating torrents with symbolic links
  • lt: remove special case to save metadata in resume data unconditionally when added throught magnet link
  • lt: fix bugs in mutable-torrent support (reusing identical files from different torrents)
  • lt: fix incorrectly inlined move-assignment of file_storage
  • lt: add session::paused flag, and the ability to construct a session in paused mode
  • lt: fix session-pause causing tracker announces to fail
  • lt: fix peer-exchange flags bug
  • lt: allow saving resume data before metadata has been downloaded (for magnet links)
  • lt: record blocks in the disk queue as downloaded in the resume data
  • lt: fix bug in set_piece_deadline() when set in a zero-priority piece
  • lt: fix issue in URL parser, causing issues with certain tracker URLs
  • lt: use a different error code than host-unreachable, when skipping tracker announces

— FrostWire Team Tue, 29 Dec 2020 17:10:00 -0600

New FrostWire 6.8.6 for Windows, macOS and Linux

Download the new release with the faster torrent downloads and improved search

Windows 64-bit: MB

macOS 64-bit:
frostwire-6.8.6.dmg45.7 MB

Ubuntu/Debian 64-bit
frostwire-6.8.6.amd64.deb13.5 MB

Red Hat/RPM-based
frostwire-6.8.6.amd64.rpm14.9 MB

Java 11+ for any other OS
frostwire-6.8.6.amd64.tar.gz1 4.2 MB

Source code(zip)
Source code(tar.gz)

frostwire (6.8.6) stable; urgency=high

  • New jlibtorrent update
  • New 1337x search (thanks to @HimanshuSharma789)
  • New iDope search (thanks to @HimanshuSharma789)
  • Fixed Torrentz2 search dates (thanks to @HimanshuSharma789)
  • Fixed Sound Cloud search
  • Discontinues mplayer video playback, uses os default video player for videos
  • -> 1.4
  • com.squareup.okhttp3:okhttp:4.4.1 -> 4.8.1
  • com.h2database:h2:1.4.199 -> 200
  • lt: validate UTF-8 encoding of client version strings from peers
  • lt: don’t time out tracker announces as eagerly while resolving hostnames
  • lt: fix NAT-PMP shutdown issue
  • lt: improve hostname lookup by merging identical lookups
  • lt: fix network route enumeration for large routing tables
  • lt: fixed issue where pop_alerts() could return old, invalid alerts
  • lt: fix issue when receiving have-all message before the metadata
  • lt: don’t leave lingering part files handles open
  • lt: disallow calling add_piece() during checking
  • lt: fix incorrect filename truncation at multi-byte character
  • lt: always announce listen port 1 when using a proxy

— FrostWire Team Sun, 23 Aug 2020 10:45:00 -0600

New FrostWire for Android (2.1.10) fixes Music Playback on older Android Lollypop (5.x)

Sorry for the inconvenience to Lollypop users, not sure how music playback was broken, a last minute bug must have slipped in our last release. In any case, here’s a new installer that resolves music playback issues for all Lollypop releases.

frostwire-android-release-2.1.10-b638-plus.apk 19.4 MB

Get FrostWire Plus 1.9.9 for Android!

Download NOW!

It’s time to update! A new version of FrostWire Plus is available for #Android users. If you want to get more search results using FrostWire, you have to download this new version. We fixed EZTV, Torlock, and Zooqle. Moreover, we fixed some bugs related to the filtering tools. Also, the music player now has all horizontal layouts available.


FrostWire 1.9.9 – AUG/14/2017
– Creative Commons Features removed for Google Play users, available on FrostWire Plus
– Search: EZTV, Torlock, Zooqle fixed
– Search: BTJunkie removed
– Download: Yify magnets can now be found in DHT
– New jlibtorrent
– Filtering bug fixes
– Audio Player ‘Clear Queue’ fix
– Crash fixes, performance upgrades
– ogury 2.1.13
– compileSDK 26, gms 11.0.4, gradle 4.0.2, android support 26.0.1
– Update in VPN offering
– Fixes freeze copying magnets to clipboard
– Less ads
– Music player has all horizontal layouts
– Warn user about Internet Connection dropped

What is FrostWire?

FrostWire is a free, open source BitTorrent client first released in September 2004, as a fork of LimeWire. It was initially very similar to LimeWire in appearance and functionality, but over time developers added more features, including support for the BitTorrent protocol and a full blown media player.

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.

Get FrostWire 6.3.4. for Windows, Mac and Linux! New Media Player Included!

Get FrostWire 6.3.4!

Big News! Today, we are releasing a new FrostWire version (6.3.4) for Windows, Mac and Linux.This update features a major upgrade.Now, FrostWire includes a new Media Player build based on bleeding edge mplayer +1.3.0 and ffmpeg +3.0, which not just allows you to play a lot of videos you might not have been able to play before, it’s a faster player which uses your computer CPU more efficiently, featuring over 2 years worth of upgrades by hundreds of open source contributors worldwide.

Moreover, this new MPlayer previews fine all YouTube audio/video. It supports VP8, VP9 and HEVC codecs, so now you are allowed to watch millions of videos. The new Mplayer features over 2 years of fixes and upgrades in audio/video technology included.

Our YouTube search has been fixed so expect more search results after the update!


frostwire (6.3.4) stable; urgency=high
* Fixes YT search issues
* New media player based on mplayer 1.3.0 and ffmpeg 3.0 fixes
YT audio preview issues, video playback issues. VP8, VP9, HEVC support.

— FrostWire Team <> Mon, 18 Jul 2016 20:59:05 -0500

What is FrostWire?

FrostWire, a BitTorrent Client & YouTube Downloader that makes it easier to search, download, play and share content from the BitTorrent network & cloud sources, all in one place, announced today its new ‘preview’ and ‘play as you download’ capabilities for Android phones and tablets. The new preview feature not just enables users with a more convenient way to find and discover content, it makes downloading optional in some cases.

Get FrostWire 6.3.0 for Windows, Mac and Linux!!

Finally you can download FrostWire 6.3.0 for Windows, Mac and Linux, a new version with a really and highly requested feature: a new transfer tab that allows you to filter transfers by state and keywords.

filter frostwire


We also fixed Torlock and EZTV search results, and we added a new search engine:

Search Engines


frostwire (6.3.0) stable; urgency=high
* Greatly improved seeding connectivity. Seed and share magnets!
* New transfers tab, allows you to filter transfers by state and keywords.
* Finished cloud transfers are seedeable.
* If seeding setting is active, finished cloud transfers are seeded.
* Improved ‘Search for Keywords’ suggestions for episodic queries.
* New jlibtorrent
* Spanish, Portuguese translations updated.
* Fixes Torlock search.
* EZTV no longer returns irrelevant results.
* New Search Engine:

— FrostWire Team <> Thu, 02 Jun 2016 11:42:00 -0500

What do you think about this new version of FrostWire? We want to read your opinion!

What is FrostWire?

FrostWire, a BitTorrent Client & YouTube Downloader that makes it easier to search, download, play and share content from the BitTorrent network & cloud sources, all in one place, announced today its new ‘preview’ and ‘play as you download’ capabilities for Android phones and tablets. The new preview feature not just enables users with a more convenient way to find and discover content, it makes downloading optional in some cases.

FrostWire Plus, a BitTorrent Client and YouTube Downloader. How to Install It?

FrostWire Plus is a free, fully featured BitTorrent Client and YouTube/SoundCloud downloader with a built-in Music Library designed specifically for Android devices.

FrostWire Basic (the one you can get on Google Play) and FrostWire Plus are based on the same code, but FrostWire Plus has the ability to download from YouTube and SoundCloud in addition to the BitTorrent Network.

You can get FrostWire Plus for free on our official site. To install, follow this easy steps:

1. Allow Apps from outside Google Play first: Tap on Settings -> Lock screen and Security -> allow ‘Unknown Sources’

lock screen security

Unknown sources

2. Go to with Firefox or any browser other than Chrome and download the installer.

FW Plus

3. Tap on the .apk file from the Android notifications or find it using any File Explorer (we like File Commander). The .apk will usually be in the Downloads folder.

install fw

[If you get an error ‘Can’t open file’, you need to download any APK Installer from Google Play first. Most devices come with one pre-installed though]

4. Install it and you are ready!

FrostWire Plus

Watch this video if you have any doubt!

Need more help? Send us a message on Facebook!

New FrostWire 6.2.0 [Windows, Mac, Linux] is out – Fixes YouTube issues and more

Download FrostWire 6.2.0 now

A new FrostWire update is available for Windows, Mac, Linux.  This is an urgent release that includes YouTube search fixed, TPB search fixed and also a search results issue fixed.

frostwire (6.2.0) stable; urgency=high
* Fixes issue where partial downloads from search results would download. the rest of the .torrent files.
* New jlibtorrent
* Updated okhttp to 2.7.1.
* TPB fixed.
* YT fixed.

— FrostWire Team <> Tue, 05 Jan 2016 20:40:10 -0500

What is FrostWire?

FrostWire, a BitTorrent Client & YouTube Downloader that makes it easier to search, download, play and share content from the BitTorrent network & cloud sources, all in one place, announced today its new ‘preview’ and ‘play as you download’ capabilities for Android phones and tablets. The new preview feature not just enables users with a more convenient way to find and discover content, it makes downloading optional in some cases.

New FrostWire Plus for Android (1.6.9) – First Release of 2016!

Download FrostWire Plus 1.6.9 now

Happy 2016! We hope this year brings you happiness.

We are proud to launch a new version of FrostWire Plus for Android. This release has some important search fixes, so you’ll want to get it right now!


FrostWire 1.6.9 – JANUARY/05/2016
– Crash fix.
– Updated to new jlibtorrent
– Updated to new okhttp 2.7.1.
– Fixes on torrenting settings that were not being correctly applied.
– TPB fixed.
– YT search fixed.

How to install FrostWire Plus?