search

RoboSats / robosats

A simple and private bitcoin exchange
https://learn.robosats.com
GNU Affero General Public License v3.0
752 stars 146 forks source link

missing onchain payout #552

Open 84adam opened 1 year ago

84adam commented 1 year ago

On-chain payout missing. No TXID/hash generated. Began loading (indicating swap in progress), but then (address and loading indicator) disappeared and showed no TXID. Trade reported as "finished" but funds not sent.

Used Tor Browser, with Muun for bounty. Muun bounty was returned properly. (Fiat payment went through too, of course.)

Can provide more details if needed.

84adam commented 1 year ago

Triaged via Telegram. Transaction successfully broadcast and received. DB was temporarily "in an incoherent state", I am told. Further investigations pending.

anaconda5486 commented 1 year ago

I have had this same issue just now. Sent comment on telegram.

Reckless-Satoshi commented 1 year ago

Hey @84adam and @anaconda5486 , thanks for reporting!

There seems to be something with this gRPC call that either exists or does not return a TXID. It might have been caused by the large mining fee environment of yesterday, but more research is needed. We need to implement better handling of exceptions here:

https://github.com/RoboSats/robosats/blob/daa1127cfc5040cecc859bb16b9964a16af46169/api/lightning/node.py#L168-L172

84adam commented 1 year ago

What is the MAX_SWAP_AMOUNT set to? More than the default amount, I assume..?

https://github.com/RoboSats/robosats/blob/daa1127cfc5040cecc859bb16b9964a16af46169/api/lightning/node.py#L42

Reckless-Satoshi commented 1 year ago

More than the default amount, I assume..?

On the experimental coordinator MAX_SWAP_AMOUNT is larger than MAX_TRADE_AMOUNT. That means, all orders are eligible for onchain payouts. However, if the MAX_SWAP_AMOUNT was smaller than the order size, the Robot buying will not be allowed at all to submit an Onchain address, only a lightning invoice (this is in /api/logics.py ). Therefore, MAX_SWAP_AMOUNT is used inside the send_coins() function only as a double check that nothing very stupid is happening (e.g. some sort of DB injection to send a payout much larger than possible).

84adam commented 1 year ago

I believe the issue was that the maximum fee rate was set too low (increased subsequently to 500 sat/vbyte from 100 sat/vbyte). My transaction required over 100 sats/vbyte at the time, and thus got stuck. (Please confirm.)

Reckless-Satoshi commented 1 year ago

While we have not deployed any fix, this issue has not occurred again.

LND logs seems to indicated something in the line of: "cannot spend and already spent output". Most likely, this was some sort of attempt of LND of re-spending an output that was already spent in the mempool.

Let's keep this issue open as it is likely to happen again eventually. We might then gather enough data to fully debug it.