-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wallet compatibility #44
Comments
LnTxBot tested on BUYING successfully. The hold invoice is shown as a pending payment and shows a user-friendly text.
The TX details is shown as:
If the invoice expires then it shows a failed payment message. It also shows a failed payment when it unfreezes at trade completion.
And the log shows as:
In summary: good experience with LnTxBot on RoboSats |
Maintainer from Zeus here. We'll be adding support for hold invoices soon. You can track progress here: ZeusLN/zeus#865 |
Tested the Bitcoin Wallet by being on both sides of the trade. Worked well.
|
CoinOS tested on BUYING successfully. Hold invoice works (in Robosats you can see the fidelity bond is locked), but CoinOS shows a progress bar for the transaction for a couple of minutes, and finally it throws an error . Payouts from Robosats receiving bought sats works fine |
Breez Wallet SELLING tested successfully. Have yet to test buying. Hold invoices seemed to work as intended. |
I tested paying the fidelity bond as a buyer using Cash App's lightning wallet, and it worked successfully. That is, the payment first showed as pending and then when the trade completed successfully, the send payment in Cash failed and I got the sats back. Bonus: I got a text message |
Just tested Robosats with Electrum 4.3.0 on Testnet. |
Did you take both sides of the trade with the same wallet? If so we should update the table to confirm Electrum is fully compatible. |
Yes, both sides with the same wallet! |
with latest phoenix 1.5.6 I only could create an offer with 06:00 + 02:55 other tests like 06:55 + 03:00 didn't work. |
Breez wallet has worked without a hitch as a maker for both buy and sell transactions. It's also very convenient to use for beginners as it takes care of channel setup and balance for you (for a small fee, of course).
|
@editwentyone thanks for reporting, we can better nail this param now. @RippedTrojan great to know, thank you! must be added to the docs: |
Closing. Please open a new issue if related to wallet compatibility or directly open a PR editing our wallet compatibility docs: http://learn.robosats.com/docs/wallets purse |
Strike works great to sell. Haven't tried buying/receiving but don't think there'd be any issues |
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
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.
The text was updated successfully, but these errors were encountered: