Select Page

Counterparty Community Update / Ledger Fork

October 25, 2024

Community Updates

Recently the Counterparty 2.0 core devs released a new version of the counterparty-core software 10.4.0, which added some exciting new features (fair minting, atomic swaps, etc.) as well as some controversial changes that changed the way dispensers (vending machines) worked. While some of these changes were controversial, they were supposed to be fully backwards-compatible with the way previous versions of counterparty software operated to ensure ledger integrity.

These new changes went into effect at block #866,000, after which point, counterparty-core immediately went down due to an issue with some of the new UTXO functionality not working as expected. The Counterparty network remained down for 20+ hours, the longest downtime period in Counterparty’s 10+ year history. Eventually a new “hotfix” release was put out, and the “Counterparty 2.0” network began functioning again. However, additional issues continued to be found throughout the following weeks, and “hotfix” releases continued to be released in rapid succession in an attempt to deal with all of these regressions, bugs, scaling issues, and functionality loss.

Unfortunately, during this time a number of websites, services, and wallets failed to update to the newest versions of counterparty-core 10.XX (Counterparty 2.0), and continued generating transactions which were only see on one ledger (Counterparty Classsic). In addition, a specific regression inside counterparty-core release related to BTC Sends not automatically converting to dispense transactions, resulted in a number of transactions which were generated on the latest version of “Counterparty 2.0“, but failed to trigger dispenses on dispensers (vending machines). As a result, a number of users lost funds, and chaos ensued as dispenser operators had to try and coordinate returning funds to buyers who used “Counterparty 2.0” to buy from dispeners, sent BTC funds to the dispensers, but never received a token from the dispenser as expected.

Due to all of these factors, the Counterparty network experienced a ledger fork at block #866,000 and the ledgers continued to diverge for over 3 weeks as the Counterparty 2.0 core developers struggled to rectify the situation.

Contributing to the frustrations of a ledger fork and unstable software, was the loss of functionality on Dispensers (vending machines), where previously users were able to open up a dispenser on a new/empty address using only a single transaction, as well as close the dispenser in a single transaction and return funds to the `origin` address. In the new “Counterparty 2.0” versions, this functionality now required 3 transactions instead of 1, making dispensers much more expensive to operate and further frustrating many in the community who had come to rely on this simple functionality. Additionally, counterparty users lost the ability to do cheap Multi-Peer Multi Asset Sends (MPMA) due to the core developers depreciating P2SH encoding, and forcing users to use the more expensive and wasteful multi-sig encoding method. In addition, users lost the ability to do MPMA sends using separate memos, a feature which many in the community, including exchanges, had come to rely on for cheap asset distributions.

What is a ledger fork?

A ledger is a list of all transactions that occour on a blockchain, or in the case of Counterparty on a metaprotocol. Typically all transactions are interpreted the exact same by all versions of the software and all nodes write the same data to the ledger to maintain ledger integrity and avoid what is known as a ledger fork.

A Ledger fork occurs when 2 different versions of software interpret the same transaction differently, and different data interpretations are written to each ledger in different states. This different data being written to each ledger is referred to as a ledger fork.

What is a software fork?

A software fork is when a new version of software is released. The new version of software with the changes is always referred to as the “fork” or “forked” version, as it has made changes from how the software operated in the past, and “forked” away from how things used to operate.

In Counterparty great efforts have been made over its history to ensure that any “software forks” do not result in a “ledger fork”. This has been achieved by extensive testing of features in the new “forked” version of software, before release, to ensure that transactions are interpreted in a reverse-compatible way.

Additonal Information on the dispute between the “Counterparty 2.0” and “Counterparty Classic” communities.

A counterparty community member created the “UNITYXCP” token which does a good job of summarizing the key themes and tensions between the two communities which led to the ledger fork. The description of the UNITYXCP token is given below :

