File Detail


text/markdown; charset=utf-8

Bitcoin Agent

An on-chain Byzantine fault tolerant service indexing network using Bitcoin's Proof-of-Work and tamper resistant chains of digital signatures built into the base layer.

Attila Aros - Chief Technology Officer, MatterPool Inc. [email protected]

Document version 1.0.0


This paper introduces a novel service framework "Bitcoin Agent" that allows anyone to independently operate, verify, index, and query the blockchain in a way that is Byzantine fault tolerant and provides a general Turing-Complete state machine that can be independently verified using the native tamper resistant chain of digital signatures built into Bitcoin satoshi token themselves. All applications can operate trustlessly with no direct communication (if desired), but instead act as "Byzantine listeners" whom track the strongest proof-of-work signal for any state coordination. Indeed, this agent is a special kind of listening Bitcoin node (ie: One which only reads blocks and does not create them) that relies only on the raw block header proof-of-work chainwork and the raw block data itself which can be obtained securely and trivially from any provider. We analyze the framework and claim this approach is capable of easily handling 1-10 GB blocks every 10-minutes (about 3-30 million transactions) on home desktop computers simply equipped with an internet connection with only +20 mbps bandwidth. Additionally, we outline a sketch of a hypothetical Bitcoin digital asset protocol "SimpleAsset", a non-fungible smart token and some of the desirable properties.

We will show that using the satoshi token and it's own chain of digital signature history ("title history") is the key to sharding the UTXO set that unlocks massive scale for businesses and are the key to building an on-chain distributed verifier network and it was Satoshi's "vision" all along to have businesses and users running their own (UTXO-sharded) listening nodes. It never really hits a scaling ceiling.

Note: Throughout this paper "Bitcoin" refers to the original protocol "Bitcoin (BSV)".

Background and Problem Overview

"The bitcoin network needs to be able to form a consensus about a non- contradicatory subset of transactions... there may not be an objectively best answer, but there needs to be 1 answer that is settled upon. That is the double spending problem. And proof of work is Bitcoin's means of coming to consensus." from "Bitcoin Stuff - The Beacon, the Bunker, and the Faulty Node"

Users, wallets and services today do not have a way of maintaining arbitrary consensus state with each other. Even when relying on miners, SPV, blockchain providers, and other data services there is only consensus at the most base primitive layer: the satoshi token, but nothing else. They all converge just fine on consensus regarding the state of satoshi tokens themselves and the immutable timestamped transactions history. However using "script-based" and "opreturn" data carrier techniques themselves require a higher-level interpretor or state machine to "load the tape" of data and run it forward to the next step.

These script and data carrier based protocols are often referred to as "Layer-1" and "Layer-2" smart contracts because they "sit on top" of Bitcoin Virtual Machine (BVM) as code constructs in script or as higher interpreted languages, merely relegating the satoshi token layer as a data carrier or unintelligent timestamping substrate. By ignoring the satoshi token base layer itself means that strong consensus is not enforced by the proof-of-work mining network for these services' state at all. It's all developers and services hoping silently that the counter party correctly indexed the blockchain in a way that resembles some form of reality between themselves. Even though they are listening to the blockchain, how do they know they each arrived at the consensus state correctly, yet independently?

In other words, the same consensus guarantees that Bitcoin miners ("Byzantaine Generals") themselves enjoy is between each other for maintaining satoshi token state (UTXO index), is not available to non-mining client wallets, users, and developers as of today without a paradigm shift in thinking about the nature of ownership and history. Namely, clients have no way of verifying application state in a deterministic, tamper resistant way, and as a result are unable to achieve strong consistency between their business partners, other users and services. This is because the miners have an economic incentive for strong digital signature chain consistency and therefore always process entire blocks and build UTXO index so they can be absolutely sure they are not being fooled by other potentially hostile Byzantaine Generals. Users and developers in BitCoin have been mislead and now are averse to processing block headers and raw blocks. This need not be the case as we'll show in this paper.

Are businesses and users, forever chained to "miners and transaction processors" for getting their transaction histories and "proofs"? Absolutely not! Because it is case that "businesses can be businesses" and user and businesses alike have the same absolute certainty of their relevant chains of digital signatures for not only bitcoin satoshis, but also for all types of computations. The path forward is hinted at in the Bitcoin Whitepaper.

