Defining protocol

Getting your Trinity Audio player ready...

This article was first published on Dr. Craig Wright’s blog, and we republished with permission from the author.

The Transmission Control Protocol (TCP) of the internet has functioned for decades. It was originally constructed using the statements by Postel of how the protocol should be constructed in 1981 (1981). The latest document concerning TCP is RFC 9293 (Eddy, 2022). Of course, you could make the argument that TCP is not fixed, because there are updates that have occurred. But if you did, you would be in error. While certain documents update the protocol, they are not changing the underlying structure, but rather adding clarifications of how the various systems implementing the protocol should act.

When TCP was first released, the implementation of areas that were listed as “should” rather than “must” in the protocol was handled differently by different vendors. This led to issues such as “reset handling while in the SYN-RECEIVED state” (Eddy, 2022) being represented differently in different platforms. The protocol was not changed; rather, additions have refined the methodology used to handle packets. In the past, the implementation by vendors would lead to different outcomes. Some machines would be less interoperable than others.

The structure of the network has been improved through the discovery of problems and the clarification of how each of the network protocol components should be applied. While differences will still continue to exist, and as we discover new hardware and software and scale networking, new problems will develop, and new clarifications will need to be issued, such clarifications are not protocol changes. Rather, they are fixing the areas that were not defined adequately and that allowed lenders to implement solutions differently.

The same applies to Bitcoin. The protocol is fixed. Yet, its development still requires the interaction and update of the system. New operating systems will be developed. New network structures will evolve. The distinction here is that a transaction created in 2010 should still be valid and able to be added to the network if it is only sent in the year 2150. Such is the true nature of a fixed protocol. The Bitcoin white paper (Wright, 2008, p. 8) explicitly says, “Any needed rules and incentives can be enforced with this consensus mechanism.” It is not a right for developers to change the protocol, but rather presents a necessity to implement the original protocol and ensure each function is available.

To some extent, this ensures that OP_Codes are functional and work securely. Additionally, structures that ensure the safe operation of simplified payment verification (SPV) clients must be implemented. The Bitcoin white paper (Wright, 2008, p. 5) notes that protections can be implemented against invalid blocks or ‘double-spends’ where “[o]ne strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block.” This functionality was not available in 2009 when Bitcoin launched. Yet, the structure of the system was robust enough to facilitate such a development and implementation. While the nature of the protocol was not defined in detail, a broad-brush argument for the ability to enforce legal requirements and to alert users was already noted within the Bitcoin white paper.

As for the continuing development of TCP, RFC 793 remains valid, but the interpretation of the document has been refined and continues to be refined up to and including the descriptions posted in RFC 9293. When created using an old machine with the TCP stack from Winsock issued in 1984, such packets will work on the existing internet. The difficulty is that some of the machines will be far less efficient and not be able to handle the volume of traffic that a machine with a more refined version of TCP will process. The same will apply to Bitcoin.

Governance Issues

In 2010, the original concept for the Bitcoin Foundation was developed. While the organisation took years to launch properly, the concept was meant to be analogous to the process used within the internet standards committees that manage the RFCs. This is a process like one run by the IEEE or IEFT. Yet, it is not a system about decentralised power, but rather one that structured a secure and stable protocol designed to grow and act as a framework for internet commerce.

More importantly, it would act as an independent body that would interact with the various vendors that would start to develop. For instance, internet stacks are produced by a multitude of companies. Cisco, Juniper, Microsoft, and IBM all maintain their own separate TCP/IP stacks. In addition, Google and various phone manufacturers, including Apple, produce TCP/IP stacks based on software each company develops independently. Yet, for the most part, they work together. Where problems occur, updates refining the standard, such as RFC 9293, are issued to ensure that problems that may infrequently develop are sorted and people know how the ongoing development process will be structured.

A similar system should exist with Bitcoin, which is what I hoped to develop with the Bitcoin Association. It is not a system I run but one that will allow vendors and other parties to create and disseminate layers within Bitcoin. Layers are transactions inside transactions. This is analogous to how TCP is encapsulated within IP. Equally, central bank digital currencies (CBDCs), asset tokens, and much more will be developed and issued inside an underlying Bitcoin transaction.

The requirement of a stable platform in internet protocols differs from the implementation of benevolent dictatorship, which is analogous to the Linux model and has been applied to systems such as BTC Core (Azouvi et al., 2019). While this had led to claims of ‘censorship resistance’ and authors saying that “[i]n a decentralized system, no one entity can act to censor transactions or prevent individuals from joining the network” (Azouvi et al., 2019, p. 1), such assertions are false. Such a concept is premised on the ‘cypherpunk’ ideal of political decentralisation, and is radically different to the concept of network decentralisation, such as that produced by Baran (1964) with the introduction of packet-switching networks.

