robosats / robosats

A simple and private bitcoin exchange

RoboSats - Buy and sell Satoshis Privately

RoboSats is a simple and private way to exchange bitcoin for national currencies. Robosats simplifies the peer-to-peer user experience and uses lightning hold invoices to minimize custody and trust requirements. The deterministically generated avatars help users stick to best privacy practices.

Try it out!

• TOR URL: RoboDexarjwtfryec556cjdz3dfa7u47saek6lkftnkgshvgg2kcumqd.onion ( Open with Tor Browser)
• Clearnet URL: dex.robosats.com (not recommended!)

Always use Tor Browser and .onion for best privacy. The Clearnet URL redirects to a third party Tor2web service. Your privacy cannot be guaranteed to be respected. Use clearnet only to check around the app, never use for trading!

You can use Testnet Bitcoin by going to the Settings page and switching to Testnet

How to use it

ROBOSATS_EN_small.mp4

Written guides

• English
• Español
• Deutsch

Video guides

• English
• Español
• Deutsch
• Português
• Polski

How it works

Alice wants to buy satoshis privately:

1. Alice generates an avatar (AdequateAlice01) using her private random token.
2. Alice stores safely the token in case she needs to recover AdequateAlice01 in the future.
3. Alice makes a new order and locks a small hold invoice to publish it (maker bond).
4. Bob wants to sell satoshis, sees Alice's order in the book and takes it.
5. Bob scans a small hold invoice as his taker bond. The contract is final.
6. Bob posts the traded satoshis with a hold invoice. While Alice submits her payout invoice.
7. On a private chat, Bob tells Alice how to send him fiat.
8. Alice pays Bob, then they confirm the fiat has been sent and received.
9. Bob's trade hold invoice is charged and the satoshis are sent to Alice.
10. Bob and Alice's bonds return automatically, since they complied with the rules.
11. The bonds would be charged (lost) in case of unilateral cancellation or cheating (lost dispute).

Contribute to the Robotic Satoshis Open Source Project

Check out our Contribution Guide to find how you can make RoboSats great.

⚡Developer Rewards ⚡

Check out the Developer Rewards Panel for tasks paid in Sats.

Sponsors

Reviews

• Athena Alpha
• Bitcoin Magazine
• KYC? Not Me!
• H17N Bitcoin
• blockdyor

Inspiration

The concept of a simple custody-minimized lightning exchange with hold invoices is inspired in P2PLNBOT by @grunch

License

The Robotic Satoshis Open Source Project is released under the terms of the AGPL3.0 license. See LICENSE for more details.

robosats's Issues

Translate REST API trading pipeline to Websocket.

Current setup relies on OrderPage sending requests for update refreshes. It works, yet, it might get heavy on the server side over time, while it might also not feel snappy enough on the client side.

Converting the OrderPage into a bidirectional communication would be great; but also a big task. This feature would certainly break stuff that works at the moment.

This feature will eventually be very needed, yet, as of now, low priority. I am marking it for future releases after v0.2.0 alpha.

Missing some icons on Desktop

Describe the bug

When you use RoboSats on Tor Browser Desktop, 🌍 (ANY) and 🟨 (XAU) icons are missing.

To Reproduce

Visit RoboSats onion site with desktop Tor Broswer.

Screenshots

Browser:

• Tor Browser Desktop v.11.0.10

Additional context

The bug maybe is caused by missing fonts on the system or Tor Browser trying to block fingerprinting attacks and is blocking some unicode characters.

Using PNG images or SVG icons and avoiding unicode characters can solve this.

Also, why not use use a better XAU icon, like an small gold bar?