We assume that users and businesses will want to store their entire transaction histories and assets of interest for their customers and partners. This assertion is made without proof, but at MatterPool have seen almost all clients require some form of transaction history (usually most or all of it) that they can rely on for their internal systems, display to their customers, etc. The interesting question is: why didn't the previous owner give them the full chain of signatures going back to the coinbases in the first place? Afterall, at every step of the way each owner had the parent inputs trivially in hand, why not just pass it directly onto the next user safely.

It is left as an exercise for the reader to show that the storage and computational cost for passing on a full UTXO chain of signatures back to a coinbase transaction is amortized O(n) time and space complexity where n is the sum of the total assets being watched along with their full UTXO chain of signatures. Losing this "title history" and not passing it on means the new owner has to query the miner or blockchain service for the history, wasting resources unncessarily. This Bitcoin Agent methodology and framework imposes zero indexing overhead above and beyond the native processing that Bitcoin consensus mining nodes perform themselves when updating the UTXO set. The user only stores and process transactions that have meaning for them and does not need to store any other part of the blockchain or UTXO set that is not relevant to their purposes.

"Driving" the point home...

Imagine buying a used car without inspecting it's full title history or ownership, or real estate or investment contracts. Businesses already store this in their databases and file systems today because it is crucially important they have in-hand the entire history for their business to serve their customers day to day and in real-time. In the case a business loses or "shreds" their old files, they are available to be replayed on the blockchain for a fee. But in practice businesses will normally keep records as long as feasible and as long as the data has value to them. It would be ludicrous to think that businsesses will publish their chains of transactions to the miners, and not index or keep this valuable business information. It costs orders of magntitude less to save coins with 1,000,000 transfer histories (just 100 MB of history) on mobile devices, home and commercial computers than it is to save and recall that data at a later point in time from a miner or archiver. A trip to the archiver is good when you need old lost information, it is not so good when you are serving millions of customers every day and need this information readily available and pre-indexed.

We will outline a solution that we've tested at MatterPool that is a simple and powerful framework and methodology that gives any token, smart contract or data on the blockchain the same powers as regular satoshi tokens themselves receive and all the Byzantine fault tolerant guarantees that come with using native Bitcoin.

Almost everyone until now has has been acting like a small blocker in Bitcoin BSV, despite that fact that almost everyone has a laptop computer that would barely even be stressing to process 1GB blocks every 10 minutes, just indexing the UTXO shard relevant to their own needs.

Symptoms that a service is not in consensus with others include:

  1. Depend on a custom (usually non-determinstic) API to reproduce state, trusting that the "blockchain provider" will do the right thing.
  2. Unable to point to a single source of state truth for their businesss business needs*. How does a business know with 100% certainty a middleman didn't tamper with the packet between the API service and the client?
  3. Worries of silent data corruption and unable to detect it without incurring a difficult and resource intensive effort to reconstruct state. How to handle rollbacks and ensure (prove) replays are idempotent and correct?
  4. Unable to provide cryptographic evidence that you processed the block's UTXO or state transition mutations correctly to business partners or customers
  5. Frequently dealing with race conditions due to complicated systems architecture. The asynchronous nature of Bitcoin is being fought, instead of being embraced.
  6. Locked in to one provider and "their way" of searching and doing things. When really you just need the blockheaders and the raw blocks themselves.

We intend to show that all the problems can easily be solved by taking the "Bitcoin Agent" and using the full power of native Bitcoin satoshis and it's tamper resistant digital signature chain.

It's important we first clear up some misconceptions about what Simplified Payment Verification (SPV) can do and cannot do and how it relates to these problems.

War and Peace: Simplified Payment Verification (SPV)

What about Simplified Payment Verification (SPV)? Doesn't that provide us with everything we require to prove that a transaction was confirmed? (ie: not double spent, in a block)

In short, the only capability SPV provides is a way for users and mining peers to have some level of assurance that their UTXOs (transaction chains) are valid and timestamped as long as the network is currently not in some attack condition (perhaps covertly long running) at that point in time. In other words, SPV is meant to be used in peacetime, not wartime.

SPV merely gives confidence level that can be measured by comparing how much energy it would take to reverse the spends back to any number of blocks. The client is able to quantity and choose their risk-level by deciding how much energy cost they have before considering the transaction "settled". Moving a billion dollars of value is only safe when the cost of reversing the chain of blocks back to before that point in time is greater than the billion dollars being moved in that transaction, for example.

