What is ColliderScript? - Bitfinex blog
24443
post-template-default,single,single-post,postid-24443,single-format-standard,bridge-core-3.0.6,et_bloom,qode-page-transition-enabled,ajax_fade,page_not_loaded,,qode-title-hidden,qode_grid_1300,footer_responsive_adv,qode-content-sidebar-responsive,qode-child-theme-ver-1.0.0,qode-theme-ver-29.3,qode-theme-bridge,qode_header_in_grid,cookies-not-set,wpb-js-composer js-comp-ver-6.10.0,vc_responsive

What is ColliderScript?

ColliderScript introduces a method for implementing covenants on Bitcoin, which could enhance Bitcoin’s functionality. Covenants aim to allow for more complex transaction conditions, governing how and when Bitcoin can be spent. It does this by using 160-bit hash collisions, allowing transactions to enforce conditions on future spending without requiring a soft fork. Unlike other proposals, ColliderScript leverages existing opcodes, sidestepping the need for consensus-driven protocol changes, which makes it flexible but computationally expensive. While this technique provides a proof of concept for covenants on Bitcoin, its high resource demands currently limit practicality. However, with further optimisation, ColliderScript could advance Bitcoin’s programmability and encourage broader discussions around covenant adoption in Bitcoin’s scripting environment. 

How Could ColliderScript Covenants Improve Bitcoin?

ColliderScript introduces a potential pathway for enhancing Bitcoin’s functionality by implementing covenants, which allow for more complex transaction conditions on the blockchain. Covenants specify rules around how and when bitcoins can be spent in the future, effectively broadening Bitcoin’s scripting language to support new use cases like restricted wallets and vault mechanisms. ColliderScript’s approach bypasses the need for a soft fork by using 160-bit hash collisions, allowing covenants to function within Bitcoin’s existing infrastructure, without lengthy debates in an effort to sway consensus. This method sidesteps the need for protocol changes, which can be controversial and slow-moving due to Bitcoin’s decentralised governance. By keeping within the bounds of Bitcoin’s current opcodes, ColliderScript offers a technically feasible path for covenants, albeit one that requires a lot of optimisation to become practical.

Bitcoiners see several use cases for covenants, particularly around security and layered network efficiency. Covenants could enable “vault” wallets, where funds are held in a secure account with strict conditions on withdrawal. This structure would allow users to set time delays on transfers or restrict transactions to specific addresses, enhancing Bitcoin’s security features. In addition, rate-limited wallets could help prevent unauthorised transactions by imposing spending limits, offering a layer of protection that is currently challenging to implement natively on Bitcoin. These covenant-enabled wallets and vaults could appeal to users who want greater control over their funds, especially those managing large amounts or handling assets in custodial capacities.

Beyond improving security, covenants hold potential for improving efficiency in Bitcoin’s layer 2 ecosystem, especially on secondary layers like the Lightning Network, Ark, or BitVM. By imposing specific rules on Bitcoin transactions, covenants could streamline processes in multi-party and time-sensitive transactions, reducing the operational complexity required for these systems. For instance, covenants could aid in transaction batching or in ensuring that payments follow predetermined channels, making it easier to create scalable and efficient solutions atop Bitcoin. This could, in turn, lower transaction costs and enhance the reliability of the network for users relying on these layer-2 solutions for faster and more affordable transactions.

Covenants in Bitcoin will enable a range of smart contracts that allow for more sophisticated control over how transactions are processed and funds are spent. They can facilitate time-locked or conditionally limited wallets, where funds are only accessible under specified circumstances or time frames, making them useful for applications like inheritance wallets or automated escrow services. Covenants can also enable multi-signature wallets with custom rules on transaction limits, which is valuable for business accounts that require controlled spending. These capabilities make covenants a powerful tool for creating programmable conditions on Bitcoin, similar to certain functionalities found in Ethereum smart contracts, but tailored to Bitcoin’s security and scripting environment.

Despite the potential improvements, ColliderScript covenants face practical challenges, primarily due to their high computational cost. As ColliderScript relies on collision-finding techniques, its current model demands considerable processing power, making it too costly for widespread adoption without further optimization. However, even as a proof of concept, ColliderScript could accelerate interest in covenant functionality by demonstrating their utility and feasibility within Bitcoin’s scripting constraints. This research could ultimately contribute to community discussions and potentially support a future protocol upgrade, should stakeholders decide that covenants warrant a more efficient, integrated solution in Bitcoin’s code.

Can ColliderScript Improve Bitcoin’s Programmability Without a Fork?

ColliderScript leverages 160-bit hash collisions, specifically using SHA1 and RIPEMD hash functions, to achieve these covenants in Bitcoin’s existing scripting environment. This technique involves creating an “equivalence check” that allows data processed in Bitcoin’s Small Script to mimic data processed in Big Script. By bridging these two parts of the Bitcoin scripting language, ColliderScript opens a pathway to implementing covenants without modifying Bitcoin’s consensus rules.

