With the new Beta 11 release users can now use the Wyre widget to buy and send funds directly to their router.
We've been dreaming about a system like this for a very long time. While Wyre pay isn't available in every state or region where it is available users won't have to navigate Coinbase any longer.
The process of buying and then withdrawing to the router was essentailly our largest usability barrier.
I'm really looking forward to seeing this in production over the next few weeks.
Bugfixes and optimizatons
As we scale up our operations new bugs continue to become apparent. This is just a small selection of recently fixed bugs.
commit 9ad66361da8b6dd9b3372ee64c17361281fd1e3d Author: Justin Kilpatrick <firstname.lastname@example.org> Date: Wed Feb 5 14:31:15 2020 -0500 Reduce unneeded database loads in status request path The exit was performing a db request to check if a user entry existed and then just a few lines later requesting that same entry. We can save the round trip time and grab it while we check if it exists
commit 2bda1b3b232e387c70ad90e405a749ae8d63a19e Author: Justin Kilpatrick <email@example.com> Date: Wed Feb 5 15:06:43 2020 -0500 Optimize client database entry updates Previously several database requests would be made for every client checkin to potentially update the email and phone number. Now we only perform an update when there are actual changes and also only update the last seem timestamp every 12 hours. This required banning entry timeouts less than 24 hours but that's a satisfactory compromise for much faster general operation. The total number of database requests per endpoint hit should be reduced from 5 to 1 on average by this patch and the previous one.
commit ee8169d3d8975982d101fbe301379dadddbab856 Author: Justin Kilpatrick <firstname.lastname@example.org> Date: Thu Feb 13 21:31:45 2020 -0500 Correct payment validator logic to prevent double payments Previously we used independent do_send statements in order to validate payments. This is logically incorrect as it's possible for the payment to be accepted in debt keeper before it is removed from the validation list in payment validator. This patch corrects that error by making sure that in order to send debt keeper messages the removal from the existing list must first succeed. The next race conditon to consider is that multiple calls to remove may be running in parallel. We address this by having remove return an error when no such transaction exists. Since Actors themselves serialize access to self this means removal from the list is fully atomic.
commit e8fa2fa35e255b6f706b21c9acfbd00a1e0b17bb Author: Justin Kilpatrick <email@example.com> Date: Tue Feb 11 07:48:25 2020 -0500 Add protection for full node communication After discovering that nodes would overpay the exit I've been looking to prevent it from happening again comperhensively. My first attempt was to refund incoming transactions immediately and add long timeouts to the transaction checking. While refunding incoming transactions has worked quite well to unwind our overpayment balances long timeouts has served it's purpose but caused other problems. Like a generally huge number of timeouts in the common loop. This patch is a replacement for the long timeouts patch where instead of making very long lived futures we simply keep track of if we have actually talked to a full node about any given transaction. If we have not succeeded we panic. Both servers and clients have an auto restart catch. In some cases this won't help, in others where the node is merely overloaded it will In the specific case of the exit running slowly and not validating anything this would resolve the issue nicely.
commit 43222e762f17aaa511534fb246fad5be079cb2b6 Author: Justin Kilpatrick <firstname.lastname@example.org> Date: Sat Feb 8 22:01:05 2020 -0500 We set the average Xdai gas amount Since we make up such a large porition of the xdai transaction volume we effectively set the gas amount you'll get from the full node endpoint. Therefore to actually lower our own gas costs it's not enough to remove the constant, we must also enforce a maximum gas price.
commit eb2f4282fa467be7c47ece19835ca6de6437beb1 Author: Justin Kilpatrick <email@example.com> Date: Mon Feb 10 13:36:45 2020 -0500 Cache most exit vars This patch caches all the exit settings referneced by the endpoints. As exits scale more and more threads get thrown at their threadpools resulting in rising and eventually untenable lock contention on the main SETTINGS lock. Most things behind that lock we never really want to change at runtime. other things like the price we do. This patch isn't the best soltuion to the problem by far, moving the locks down to a more granular level within SETTINGS is the real solution here. But that would have wide reaching syntax changes throughout the codebase. No to mention a re-write of settings serialization as you obviously can't write locks to the disk. Overall I find this to be an acceptable compromise. Price is the only thing we must update at runtime so it is refreshed from the main settings object every 10 minutes. This will block one of the many worker threads while it waits for all other worker threads to release their read locks, updates the value and moves on. This only requires a single read lock on the main settings and won't block the main thread. Two big advantages. Remember actual exit billing is synced with the clients through endpoint hitting so this won't affect payments. But it will create slight discrepencies in the user local accounting since local billing won't update the updated price change.
I'm actually still in the progress of debugging a dns related issue on the exits. Hopefully our next dev update can cover that in detail as it's been an interesting ride.