Bitcoin mining consensus nodes themselves actually have this concept of "sufficient" energy cost built in with the requirement that new coinbase UTXOs cannot be spent until the chain of block headers that the coinbase transaction is included in has been extended by 100 more headers. They cannot spend their coinbase rewards until 100 confirmations have "elapsed". Like mining nodes, users will also select their required confirmations based on their total value being transacted. Someone moving significant sums of money (millions or billions perhaps) might even want 100 confirmations or even much more to be absolutely sure an attacker or alternate chains forks do emerge spontaneously (consider stressful economic, societal and global conflict scenarios).

Technical note: Opportunity cost (energy expenditure) in Bitcoin is measured in units of "Difficulty". For example Difficulty=1 is a hashrate of 7 MH/s while difficulty=2 is 14 MH/s (difficulty is additive). This means that after about 10 minutes (on average) of hashing at 7 MH/s then a block header nonce will be found. For a detailed discussion about proof-of-work as a service and opportunity cost see the Boost POW Whitepaper

The Utility of SPV

SPV is a double-spend risk mitigation technique and provides the following fundamental assurances:

  1. Client or Miner Peer can get proof that a txid existed immutably at the time that some block header was mined that included the txid. (Note that this could be just a single orphaned block header at some time t)
  2. Client or Miner Peer can get proof of the energy cost that went into timestamping it (and any extra energy in subsequent headers can be calculated irrefutably)
  3. Client or Miner Peer can get proof of the chronological ordering of transactions between blocks and inside each block
  4. Client or Miner Peer can get proof of the causal (or topological) ordering of transactions within the same block. Get 2 transactions in same block and compare their merkle trees to deduce causal (topological) order.
  5. (Optional) Client can request digital signature (signed receipt) that the miner has seen the transaction and validates it against it's own block header chain and merkle tree storage indexes. This is like a contract or a public committment to what their state commitment is.

There is this misconception in Bitcoin today that the "miners will do for us" and "SPV will solve our problems" and "miners have an economic incentive to index all my token histories". No they do not have an "economic incentive" to proactively index and serve your spend and transaction histories. Retroactively for a fee, sure, but there is nowhere in the whitepaper it says that token spend history will be kept. And why would all miners do that? Perhaps some have fast bandwidth and good CPU but do not want to operate a 10 more football fields of storage data centers. 1 football field for their hashing and computational market is enough. The only party by definition that cares the most about the honest title and ownership history of a token, satoshi, or any asset is the person that is buying or selling the item.

SPV Myths

SPV is all that is needed to maintain a client focused trustless payments network

FALSE: SPV is strictly a "peacetime" measure and is less trusted when network has a covert or known active attacker. It is a fast probabilistic check for block inclusion of a transaction. It is preferred and recommended that _power users, businesses, and mining nodes all keep the transaction digital signatures of interest themselves, especially in the case of purchase of digital assets and investments that must be shown to link back to a minting transaction.

If I have an SPV proof which means by database is safe from corruption

FALSE: One moment you have an SPV "receipt", another moment you have a stale receipt that is not linked to the active chain due to re-organization. This is acceptable as probabalistc measure of safety for payments, but not for the ownership and history of valueable assets themselves.

Businesses prefer to have the cheapest costs and complete history at hand for signatures and transactions histories fully intact for the efficient operation of their business. A "second best" is to have SPV for the guarantees it affords to the satoshi token payments themselves but it provides very little in it's current usage to clients trading rare and valuable digital assets for example.

Chain of Digital Signatures

Consider the situation of a car owner who bought a car to keep their purchase papers, maintenance receipts and then passes it onto the next person. Then the next owner will add to the records and then pass the entire history peer to peer to the next person's wallet. This is a simple and 100% trustless technique for passing on token histories and digital signatures. In the case that the person lost the history, or in the car example the prospective buyer can run a registration "title history" check with or a similar provider. This is what will happen when users do not pass on their tokens' title histories - they must then go to a central party to serve the data back to them. Why not just index the UTXO shard and digital signatures that's relevant to themselves in the first place?

From the Bitcoin Whitepaper:

We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership.

A coin (satoshi token) is defined as a chain of digital signatures. Full stop. It is not defined as the UTXO set, nor is it defined to be a single output. It is the totality and entire tamper-resistant chain of signatures that gives each coin it's value. It's also necessary for Bitcoin miners and blockchain validators to beable to trace back in the case of system failure or fraud. A coin is a chain of digital signatures because that's the only way a payee can verify the chain of ownership and state completely trustlessly (ie: back to coinbase txid or some other "minting" transaction - more on that below when we introdruce SimpleAsset)