One significant advantage of ColliderScript is that it bypasses the need for a soft fork, a challenging process requiring broad community consensus. Other proposed covenant methods, like OP_CAT and OP_CTV, mandate changes to the Bitcoin protocol itself, introducing operational and social hurdles. ColliderScript, on the other hand, relies solely on existing opcodes and hash functions, thereby avoiding the risks and delays associated with protocol updates. This independence from consensus changes provides flexibility and allows developers to explore and potentially implement covenants directly on the current network.

It’s not perfect, ColliderScript also has notable limitations. Its current implementation is computationally expensive, potentially costing millions of dollars in computational resources to execute. The approach relies on collision-finding, which requires significant computational power, and transactions using ColliderScript demand a considerable amount of memory and processing time. These high costs make ColliderScript impractical for widespread use in its present form. While the ColliderScript method demonstrates the feasibility of covenants on Bitcoin, these resource-intensive demands may deter adoption without further optimisation.

ColliderScript represents an important proof of concept for future developments in Bitcoin programmability. Despite its current limitations, improvements in hardware or optimised algorithms may reduce the cost of implementation, making ColliderScript more viable. This research also serves as a foundation for ongoing discussions around covenants in Bitcoin, potentially accelerating the soft fork process by highlighting covenants’ utility and practicality. ColliderScript thus plays a dual role in advancing Bitcoin’s technical capabilities and fostering community dialogue around evolving the Bitcoin scripting language.

What are the Potential Tradeoffs to Adding Covenants in Bitcoin?

While ColliderScript introduces new programmability to Bitcoin through covenants, it also opens the door to potential risks and unintended consequences that could impact Bitcoin’s core principles. Covenants allow users to embed spending restrictions within transactions, which could, under certain implementations, restrict how and when bitcoins can be spent. Although designed with flexibility in mind, such restrictions could lead to scenarios where Bitcoin’s fungibility and freedom of use are compromised. This programmability may create opportunities for restrictions that Bitcoin users do not expect or want, potentially undermining Bitcoin’s role as an open and permissionless form of money.

One significant risk is the possibility of making Bitcoin “expireable” through covenants, a characteristic associated with Central Bank Digital Currencies (CBDCs) where funds can be set to expire after a certain period. Covenants could be configured to prevent a transaction from executing beyond a specified time limit, meaning that bitcoins could effectively expire if certain conditions aren’t met. This could harm Bitcoin’s fundamental value proposition of being an unrestrictive, censorship-resistant, durable store of value. By enabling “time locks” in spending covenants, it’s conceivable that some bitcoins could be programmed with expiration dates, turning them into a tool that enforces forced spending or devaluation, potentially diminishing users’ long-term trust in Bitcoin as a stable digital asset.

Another potential concern is the ability of covenants to restrict Bitcoin from being used for specific types of purchases. Covenants allow for spending rules to be written directly into transactions, meaning that coins could be made “non-spendable” for certain categories of goods or services. This could lead to a fragmented ecosystem where some bitcoins are restricted from particular uses, making Bitcoin less fungible and thus deviating from its original purpose as a universally usable digital currency. Over time, if widely adopted, such restrictions could create a precedent for more controlled or monitored spending, potentially making Bitcoin susceptible to limitations more commonly associated with regulated digital assets or state-controlled currencies.

A primary concern is that covenants might enable increased surveillance capabilities by encoding tracking mechanisms directly into transactions. For instance, specific covenants could enforce a chain of custody, where each successive transaction retains a record of its past holders or restricts future transactions to known, whitelisted addresses. This could create a de facto surveillance layer, reducing the pseudonymity and privacy Bitcoin currently affords.

Another risk is the potential for creating “blacklisted” bitcoins, or coins marked as unusable for certain recipients or regions. If covenants gain traction in scenarios where regulatory or compliance rules are embedded in transactions, bitcoins could become subject to restrictions based on geographic location, identity, or other arbitrary factors, resulting in decreased financial inclusivity. Additionally, the risk of “covenant proliferation” exists, where coins could become embedded with so many conditions that they become unusable or difficult to spend freely, creating liquidity issues or burdensome complexity in the Bitcoin ecosystem.

Lastly, covenants could pave the way for “socially enforced” restrictions if consensus emerges around certain use cases. For example, some might advocate for covenants preventing bitcoin from funding certain activities or political causes, leading to a form of soft censorship. This would conflict with Bitcoin’s principle of neutrality and could lead to a fragmented ecosystem where different factions implement and enforce competing restrictions. These risks illustrate that, while covenants add valuable functionality, their design and use must be carefully considered to preserve Bitcoin’s role as a decentralised, open financial tool.