Consecutive failed routing retries (LND's mission control does not actually retry)

Observation: When a payout invoice fails routing, it will likely keep failing the next retries (every 5 mins). However, if the operator resets the mission control of LND lncli resetmc the payment can actually be successful.

Plausible explanation
LND mission control (MC) avoids routes that it knows are out of liquidity due to previous failures, saving time and resources the next time it tries to send a payment. However, this might be counterproductive in a setting where the receiver has been notified 'he may lack inbound liquidity', since even if the receiver increases the inbound, the payment will keep failing (LND would not even try routing).

Submitting a new invoice does not help as the receiver pub_key is usually the same (unless the receiver has decided to use another wallet).

Fixes?
Resetting mission control during retries is the easy solution. However, this means an increase on the overall time spent on retrying bad routes and might hinder scalability.

It might be possible in retries to replace SendPaymentV2 for SendToRouteV2 fed with routes found by QueryRoutes using param use_mission_control=False . Maybe there is a more straight forward way to tell SendPaymentV2 to ignore mission control.

There might also be different ways to configure LND MC that I have yet to explore.

Android/iOS app. Torified webview in react-native.

It might be a low hanging fruit to create a tiny react-native webview app wrapping the current webapp. It might also be possible to use react-native-tor https://github.com/Sifir-io/react-native-tor, so the user does not need TOR Browser nor Orbot, but only the .apk.

This could be a good start towards something more versatile and smartphone friendly.

Implement cookies tied to a browser window?

For privacy, you use one avatar per order.

This prevents people monitoring the site learning about your payment methods, locations, bitcoin holding etc.

To allow arbitrage, you can run multiple bots. e.g. one to trade in JPY, one to trade in USD.

To make arbitrage easier, you could have a separate cookie per tab.

However, because both connections will go via the same tor circuit, this still leaks to the site that you have a JPY and a USD bank account, which could be stored, hacked, exploited.

Describe alternatives you've considered
Keep accounts separate by 'burning' your tor connection whenever swapping account. Correlation analysis would still link the two (on the server side), but it raises the bar.

Additional context

Perhaps this is a bad idea afterall...

Public order options: pause and renew

Facilitate public order management by introducing two features:

1. Pause public order: A maker can hide at will a public order from the book. Example use: if a maker cannot attend for X hours a public order, he can hide it. No risk for him to lose his bond for not replying to a taker and no time wasted for the taker, same effect as if he cancels and re-create. Yet, it is way easier to pause & un-pause than cancelling and creating an order anew.

2. Renew public order: simple, you click on renew, a new maker bond is shown, once locked the order stays alive for 24 more hours. If the order expires while public, the "renew button" stays visible for 3 more hours. If the telegram notifications are enabled, the telegram bot sends a message with an invoice to renew the order (new maker bond) payable in the next 3 hours from order expiration. Once locked, the order goes back to being public in the book (no need to open the RoboSats site).

Thanks @decentralizedb, @zehks and Kote in the community channel @robosats_es for brainstorming and giving shape to these features.

Improve chat to facilitate dispute solving

The current chat works . That's about it. It is a simple websocket that replies to everyone in the chatroom.

Issues:

• There is no message logging (if the user refreshes, messages are gone).
• There are no restrictions to enter the room for users not participating in the order.
• It is not end-to-end encrypted.

The first issue makes it very difficult for staff to resolve disputes. The second issue is obviously bad for privacy as chats can be spied by an attacker.

Fixing the third issue will, once again, also make it difficult for staff to solve disputes. Therefore, when e2e encryption is added, there should be a way to submit a view key to the staff when opening a dispute. I do not know whether this is technically possible, and indeed I do not personally have the knowledge/skill to pull off this feature.

To do:

• Limit the rooms to only order participants.
• End-to-End chat encryption. (see below for more context)

Edit ideas that probably won't happen:

• Save messages to database and serve them again if the client re-enters the chatroom. (edit: Won't do)
• Send view key to staff when opening a dispute. (if this is technically possible, otherwise the preferred solution must be privacy first: chat must be blind for staff always) (Edit: won't do)

In order to leapfrog and improve greatly the chat experience with little workload, a Django chat app such as https://github.com/Bearle/django_private_chat2 could be used. However, messages will still not be end-to-end encrypted.

I can also think of using django-encrypted-model-fields as a preliminary/easier step to ensure only the 2 users and the staff can read the chat https://gitlab.com/lansharkconsulting/django/django-encrypted-model-fields/

Introduce RoboSats to r/Bitcoin

Hey everyone.

As discussed in the community groups, we are planning to openly launch RoboSats to the public by writing a note in r/Bitcoin. That subrredit is a zoo :). But it also probably concentrates the biggest amount of people interested in privately buying/selling BTC, many of which might find intimidating the alternatives (Bisq, hodl-hodl, etc). So hopefully our post in Reddit adds value.

This is the draft for the release note. It should have an epic and irreverent tone, yet be clear about the limitations and risks of the platform. I very much appreciate comments and ideas to improve the text. I will be editing this issue as we mature the release note. Will be posted on Feb 27th 9:00AM GMT

---

Title (pick one)

# Everyone keeps saying we need convenient and cheap markets for non-KYC BTC... So I have done this.       
(This is the very reddit-ish title that is usually seen in the top)

# RoboSats: Easy and Private P2P BTC/Fiat over Lightning.										           
(This title is truthful, but it sounds commercial and a bit boring...)

TL;TR

TL;TR: Bitcoin is slowly being captured by the tight grip on the fiat on/off ramps. We need convenient, fast and cheap markets for non-KYC bitcoin. I have worked my ass off for two months to create an easy and private P2P exchange that uses solely lightning hold invoices. It is called RoboSats and I believe it can potentially rival centralized exchanges in ease of use and fees, while being totally private and having a close to custody-less pipeline. You can use it from your smartphone right now: it is straightforward to use even for the very noob. The platform is fully open source and will always be. It works quite well, but it is experimental and should be used with caution: read the info and trade small amounts! Open it now with Tor Browser [ONION LINK](http://robosats6tkf3eva7x2voqso3a5wcorsnw34jveyxfqi2fu7oyheasid.onion/)) 

---

Body

Background

One of the main threats for the Bitcoin network and its users is the ability of a few entities to control the fiat on/off-ramps. The tight grip on them allows for censorship and surveillance by linking funds with identities and strips the freedom away from Bitcoin. While there exists several peer-to-peer alternatives to centralized exchanges, these are rather technical, slow and costly. Most users still prefer the convenience of a centralized exchange at the cost of their privacy and a difficult initial setup (submit passport, selfie-video, etc). Things do not look too well for a truly free Bitcoin ecosystem.

However, there are opportunities too. Using the Lightning Network it might very well be possible to create a very user friendly, safe, fast and cheap peer-to-peer market. By using hold invoices as fidelity bonds and trade escrows, trust/security can be maximized. It will never be as secure as an on-chain escrow. But one can dream that an open p2p market like that could rival the ease of use of centralized exchanges and have very low fees too; yet, with minimal privacy invasion and a close to custody-less trade pipeline.

Wait, is that u/Reckless_Satoshi wearing a hoodie... AGAIN!?. He must have been up to something.

For the last two months I have been locked in my basement, feeding protein shakes and listening to SaylorWaves instead of sleeping... yeah, living the good life. And... I have also built RoboSats during that time :)

What is RoboSats?

It is a BTC/FIAT peer-to-peer exchange over lightning. It simplifies matchmaking and minimizes the need for trust. RoboSats focuses in privacy, speed and user friendliness. RoboSats is an open source project.

How does it work?

Alice wants to buy bitcoin privately. She generates an avatar in RoboSats homepage (AnonymousAlice01) and stores her random token safely so she can recover the avatar later. She creates a new buy order. Bob wants to sell bitcoin and takes Alice's order. Both have to post a small bond using lightning to prove they are real robots. Then, Bob posts the trade collateral also using a lightning hold invoice. RoboSats locks the invoice until Bob confirms he received the fiat, then the satoshis are released to Alice. Enjoy your satoshis Alice!

At no point, Alice and Bob have to entrust the bitcoin to each other. In case they have a conflict, RoboSats staff will help resolving the dispute. You can find a step-by-step description of the trade pipeline in How It Works

Use it now

Click the link below to start buying/selling non-KYC Bitcoin, no registration or any other BS required. Just visit the site using TOR Browser (Mobile works great). Brave is OK too:

RoboSats6tkf3eva7x2voqso3a5wcorsnw34jveyxfqi2fu7oyheasid.onion

... if it does not work, you must download Tor Browser for your device

They usually place fancy screenshots of the apps in the play store / apple store. This is just my attempt to conform to expectations. There is more to RoboSats that what can be seen here, make sure to read the how-to-use guide.

In more details

• Here a full guide with two complete walk-throughs: How to Use RoboSats

• You can also read the full list of features in the RoboSats v0.1.0 stack release

What payment methods are accepted?

Basically all of them as long as they are FAST. You can write down your preferred payment method(s). You will have to match with a peer who also accepts that method as you pay each other directly. The step in the contract to exchange fiat has an expiry time of 24 hours before a dispute is automatically opened. So, I highly recommend using instant fiat payment rails.

Are there trade limits?

Maximum single trade size is 500,000 satoshis to minimize lightning routing failure. There is no limits to the number of trades per day. A robot can only have one order at a time. However, you can use multiple robots simultaneously in different browsers (remember to back up your robot tokens!). At launch RoboSats is limited to a maximum of 100 public orders at a time (...just a temporary safety measure).

Is RoboSats private?

RoboSats will absolutely never ask you for your name, email, phone number, country or ID. RoboSats does not custody your funds and does not care pinch about who you are. For best anonymity use Tor Browser and access the .onion hidden site.

Your trading peer is the only one who can potentially guess anything about you. Keep your chat short and concise. Avoid providing non-essential information other than strictly necessary for the fiat payment. But don't forget to be polite! :)

What are the risks?

This is an experimental lightning application, things could go wrong. Trade small amounts! The seller faces the same charge-back risk as with any other peer-to-peer service. I do not recommend using Paypal or credit cards.

What is the trust model?

The buyer and the seller never have to trust each other. Some trust on RoboSats is needed since linking the seller's hold invoice and buyer payment is not atomic (research ongoing). In addition, disputes are solved by the RoboSats staff.

To be totally clear. Trust requirements are minimized. However, there is still one way RoboSats could run away with your satoshis: by not releasing the satoshis to the buyer. It could be argued that such move is not in the platform's interest as it would badly damage the reputation for a small payout. However, you should hesitate and only trade small quantities at a time. For large amounts use an on-chain escrow service such as Bisq. You can build more trust on RoboSats by inspecting the source code.

What are the fees?

The trading fee is 0.2%. That's about the same as Binance, yet you will not have to pay a withdrawal fine (that same fee covers for the routing to your wallet). The fidelity bonds are sized 1% with respect the trade amount, these are automatically returned.

What happens if RoboSats suddenly disappears?

Your sats will return to you. Any hold invoice that is not settled will automatically return even if RoboSats goes down forever. This is true for both, locked bonds and trading escrows. However, there is a small window between the seller confirms FIAT RECEIVED and the moment the buyer receives the satoshis when the funds could be permanently lost if RoboSats disappears. This window is about 1 second long, so make sure to have enough inbound liquidity to avoid routing failures. If you have any problem, reach out trough the RoboSats public channels (Telegram).

Is RoboSats legal in my country?

In most countries using RoboSats is no different than using Ebay or Craiglist. Your regulation may vary. It is your responsibility to comply (lmao, sorry but I have to write this). If your country is shitty about p2p commerce start thinking about moving, it will only get worse.

Can I access it without Tor Browser / Brave?

Not yet, and why should you? Use Tor and improve your privacy! However, the site robosats.com will be accessible at some point. It will be a simple web2tor bridge to widen the access to any browser and improve URL memorability... It comes with a huge set of caveats for privacy and security: so you should always use the .onion site and Tor Browser if possible!

You make RoboSats a great place

If you like what you see, there is a lot of ways you can become part of this open project. The most needed contributions are: develop code (funding might be possible, ask); create tutorials and guides; open outbound LN channels towards RoboSats node (1ML); and help newbies in our community groups (Telegram: English and Spanish). Needless to say, simply using the platform, telling a friend or sharing your idea/criticism is a huge help!

Give it a try now and contribute to make this open source project glorious!

Cheers,
Reckless_Satoshi

Small typos on "What is RoboSats?" INFO

1.

There's an space and two final dots in the last phrases on this text:

[...] You can find a step-by-step description of the trade pipeline in How it works. You can also check the full guide in How to use.

2.

The last dot must not be part of the link here:

You can build more trust on RoboSats by inspecting the source code.

Show the chat box even before the counterparty is 'online'?

Is your feature request related to a problem? Please describe.
As a noob, I'm not sure where the chat box should appear / if hte site may be broken / if I@m supposed to be doing something, etc.

Describe the solution you'd like
If the chat box appeared with teh animated text (waiting for counterparty...) I would know the state wasn't 'on me' and that I'm waiting for someone in the background.

Describe alternatives you've considered

• Checkign the docs to see what the chat box should look like (there is no screen shot for the web)
• Refreshing the page every 10 mins to make sure that something hasn't happened on a closed websocket or whatever.

Additional context
Meh

Buy lightning btc with onchain btc

I think that this project can be a good place for a lightning btc <-> onchain btc market.
I think there will be people to offer liquidity who don't want to sell their btc.
This would also incentive people who don't want Fiat to open a channel to robosats as they can sell their lightning btc in that channel for onchain btc.

Create Get OrderBook API call and simple front end with cards

A simple order maker page is up and working. Now the second part, an order book page is needed (for takers)

• API view with GET method that returns all orders. Filters by "Currency" and by "Type" (Buy or Sell).
• Set up BookOrder React Component with cards in 2 columns.

Order Book is by default set to any type (buy or sell) and any currency

This feature will help to avoid opening an empty order book at page load

Javascript error in Copy of Clipboard from Contract Box

In trying to pay the committment trx to PUBLISH my order, when I see the Contract Box, with the QR code, I then tried to press Copy To Clipboard

Expected behavior:
That the LN Invoice would be copied to my clipboard

Actual behavior:
No change to my clipboard.

In showing the Javascript console, I see:

react-dom.production.min.js:101 Uncaught TypeError: Cannot read properties of undefined 
(reading 'writeText')
    at onClick (TradeBox.js:213:31)
    at Object.Rb (react-dom.production.min.js:52:317)
    at Xb (react-dom.production.min.js:52:471)
    at Yb (react-dom.production.min.js:53:35)
    at Ze (react-dom.production.min.js:100:68)
    at se (react-dom.production.min.js:101:380)
    at eval (react-dom.production.min.js:113:65)
    at Jb (react-dom.production.min.js:292:189)
    at Nb (react-dom.production.min.js:50:57)
    at jd (react-dom.production.min.js:105:469)

Make the frontend pretty.

The frontend is currently vanilla Material UI V5 with no theme whatsoever.

It is composed only by a few elements and users can only see 4 pages: home/user-generator, order maker, order book, order/contract box. It is in addition, the first time a write a frontend, so there is a lot that could be improved about style!

I know for a fact there is quite some artists out there :D Bring it on! Propose any idea you have and let's work on it together. Let's make RoboSats pretty!

Suggestion: Publish README.md using Github Pages (i.e., Github.io )

If the project was published to Github Pages, then there would be a nice clean URL for the README.md:

The URL to show the README.md would be:
https://Reckless-Satoshi.github.io/robosats

Which is easier to share on social media and such.

Slow payment methods vs CLTV expiry and channels force closure

In the initial days of operation of RoboSats several orders have been placed with payment method "cash by mail". This is indeed a very good privacy preserving payment method. However, the platform is designed with instant payment methods in mind and the time to expiry of the fiat exchange step is only 4 hours. That is rarely enough for ordinary mail to arrive :)

It is however, possible to create an "Advanced settings" tab in the OrderMaker page, where makers can bump up the CLTV expiry of the bonds and escrow for that specific order to a much greater duration. This can prove however dangerous: the risk of force closure during a trade grows the longer it is open,other concurrent HTLCs being stuck might leave the trade without collateral (or settling the escrow and all bonds...). Long trades are more likely to have issues.

This is a feature to pay attention to once short-term duration trades are running smoothly.

Feature Request: Remove ajax.googleapis.com scripts from the app

Is your feature request related to a problem? Please describe.
Yes. Your deployed code at the onion page does not load unless I run javascript from https://ajax.googleapis.com. This obviously is a very major trust, security, usability, and privacy problem.

Describe the solution you'd like
Write your own javascript functions or pull someone else's equivalent code from your own forked repo. Preferably the page degrades gracefully without javascript but in the spirit of who-gives-a-shit-about-privacy-and-security, a reality more readily practiced among developers who love javascript, please at least put the code you're running into your open source repo, so we don't have to run scripts from external sites, ultimately from parties that not only do we not trust, but from parties that we implicitly DO NOT TRUST.

Describe alternatives you've considered
I'm considering the alternatives to google. There are many open source javascript functions you can use to accomplish the same goal without compromising everyone's privacy and security.

Additional context
Google is not a trustable entity.

Implement full trustless escrow approach as in "hodlcontracts" for maker-buyers

In order to understand this feature request you must first understand well the work done by @supertestnet in https://github.com/supertestnet/hodlcontracts

Background

It's becoming apparent that the current approach for fidelity bond / escrow with hodl invoices works very nicely in practice. Yet, one can argue the balance of power in this tri-partite relation is heavier in the service provider side: it is the recipient of the HTLC while also the generator of the preimage .

Oportunities

It will be, no doubt, difficult to improve this fact, specially without degrading the user experience. Yet, there is a specific case " a maker that is a buyer and is running LND " where the buyer could be directly the recipient of the HTLC but not hold the preimage (the preimage is given to him by RoboSats once the seller confirms he received the Fiat).

Why would a maker-buyer need to have LND? As of now, it is the only "wallet" that allows for hodl invoice generation in this specific setup. To understand the setup better check this video by SuperTestnet of the functioning of LightningEscrow.io.
https://www.youtube.com/watch?v=vvlOzEIPRws

Discussion

I do not exactly see how this feature could be used in the case of a seller-maker or a taker (any kind), as these are probably not going to be willing to spend the extra time to run a command line tool to interact with RoboSats.

If LightningEscrow.io releases a good API that could be easily be integrated into RoboSats backend, that would be fantastic. It would be up to users if they want to pay the extra cost for this feature to LNescrow.io . If integration of an existing API is difficult, the right way to proceed would be to fully implement the feature into RoboSats' backend.

This feature will be... hard to implement and maybe won't see much use (unless big liquidity providers join RoboSats and have devs available).So at the moment I am ranking it low in the list of priorities for implementation (just a personal opinion, totally open to change my mid) . However, I truly want to encourage anyone who want to jump into implementing it: it's one of the most exciting ideas around.

Thanks

Thank you very much to SuperTestnet & Tristan for the awesome contribution to the Lightning Network and the exciting discussions around the trust models in LN.

Init Django project

The repository contains an idea. Now it needs to have code. Set up an initial Django backend.

Why Python for backend?

Initial development team is better at python.

Why Django over Flask?

Flask suits best since Django is too dependency-heavy for a small and privacy focused project. However, initial development team lacks resources and the shortest path to MVP relies on Django. Once a MVP is in production and if the community shows interest, it might be worth to migrate to Flask and focus on lightweight. Some features such as end-to-end encrypted chat (with view key export to staff) might be difficult to implement on Django's opinionated framework. No idea, I am new to web development.

'Ring' sound for makers when a taker is found.

Makers will sometimes have a long wait. This is in fact, a point of exit for new users. It would be great if the browser could "ring" when the taker is found, same as mempool.space rings when your transaction is confirmed.

Make navigation trough Order Book and user gen functions sequential

Javascript is tricky. These functions are not running sequentially at the moment, so the requests are always done with past information. Should be an easy fix for anyone who has dealt with JS previously.

Dynamic countdown timer and progressbar (expiration bar)

In the /order page would be great if the time to expiration is dynamic (moves every second) and the expiration bar is linked (100% is total time to expiration, X% is actual time left to expire).

Bonus points if the expiration bar color changes to yellow at 20%-10% and to red below 10%

If user is logged in and is taker or maker, always redirect to Order page

We want to streamline the experience to the max. So no possible error, if your user has an ongoing order, user can only see the order page unless ; logs out, order is cancelled, order expires.

Show small hints and description on mouse hover

For example hovering "Premium" gives you a small explanation of what it means. Useful for all the items in the form of the MakerPage.
In addition, there could be a on-by-default hint box over the Token TextField that reminds users to back it up.

Load all important application hparams from .env file on root dir

There are many hyperparameters that could be centralized into an .env in the root directory to ease the application managing
For example, limits for trade size could be imported from .env
https://github.com/Reckless-Satoshi/robosats/blob/9335e6abbe797e4fb281d7280da3a7114c7ef03b/api/models.py#L9-L10

• Create an .env-sample file on root directory (e.g. MIN_TRADE_LIMIT, LND_CERT, LND_MACAROON, MAX_CONCURRENT_TRADES, INVOICE_EXPIRATION_WINDOW, ORDER_PUBLISHED_EXPIRATION_WINDOW, FIAT_RATE_API_NAME, FIAT_RATE_API_URL)
• Substitute most important variables for those moved .env in the whole project

High sensitivity to client's clock

A user's clock that is a few minutes behind or ahead of server time can lead to bad UX. 1) Expiry counters does not match real expiry time. 2) LN invoices for bonds that are "already expired" when they are actually not.

Fix

UI: the frontend uses the client's clock to compute time left to expiry. This is an easy fix as the difference between current time and expiry time (expiry_diff) can be computed on the server side and replace expiry_time in the response.

Invoices: There is no fix for this. However, the invoices are already padded with a margin for the expiry time in order to avoid being rejected by an slightly misconfigured client clock. Clocks that are more than 5-10 minutes ahead of time will still be a problem.

For @RoboSatsBot, Brave blocks Telegram links

After paying the commitment transaction to PUBLISH, I was given the option to ENABLE TELEGRAM NOTIFICATIONS

Clicking that, I see:

Enable TG Notifications
You will be taken to a conversation with RoboSats telegram bot. Simply open the chat and press "Start". Note that by enabling telegram notifications you might lower your level of anonimity.

I clicked Enable.

Expected result:
A new browser tab would be launched, and that would resolve by the next step:
My Telegram desktop client would open and the @RoboSatsBot would be summoned

Actual result:
A new browser tab launched, but after a short duration the page shows:

“tg” links are blocked

This page has been blocked by Brave
ERR_BLOCKED_BY_CLIENT

The URL that the browser tab had was:
tg://resolve?domain=RoboSatsBot&start=[identifier]

I was able to manually summon the robot by DM and copy & pasting the
"start=[identifier]"

Wallet compatibility

Full and up-to-date wallet compatibility table in 👛 http://learn.robosats.com/docs/wallets 👛

Lightning hold invoices are weird . They are not used often and little focus is put on them by lightning wallet developers. In this issue I will be collecting some data while I test different wallets. Eventually info here might become a /doc/.

Background

In plain words, hold invoices are lightning payments that do not quite arrive. Wallets are blind to what is actually happening at the receiver end. Most often, the wallet will have a spinner to let the user know the payment is on transit. Yet, the only way the user can know whether their fidelity bond is locked is by checking on the RoboSats app. This makes for a poor user experience, especially if both wallet and browser are on the smartphone; the user might stay waiting for the never ending spinner and never check whether the bond is lock on the browser.

Wallets Compatibility Table

Wallet	Version	Interface	Recognizes Hold	Misleading	Concurrent HTLCs	Compatibility	Recommended
Blixt	v0.4.1	Mobile	No	Yes	Yes	Good	Yes
Electrum	4.1.4	Desktop	No	Yes	NO	Bad	No
LND	v0.14.2	CLI	No	No	Yes	Good	Yes
Zeus	v0.6.0-rc3	Mobile (Remote backend)	No	Very!	Yes	Good	Yes
SBW	2.4.27	Mobile	No	Yes	Yes	Good	Yes
Muun	47.3	Mobile	No	Yes	Yes	Awful	NO (read below)
lntxbot	NA	Mobile	No	Yes	Yes	Good	Yes(more info)
BlueWallet	1.4.4	Mobile	No	Yes	Yes	Good(but buggy)	so-so
WalletOfSatoshi	1.15.0	Mobile	No	Yes	Yes	Good	Yes
Phoenix	35-1.4.20	Mobile	No	Yes	Yes	Bad	No
Bitcoin Beach	v1.7.7 build 310	Mobile	No	No	Yes	Good	Yes (more info)

Blixt (Android/iOS, LND light backend on device)

Most development testing for Robosats has been done using Blixt. This is one of the most complete lightning wallets around. I recommend it to use with RoboSats. However, it does lead to misunderstanding when hold invoices are locked. As it shows a spinner with payment in transit. The user needs to check on the website for confirmation. Blixt allows for multiple pending HTLCs, this is necessary as a seller since you need to lock a taker/maker bond and then a trade escrow (2 pending concurrent HTLCs). Might show as paid/charged invoices that are still pending, specially if the user force closes blixt and reopens it. Occasionally can display as charged fidelity bonds that have been returned.

Electrum (Desktop)

Experience using Electrum is limited. It does not seem to support more than one pending HTLCs (even if there is multiple channels). This wallet is not recommended to use with RoboSats. However, it works well if you are a buyer, as only one hold invoice for the fidelity bond is needed. The payment shows as pending with a spinner for the duration of the locktime.

LND (CLI Interface)

Raw, it shows exactly what is happening and what it knows "IN_FLIGHT". It is not user friendly and therefore not recommended to interact with Robosats by beginners. However, everything works just. If you are using LNCLI regularly, you will find no issue to use it with RoboSats.

Zeus (Mobile, LND remote backend)

It is an interface to LND. It works as expected. It is extremely misleading with a full red screen "TIME OUT" a few seconds after sending the HTLC. Yet, if the user checks on the website, the invoice is correctly locked.

Muun (Mobile)

Muun plays same nicely with hold invoices as Blixt or LND. You can be a seller in RoboSats using Muun and the user experience will be great. However, Muun is fee siphoning attacking any sender to Muun wallet. There is a mandatory hop trough a private channel with a fee of +1500ppm. RoboSats will strictly not route a buyer payout for a net loss. Given that RoboSats trading fees are 0.2% and it needs to cover the routing fees, RoboSats will never find a suitable route to a Muun wallet user.

I would personally recommend you switch anyway to another lightning wallet. Muun fees are outrageous: if I was your friend and you ask me to send sats to your Muun invoice, I would kindly ask you for another invoice, or else, we stop being friends :). RoboSats is a lightning app and cannot afford to cover the cost of Muun's submarine swaps. Muun users should cover Muun operational costs, not the third parties.