Consider a simple Non-Fungible Token (NFT) smart token that is exchanged 10,000 times. If each output is 1kb, then that is only 1MB of history back to the minting genesis. Are we really saying that it's infeasible for every wallet simply to just pass on the history to every other wallet? Even with 100,000 updates or transfers that is 10MB or about the size of a high resolution consumer photo. Why is everyone in Bitcoin acting like they have Raspberry Pi's and unable to download or pass on say a 10MB or even 50MB chain of signatures? Perhaps someone will receive a coin that has millions of transactions in it's parent chain of inputs. But more likely it will have an average number of a few hundred or thousand transfers. Even in the scenario of 1,000,000 transfer that is only 100MB and at current internet takes a few seconds to download.

Why wouldn't a potential buyer of a media file or digital artwork not want to inspect the few hundred or thousands of updates of it's history to be 100% guaranteed authentic and actually legally owned by party claiming to be selling it? We can trust a miner for SPV, but only in peacetime, and only for the satoshi token themselves as things stand today. It is necessary to have a ccomplete chain of digital signatures for legal purposes as well. See The Risks of Segregated Witness: Problems under Evidence Laws for a thorough discussion about the need for businesses to keep complete chains of digital signatures.

By now it should be clear to the reader that SPV is designed as an risk mitigation technique and a way to quickly check any of the properties outlined above (but not the fully digital signature chain of asset ownerships). However, the strongest form of evidence and assurance is to simply keep the full chain of digital signatures intact for all the data a person or business would want to keep.

They can always go "to the blockchain" and scan and re-index it -- but if they bought something valuable in the first place why would the user discard their "title history"? It is like buying a nice well maintained used car and the previous owner handing you the pile of records and then merely discarding the records because "I can always pay for it later". What sense is in discarding the data that the seller already has anyways? To retain the value of your asset (the car) wouldn't it be better to keep the title history records in hand?

The Whitepaper makes it clear that in the case of network stress or discrepancies that businesses and services will (re) index the transactions, back to their minting coinbases, to be absolutely sure they have the full chain of history. SPV is a short-cut, but it was always intended that businesses and services will run their own sub-UTXO shard indexer if they accept and make payments frequently. It says clearly in the Whitepaper that this was the case and SPV is a useful, but strictly less preferred alternative to verifying the entire chain. We can see this in the narrative about SPV for payments use cases, but never mentioned for "asset and token ownership" usages. That's because it is strictly inferior for that use case and thus rarely ever mentioned in that context.

One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency - Bitcoin Whitepaper, Section 8.

Bitcoin Agent Quick Theory of Operations

The concept is simple and can be explained like this: lock satoshis in an output script that represent the value of the smart contract, computation or token. The value is decided by the user and the amount does not matter for the purpose of successful operation. This is the original "colored coins" idea proposed by Mike Hearn which was to actually color the satoshi itself. Somewhere along the lines almost everyone forgot this simple idea and overlooked it's profound implications and it's inherent superiority to every other blockchain that supports smart contracts, such as Ethereum.


Before we describe the method in detail, we must first give an overview of the actual mechanism and data structure a Bitcoin mining node performs itself when building up the UTXO (state) index for verification. By analyzing this process, we can draw a direct parallel with the processing done by Bitcoin Agent and then proceed to show it is optimal (zero overhead indexing).

How Bitcoin nodes build and verify state

An introduction to the UTXO-set is prerequisite knowledge Bitcoin’s UTXO Set Explained to bring the reader up to speed. The following discussion pertains specifically to how a Bitcoin node itself implements the data-structures necessary to support it. This analysis will be used to construct the formal proof that Bitcoin Agent is storage and computational cost is optimal (zero overhead indexing)

The process that a node goes through in building up a UTXO set is to basically keep a Map data structure that is used to reference parent inputs (by "txid" and "index" -- outpoint). When the block processor tries to process a transaction, it performs a lookup on all the parent inputs and checks if it exists as 'unspent' in the UTXO Map. If it present (ie: not-spent before), then the UTXO Map entry is deleted completely (it is old state afterall and no longer needed). On the other hand, if it is not present, then an exception is thrown and the block is marked as invalid.

