RoboSats/robosats

missing onchain payout

Opened this issue · 7 comments

84adam commented

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

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

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

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:

response = cls.lightningstub.SendCoins(request)
if response.txid:
onchainpayment.txid = response.txid
onchainpayment.broadcasted = True

84adam commented

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

MAX_SWAP_AMOUNT = config("MAX_SWAP_AMOUNT", cast=int, default=500_000)

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

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

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.