Philip Glazman is a software engineer at River Financial, a start-up aiming to become the world's first Bitcoin financial institution. Today we asked him a few questions about how the company leverages Bitcoin's cutting edge developments to enhance the service it offers to its customers. Note that this is not a sponsored article.
Hi Philip. First of all, can you explain the technical reasons why River Financial is a Bitcoin-only business?
River Financial is a challenger financial institution specializing in Bitcoin financial services. River Financial’s flagship product, a Bitcoin brokerage, provides retail investors with a high-touch platform to buy and sell Bitcoin.
From a technical perspective, there are huge returns on focusing solely on Bitcoin. In attempting to support several cryptocurrencies, the feature set would be limited to the lowest common denominator of all the chains. Specializing on Bitcoin allows us to build the best tooling and products focusing on the native protocol. The backend infrastructure was written in-house with the aim to build enterprise grade tooling and software that we can iterate on to support future protocol upgrades.
A concrete example of this laser focus includes our integration of the Lightning Network for handling deposits and withdraws from the first day we launched. Supporting Lightning requires tooling and domain specific knowledge that can only be developed in an environment where there is detail for the entire Bitcoin stack.
In addition to Lightning, we have recently started inviting clients to beta test our Hardware Wallet Account which allows clients register their hardware wallet with River to monitor balances, generate deposit addresses, and keep track of tax lot information while promoting self-custody. This product required our Bitcoin infrastructure to be robust in handling descriptors, wallet rescanning, and supporting the edge cases of different hardware wallets.
Outside of specific products, our technical focus allows us to optimize for better fee estimation, coin selection, and security. There is quite a lot of work to be done to build the best Bitcoin brokerage and products I wish existed years ago. The focus on building the best foundation with the right engineering principles enables us to build the best Bitcoin-specific products.
Can you explain briefly what Descriptors and Partially Signed Bitcoin Transactions (PSBT) are and how you build on them?
The relationship between Descriptors and PSBTs are separate but related technologies in the context of our wallet infrastructure.
One of the primary design philosophies of our wallet software (walletd) is to embrace interoperability in the ecosystem. Adopting PSBT was critical in the development of our wallet in order to ensure that we treat a signer as an interface. In doing so, we can have a diverse set of signers and are able to scale our infrastructure to handle multiple wallets with different scripts. The PSBT format encapsulates all the necessary information for a signer perfectly and it has been a pleasure to use it within our infrastructure.
All of our wallets in walletd are described using a descriptor. A descriptor encoded in a string can be imported to our service and walletd can start to generate scripts and handle transactions. Our recent Hardware Wallet Account takes advantage of this technology by generating a descriptor using an extended public key in a hardware wallet’s BIP32 tree. Before descriptors, it was difficult to describe a wallet in a simple way. Descriptors reduce operational complexity in importing wallets as well as provide a simple language in understanding the scope of wallets.
In walletd, descriptors and PSBTs work well with each other. When there is a request to create a transaction, walletd will draft a transaction and create a PSBT-compliant format to express it. The fields of the PSBT that require BIP32 paths and script information can be populated by querying a data store with the wallet descriptor with relevant information. A designated signer will receive the PSBT from walletd and return the response for it to be finalized.
There is additional detail on our use of these two technologies written in a Field Report with Bitcoin Optech.
Our approach to having multiple custodial wallets has been a great experience for us and has been made easier using descriptors. We generate scripts belonging to our cold wallet for client deposits and our hot wallet handles withdrawals. Separate wallets with different spending conditions allows River to keep the absolute minimum Bitcoin in the hot wallet (to minimize risk) and better manage the UTXO pool to service withdrawals. Both wallets have different descriptors and different spending conditions described in the descriptor.
River Financial also uses SegWit and batching, can you explain the difference they make?
We have the fortunate benefit of building wallet infrastructure in a post-SegWit Bitcoin world thus allowing us to use SegWit since the first day of engineering. Embracing SegWit lowers on-chain transaction costs and fixed transaction malleability issues. The lower fees is a benefit we pass on to our clients making withdrawals cheaper. Our fee estimation takes the output address into consideration, and P2WPKH outputs use less weight in a block. Therefore we indirectly incentivize customers to use native SegWit outputs for a lower on-chain fee.
We use native SegWit in P2WPKH and P2WSH scripts that are used for the hot and cold wallets respectively.
Although we currently do not offer batching through our Bitcoin brokerage product, we plan to offer clients this feature for cheaper withdrawals soon.
What do you think the Lightning network brings to your product?
For our clients, Lightning brings cheaper fees and fast settlement times for sending and receiving Bitcoin, but has historically been hard to use for a non-technical user. By abstracting the concept of "On-chain Bitcoin" and "Lightning Bitcoin" River makes using Lightning easy for clients by only having one aggregate Bitcoin balance.
Having integrated the Lightning Network with our product from day one, we have found some interesting insights on how clients use the feature. Inbound Lightning payments are swapped for on-chain coins and sold to get instant US dollar liquidity.
I am very excited to iterate on our offering as the Lightning Network continues to mature over time. Future iterations will include increasing invoice limits and supporting Spontaneous Payments. It’s also very satisfying to see clients using off-chain solutions like the Lightning Network with rising on-chain fees.
Finally, what are some other Bitcoin developments you are particularly interested in and how do you plan to use them?
A non-exhaustive list of developments I am personally excited about include the Schnorr and Taproot proposals and Spontaneous Payments on Lightning.
We are starting to experiment with Schnorr and Taproot in a serious capacity so that we can identify the benefits we can pass onto our clients. With Taproot and adjacent technologies like Miniscript, it is becoming increasingly possible to offer more interesting scripts. I am very interested in working on Bitcoin-specific products that leverage interesting scripts to cryptographically guarantee useful and novel spending conditions. A likely benefit from these protocol upgrades will be more robust cold storage leveraging new scripts. It gets pretty interesting when a custodial service can provide guarantees about clients’ money by using the native protocol in addition to application level security.
Spontaneous Payments on Lightning, formerly key-send, is a way to send invoice-less payments by including the pre-image inside the payment. This is particularly great for user experience because one can start receiving Lightning payments without creating an invoice. This mimics the user experience one expects on-chain and is a great way to continue abstracting the notions of “on-chain Bitcoin” and “Lightning Bitcoin”. At River, we always look to improve the user experience for Lightning so that more people can have access to cheaper fees and instant settlement.