For a block of n transactions (assuming on average 2 inputs and 2 outputs) we can see that the number of UTXO Map lookups must always be at least O(n) because we must check each and every input for all transactions in the block. Notice however that the size of the UTXO set is larger than the number of transactions in a given block. Let w represent tthe number of unspent outputs accumulated up until some block height h:

Therefore, the run-time complexity is O(n * logw) where w is the total number of unspent outputs at height h. If a Hash Index is used (trading off run-time for more space) then we can achieve O(n*1) = O(n) run-time complexity instead.

What about storage complexity? The storage complexity is O(w * logw) using a Btree because by definition all unspent UTXO's carry some non-zero and non-negative value which represents future revenue for a miner. We will assume we are using a Btree instead of a Hash Index, even though a Hash Index lowers the storage requirement to O(w).

It is important to note here that not all miners will serve full transaction indexes (not to be confused with UTXO set index) for historical data. In the limit miners will likely only serve the UTXO's between themselves because there will be no need to bloat the Bitccoin mining node and lower it's competiveness at building and finding blocks. Anything above and beyond UTXO set management will be provided as an extra service by the same or other miners. Not all miners will want to store EB's of data in massive data centers and instead will just maintain the (private) UTXO set like we see today already.

Proof that Bitcoin Agent is Optimal (Zero Indexing Overhead)

Lemma 1. A user or service that needs to have an irrefutable chain of digital signatures for proving the authenticity must analyze at least O(n) inputs where n is the total number of spends of a coin or asset.

Lemma 2. Each ownership transfer adds O(1) extra storage overhead to the history of digital signatures that gets passed onto the next owner. After n transactions, the latest owner has n transactions (each owner passed on the previous history +1)

Lemma 3. A user or service that wants to maintain consensus on a state of a smart contract, token or computation must either proactively index the inputs ahead of time, or reactively receive and verify the entire parent chain to be 100% certain of authenticity.

Lemma 4. SPV can be requested for only the UTXO digital signature chain tip (ie: the last settled UTXO) to know that the entire chain of transactions anchored back all the way to the minting event has been successfully timestamped and accepted by the network.

Side note: A user that owns a token or computational state can pass the entire history over to the new owner, who then in turn verifies that the chain of digital signatures is intact and correct back to genesis. Alternatively users and businesses can proactively pattern matching the minting transaction formats themselves (just like a Bitcoin node itself does on the native satoshis and coinbase transactions) which then in-turn indexes all downstream UTXO's from that point onwards forever.

The fact remains: If someone wishes to verify authenticity they must do it proactively themselves up-front or reactively (such as when a sender transfers a new token and it's associated history in p2p or when instead requesting the full "title history" from the Bitcoin blockchain miners from the archives).

Theorem: The time and space complexity requirements for a Bitcoin Agent to maintain consensus is identical to a Bitcoin mining node.

Because the satoshi token itself is carrying the exact value of the minting input value, and we can trustlessly verify the chain of signatures up the chain of UTXOs then the problem of determining the latest state of a smart contract, NFT, or other computation. Only a UTXO Map is required for being able to successfully process a block and accept the computation. This implies that after some number of confirmations, all agents processing this chain of digital signatures will arrive at the same state because the algorithm and problem of consensus is merely reduced to verifying the input spends in a Map data structure.

The topological ordering property guarantees that if we only index the minting transactions (or plain coinbases) then we can be sure that all transactions of interest appear in the downstream DAG of the outputs of these minting transactions. Since the indexer has chosen to create a minting transaction for the purposes of state transformation and verification, it follows trivially that all causally related transactions are located directly downstream. "UTXO Shard in a box" for every wallet, service, business at scale.

Block re-organization block undo/redo information is constant. The space and storage complexity of storing adequate block undo/redo information is bounded because after so many confirmations (> 100) they can be pruned, setting a large constant O(1) upper bound on storage and run-time for this "re-organization" protection.

For a block of n transactions (assuming on average 2 inputs and 2 outputs) we can see that the number of UTXO Map lookups must always be at most O(n). However when indexing special NFT's or smart contracts -- it is not necessary to track coinbase txids (because those are not the NFT's we wish to track). The number of minting transactions of an NFT must be equal to or less than n tranactions. Therefore the number of Map lookups must be at most O(b) where b ( Where b < n) is the size of the history of assets under verification by the custodian or owner.

Therefore, the run-time complexity is O(b * logb) where b is the total number of unspent outputs (latest state) at height h for assets being tracked. If a Hash Index is used (trading off run-time for more space) then we can achieve O(b*1) = O(b) run-time complexity instead.

