RoboSats/robosats
1
1
Fork 0
mirror of https://github.com/RoboSats/robosats.git synced 2024-08-17 09:50:41 +03:00
Code Issues Packages Projects Releases Wiki Activity

Update Phoenix wallet compatibility. Fix escrow cltv expiry blocks computation

Browse Source
This commit is contained in:
Reckless_Satoshi 2022-07-22 08:05:47 -07:00
parent 20817fc126
commit ff0efd7664
No known key found for this signature in database
GPG Key ID: 9C4585B561315571
2 changed files with 5 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
api/logics.py
View File

@ -992,11 +992,9 @@ class Logics:
invoice_concepts (str): maker_bond, taker_bond, trade_escrow
'''
# Every invoice_concept must be locked by at least the fiat exchange duration
# Every invoice must also be locked for deposit_time (order.escrow_duration or WFE status)
cltv_expiry_secs = order.t_to_expire(Order.Status.CHA)
# Both fidelity bonds must also be locked for deposit_time (escrow duration or WFE status)
if invoice_concept in ["taker_bond", "maker_bond"]:
cltv_expiry_secs += order.t_to_expire(Order.Status.WFE)
cltv_expiry_secs += order.t_to_expire(Order.Status.WFE)
# Maker bond must also be locked for the full public duration plus the taker bond locking time
if invoice_concept == "maker_bond":

6
docs/_pages/docs/03-understand/07-wallets.md
View File

@ -37,7 +37,7 @@ This is a non-exhaustive compilation based on past experience of users. We have
|[lntxbot](https://github.com/Reckless-Satoshi/robosats/issues/44#issuecomment-1054607956)|[NA](https://t.me/lntxbot)|{{page.laptop}}{{page.phone}}|{{page.good}}|{{page.good}}|{{page.good}}|{{page.good}} | [{{page.thumbsup}}](https://github.com/Reckless-Satoshi/robosats/issues/44#issuecomment-1054607956)|
|[Blue](#bluewallet-mobile)|[1.4.4](https://bluewallet.io/)|{{page.phone}}|{{page.good}}|{{page.unclear}}|{{page.unclear}}|{{page.good}}|{{page.unclear}}|
|[WoS](https://github.com/Reckless-Satoshi/robosats/issues/44#issue-1135544303)|[1.15.0](https://www.walletofsatoshi.com/)|{{page.phone}}|{{page.good}}|{{page.good}}|{{page.good}}|{{page.good}}|{{page.thumbsup}}|
|[Phoenix](#phoenix-mobile)|[35-1.4.20](https://phoenix.acinq.co/)|{{page.phone}}|{{page.good}}|{{page.bad}}|{{page.good}}|{{page.bad}}|{{page.thumbsdown}}|
|[Phoenix](#phoenix-mobile)|[35-1.4.20](https://phoenix.acinq.co/)|{{page.phone}}|{{page.good}}|{{page.soso}}|{{page.good}}|{{page.good}}|{{page.unclear}}|
|[{{page.bitcoin}} Beach](#bitcoin-beach-mobile)|[v1.7.7](https://galoy.io/bitcoin-beach-wallet/)|{{page.phone}}|{{page.good}}|{{page.good}}|{{page.good}}|{{page.good}} |[{{page.thumbsup}}](https://github.com/Reckless-Satoshi/robosats/issues/44#issuecomment-1126318591)|
1. **UX:** Does the wallet convey clearly that there is an "ongoing" payment (hodl invoice)?
@ -48,7 +48,7 @@ This is a non-exhaustive compilation based on past experience of users. We have
### 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.
Most development testing for Robosats has been done using Blixt. This is one of the most complete lightning wallets around. 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). It might eventually also display 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 in fact 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.
@ -66,7 +66,7 @@ It is an interface to LND, CLN and Eclair. It works as expected. It is extremely
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, in order to be a buyer, you need to submit an onchain address for the payout, a lightning invoice won't work. 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**. At the moment, RoboSats will scan your invoice for routing hints that can potentially encode a _fee siphoning attack_.If this trick is found, the invoice will be rejected: submit an onchain address instead for an on-the-fly swap.
### 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 shortened.
Phoenix works very well as an order taker. Phoenix will also work well as an order maker as long as the order settings `public duration` + `deposit duration` are lower than 10 hours. Otherwise you might have problems locking the maker bond. If the total duraton of bonds/escrow invoices exceeds 450 blocks, Phoenix will not allow users to lock the bond (`Cannot add htlc (...) reason=expiry too big`).
### 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!