Image: Hamish Duncan

Lightning VS Raiden #3: myths about business models and accountability of watchtowers (also Celer & PISA)

In the third article of this series we will try to understand if layer-2 watchtowers can scale without becoming a tool of global financial surveillance.

Lightning and Raiden series:

1. Differences between LN watchtowers and RDN monitoring services
2. Solutions to scaling problems and their trade-offs
3. Accountability and viable business models (current)

Other languages: 简体中文

Disclosure: I own BTC, ETH, BCH, RDN and other coins, but my portfolio is heavily diversified, so I don’t have financial incentives to shill for any particular coin. I’ve been contributing to Raiden and Celer projects, and I hope to see many more projects with different scaling solutions that will compete with each other, while users will have a freedom to use a payment solution of their choice. If you belong to a different camp, that’s fine, I have nothing personal against you and we can still collaborate. This article is brought to you by a privacy-oriented peer-to-peer marketplace LocalCryptos.

Intro

Watchtowers will have a tremendous impact on users of payment channels, so two previous articles of this series spiked great discussions in the community, because it’s important to research incentives models and different designs while the tech is in early development stage. Unfortunately, there is a lack of research papers on this topic, and there are widely accepted misconceptions such as “we shouldn’t worry about UX and privacy at the start, because they can be improved over time”, which we will debunk in this article.

I’d suggest to read the first part of this series in order to understand why watchtowers are essential for scaling and their main challenges. Additionally, in the second article you can learn about different solutions to privacy and scalability issues, and their trade-offs. And finally, now it’s the time to discuss viable business models and accountability in order to understand if payment channels can scale without becoming a tool of global financial surveillance.

Note that off-chain protocols have different names for watchtowers such as Raiden monitoring services, Celer’s State Guardian Network, or PISA. However, in this article we will refer to all implementations as “watchtowers”, unless specified otherwise (e.g., LN watchtowers, RDN monitoring services, etc.)

We will also use terms:

1. business-oriented to refer to watchtowers that can link together all state updates made by the same channel or account
2. privacy-oriented to refer to watchtowers that cannot link together state updates made by the same channel or account

For more details about these models, see the first article.

Side note: some people have asked why the wording is “business VS privacy”. Well, businesses try to increase their revenues and survive the competition. Watchtowers that don’t care about privacy have more ways to increase their incomes and decrease expenses, which makes them more viable.

Accountability

Each user wants to be sure that a hired watchtower will protect him 24/7 and it will be on his side during any dispute, so let’s start our journey by quickly outlining main approaches to improve accountability and their drawbacks.

For better understanding of main differences, let’s make a rough rating of key characteristics of each model.

Keep in mind that “High” security doesn’t mean that user’s funds are 100% safe, because there still be different vulnerabilities that can be exploited via e.g. collusion or hacker attacks.

It’s important to mention that these accountability approaches can be combined together and they will be used with different business models (described in the second part of this article), so the final outcome is unclear. We will think about the perfect solution for a watchtower problem in the last article of this series (coming soon).

Now let’s discuss different accountability models in more details.

1. A reward for a successful dispute of a malicious settlement

This approach is important to insure that a watchtower will be on user’s side in most disputes, unless it colludes with a malicious actor (e.g. a big hub) in order to get a higher reward for not stopping a fraudulent settlement.

UX of this model is high as well, because a user won’t need to perform any additional actions, apart from sending his state updates to watchtowers.

However, this approach will create a conflict of interest, because watchtowers will financially benefit if there will be many cheating attempts or unintentional channel closures with invalid states.

2. Reputation system

Although implementing a reputation system is a popular approach to reduce risks on peer-to-peer platforms, there are many drawbacks:

• A trust-based system is opposite to trust-less values of cryptocurrencies.
• A reputation system won’t prevent mass-exit-scam scenarios unlike on p2p exchange platforms. For example, if a trader on a P2P OTC trading platform decides to go rogue, his reputation will drop fast and thus he won’t be able to cheat many users; while a malicious watchtower will be able to cheat all of its clients at once by stopping providing its services, even though the services were prepaid in advance. Additionally, an adversary watchtower can collude with malicious hubs or other 3rd party entities to maximize its gains during a massive exit-scam.
• It’s unclear how to make sure that a watchtower’s reputation will decrease if it failed to perform its duties. If a user loses his device with all the latest state updates, then it will be almost impossible for a user to prove that a watchtower has failed to protect him, especially since laymen are not tech-savvy and often lazy to pro-actively report such events. So how can users trust that a watchtower’s reputation score is accurate and that it did prevent all malicious settlements in the past?
• A reputation system has poor UX, because a user has to take additional steps during on-boarding process in order to find a watchtower that suits his requirements, using some aggregator or so-called “marketplace”. Unfortunately, such marketplace will add even more complexity to already complex system and thus greatly decrease adoption beyond geeks.
• What if (1) a watchtower decided to exit the business without cheating anybody or (2) a watchtower’s reputation has seriously decreased, who and how will notify a user about that? Should a user again trust some 3rd party to notify him in case he needs to perform additional actions?
• What if a watchtower decided to exit the business, but continues to receive new state updates and payments without actually storing state updates or monitoring the blockchain, how much time will pass until users will find out that a watchtower is not protecting them anymore?
• A system is vulnerable to Sybil attacks (fake clients, reviews, etc.)
• A reputation system increases centralization, because laymen often choose the most trusted vendor.

3. Security deposit to financially penalize malicious watchtowers

A watchtower can stake some coins/tokens, which it risks to lose if it will fail to dispute a settlement when a malicious counterparty appears.

There are two different models: either a watchtower is randomly chosen by an algorithm from a pool of watchtowers, depending on its staking size, or each user chooses his own watchtower directly.

3.1. A pool of watchtowers

A watchtower is randomly picked by an algorithm from a pool of watchtowers, depending on its stake size. The more coins one stakes, the statistically more likely he gets assigned to watch user’s states and earn fees. The key idea is that each state update is being distributed among multiple watchtowers (e.g. 3–5) and if the first watchtower fails to fulfill its duties in time, other watchtowers will be able to take its deposit.

This solution is utilized by Celer Network, and has great advantages such as strong collusion resistance, but there are certain drawbacks and concerns:

Side note: keep in mind that the concerns below are about an accountability solution (a pool of watchtowers), not about Celer in general. However, some concerns below are valid for Celer’s SGN as well.

• Each state update will be guarded by multiple watchtowers, which improves overall security, but as a trade-off it increases operating costs of the network, overall off-chain transactions fees, and decreases privacy.
• Staked coins are exempt from the circulation, decreasing overall liquidity, because in order to achieve high security, watchtower’s deposit size should ideally match the maximum possible loss of user’s funds.
• If a system won’t require watchtower’s deposit size to match the maximum possible user’s losses, then during low competition periods the average deposit will be too low to prevent mass-exit-scam scenarios via collusion with multiple entities (e.g., watchtowers and hubs). On the other hand, in case of high competition the entry barrier will be too high, which typically leads to businesses centralization.
• If a watchtower loses the whole deposit in case of a failure to stop any malicious settlement, then it will be very risky to stake a big deposit. To avoid such risks, a watchtower will try to split its deposit into multiple peaces, acting as different independent watchtowers. That will give one entity higher chances to receive all state updates from the same transaction, which will increase risks of cheating attempts via e.g. collusion with malicious hubs.
• If a watchtower with a large deposit will get disproportionally high chances to be appointed as a watchtower (e.g., 20% of network deposit will give 30% to be appointed), then that will increase centralization.
• The system is sensitive to price swings (e.g., during bear markets people are less incentivized to become watchtowers, because they have to stake coins that are constantly losing value; while during bull-runs watchtowers will be financially incentivized to start unstaking period to sell their deposits).
• If a user lost his device with all the latest state updates and can’t recover cloud backups, then he won’t be able to submit a proof that a watchtower failed to dispute a malicious settlement in order to get a compensation from a security deposit. There are some workarounds though, e.g. Celer Network is planning to solve that with SGN full nodes, which are basically watchtowers that store all the latest state updates for all channels, and they can help a user to punish malicious watchtowers in exchange for a fee. However, there are concerns about the implementation, privacy and viability of full nodes model, because full nodes will have high operating costs that have to be covered.
• A user cannot prove a malicious behavior and get a compensation if he comes online after malicious watchtowers have unstaked their deposits. Of course, unstaking period should be very long, but a user can get into jail, coma, etc.

Mo Dong, co-founder of Celer Network, is more optimistic about these issues, you can read his responses to most issues above in this Twitter thread (there are many branches).

3.2. Individual watchtowers

Another approach is that each user will choose a certain watchtower, which has locked up large funds in the smart contract as a “security deposit”. This approach is used by PISA, but it also has certain drawbacks and concerns:

• Large collateral requirements for watchtowers will lead to centralization.
• There are two different designs. (1) Suppose a watchtower loses just a portion of its deposit in case of a failure to defeat an attack, then that won’t prevent massive exit-scam scenarios, when a big watchtower is colluding with a big hub to cheat many users at once.
• (2) In another design (the original PISA’s approach), a watchtower losses all its stake (e.g., $50k) in case of a failure to defeat even a small attack (e.g., $10). On the one hand, this decreases risks of collusion, which is good, but on the other hand, this increases business risks of operating a watchtower, since a network outage or other technical problems can lead to a loss of all the stake. And it’s fair to say that high business risks lead to either high fees, or low competition, and hence higher centralization.
• During a long bear market people will be less incentivized to stake large deposits in order to become a watchtower, which leads to lower competition and greater centralization.
• Poor UX, because a user has to find a watchtower in some database that contains id/name, a security deposit value, a deposit period (withdrawal date if any), monitoring fees, and then make a conscious decision which watchtower to choose. Additionally, guarding fees can change anytime, or a watchtower can decide to unstake its deposit, so user will be forced to find another watchtower.
• Poor UX will probably increase centralization even further, since laymen tend to use the most popular vendor.
• This model also shares certain drawbacks with a previous model such as large deposits decrease overall liquidity, the system is less stable during price swings, and a user can’t punish a watchtower that has already unstaked its deposit.

Patrick McCorry, creator of PISA, disagrees with certain statements above and argues that UX barely exists in any off-chain protocol; you can read his point of view in this Twitter thread (it has many branches).

Now, when we have a basic understanding of different approaches to solve accountability, let’s finally move to the most anticipated part of this series.

This article is brought to you by a privacy-oriented peer-to-peer self-custodial end-to-end encrypted marketplace LocalCryptos, where you can buy & sell cryptocurrencies for fiat money. To start trading, create a new password-protected account or log in with your favorite wallet such as Ledger, MetaMask, or mobile apps like imToken.

Business models

Watchtowers can choose different strategies to monetize their services, and all of them have certain pros and cons:

If you tend to appeal to authority, then you can finish reading here, but if you want to find the truth by yourself and may be challenge my statements, then keep on reading, because now I will explain the results for each model.

Side note: there is a common misconception that “UX and privacy can be easily improved overtime”, so it’s important to mention that poor UX and low privacy in this chart doesn’t refer to just the beginning stage, but to a mature product after a significant amount of development. The root-cause of poor UX and low privacy is not the implementation, but the model itself. Good UX should be able to compete with centralized e-payment solutions such as Visa, PayPal, WeChat, AliPay, PayTM, etc., while high privacy should give a similar amount of privacy as cash.

1. Altruistic watchtowers (no compensation at all)

Laolu “roasbeef” Osuntokun, CTO of Lightning Labs, said that a current goal is “to get a basic system up without any sort of compensation.” This approach is the simplest one, but will fail on the global scale because of high operating costs of watchtowers (especially, privacy-oriented watchtowers).

Accountability

It’s not clear how to fix accountability issues without any financial incentives, because even a reputation-based system won’t work, since a watchtower won’t be financially attached to its reputation score.

Scalability

You can argue that a billion different state updates won’t take much space, and that’s true, but the database of a privacy-oriented watchtower will grow quadraticly, and bandwidth requirements will increase as well, so eventually altruistic watchtowers will not be able to handle the transaction quantities taking place.

Additionally, this model is extremely vulnerable to spam attacks.

Privacy

Adversary watchtowers might provide their services for free and then sell all the collected data to the highest bidder, which introduces major privacy risks. Of course, developers say that this data is encrypted and thus worthless, but that’s a clear exaggeration, because adversaries will get a lot of info:

• time of each transaction
• frequency and total amount of transactions

Also possible to obtain:

• all transactions associated with a particular channel (RDN)
• all transactions made by the same channel or account (LN’s eltoo & RDN)
• IP address (most laymen won’t use anonymizers, unless they are built-in and set by default in a client; and don’t forget that VPNs and even Tor bridges often don’t work in many censored regions, especially since there was a huge expansion of censorship technologies in the last few years into developing countries due to a rise of authoritarian governments)
• approximate transaction destination via traffic correlation