The storage complexity is O(b * logb) using a Btree because by definition all unspent UTXO's carry some non-zero and non-negative value which represents future revenue for a miner AND value for the business itself. We will assume we are using a Btree instead of a Hash Index, even though a Hash Index lowers the storage requirement to O(b).


Run-time complexity of Bitcoin Agent compared to Bitcoin mining node:

O(n * logb) <= O(n * logw)

Where n is the number of transactions in the given block and b is total number of unspent UTXO's in the shard. w is the size of all global utxos. In practice b << w (and in the limit it is merely recovering the entire global UTXO set) and this means storage requirements only grow with the actual needs of the business, not the total size of the Bitcoin economy.

And the storage complexity: O(b * logb) <= O(w + logw)

That completes the proof.

Corrollary 1: Any smart contract, token, or state machine built on Bitcoin that does not leverage the base chain of digital signatures must use additional indexes and storage space than the Bitcoin node itself.

Corrollary 2: Because every on-chain listener has the exact shard of the UTXO that they all have, then they each have independantly arrivied at the same computation. They can trivially compare the UTXO set in any mining node or any other Bitcoin Agent (at leas those that index the same subset of the shard) and inspect 100% bit for bit correctness in state. Therefore it is trivial to publish a UTXO mutation set committment hash at every block and merely compare to each peer to know if one of the peers has failed due to corruption or system failure and they can quickly inspect the mutation operation updating the spend and identify the problem at a specific point in time trivially. The Bitcoin Agent operators can quickly and easily identify the root and fix it precisely at that point in time with confidence once their committment hash matches everyone elses

It is not necessary to use these committment hashes, because the state is guaranteed to be correct, in exactly the same way as a Bitcoin node does with it's global UTXO set. However the hashes serve as a useful checksum because bit-errors do occur and being able to publically see that error and fix it is valuable to any one single participant.

What "Bitcoin Agent" is not

Simply put, the "Bitcoin Agent" is not specific code or tool that everyone installs and uses together. It is a "framework" in the sense that anyone can easily build on on-chain agents in a 100-200 lines of code in any language or database that merely follows block headers and can obtain raw blocks for filtering down transaction outputs of interest. Anyone can start now and immediately be able to achieve consensus and have a way to verify when a mistake was made in the computation. There are numerous Bitcoin blockchain service providers that can quickly return the block headers and raw blocks, which operates on zero-trust.

Sketch of SimpleAsset Non-Fungible Token (NFT)

We will briefly discuss a hhypothetic Non-Fungible Token (NFT) that carries satoshi value that the creator fused into the token at time of minting. The only way to spend this output, is to create another output that carries the identical satoshi value and original minting txid along with it. Using OP_PUSH_TX we can trivially impose this condition to guarantee exactly 1 output carries the state forwards (ie: to the next or same owner, in the case of a state update).

By enforcing this constraint we basically enforce, at the script level, the deletion of the spent token from memory. Without using satoshi token value, an off-chain database must mark the entry or pointer as deleted (ie: another index is needed above and beyond the mere UTXO set). This is why it is crucial to use Satoshi value to update token/computational state.

When a user receives a token they receive the entire chain of signatures back to the minting. The users wallet verifies the parent signatures all match to provide 100% certainty of authenticity. An NFT with 10,000 transfers or state updates is only 1MB in total size (off-chain data transfer). However if the owner of an NFT lost their history, then a service provider can perform the lookup quickly, return all 1MB worth of the 10,000 transfers so the current owner has that information readily available from then on.

We will demonstrate the SimpleAsset token in functional code and examples in a future paper.


  • Users can permissionlessly mint any smart contract or NFT
  • Users can permissionlessly transfer and even "melt" tokens back to native cash satoshis
  • Users can choose _how many satoshis to infuse into the NFT. Giving it instant instrinsic value that must be passed along for the entire lifetime of the token before being melted back
  • Users, businesses and Bitcoin miners themselves can track all mutation hash committments trivially and show that all arrived at the same state. (Optional)


  • Zero overhead indexing above the required native UTXO set
  • Capable of scaling to 1 GB blocks on a +60 mbps internet connection and using only 5TB/month with (zero storage overhead and zero extra indexes compared to the native UTXO set)
  • Token can be transferred 100,000 and the off-chain history is only 10MB. Each transfer adds about 1kb of history to the title. Even a token with 1,000,000 transfers is still manageable at 100 MB.

