Althea Development Update #82: Direct router deposit with Wyre!
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 <justin@althea.net>
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 <justin@althea.net>
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 <justin@althea.net>
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 <justin@althea.net>
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 <justin@althea.net>
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 <justin@althea.net>
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.