Justin Kilpatrick |

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.

Subscribe to our newsletter!