Certain entities are able to do traffic analysis on Tor network, so they will definitely try to do similar analyses using watchtower’s data in attempt to deanonymize certain users, especially knowing how much money are spent on financial surveillance nowadays.

UX

Users won’t have to perform any additional actions, so overall UX is good.

Results:

• Scalability: hard
• Privacy: uncertain
• UX: good
• Viable: NO

2. A reward for preventing a breach attempt

Users might offer compensation to watchtowers for each penalty transaction that was successfully broadcasted by watchtowers on behalf of their clients.

Accountability

Watchtowers will be financially incentivized for broadcasting penalty transactions (or stopping malicious settlements in case of RDN), which is important. However, watchtowers won’t lose anything for not stopping cheating attempts, unless there will be a complex reputation system with a poor UX, or some kind of security deposit.

Scalability

Unfortunately, this business model is fundamentally flawed, because in order for watchtowers to exist, the cheating transactions should occur frequently enough to cover watchtowers’ operating costs.

Even Tadge Dryja, co-author of the Lightning Network white paper, admitted that it’s not a reliable scalable system.

Hopefully the channel never closes in an invalid state, so you’re giving them a reward for something that’s not supposed to happen. So that doesn’t work.

Additionally, not only big hubs, but also watchtowers will be financially rewarded if users accidentally close their channels with invalid states, so watchtowers can broadcast penalty transactions and get their rewards. That will financially incentivize big off-chain entities to develop malwares that will close users’ channels with invalid states in order to “legally” steal funds from users.

This model is also vulnerable to spam attacks since users are not directly paying for watchtowers services.

Conclusion: this approach will create a strong COI (conflict of interest). In general, watchtowers will benefit if the network will be safe-to-use, because that will increase the number of its users. On the other hand, watchtowers will need a certain amount of users to periodically lose their money due to “invalid-state-closing”, because watchtowers need to broadcast penalty transactions in order to cover their operating costs.

Privacy

A high level of privacy can be achieved with this approach.

UX

Users won’t have to perform any additional actions, but a reputation system as an attempt to improve accountability can decrease user experience.

Results:

Scalability: low

Privacy: high

UX: good

Viable: NO

3. One-time fee for each new state update

This is the current approach of many designs — to include a small payment into each package sent to a watchtower, or pay during a session initiation, which will reserve a number of “slots” that can be later filled with encrypted blobs (state updates).

This approach ensures that watchtowers will cover operating costs even in the absence of any cheating attempts or accidental “invalid-state-closing” events. Watchtowers will also get a different reward from each user depending on his economic activity.

Accountability

The key problem here is that users won’t have any guaranties that watchtowers won’t exit business in the next few days/months/years, so users have to trust watchtowers to store their state updates and watch their open channels forever(?).

And since there will be no direct financial incentives for broadcasting penalty transactions, there most likely be a complex reputation system with low UX, which won’t prevent exit-scam scenarios, or a security deposit, which has its own drawbacks.

Scalability

The problem with scaling is that privacy-oriented watchtowers will get only one-time compensation for each state update, while they will have to store it forever (or, in some implementations, until the channel will be closed), so the operating costs will constantly increase, even if the money inflow from new transactions will stay at the same level or decrease. That leads us to a system that can be stable only during exponential growth, while during times of declined activity, most watchtowers will be pushed out of the business.

Imagine a privacy-oriented business that charges users for every uploaded file only once, regardless of how long the file should be stored. How viable this business will be?

One can argue that business-oriented watchtowers need to store only the latest state update, so they don’t have to store each state update forever. Although it’s true, this approach will have low privacy, since watchtowers will be able to associate all state updates made by the same channel, and low UX, because users will have to choose the amount of fee they want to attach to each state update, but some state updates should be stored for just a few minutes, while others must be stored for months. It’s completely unclear how to prevent high over-lapping fees, while preserve security. And if we don’t care about privacy or UX, then there are much more viable business models (see below), so I don’t see any reason to implement a one-time fee for each new state update together with business-oriented watchtowers.

Privacy

The good side of this approach is a high level of privacy if implemented together with privacy-oriented watchtowers.

UX

Users won’t have to perform any additional actions, but they will have to pay an extra fee for each transaction, which will decrease UX; and a reputation system or security deposit as an attempt to improve accountability can decrease UX even more.

Results:

• Scalability: hard
• Privacy: high
• UX: medium
• Viable: NO

4. Monthly or annual subscriptions