While the statement is made that “[i]n theory, each peer in the network has a “vote” proportional to their computational power, which is used to seal transactions into the ledger” (Azouvi et al., 2019, p. 1), the claim is intentionally misleading. Rather, nodes vote on the order of transactions—refusing to work on invalid transactions, such as those that are ‘double-spent’ (Wright, 2008). The peers and such a network are limited to large commercial operations and do not fulfil the cypherpunk ideal of a wide variety of individuals acting outside government control. Rather, the design of systems such as Bitcoin creates an incentive structure that necessarily leads to developing server farms that act as nodes. Such systems are large enough to be monitored and for the imposition of legal frameworks to apply.

Other researchers (Filippi & Loveluck, 2016) confuse the nature of trusted third parties with all trusted authorities. The Bitcoin white paper explicitly notes that “no mechanism exists to make payments over a communications channel without a trusted party” (Wright, 2008, p. 1). As such, Bitcoin hasn’t replaced the need for trusted parties, but has introduced a means of mitigating the necessity to involve trusted third parties or internet intermediaries in providing “small casual payments.” Such an innovation allows for the creation of a system that provides micropayments. With small casual payments, “non-reversible payments for non-reversible services” may be offered (Wright, 2008, p. 1). Such an offering excludes payments that would come under anti-money laundering (AML) or know your customer (KYC) requirements, as they would necessitate validating identity.

While Filippi and Loveluck (2016) capture some of the issues that occurred with the early development of Bitcoin, they falsely promote the nature of the system as one of a governance structure that is volunteer-driven and that they seek to self-organise (Filippi & Loveluck, 2016, p. 9). The maintainers associated with BTC Core are limited, and hold sway over which patches can be applied in a “benevolent” form of dictatorship that is arguably anything but benevolent. The process necessitates implementing changes, and despite the claims of not being involved in decision-making, the implementation of segregated witness (SegWit), despite the majority of nodes voting against it, demonstrates how development decisions override any community desire.

Other researchers have likened the control of blockchain networks such as Bitcoin or the BTC network to that of the internet and the domain name structure (Musiani et al., 2016). In a common form, the authors misrepresent the peer-to-peer nature of Bitcoin and falsely argue that each system connected as a node must be a node of the system even if it does not engage in the consensus process. This error remains common. Other researchers assume that technology can shape governance (Reijers et al., 2016). In analysing the structure of how Bitcoin governance works, the authors have erroneously argued that BTC Core changes are based on a voting system and have failed to investigate such claims.

While other authors (Walch, 2020) have noted the discrepancies in such assertions, the majority of researchers overlooks the technical flaws with such an argument because of the amount of money that flows within the ‘blockchain communities.’ Unfortunately, such a willingness to sell out truth for short-term gains seems to be an ongoing societal problem. Yet, the scenario will change as the judicial system starts to understand Bitcoin and other blockchain networks at a deeper level, because of the cases set to be heard in the coming months and years. Unfortunately for them, many individuals who have accepted payouts from organisations seeking to avoid legislative controls will understand the concept promoted by Timothy Wu (2003) decades earlier, when he explained that code was not law.

References

Azouvi, S., Maller, M., & Meiklejohn, S. (2019). Egalitarian Society or Benevolent Dictatorship: The State of Cryptocurrency Governance. In A. Zohar, I. Eyal, V. Teague, J. Clark, A. Bracciali, F. Pintore, & M. Sala (Eds.), Financial Cryptography and Data Security (Vol. 10958, pp. 127–143). Springer Berlin Heidelberg. https://doi.org/10.1007/978-3-662-58820-8_10
Baran, P. (1964). On Distributed Communications Networks. IEEE Transactions on Communications, 12(1), 1–9. https://doi.org/10.1109/TCOM.1964.1088883
Eddy, W. (2022). Transmission Control Protocol (TCP) (No. RFC9293; p. RFC9293). RFC Editor. https://doi.org/10.17487/RFC9293
Filippi, P. D., & Loveluck, B. (2016). The invisible politics of Bitcoin: Governance crisis of a decentralised infrastructure. Internet Policy Review, 5(3). https://policyreview.info/articles/analysis/invisible-politics-bitcoin-governance-crisis-decentralised-infrastructure
Musiani, F., Cogburn, D. L., DeNardis, L., & Levinson, N. S. (Eds.). (2016). The Turn to Infrastructure in Internet Governance. Palgrave Macmillan US. https://doi.org/10.1057/9781137483591
Postel, J. (1981). Transmission control protocol.
Reijers, W., O’Brolcháin, F., & Haynes, P. (2016). Governance in Blockchain Technologies & Social Contract Theories. Ledger, 1, 134–151. https://doi.org/10.5195/ledger.2016.62
Walch, A. (2020). Deconstructing ‘Decentralization’: Exploring the Core Claim of Crypto Systems. In Papers.ssrn.com. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3326244
Wright, C. S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. SSRN Electronic Journal. https://doi.org/10.2139/ssrn.3440802
Wu, T. (2003). When Code Isn’t Law. Virginia Law Review, 89(4), 679–752.