Security Guarantees

  • A seller will always provide the complete title history, so the buyer can inspect authenticity trustlessly
  • Even if a seller does not have the title history, simply call a blockchain service and pay them a small fee to obtain it quick so that the new buyer then has it going forward (which they can then pass onto the next new owner in the future if they are so kind)
  • Buyer can perform a single SPV on the latest state, to know with certainty that the entire history is valid.
  • Full Byzantine fault tolerance guarantees that are afforded to satoshis at scale with zero indexing overhead and zero risk of being fooled with un-authentic assets. Every smart contract/NFT is enforced by the POW header chain and raw blocks (Layer zero) and therefore all state can be arrived at deterministically in the same way that a Bitcoin node itself does now.

How is this different from other L1, L2 solutions?

Any non-base layer token will incur at least a 100% storage and execution overhead because at minimum 1 extra fast KV store or index is required (due to the fact that the 'value' field is seperate in the data). Anyone operating with satoshis as the token value will have a signficant cost reduction over any competitor that does not. The operator using this new method will also have fast resolution of conflicts and be able to trivially prove to their customers that they computed the correct state and users have 100% certainty of authenticity that is independently verifiable.

Additionally, these SimpleAsset NFT's only require one SPV check (the utxo "tip" only) at the point of inquiry to confirm ALL of the state back to the beginning forever. This is not possible if the satoshis themselves are not used for carrying value because the Bitcoin miner UTXO Map algorithm for managing spends does not concern itself with anything _except the chain of digital signattures in the satoshi inputs/outputs only*.

Preliminary Results

Our preliminary results show that a home desktop laptop can easily process and index the UTXOs of the 1.3M transactions in block #635141 in about 60-90 seconds on just a single core of the Intel i7 2.6ghz on a consumer grade NVMe SSD storage device (non-raid). A user only needs a 5TB/month internet data plan and a minimum connection speed of +20 mbps (over 100mbps is the average in the United States as of 2020) to be able to track the latest blockchain fast enough to kep up to date within ever 5-10 minutes (ie: less time than the next confirmation). Since the user is only indexing the shard of the UTXO set (as described in an algorithm below), then storage and indexing is negligible and will grow strictly as a function of their own need for retention of that data.

We envision a world where "Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification". Even if all blocks filled up 1GB with 3M transactions each forever starting now, then every business could still easily obtain the immutable block headers, download the latest block by blockhash and then set a single core of their laptop to sync each block within about 2-3 minutes. They would only store the UTXO set and index for their wallets, business data and transactions only. This would be in some RDBMS or fast KV store for easy and efficient access. We built one internally and this paper is the culmination of that research and development.

Even 10GB blocks (30 million transactions) every 10 minutes is only 50TB of bandwidth a month and 99.9999% of that data is not relevant to the business/user, so their index and storage size is small and will scale easily using traditional web technologies. Parallelize the code to 10 cpu cores and 10GB blocks can be processed by a higher end desktop computer today in under a minute or two.

The result will be that disparate, cooperative and even competing agents can "telepathically" communicate arbitrary application state and be 100% absolutely sure there was no forgery nor double-spends to the exact same degree as a mining node itself knows, the computations' forward evolution will be actually backed by proof of work because it's using the native satoshi token history itself. SPV now also works as expected for application state, finally.


This paper introduced a novel service framework "Bitcoin Agent" and acts as an "on-chain" agent operating at zero overhead compared to a Bitcoin mining node itself. This framework and approach of using the satoshi token itself as the "state transition mutex" that carries the value and computation forward now provides application developers the ability to achieve consensus in a fully reproducible, deterministic and tamper resistant manner.

Additionally, we introduced a new Bitcoin digital asset protocol "SimpleAsset", a non-fungible token specification, for the purposes of demonstrating and analyzing the concept in greater detail.

Our internal preliminary results show that Bitcoin Agents can easily handle and blocks of sized 1-10 GB on a standard desktop computer with at least +20 mbps internet connection and storage just adequate for their own asset tracking. We have not even tested using more than 1 CPU core, as there is no difficulty in processing 3 million transactions in under 3 minutes. Bitcoin fundamentally scales because of the UTXO model and it is trivial to parallelize to multi-core systems.

It was Satoshi's "vision" all along to have businesses and users running their own indexer and store their own chains of digital signatures. It never really hits a scaling ceiling.