Threshold cryptography in distributed trust banking environments

This post is the first in a series on distributed banking. Over the last few months I’ve been seriously looking at the current banking landscape - the issues facing current banking institutions in playing catch-up with fintech startups eating revenue, the increasing revenue decline from current accounts and the risk-related incentive to maintain current core banking solutions. The focus of this post will be the movement of current accounts into a utility offering one possible implementation to this idea. »

Bank: Multiple accounts and merchant accounts

In this post I will detail the most recent additions to the banking project: multiple accounts per user and merchant accounts. Multiple accounts per user When I first started developing the project, I decided to do a one-to-one on users and accounts. The logic was that this would be the most simple implementation I could do that would allow me to still work on the more complex parts of the system. »

Bank: React Native MVP

Over the past few weeks I’ve been working mostly on the mobile application using React Native. The app is in a good state and I am currently getting it ready for store release. Screenshots I put a lot of effort into the design and UX of the application as this will be the first stop for any consumers. Overall I am really happy with the way it turned out. As always there are tweaks to be done, but for now a great starting point. »

Bank: Authentication update to stronger standards

I’ve been doing a lot of reading on cryptography lately. Some of my goals require a deep knowledge of encryption and how to implement successfully, so diving in now is an ideal time. One of the first updates I decided to do, in order to strengthen the banking project, was to update the password storage. I took a lead from the OWASP guidelines: Use a unique salt per password Have a sane, long minimum for password length Use an expensive cryptography function for hash calculation Argon2 At the top of the list of recommended hashing functions was Argon2. »

Distributed banking: Product vs Utility

I’ve always been a fan of the free and open web. The practically zero barrier to entry It’s the biggest reason I could get into web development, and I use free and open source software (FOSS) wherever I can. This past weekend I took a look through some of the talks from the Distributed Web Summit. Some of the greatest minds gathered to try and fix the problem of centralisation that the open web is currently facing. »

Bank: Integrating push notifications

After a fair period of doing research into the industry and various technical considerations, development work on the banking project has started once more. On the to-do list for some time now was push notifications. This is an interesting one as it affects both the server and the client and both are closely tied together. Backend structure I decided to add a separate table for the token storage. This table links tokens to an account, holds the token value, and also holds the platform the token is for. »

Bank: Integration and secrecy

The banking project has turned a corner. Status The development of the last eight months has led to a barebones functional banking core with a REST and CLI API and mobile application. With a few rewrites under the belt tests have been written, error handling has been implemented, and benchmarks have been included. The mobile application has been written in a few languages with the final choice being React. »

Bank: Progress update - DB, decimals and benchmarks

Over the past week I’ve done backend work on the bank. These aren’t sexy changes, but definitely much needed. DB Connections When I first wrote the database connections, I wasn’t sure how they worked exactly. I assumed that the database connections were closed on function exit, and that only queries needed to be explicitly closed. I was half right. Go uses a DB connection pool which is meant to be long lived and shared between functions in the application. »

Bank: React Native

As part of the process of building out full infrastructure, I had already started work on an iOS app. The app had been built and was working and at the time used the TCP CLI client. I started moving this over to HTTP, but almost immediately ran into issues around async calls and more. These issues required too much deep diving so I decided to try the app using something I was more familiar with and that also provided cross-platform development. »


The past few days have been busy. After the big rewrite I had enough done to start the HTTP REST API. I tried to keep the implementation as simple as possible, staying away from big frameworks etc, so I landed on just using net/http and gorilla/mux. The Gorilla Mux is small enough to add minimal overhead abd be close enough to the metal. Implementation With this simplicity in mind, the implementation is easy. »