Phoenix (Mobile)

Phoenix worked well when full trade pipeline was limited to 10 hours. Now that it is 24 hours of public order plus 24 hours for the fiat exchange step it will not allow users lock the bond (Cannot add htlc (...) reason=expiry too big). Might become compatible with RoboSats again once trades are shorted.

Bluewallet (Mobile)

It works well. But they are having issues in the custodial mode. Escrows that RoboSats returns are charged to users (so Bluewallet is keeping that balance?). Bonds that are slashed...are charged twice by Blue! More info once they reply to us. EDIT: Blue has confirmed they are working to soon solve these accounting bugs!

Some ideas

As of now, the invoice encodes a description that tells the user to check on the website for confirmation.

The invoice description is also explicit and encodes the keyword "hold invoice". It might be a stretch, but if hold invoices become more popular it might be possible for some wallet providers to adapt the behavior of the UI for HTLCs that are pending when the keyword is found on the description. E.g. instead of showing a never ending spinner, it could let the user know "This might be a hold invoice. Check with the receiver if it has been locked on their side."

Most wallets show the user the available balance locally at all times, and this number does change while routing is attempted (it gets smaller...). It is possible to show a "pending" balance too live in the same way.

Multilanguage Support

Make RoboSats available in more than just English.

Lightning functionality; calls to LND RPC and logic updates as invoices are locked and validated.