Watchtowers can charge monthly or annual service fees, which will ensure that they will cover operating costs even in the absence of any cheating attempts or accidental “invalid-state-closing” events. Unfortunately, there are a few issues with this approach.

Accountability

Watchtowers won’t be directly rewarded for punishing cheaters, so accountability issue is very important in this design. Most likely it will involve a security deposit or a reputation system, which will decrease UX and will be vulnerable to mass-exit scenarios.

Scalability

Even thought this business model is more viable than those listed above, there are still many problems.

• The operating costs will vary a lot depending on the user’s activity.

It’s not clear how much of a monthly fee to charge. Some very active users or businesses can do 1000 times more transactions, than other less active users. Of course, this issue can be mitigated by introducing different monthly fees depending on the amount of transactions made per month, or the total amount of states that were updated and stored, but that will add even more complexity to a system and further decrease UX.

• Developing countries can’t pay the same price.

Even a relatively small fee of a few dollars per month can be a deal-breaker for a global adoption, because most population live in developing countries, where an average salary is much less than in privileged countries.

• Laymen will trust one single watchtower.

Users will need to buy multiple monthly subscriptions from different watchtowers to mitigate the risks associated with trusting one 3rd party entity. Unfortunately, with this approach users have to pay more for every additional watchtower in use, so most laymen will skip that and just use one watchtower, decreasing the overall network security.

Privacy

This business model implies that watchtowers will be able to associate together all state updates made by the same account, which opens a door to a massive financial surveillance similar to traditional banking system.

UX

Firstly, a user has to find a watchtower, prepay one week/month/year, and then make periodic payments every now and then, which is already a poor UX comparative to other centralized e-payment solutions that don’t have any watchtowers.

Secondly, what if a user forgets to pay monthly/annual fee? OK, suppose there will be auto-payment options, but what if a user couldn’t pay a fee because of financial problems? All state updates will be deleted after a certain period of time and a watchtower will stop protecting him from cheating attempts? That will expose a user to risks of losing his money, which will worsen his situation even further.

Results:

• Scalability: medium
• Privacy: low
• UX: poor
• Viable: YES

5. A periodic fee for each stored state update

The most viable business model for privacy-oriented watchtowers involves a subscription-based system, in which each user pays a periodic fee for the amount of state updates that being stored by a watchtower.

Accountability

If there will be no direct financial incentives for broadcasting penalty transactions, then most likely there will be a security deposit or a complex reputation system with low UX, which won’t prevent exit-scam scenarios.

Scalability

This approach allows easy scaling, because both business-oriented and privacy-oriented watchtowers will have enough funds to cover their operating costs even in the absence of any breaching attempts.

Privacy

Unfortunately, this model implies some kind of subscription-based system, because users will have to pay monthly/annual fees for the amount of stored state updates, so a watchtower will be able to associated all state updates with certain accounts. This business model will allow massive financial surveillance, destroying the whole purpose of a privacy-oriented design of watchtowers.

UX

The user experience of this model is also poor, because users will have to pay periodic fees every now and then. Of course, it’s easy to implement auto-payments, but what if a user will forget to keep a positive balance on his wallet or he will have financial problems? Delaying a periodic fee will expose a user to risks of losing his money.

Additionally, users will be financially incentivized to close “heavy” channels if using privacy-oriented watchtowers, send requests to delete old state updates, and open new channels, which is again a poor UX. This behavior will increase on-chain pressure, leading to higher on-chain fees.

Results:

• Scalability: easy
• Privacy: low
• UX: poor
• Viable: YES

6. A periodic fee for the amount of bandwidth

This approach is for business-oriented watchtowers that can link together all state updates made by the same address, so they are required to store only the latest state update and thus data storage requirements are not a bottleneck.

Watchtowers can charge for the amount of daily/monthly transactions to cover all their operating costs, which is a totally viable business model, but it suffers from the same privacy and accountability problems as the previous model.

Results:

• Scalability: easy
• Privacy: low
• UX: medium
• Viable: YES

7. One-time fee to store a state update for X amount of time

Another viable model implies that a user can add a certain fee to each state update sent to a watchtower asking a watchtower to protect this state for a certain period of time. This approach is being used by Celer Network.

Accountability

If there will be no direct financial incentives for broadcasting penalty transactions, then most likely there will be a security deposit or a complex reputation system with low UX, which won’t prevent exit-scam scenarios.

Scalability

This approach allows easy scaling, because watchtowers will have enough funds to cover their operating costs even in the absence of any breaching attempts.

