diagram showing hash algorithm to hash value

Craig Wright’s recent blog explains digital signatures and identity in Bitcoin

Dr. Craig Wright recently released a blog post explaining the first sentence of the Bitcoin white paper in detail. Now, he has released another explaining the second sentence. This essay is about digital signatures and identity and the crucial role they play in the Bitcoin system. You can read the post here.

The second sentence of the Bitcoin white paper

Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending…

Dr. Wright reminds us that the Bitcoin white paper states clearly that a digital signature algorithm is needed to “prevent the deployment of trusted third parties or alternative systems.” He points out that in BTC, such alternative systems have been deployed, specifically naming the Lightning Network and SegWit as examples. These systems have reintroduced the need for a third party.

Reminding us that the Bitcoin white paper says that digital signatures form part of the solution, Dr. Wright also tells us that they are not new. He cites Wayner (1996) and points to the multiple other forms of digital or electronic cash that existed over a decade before Bitcoin.

“One of the solutions from this time involves signature-only public-key systems,” he says. Defining these in greater detail, he explains that such systems can be used to verify signatures but not to encrypt them so as not to annoy governments that want to control the use of encryption. By contrast, blinded digital signatures can be used to create anonymous cash.

Dr. Wright again reminds us that digital signatures are only part of the solution, as stated in the second sentence of the white paper. Many other elements of the system are needed to make it function and keep it secure. He maintains that some of the benefits of the Bitcoin system remain misunderstood, reminding us that it is primarily a micropayment system. It aims to enable electronic cash to be distributed in “small, casual transactions.” 

For larger transactions, rules around money laundering and other financial transaction rules require the use of intermediaries. As Bitcoin is cash-like, he says we need to use the same rules that exist for cash transactions. However, unlike cash, Bitcoin is completely traceable, and transactions for large amounts can be monitored and reported easily. He points out that the white paper clearly states, “[a]ny needed rules and incentives can be enforced with the consensus mechanism.”

What is a digital signature?

Dr. Wright begins his explanation of digital signatures by pointing out that the definitions and requirements related to them (and identities) are documented by Brazell (2018). In his work, Brazell highlights the standards, technical requirements, identity issues, and jurisdictional challenges associated with digital signatures in a global context. Dr. Wright reminds us that identities are an essential part of the solution in the new privacy model enabled by Bitcoin. While the public can see somebody sending information, they can’t link it to anyone, he points out.

This model does not remove the need for identities but allows two parties to exchange identities at the level needed as and when required. Giving the example of someone paying for coffee, Dr. Wright paints a picture of how the coffee shop can present an invoice that reveals the business identity, whereas the buyer can be treated as someone paying in cash. The transaction level dictates how much information needs to be revealed and by whom, he tells us. None of this information has to be on-chain.

Dr. Wright also points out that signatures can always be repudiated. Therefore, Bitcoin can function as cash for small, incontestable values where the cost of seeking to repudiate the transaction exceeds the amount exchanged. For amounts under $10,000, there’s little possibility of recovering funds as, even in a small claims court, the cost of doing so will likely exceed any benefit gained. However, for large amounts, he reminds us that it’s possible to form a strategy to alert nodes to reject blocks that have been frozen by court order.

One such strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user’s software to download the full block and alerted transactions to confirm the inconsistency – Wright, 2008 

Giving an example, Dr. Wright explains that creating a block that allows a transaction from a frozen UTXO would be considered invalid. This process can be automated, making it easy for nodes to take action regarding criminal funds or money frozen by court order. Delving deeper, he explains that this process is completed in two steps: the freezing and reallocating of funds. Since non-repudiation is not possible in electronic systems, it requires a court-based legal process. He emphasizes that the Bitcoin white paper does not say that the system protects “possession.” Instead, it says it protects “ownership.” That’s a key difference.

Bitcoin as an electronic cash system and the necessity of identities

Dr. Wright reminds us that the main benefits discussed in the Bitcoin white paper are related to its use as electronic cash. He tells us that when there are third parties, requirements related to access and use mean it’s more expensive than what can be delivered in Bitcoin. In these cases, we end up not with the “small casual payments” Bitcoin is capable of, but with the digital gold system that is “expensive and less effective than banks and the existing financial infrastructure.” 