Probably a big step, but the last part to have a minimum viable product.

Reputation based trust model vs privacy

Most p2p exchanges rely on reputation models. After a trade users can rate each other. Over time, users can build a profile with good reputation facilitating trust.

The reputation based model, while successful in practice, has a clear disadvantage regarding privacy: it incentivizes identity reuse.

One of the core ideas in RoboSats is to avoid identity reuse. This is achieved by facilitating avatar generation. By following the minimum effort route users are constantly creating new identities. Every time a user lands in the homepage, a new avatar is created. Extra effort is needed if the user wants to reuse an identity (yet it is possible by backing up the user token and inserting it once again).

RoboSats trust model relies solely on the fidelity bond system (bonds of misbehaving users are slashed). This is why users can expect counterparts to not cheat. It is however unclear whether liquidity will grow in a market that does not allow liquidity providers to build reputation.

As of now, it might be best to have a reputation system in place, and let users decide whether that is important for them or not. Indeed, it might get problematic if users start demanding other users to have a good profile (therefore, lowering their privacy practices). In the v0.1.0 MVP there is already an implemented reputation system, however the scores are not shown anywhere in the frontend.

Anecdotally, I myself have had trouble when starting to use a new p2p platform. Most makers limit their offers to users that do not have any previous trade. So one ends up taking a few small and pricey trades to start building a profile. The incentive to reuse the same identity is strong, and all trades from that point on are linked under the same username.