Summary of Key Themes and Tensions

  1. Legacy vs. Innovation:
    • Classic Supporters: Those aligned with Counterparty Classic value stability, backward compatibility, and decentralization. They see Counterparty’s original framework as a model of a user-driven, decentralized platform. Their concerns largely stem from a fear that too much modernization (and association with VC funding) could erode the community’s core principles.
    • 2.0 Advocates: The 2.0 team and supporters believe innovation is essential for Counterparty’s growth, advocating for new features like atomic swaps, replay protection, and venture-backed scalability. However, their rapid pace of change, lack of backward compatibility, and venture capital backing raise trust issues among classic users.
  2. Moderation and Governance Issues:
    • There’s growing frustration around moderation practices, particularly regarding censorship and bans on critical voices. Many in the community want a structured, community-based governance model to prevent unilateral decision-making and ensure all voices are respected.
    • Calls for Community Voting: The lack of a formal voting mechanism or a decentralized autonomous organization (DAO) has made many feel that major decisions are imposed by developers or individuals rather than by consensus.
  3. Usability and User Education:
    • Complexity of New Tools: Innovations like atomic swaps and replay protection are appreciated, but without adequate documentation or tutorials, they become inaccessible for less technical users. Many in the classic community miss the simplicity of dispensers and other familiar tools.
    • New User Onboarding Challenges: The lack of user-friendly interfaces and guidance hinders new user adoption, creating a gap between experienced members and newcomers trying to understand advanced tools.
  4. Transparency and Trust Concerns:
    • VC Funding Concerns: The association of the 2.0 team with venture capital is seen by some as a potential risk to the platform’s decentralization. There’s a worry that investor influence could prioritize profit over community needs, possibly compromising Counterparty’s ethos.
    • General Distrust: Both factions feel misrepresented or misunderstood by the other, deepening divisions and creating a polarized environment. This gap is worsened by perceived disrespect and dismissiveness in responses from either side.

Proposed Decisions to Unify the Counterparty Community

  1. Establish a Decentralized Governance Model (DAO) with Community Voting:
    • Creating a DAO or implementing a community voting system would empower users to have a voice in platform decisions, from technical upgrades to moderation policies.
    • This governance model could ensure that any changes, including major updates like 2.0 features, are backed by community approval rather than unilateral decisions.
    • Implementation: Develop proposals around critical issues—e.g., replay protection, backward compatibility, funding strategies—and allow the community to vote. Transparent voting results could restore trust and help find middle ground.
  2. Create a Clear Roadmap with Phased Rollout of Features:
    • A phased approach to implementing new features could balance classic users’ concerns with 2.0’s desire for modernization. A roadmap that highlights which updates will roll out and when, along with community feedback stages, could prevent sudden or divisive changes.
    • Backward Compatibility Considerations: Ensure key classic features, like dispensers, are retained or have modern equivalents accessible to both tech-savvy and less-technical users.
  3. Formalize Replay Protection and Security Standards:
    • Replay protection is a critical issue, and implementing it across both versions could safeguard users and simplify transitions between classic and 2.0 functionalities.
    • Shared Security Protocols: Formalize security standards that both the classic and 2.0 teams agree upon, reducing the risk of loss or confusion and aligning with the community’s safety needs.
  4. Implement User Education Initiatives and Tutorials:
    • New features like atomic swaps require robust tutorials and guides. Developing educational resources can empower users to better understand and utilize the advanced tools introduced by 2.0.
    • New User Resources: Create an onboarding kit or series of visual guides explaining Counterparty’s unique features. This would make the platform more accessible and improve user experience, fostering growth and retention.
  5. Enhance Transparency Around Funding and Development Goals:
    • To address concerns about VC influence, the 2.0 team could provide transparency about funding sources, goals, and how investor expectations align with the community’s decentralized ethos.
    • Investor Communication: Regular updates on funding use, investor influence, and the development timeline would clarify that Counterparty’s future remains community-centric, easing trust issues.
  6. Revamp Moderation Policies to Encourage Open Dialogue:
    • Revising moderation policies to allow respectful disagreement without fear of banning would encourage more open discussions, helping both factions feel heard and valued.
    • Community Moderators: Consider rotating community-nominated moderators who reflect both classic and 2.0 perspectives, fostering balanced conversations and reducing the risk of bias.

Conclusion

Counterparty’s path forward can balance innovation with its original decentralized values by establishing governance structures, prioritizing transparency, and fostering open communication. With a phased approach to feature rollouts, a strong user education initiative, and a respectful moderation framework, Counterparty could bridge the divide between classic and 2.0 supporters, creating a unified, resilient community that embraces both legacy and growth.

How does this effect Counterparty Users?

Due to the ledger fork continuing for so long, a number of wallets, explorers, and services have decided the best thing to do in this unfortunate ledger fork situation, is to provide tools to allow users to choose which version of the ledger they would like to interact with.

These ledgers have been named differently so that it is clear to users what ledger they are viewing and interacting with. The ledger forks are :

It is suggested that users stay on the latest version of Counterparty which is currently “Counterparty 2.0“. However, if you are a counterparty user and prefer to interact with the older version of the ledger, where dispensers, Multi-Peer Multi-Asset (MPMA) sends continue to function as they have for many years, you have the option to do so via “Counterparty Classic“.