Open letter to core devs (reflections/questions from the op_return saga and proposal to establish a well-organized channel/link between devs and users)

The recent changes in Bitcoin, such as OP_RETURN, full-RBF (Replace-By-Fee), and minrelaytxfee adjustments, stem from the realization that limitations failing to deter unwanted behaviors, while encouraging more problematic workarounds, are counterproductive. Specifically, the persistence of the OP_RETURN limit does not halt the embedding of data within the blockchain, as users circumvent this through alternative methods like ordinals. Allowing data storage via OP_RETURN for modest amounts of information benefits both the network by avoiding unnecessary transactions for data revelation and the users by providing a simpler method for embedding data, without straining the blockchain with arbitrary limits constrained by the maximum transaction size.

Moreover, discrepancies between node mempool policies and miner actions exacerbate issues within the Bitcoin network. When nodes impose policies not adhered to by miners, such as enforcing specific RBF flags or minimum transaction fees, or limiting OP_RETURN data sizes differently than miners do, it leads to a disconnection between expected and actual block content. This misalignment significantly hinders compact block propagation, slowing down the entire network. The point is underlined by the observation that most miners had already been disregarding these node-enforced limitations to various extents.

In addressing the broader challenges of communication within open-source projects, it's noted that coordinating among loosely connected volunteer developers often results in lost or diluted messaging. Despite these hurdles, those keenly interested in Bitcoin's technical evolution have access to numerous resources, including mailing lists and forums well-equipped to shed light on the rationale behind recent changes. Direct examination of discussions and updates on platforms like Github also provides deeper insights, contrasting with less productive debates seen on social media platforms.

Lastly, an analysis of Bitcoin nodes using BitNodes reveals significant disparities in node representation. A substantial portion of nodes identified with “Knots” in their subversion are operating over Tor, with suggestions that many might be duplicates due to the ease of creating multiple onion addresses linked to a single node. Among the much smaller number of Knots nodes running on IPv4, there's speculation on whether these are newly deployed or converted from Core nodes, especially given the rapid adoption of a recently released version by approximately half of these Knots nodes. This scenario hints at the possibility of a limited number of individuals managing a significant fraction of these nodes, further complicating the landscape of Bitcoin's decentralized network infrastructure.