I think keeping an eye on this phenomena and steering away from it, while not damaging market liquidity, should be a priority for RoboSats.

API Documentation

We are using django-rest-framework so it is a very low hanging fruit to exploit the API. In fact, some developers seem to be using it before any documentation has been made. This is due to how simple and easy it is to explore the robosats API. Will summarize here everything you need to know to use it.

Short API documentation

Simply open your Tor Browser (http://robosats6tkf3eva7x2voqso3a5wcorsnw34jveyxfqi2fu7oyheasid.onion) and check the following endpoints for full details:

Order limits for every currency pair

/api/limits/

Historical exchange activity

/api/historical/

All Market Ticks

/api/ticks/

General exchange information

/api/info/

Exchange rates and premiums

/api/price/

For all national currencies for non-KYC BTC in the RoboSats market (this data has some limitations)

Every public order in the book

/api/book/?currency=0&type=2

Use the currency number to query only public orders for one currency, use 0 for all. Types, use 0 for BUY orders, 1 for SELL orders, 2 for ALL.

New user or login

/api/user/?token=

Create a new user or login if there is an existing user. Token should satisfy minimum entropy constrains

Make an order

/api/make/

Orders

/api/order/?order_id=

Check order information. Use the POST method for updating the order. By updating the order when needed, a complete trade pipeline can be completed just by using this endpoint.

---

The only thing that is not accessible trough those endpoints is the chatrooms.

A tutorial explicitly made for OpenKeychain+RoboSats (/docs/)

As raised in the community groups, users should not trust the chat is not logged or encrypted (in fact, it is not in v0.1.0). It is best to PGP encrypt the sensitive information.

It would be ideal to create a straightforward and concise tutorial on how to use OpenKeychain with RoboSats. Would be great if it includes a complete use case: pubkey generation, key exchange in robosats' chat, and encryption decryption of the sensitive info.

Looking for volunteers for this one :D

Create OrderPage.js and set up API endpoint

A component that will show the order details when queried with an order ID. This is the one that should show when clicking on a order from the order book. Could also be added to the waiting room.

Create a general app status information endpoint and react component to place in the bottom

Just a GET method that returns some basic data ( number of buy and sell order, etc) to display on the bottom left of the app under homepage. The component could refresh every X seconds.

Notify makers when an order is taken (even if they left the site)

Once an order is published in the order book it remains visible for 6 hours. A taker might be found right away or might take hours. Currently makers need to keep a browser tab open, once the taker is found the browser plays a tone. This works well on desktop, specially if you were planning to leave it on anyway. However, it is really difficult to be a maker in the mobile browser (screen turns off and the sound notification never plays).

Possible solutions

Telegram bot

As seen in hodl-hodl. Users get notified on telegram once the order is taken. Cons: users give out an identity that can be used to link all the trades they make under different avatars, breaking completely the privacy model.

Web push

Browser push notifications only have one purpose: annoy you. However... this might be a good use case. It might be a stretch to implement and might not play nicely with mobile Tor Browser. Preliminary research leads me to believe this is indeed possible. A way to speed up implementation is to use djanjo-push-notifications package. However, this is only a valid method as long as it does not require Google's Firebase or APNS. Need to research more about VAPID method to assess plausibility and the privacy trade-offs.

Do not solve and center on Android/iOS release.

Not a short term solution, but by not fixing the notifications right now, more energy can be centered on bringing out the app (... which is a solution).

Initialize frontend and create first pages

Given that we have the first end point ('api/make') to POST new orders. We could jump into creating a tiny bit of the front-end and lay down the page structures.

• Initialize a React frontend
• Document process for contributors
• Create components structures
• Create index template
• Create routing on HomePage and redirect urls correctly
• Implement the frontend page for the API endpoint make/

Send correct status message when OrderView is called

The Status choices are named WFB, PUB, etc. However, these encode for a order status number (0,1,2..) and a status message ('Waiting for bond', 'Published'...). Frontend should receive the message in the reply, not only the number.
Fix goes around here:
https://github.com/Reckless-Satoshi/robosats/blob/a61eb217b537aa0c068ecbfc90a1cf1d3ff672e2/api/views.py#L82-L83

Create user generator backend and frontend landing page

Create user generator page that will act as landing page.

In the first visit, the front end generates a high-entropy token, the backend replies with new user credentials a Nickname and a RoboHash avatar.

The user can either accept the given "Robosat" avatar (button It's cool!), generate a new one (button Nah, give me another, or log into existing one (button I have my own). It's cool takes the user to /home/, where he is presented with Buy/Sell option (or altenatively make/take options depending on site structure).

• Create API endpoint UserGenerator() (view) that handles user creation from request token. Replies with a nick and avatar and keeps the user logged in.
• Validate the token is high entropy ( >128 bits >0.7 shannon).
• Create API endpoint UserDelete() deletes current logged in user and creates a new one if a high-entropy token is given.
• Create frontend component
• Implement client-side high entropy token generator
• Build forms and routing

Advanced options for makers

The maker page is simple, yet it should be sufficient for most casual users. However, some advanced options can be added in an "Advanced Options" tab. These are mostly directed to fulfill the needs of larger liquidity providers and advanced users.

Possible advanced options

• Set public expiry time. A datetime input to explicitly specify the time of expiry of a public order. This input will have to be limited to a max of ~10 hours from 'now' in order to not have too long-lived HTLCs. Example usage:
  • A maker has only 30 minutes for lunch or before going to bed. He places an order with a expiry time 30 minutes in the future. If it is taken he will be available for the trade, else the order expires no action needed.
• Set fiat exchange duration. It has recently been bumped to 24 hours. I deem it already too long (probably unsafe). Yet, makers might still want to ask for very slow payment methods such as bank transfers or cash by mail (totally not advised!). This option could allow for CLTV expiry of up to 1 week. It will have to be extensively tested in testnet first. (EDIT: longer CLTVs will probably never happen, looks bad, see #56 for more info)
• Amount range. the maker enters the minimum and maximum order size. The taker will select the exact amount just after "Take Order" button is pressed. Challenge: it is harder to compute a fair maker bond size.
• Set bond size. Bounded 1-20%. Will be the size of both, maker and taker bonds.
• Allow bond-less takers. How is someone new to LN going to buy Satoshis if he needs to lock satoshis in the first place? Makers might choose to allow bond-less takers in exchange of collecting a higher premium for the extra counterpart risk.

Submit your comments and ideas so we can craft this feature the right way before putting the work into it.

Challenges

Most of these options will make the overall UI messier in other pages. For example, the book and order page will need to accommodate the extra information of these advanced options so takers are aware of the details of the order. That might make new users dizzy. There might be a way to simply add a check in the order page "Show advanced", otherwise the advanced orders will not show.

Error changing Pricing Method when Amount Range is enabled

When creating a new order, if Amount Range is selected under the customize tag, the behavior of the Pricing Method is not as expected. It seems that the Explicit option is desactivated, indeed if you click on Explicit the radio button is not changed (it stays as Relative) but the text box expects to enter a Explicit amount and the text below also changes according to an Explicit Pricing Method

Steps to reproduce the behavior:

1. Go to MAKE ORDER
2. Click on CUSTOMIZE
3. Enable Amount Range
4. Click on ORDER
5. Click on Explicit
6. Radio button is not switched but text below expects an explicit amount

Screenshots

Desktop (please complete the following information):

• OS: Windows 10
• Browser: Tor Browser
• Version: 11.0.9 (based on Mozilla Firefox 91.7.0esr) (64-bit)

Give a 'Step x of y' infographic while trading

Is your feature request related to a problem? Please describe.
I didn't visually notice the difference between the bond and the trade invoices.

Describe the solution you'd like
Make it clearer that the bond has been paid and the trade now needs to be paid.
e.g. a 'milestone' type progress bar that shits along like the 'Order details' text does.

Describe alternatives you've considered
The order details text could grey out past steps instead of deleting them.

Additional context
I'm number blind.

A privacy friendly referral program.

Eventually the usefulness of RoboSats will boil down to how much liquidity is in the book.

In order to increase liquidity organically (i.e., make the platform more popular) one could think of a referral program; that is, a user is rewarded for recommending the platform to other potential users. However, implementing a referral program is extremely difficult while 1) avoiding users to spy on each other and 2) keeping minimal tracking and logs.

Example Implementations

1. Reward a user X% from the fee for every trade of the referred users (aka Binance model). Issue: can easily be exploited by a user to spy on other users' trading activity, especially if the rewards are deterministically linked to the users activity.

2. Direct single payout for every new user that is referred. Issue: the low barrier to create new users in RoboSats makes it very easy to abuse this feature. One can create a referral link and reward himself many times.

I do not think there is an optimal solution, therefore a referral program will probably never be implemented. However, it makes for an interesting thinking puzzle... Maybe there is a way to solve it...

Load currency dictionary from .json into both: backend model and frontend form.

List of available currencies are a hack at the moment.

Would be great if the list of currencies could live in the static folder as a .json and be read from there by both:

• The choices field of the Order model
  https://github.com/Reckless-Satoshi/robosats/blob/9335e6abbe797e4fb281d7280da3a7114c7ef03b/api/models.py#L18-L21

• The Select form in the front en MakerPage
  https://github.com/Reckless-Satoshi/robosats/blob/9335e6abbe797e4fb281d7280da3a7114c7ef03b/frontend/src/components/MakerPage.js#L139-L150

• Create preliminary .json file with currency number and currency code

• Replace Currency IntegerChoices for the options in the currencies.json in models.py

• Replace Select currency options for the options in the currencies.json in MakerPage.js

• Update the logics of handleCurrencyChange to print the right currency code over the "Create Order" button.

Add an API endpoint to make orders

• Configure the Django project,
• Add an API app
• Create the "Order" model
• Create a view to handle POST calls.

INFO button visibility on night mode

Describe the bug
The INFO button is hardly visible (some devices better than others) on night mode, maybe is better maintain the black color in this:

Sound notifications blocked by NoScript in mobile Tor browser

First sound notification in Android mobile Tor browser gets blocked by NoScript. This is caused by a simple component that plays the robosat-sounds. Once the user allows it for the first time, any future sound notifications will work as expected. The user can decide to "Collapse blocked objects", and sounds will not be played but everything works normally.

For most users this won't be a problem; it seems to be dependent on the version of Tor Browser and the security settings. Default security settings in the latest Tor Browser for Android works well.

There might be no way around this. However, this is rather a minor issue: it is up to the users to allow sound notifications if these are wanted. Sound notifications are not critical for the trading pipeline.

While the NoScript alert is in place, the focus is drawn to the Contract Box; this breaks the dialog pop ups that can be open from the bottom tool bar, as they are shown behind the contract box.

Keep user nickname, avatar and token on sight always

It could be placed on the top right. It could show user nickname and avatar (after the user-generator page they get out of sight and might be that the user did not write them down).
There could be an option to "show token" and the user token be shown again, however that would involve some sort of client-side storage for the token.

Add field "payment_method" to Order model and front end form

Just realized the payment method field is missing from the current/Make/ endpoint.