Privacy

The good side of this model is that a relatively high level of privacy can be achieved if combined with privacy-oriented watchtowers that cannot link together state updates made by the same account/channel. However, current Raiden’s and Celer’s designs of watchtowers follow business-oriented approach, and LN’s eltoo will financially incentivize LN watchtowers to associate together state updates made by the same user in order to decrease storage capacity requirements.

There are some concerns about privacy in regards of exposing a user’s online time schedule even when he doesn’t do any transactions, because he still has to resend previous state updates after an expiration time of a paid protection period.

UX

Firstly, paying an extra fee for each transaction will decrease UX. Of course, there might be monthly payments, but that will still decrease UX comparative to centralized e-payment solutions with zero fees, and that will significantly decrease privacy, since a watchtower will be able to associate all state updates with a certain account.

Secondly, a layman has to consciously decide for how long his state updates should be guarded and how much to pay for security of his off-chain funds without a deep understanding of a technology and game theory. This issue can be fixed with default settings, but that might decrease the overall security of the network, because adversaries will know the most common fee and guarding duration.

Thirdly, since state updates will be stored for a limited time only, a user will have to constantly resend previous state updates to a watchtower. Of course, that could be done automatically, but a user has to be online to resend state updates, so it’s very unclear how auto-resend functionality will work.

• If the state update will be resent a few hours/minutes before expiration time of the previous protection period, then it can create security risks, because a user might be offline at the time of the next sync/resend, so his funds will be at risk until he shows up online and resends the latest state updates.
• If a state update will be resent a few days before expiration time of the previous protection period, then it will mean that (1) there will be many over-lapping payments that will increase fees paid by a user, and (2) an average protection time will be very high, which again raises concerns about operating costs and fees.

There are some workarounds such as:

• A user can simply extend the time of an existent protection period, but the implementation is very unclear.
• A user can deposit some money into a smart contract which will auto-extend his protection period even if a user is offline, but there are lots of concerns about implementation, safety and UX of such a solution.
• Additionally, there should be a functionality to swap an old state update with a new one in order to fix over-lapping fees problem.

Fourthly, a user has to either set a long protection period and pay for it, or close all his off-chain channels before going offline for a long time (island, Everest, Vipassana, etc.) And we should keep in mind that user’s funds will be at risk if he suddenly goes offline for a long time (jail, coma, etc.)

Results:

• Scalability: easy
• Privacy: uncertain
• UX: poor
• Viable: YES

Conclusion

It’s unrealistic to assume that there is an easy solution to watchtowers problem, because most approaches have serious drawbacks, so there are many concerns that either watchtowers won’t scale because of poor UX and low security, or will eventually become a tool of mass surveillance.

On the other hand, multiple teams, including myself, are working on solving this problem, so it’s important to exchange our experience and continue a community-driven research. In the last article of this series we’ll think about the perfect design for a watchtower by combining multiple solutions together.

If you want to see more candid articles about watchtowers, hubs, and off-chain scaling solutions in general, please share this article or donate here, that will definitely speed up the process.

Disclaimer: I am not a licensed financial advisor, and this article is not a financial advice. The information presented here is for educational purpose only, it represents my personal opinion, and is not purported to be fact. Cryptocurrencies are very volatile and can move quickly in any direction. I’m not responsible, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with the use of or reliance on any content, goods, services or companies mentioned in this article. Seek a duly licensed professional for an investment advice.

Read this article to learn how the modern financial system evolved from commodity money to absolutely unbacked fiat money, how the US dollar became the world’s dominant currency due to the petrodollar warfare, how the aggressive US foreign policy accelerates the de-dollarization process, how many countries (China, Russia, Iran, Venezuela, etc.) lean towards cryptocurrencies in order to bypass US economic sanctions, and how China expands its empire via Belt and Road initiative, challenging the US dollar’s domination with petroyuan.

How to onboard your folks to crypto #1: from gold to petroyuan & de-dollarization

• Help inform people about LN watchtowers, RDN monitoring services, Celer SGN guardians and PISA by 👏 (you can clap up to 50 times).
• I only write quality content about cryptocurrencies and blockchain. Follow me on medium, twitter, or mastodon, and you won’t regret that. 👍
• Send me a direct message on twitter or linkedin if you want me to help improve your project, white paper, website; or sponsor my next articles.
• Use the most secure, private and intuitive way to swap cryptos with others for your local currency — LocalCryptos.