Account abstraction on Bitcoin since day 1

This post was first published on Medium.

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

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

Account Abstraction (AA)

To understand AA, we must first understand how accounts work on Ethereum. An Ethereum account is similar to a bank account, but holds ethers or ETH instead of 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 the signature is hardcoded into the base layer and runs outside 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. A CA also has storage and code, which an EOA does not.

Motivations for AA

EOA suffers from a one-size-fits-all problem. Whether an EOA has a balance of 1 ether or billions of dollars worth of ethers, it is secured with 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-storage not viable for the mainstream audience.

AA seeks to improve the 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.

AA’s history and current state

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

Some require significant protocol changes such as EIP-2938. Others do not require protocol changes but fundamentally change the workflow of a user wallet, such as the latest EIP-4337. Among other things, it introduces a new mempool, a new actor called bundlers, and several new layers. Given the enormous complexity introduced, it is not surprising that 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 use them, a user must provide the matching “key”, which usually requires some type of secret information.

Crucially, there is no difference 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 have an address that is used by all Bitcoin wallets and is controlled by the corresponding private key¹. However, the validation of the signature is still done at BVM and NOT baked into the foundation and thus requires no special handling, unlike Ethereum.

Usage cases

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

Sponsored Transactions

It allows third parties (such as a payment processor and an application) to pay transaction fees on behalf of its users. This is necessary to onboard users without bitcoins. One way to enable it is to use 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 governed by a programmable smart contract, we can use any alternative signature scheme. For example, we have implemented Schnorr and BLS signatures.

We have also implemented ECDSA on alternative curves such as 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 in can only be transferred after a user-defined time delay. A user can also set one expenditure limit per day and whitelists/blacklistsamong other things.

Recurring payments

A Patreon-like service on Bitcoin has been implemented 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).

See: Blockchain: Data Power-Ups and NFTs for eSports and Online Gaming

width=”562″ height=”315″ frameborder=”0″ allowfullscreen=”allowfullscreen”>

New to Bitcoin? Check out CoinGeeks Bitcoin for beginners section, the ultimate resource guide for learning more about Bitcoin – as originally envisioned by Satoshi Nakamoto – and blockchain.