The State of Bitcoin Development

As Bitcoin adoption grows through treasury companies and ETFs, self-custody is increasingly critical to mitigate risks from crime and policy changes, while the network’s limited scripting—two core functions (hashed timelocks, multi-signatures) and three states (UTXO, OP_RETURN, SIGHASH)—forms the foundation for custody, escrow, swaps, Lightning channels, and sidechains. Data consensus exists only for Bitcoin itself, making off-chain interpretation necessary for SIGHASH, where larger non-Bitcoin assets like stablecoins or art often reside—seen by some as corruption and others as a trustless alternative to custodial systems. Programmatic use relies on HTLCs and DLCs (with oracles), while multisig evolves via MPC, and covenant upgrades could boost security without adding Turing-completeness. Innovation continues in meta-protocols and L2s, with notable projects like Alkanes, RadFi’s Trading Wallet, and Arch’s decentralized oracle compute network advancing Bitcoin’s role as modern sound money.
The State of Bitcoin Development

As a whole wave of treasury companies launch and ETFs take off, it becomes ever more prudent that both these entities and individuals retain custody and control over their bitcoin at the risk of concentrating risks from criminal activity to changes in government policy. Bitcoin development must accelerate to meet the demand for Bitcoin to serve its role as modern sound money. This is a quick review from my own learnings about where we are currently at, how and why we got here, plus where we’re headed.

All programming can be boiled down to three functions: state, function and loop. State is the data or input, function is what you can do with that input and loop lets you set which conditions will cause repetition. If a system has all three, it is considered Turing-complete and capable of computing anything given enough time and energy. Bitcoin has state and function, but in extremely limited options. It does not have loops and therefore is not Turing complete.

The 2 functions:

  • hashed timelocks
  • Multi signatures

These allow programmatic and shared custody approaches to escrow, swapping, inheriting, locking and unlocking of Bitcoin.

Lightning channels and side chains all use these core primitives in different ways to represent Bitcoin on their networks.

The three states:

  • UTXO
  • OP_RETURN
  • SIGHASH

All data on Bitcoin is encrypted and cannot be understood without consensus about what it means. The Bitcoin protocol ensures consensus for only one thing - Bitcoin. This means SIGHASH is only used for verification and can be discarded while UTXO and OP_RETURN data is all that you actually need and is kept by consensus so it cannot be lost or corrupted except through an attack on the network.

Every block has the capacity for 1MB of 250 4KB UTXOs or OP_RETURNs, and 3MB of SIGHASH.

Signature data can be lost but many archival nodes that provide forensic intelligence and blockchain explorer data find them useful to keep. This means you need offchain consensus or custom technology to parse and understand what is being stored in SIGHASH. Anything non-Bitcoin that gets put on Bitcoin whether it’s art, memecoins, birth certificates or stablecoins that are bigger than 4KB effectively get printed on the SIGHASH. This is all fiat on Bitcoin. Some people think it corrupts Bitcoin but I find it to be the most effective way to use Bitcoin in a trustless manner. It minimizes the risk of losing Bitcoin if I’m trading with a stablecoin representation in SIGHASH vs giving my Bitcoin to Blockstream and Liquid to trade to L-USDT.

So then how do you trade if there are only 2 functions on Bitcoin? Multisig is generally non-programmatic and you rely on third parties. However, multi-party compute (MOC) technology is being developed that allows offchain key management in programmatic ways. Still, it’s the more limited function. As for HTLC, you lock Bitcoin in a programmatic way and design an off-chain “oracle” to run additional functions with additional states and spit out whether your BTC should remain locked, be returned, or given to another address you allowed for. When it’s programmatic with an oracle, you call it a DLC (Discrete Log Contract). Otherwise, as in the case with lightning where all opening and closing is signed, it’s a HTLC (Hashed Time Lock). People have been proposing several upgrades to Bitcoin protocol consensus to retain some parts of the SIGHASH in a way that will improve the security of both of these functions (generally referred to as covenants) but we have yet to agree upon the best solution or even whether it’s necessary or not. Overall everyone is agreed that looping and Turing completeness should not be allowed.

Meanwhile, developers are continuing to innovate with indexing consensus technologies (from simple meta-protocols to full on layer 2 chains) to achieve the use cases they need for trading pools, lending, payment streaming, escrow, gaming, art, micropayments.

I’m most interested today in the Alkanes protocol by OYL Corp, and Trading Wallet protocol by RadFi. Both are built on, or with reference to Casey’s work with the Ordinals meta protocol, light pools, and fully embrace PSBTs and browser wallet infrastructure. I’m also looking forward to the decentralized oracle compute network that Arch is launching. All of them will be strengthened by covenant upgrades but don’t need them. Most L2s will either piggy back off them or wait for covenant upgrades.

If anything here is not accurately stated, kindly correct with comment or message me!


No comments yet.