Account abstraction on Bitcoin since day 1

This post was first published on Medium.

Account abstraction has for a long time been a dream of Ethereum and has become a hot topic recently.

We demonstrate Bitcoin has shipped with account abstraction/unification since its genesis. Thus, all the salient features promised by AA can be and have been developed on Bitcoin, without any protocol changes and with little added complexity. Ethereum’s flawed initial design requires constant and complex retrofits to realize AA, which is still yet to be delivered, over 14 years later than Bitcoin.

Account Abstraction (AA)

To understand AA, we need to understand how accounts work on Ethereum first. An Ethereum account is similar to a bank account, but holds ethers or ETH rather than fiat. There are two types of accounts on Ethereum, both identified by a unique address.

1. Externally Owned Account (EOA)

EOAs are accounts owned by something external to the blockchain: users. They are the traditional accounts that users create with a wallet like MetaMask. An EOA has a public address controlled by the user’s private key, which can sign and initiate transactions. The validation of signature is hardcoded into the base layer and runs outside of the Ethereum Virtual Machine (EVM).

2. Contract Account (CA)

These accounts are commonly known as smart contracts and are controlled by their smart contract code, not a private key. The smart contract is run in the EVM. Also a CA has storage and code, neither of which an EOA has.

Motivations for AA

EOA suffers from an one-size-fits-all issue. Whether an EOA has a balance of 1 ether or ethers worth billions of dollars, it is secured by a single private key. If a user loses the private key (or seed phrase) due to a small mistake, she can lose everything. This makes self-custody non-viable for mainstream audience.

AA seeks to improve user experience and eliminate the existence of two types of accounts by unifying EOA and CA. It makes EOA programmable by moving the validation logic of signed transactions into the EVM, as in CA. An EOA can be tailored to each user’s needs.

The History and Current State of AA

There have been many proposals over the years on how to achieve AA on Ethereum.

Some requires significant protocol changes such as EIP-2938. Others does not require protocol changes but fundamentally changes the workflow of a user wallet, such as the latest EIP-4337. It introduces a new mempool, a new actor called bundlers, and multiple new layers, among other changes. Given the enormous complexities introduced, it is not surprising EIP-4337 has not seen any meaningful adoption.

Account Abstraction on Bitcoin

The Bitcoin equivalent of an account is a so-called Unspent Transaction Output (UTXO). The bitcoins in a UTXO are controlled/locked by the smart contract code in it. To spend them, a user has to provide the matching “key”, which typically requires some kinds of secret information.

Crucially, there is no distinction between a UTXO controlled by a private key and a UTXO not controlled by one. The spending condition of a UTXO is always validated in the Bitcoin Virtual Machine (BVM). The most popular types of UTXO has an address used by all Bitcoin wallets and is controlled by the corresponding private key¹. However, its validation of signature is still done at BVM and NOT baked into the base layer and thus requires no special handling, in contrast to Ethereum.

Use cases

Bitcoin has AA from the beginning since it unifies all account/UTXO processing. To corroborate this, we list some of the most prominent AA features that have been implemented on Bitcoin. Other AA features can be achieved similarly.

Sponsored transactions

It allows third parties (such as a paymaster and an application) to pay transaction fees on behalf of their users. This is needed to onboard users without any bitcoins. One way to enable it is using the ANYONECANPAY sighash flags. It allows anyone to add inputs to a partially signed transaction, which can be used to pay miner fees.

Different signature schemes

Bitcoin uses a specific signature scheme called ECDSA on a specific elliptic curve called secp256k1 by default, the same as Ethereum. Since a UTXO is controlled by a programmable smart contract, we can use any alternative signature schemes. For example, we have implemented Schnorr and BLS signatures.

We have also implemented ECDSA on alternative curves like secp256r1, which enables hardware signing using the secure enclave of iOS and Android devices.

Vault

A non-custodial Bitcoin vault has been built, where bitcoins locked inside can only be transferred after a user defined time delay. A user can also set a spending limit per day and whitelists/blacklists, among other things.

Recurring payments

A Patreon-like service on Bitcoin has been implement to allow recurring payments.

Multisig

Bitcoin has built-in support for multisig out of the box.

NOTE:
[1] The smart contract is called Pay to Public Key Hash (P2PKH).

Watch: Blockchain: Data Power-Ups and NFTs for eSports & Online Games