BotC Overview issueshttps://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues2024-03-04T11:40:47Zhttps://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/104Fix failed ETH cashouts2024-03-04T11:40:47ZRamaxxFix failed ETH cashoutsSome months back we've received a report from Xavi Zambrana regarding failed outgoing ETH txs:
![image](/uploads/8ff16952784e50d27a8a639ef8e442f8/image.png)
Coincidentally, that day, September 27th 2020, there was a peak of 0.30265 eth...Some months back we've received a report from Xavi Zambrana regarding failed outgoing ETH txs:
![image](/uploads/8ff16952784e50d27a8a639ef8e442f8/image.png)
Coincidentally, that day, September 27th 2020, there was a peak of 0.30265 ether on the fee price:
![image](/uploads/dfbe92b25a396ce382826afa818fca11/image.png)
As a first step to debug this issue, we decided with the tech team to switch from the old version of parity we were running as our node, to the latest stable version of `geth`, which after a careful process we've managed to complete recently. See #94
We've been experimenting the fee cap (geth --rpc.txfeecap <ethers>) to limit the fee our node would pay to the network for tx's and noticed it won't help as in case the network requires a higher fee exceeding the cap, the tx would fail and just not happen.
This was an intent to overcome the situations when fee costs peaks (like what happened when @xavislow reported the issue), but it seems we would be introducing a new issue trying and not actually succeeding to solve another one, which is avoid failing txs from our wallet.
It seems we should live with it, as fees prices fluctuate all the time.
A potential solution is to always have some spare eth on the node's payout address (the default geth txfeecap is 1 ETH actually)
Another part of the fees story to understand for us is how BotC handles the fees, and review the whole eth cashflow, as there is a middle step involved when a member wants to cashout, where we have to manually move funds from their account to the main (payout) address which is of course undesirable. But we'll create a separate issue for that.
An idea could be to create a cronjob to collect the funds from the different addresses and store them on the payout address, capped to a max amount to keep funds safer, as they cannot leave the node if not on the main address.
Let's get some feedback and take a decision.Release 2020RamaxxRamaxxhttps://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/100Exchange: No funds enought2024-03-04T11:40:48ZZambrana XavierExchange: No funds enought![photo_2020-10-18_15-10-11](/uploads/268d920a64da15c3898d287922022219/photo_2020-10-18_15-10-11.jpg)
When using the exchange feature of the wallet, it looks like some times you might get this bug. That is, you get a red message saying ...![photo_2020-10-18_15-10-11](/uploads/268d920a64da15c3898d287922022219/photo_2020-10-18_15-10-11.jpg)
When using the exchange feature of the wallet, it looks like some times you might get this bug. That is, you get a red message saying 'No funds enought'. Now, the message is misspelled (it should be 'not enough funds', or 'non-sufficient funds'). But the message is also false, as you might be able to go on with the exchange. In particular, I was able to do the 4eur exchange that it is reported in this attached image. I had enough euros, and Enric verified that there were enough ETH in the exchange wallet. Anyway, I completely ignored the message, and it was all good. But that message should not pop up like that :)https://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/94Upgrade Ethereum node2024-03-04T11:40:51ZRamaxxUpgrade Ethereum nodeBotC core tech team discovered a general issue which may affect some outgoing ETH transactions.
It's still not clear the reason why some cashouts fail.
After some investigation, we've realised the version of Ethereum node we are runnin...BotC core tech team discovered a general issue which may affect some outgoing ETH transactions.
It's still not clear the reason why some cashouts fail.
After some investigation, we've realised the version of Ethereum node we are running is quite old, so it's necessary to upgrade it in order to do debugging on a current latest stable version.
Upgrading Ethereum node may require changes on the wallet code, so we should evaulate if the process could be tracked publicly or on our internal tools.
**Update:** we've decided to migrate to `Geth` since it's a very mature and well developed software, and after our tests we've discovered it's a drop-in replacement for `Parity` and no changes to our code are needed.
Migration checklist:
- [x] Ensure that API code does not use Parity-specific namespace methods
- [x] Ensure that Wallet code does not use Parity-specific namespace methods
- [x] Ensure that API code does not use Parity-specific response fields
- [x] Ensure that Wallet code does not use Parity-specific response fields
- [x] Ensure that API code does not rely on Parity-specific API responses for bad requests
- [x] Ensure that Wallet code does not rely on Parity-specific API responses for bad requests
- [x] Ensure that API code does not rely on Parity-specific error codes
- [x] Ensure that Wallet code does not rely on Parity-specific error codes
- [x] Set up Geth infrastructure
- [x] Set up Geth software to run on a different port, in parallel with the Parity node
- [x] Notify users about maintenance window
- [x] On maintenance window, point the BotC API to the Geth port (change API config) and verify
- [x] On maintenance window, import private keys from Parity
- [x] On successful traffic, switch over all traffic to Geth and monitor for a period (weeks)
- [x] After successful switch, shut down Parity nodeRelease 2020Gampe SebastianGampe Sebastian2020-12-22