robosats icon indicating copy to clipboard operation
robosats copied to clipboard

missing onchain payout

Open 84adam opened this issue 1 year ago • 7 comments

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 avatar May 05 '23 22:05 84adam

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

84adam avatar May 06 '23 02:05 84adam

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

anaconda5486 avatar May 06 '23 02:05 anaconda5486

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

Reckless-Satoshi avatar May 06 '23 11:05 Reckless-Satoshi

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

84adam avatar May 07 '23 02:05 84adam

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).

Reckless-Satoshi avatar May 07 '23 11:05 Reckless-Satoshi

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.)

84adam avatar May 10 '23 20:05 84adam

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.

Reckless-Satoshi avatar May 26 '23 10:05 Reckless-Satoshi