Digital cash was always the holy grail of the internet, he says. However, Bitcoin is different from other attempts, such as eCash (Chaum), in that it does not attempt to present an anonymous, untraceable system. Instead, it presented a pseudonymous/private system that maintains traceability. 

Bitcoin, unlike the others, does not mitigate the need for identity. In fact, digital signatures require an identity, Dr. Wright reminds us. Referencing the relevant laws, he tells us that the UNCITRAL Model Law on Electronic Signatures (2001) formed the foundation of digital signature legislation worldwide, including in the USA and the U.K. European laws also follow the model law. He tells us that a key function of a digital signature includes “identifying the author or sender of a document.” He emphasizes the difference between digital signatures and the digital signature algorithms that provide the capability to create them.

Webs of trust

Dr. Wright says that identity can be provided through certificate authorities and public key infrastructure for high-value transactions. For low-value transactions, we can create “webs of trust.” In these cases, detailed information about identities is not required, or identities can be partially exchanged. Again, this will be decided by the size of each transaction.

Webs of trust allow users to decide for themselves who they trust (or not). As for what happens when an individual wants a refund after purchasing a small-value item using Bitcoin, Dr. Wright explains that it’s not that different than using cash—it’s up to the users to request one and negotiate accordingly. 

Bitcoin is not digital gold—It’s electronic cash

Speaking more about the digital signature system referenced in the Bitcoin white paper, Dr. Wright explains that keys may be derived using the homomorphic properties of ECDSA, allowing subkeys to be created (Wright & Savannah, 2022). This system maintains identity but also makes the broadcast of keys across the blockchain network publicly traceable while not directly or publicly linking the individual’s identity. This allows for traceability while enabling small, casual transactions to remain hidden from the world.

Dr. Wright once again emphasizes that Bitcoin has been falsely promoted as digital gold when it contains no such properties in reality. In actuality, the benefits explained in the white paper are related to minimizing transaction sizes. He explains that Bitcoins scales and has value as a payment system. It solves key problems associated with digital cash and electronic commerce that have been discussed for decades.

Talking more about the white paper, he points out that it does not mention decentralization. In section two, it says that ​​”[a] common solution is to introduce a trusted central authority, or mint, that checks every transaction for double-spending.” He explains that Bitcoin removed the need for a central issuing authority by automating the process. All Bitcoin tokens were issued in 2009, and the distribution process was automated. Instead of a central authority, multiple different competing organizations audit and check each other. 

Additionally, any user can view and audit transactions, and senders and recipients such as Alice and Bob can validate their own transactions and maintain evidence of changes. He emphasizes that this is a crucial component of the Bitcoin system; using SPV, individuals can check and maintain the number of tokens they own, validate them, and ensure that nothing has been altered. Bob can validate the input transaction from Alice without keeping a copy of the entire blockchain.

Referring to his previous article explaining peer-to-peer transactions, Dr. Wright explains how BTC Core developers have removed the decentralized aspect of Bitcoin by removing them. He reminds us that it is not decentralized because of nodes but because individuals can communicate directly without using nodes. Nodes do not serve as the primary method for disseminating and distributing transactions, he says once again, but rather they timestamp and index direct transactions between Alice and Bob.

Let more about with Bitcoin Primitives: Digital Signatures here.

New to Bitcoin? Check out CoinGeek’s Bitcoin for Beginners section, the ultimate resource guide to learn more about Bitcoin—as originally envisioned by Satoshi Nakamoto—and blockchain.

[id^="_form"]
[id^="_form"]
[id$="_submit"]
[id$="_submit"]
[^;]
[^;]
[?&]
[?&]
[^&#]
[^&#]
[(d+)]
[(d+)]
[elem.name]
[elem.name]
[+_a-z0-9-'&=]
[+_a-z0-9-'&=]
[+_a-z0-9-']
[+_a-z0-9-']
[a-z0-9-]
[a-z0-9-]
[a-z]
[a-z]
[el.name]
[el.name]
[id^="_form"]
[id^="_form"]
[id$="_submit"]
[id$="_submit"]
[^;]
[^;]
[?&]
[?&]
[^&#]
[^&#]
[(d+)]
[(d+)]
[elem.name]
[elem.name]
[+_a-z0-9-'&=]
[+_a-z0-9-'&=]
[+_a-z0-9-']
[+_a-z0-9-']
[a-z0-9-]
[a-z0-9-]
[a-z]
[a-z]
[el.name]
[el.name]