{"id":19298,"date":"2019-09-21T13:00:15","date_gmt":"2019-09-21T13:00:15","guid":{"rendered":"http:\/\/ci027cfe67700126c3"},"modified":"2025-01-27T21:22:09","modified_gmt":"2025-01-27T21:22:09","slug":"discovering-bitcoin-part-6-digital-contracts","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/culture\/discovering-bitcoin-part-6-digital-contracts","title":{"rendered":"Discovering Bitcoin Part 6: Digital Contracts"},"content":{"rendered":"
<\/div>
<\/figure>\n

This is the sixth installment of bitcoiner Giacomo Zucco\u2019s series \u201cDiscovering Bitcoin: A Brief Overview From Cavemen to the Lightning Network.\u201d Read the <\/em>Introduction to his series<\/em><\/a>, <\/em>Discovering Bitcoin Part 1: About Time<\/em><\/a>, <\/em>Discovering Bitcoin Part 2: About People<\/em><\/a>, <\/em>Discovering Bitcoin Part 3: Introducing Money<\/em><\/a>, <\/em>Discovering Bitcoin Part 4: A Wrong Turn (New Plan Needed)!<\/em><\/a> and <\/em>Discovering Bitcoin Part 5: Digital Scarcity<\/em><\/a>. <\/em><\/p>\n

In Part 6 of this \u201cDiscovering Bitcoin\u201d series, we will build on the idea of using digital puzzles as a way to reproduce scarcity, and on the importance of a supply-control mechanism to grant some hardness to digital money, to explore concepts of proving ownership through signatures and scripts, and the technique known as CoinJoin.<\/p>\n

Proving Ownership: Signatures<\/h2>\n

Our Plan \u20bf<\/a> for money brings us, for the second time<\/a>, to focus on the topic of people and the question \u201cWho?\u201d<\/p>\n

You established the conditions for the issuance of new sats<\/a>, but what about their transfer? Who is authorized to change the data in the shared balance sheet, transferring ownership?<\/p>\n

If there was a central authority in charge of reassigning sats, following instructions by current owners (maybe logged in to the system with the classical username-and-password approach, like in your previous e-gold experiment<\/a>), there would be a Mallory-vulnerable single point of failure again: Why then even bother moving from physical gold to PoW-based \u201cdigital scarcity\u201d? If, on the other hand, each user had an equal right to reassign ownership, then your system could not work at all: Everybody would be encouraged to continuously assign other people\u2019s sats to themselves. You need some kind of consistent authority-defining protocol, which everybody could independently check.<\/p>\n

The solution is a cryptographic technique called a \u201cdigital signature.\u201d It works like this: First, Alice chooses a random number called a \u201cprivate key,\u201d which she will keep absolutely secret. Then, she passes this number through a special mathematical function, easy to apply in one direction but practically impossible to reverse. The result is another number called a \u201cpublic key,\u201d which Alice doesn\u2019t keep secret at all: Instead, she makes sure that Bob gets to know it. Finally, she passes the private key and the message through a second function, again difficult to reverse, which results in a very big number called a \u201csignature.\u201d A third and last mathematical function can be applied by Bob to the message, the signature and Alice\u2019s public key, resulting in a positive or negative verification. If the result is positive, he can be sure that Alice authorized that message (\u201cauthentication\u201d), that she will not be able to later deny that authorization (\u201cnon-repudiation\u201d) and that the message was not altered in transit (\u201cintegrity\u201d).<\/p>\n

<\/figure>\n

In a way, it\u2019s similar to handwritten signatures (thus the name), which are easy for everybody to check against some public sample, but difficult to reproduce without being the owner of the \u201ccorrect hand.\u201d Or to wax seals: easy for everybody to check against a public seal registry, but difficult to reproduce without the correct wax stencil.<\/p>\n

So, you change your protocol in order to make fractions of proofs of work independently reusable<\/a> via digital signatures. The first model you implement is trivial: Each user independently generates a private key and creates a public \u201caccount,\u201d labeled with the corresponding public key. When users want to transfer ownership, they create a message including their account, the receiving account and the amount of sats they want to transfer. Then, they digitally sign and broadcast the message, which everybody can verify.<\/p>\n

Interestingly enough, a similar scheme can be used by many renowned (yet possibly pseudonymous) developers to sign different versions of your software so that they can freely change, improve, fix, update, audit and review it, and any final user of your system can independently verify said signatures before running their preferred version, leveraging a network of minimized and fragmented trust, without a need for a single authority to centrally distribute the software. This process enables a true decentralization of code.<\/p>\n

<\/figure>\n

Script and \u201cSmart Contracts\u201d<\/h2>\n

You don\u2019t want to limit the conditions that every peer has to check, before accepting any change in the shared balance sheet, to mere digital-signature validity, though. <\/p>\n

You decide that each message can also include a \u201cscript\u201d: a list of instructions describing additional conditions that the receiving account (or accounts) will have to satisfy in order to spend again. For example, the sender could require a combination of several secret keys (in conjunction or disjunction) or a specific waiting time before spending. Starting from these very simple (and easy to audit) primitives, complex \u201csmart contracts\u201d can be built, making money effectively \u201cprogrammable,\u201d even in the absence of central parties.<\/p>\n

Darkness (and Scaleness) Problems<\/h2>\n

Unlike an encrypted messaging system (where if Alice sends Bob some messages, only Bob can read them), your scheme isn\u2019t really optimized for darkness (if Alice sends Bob sats, her message will have to be revealed beyond Bob \u2014 at the very least to those who will receive those same sats later on). <\/p>\n

Money circulates. Payees cannot trust any money transfer, even if properly signed, if they cannot verify that the transferred sats have actually been transferred themselves to that specific payer, and so on, upstream, back to the very first PoW-based issuance. With enough circulation of sats, active peers would get to know a huge number of past transactions, and forensic analysis techniques could be employed to statistically correlate amounts, timings, metadata and accounts, thereby deanonymizing many users and stripping them of their deniability. <\/p>\n

This is problematic: As discussed in Part 2,<\/a> darkness is a fundamental quality for money, both for economical and sociological reasons.<\/p>\n

Smart contracts make this problem even worse, since particular spending conditions may be used to identify particular software implementations or specific organization policies.<\/p>\n

This lack of darkness is more serious than the one that affected your previous e-gold experiment: It\u2019s true that, back then, you stored most transaction metadata on your central servers, but at least it was only you, as opposed to quite literally anybody (including many of Mallory\u2019s agents), who had access! Furthermore, you could implement some particularly advanced cryptographic strategy to make yourself at least partially \u201cblind\u201d to what was actually going on between your users.<\/p>\n

There\u2019s also a minor scaleness problem connected with this design: Digital signatures are quite big, and the chain of transfers that a payee needs to receive in order to validate everything would include many signatures, making validation potentially more expensive. Furthermore, account changes are quite difficult to validate in parallel.<\/p>\n

A New Paradigm: \u201cCoinJoin\u201d<\/h2>\n

To mitigate such problems, you decide to change the fundamental entities of your model from bank-like \u201caccounts\u201d to \u201cUnspent Transaction Outputs\u201d (UTXOs). <\/p>\n

Instead of instructions to move sats from one account to another, each message now includes a list of old UTXOs, coming from past transactions and \u201cconsumed\u201d as ingredients, and a list of new UTXOs, \u201cgenerated\u201d as products and ready for future transactions. Instead of publishing a single, static public key to be used as general account reference (like a bank IBAN or an email address), Bob must provide new, single-use public keys for each payment he wants to receive. When Alice pays him, she signs a message that \u201cunlocks\u201d some sats from some previously created UTXO, and \u201clocks\u201d them again into some new UTXO.<\/p>\n

<\/figure>\n

Just like with physical cash, spendable bills don\u2019t always match payment requests \u2014 change is often required. If, for example, Alice wants to pay 1,000 sats to Bob, but she only controls several UTXOs locking 700 sats each, she will sign a transaction consuming two of those 700-sats UTXOs (unlocking a total amount of 1,400 sats) and generating two new UTXOs: one associated with Bob\u2019s keys, locking the payment (1,000 sats), and the other associated with Alice\u2019s keys, locking the change (400 sats).<\/p>\n

Provided that people don\u2019t reuse keys for different payments, this design increases darkness in and of itself. But even more so when your users start to realize that UTXOs consumed and generated by a single transaction don\u2019t have to come from just two entities! Alice can create a message spending old UTXOs she controls and generating new UTXOs (associated with Bob), then she can pass said message to Carol, who can simply add her old UTXOs she wants to consume and the new UTXOs (associated with Daniel) she wants to create. Finally, Alice and Carol both sign and broadcast the composite message (paying both Bob and Daniel). <\/p>\n

This special use of the UTXO model is called \u201cCoinJoin.\u201d (Trigger warning: Within the actual Bitcoin history, this use wasn\u2019t Satoshi\u2019s design rationale for the UTXO model itself, but was discovered as a potential twist on said design by other developers, many years after the launch.) It breaks the statistical linkability between outputs, while preserving what is called \u201catomicity\u201d: Transactions are either entirely valid or invalid, thus Alice and Carol don\u2019t have to trust each other. (If one of them tries to alter a partially signed message before adding their own signature, the existent signature becomes invalid.)<\/p>\n

<\/figure>\n

There is a possible change to your system that may actually improve the situation even more: a different digital-signature scheme, alternative to the one you\u2019re using now, which is \u201clinear in the signatures.\u201d That means: In taking two private keys (which are nothing but two numbers), signing the same message with each and adding together the resulting signatures (which also are nothing but two very big numbers), the result happens to be the correct signature corresponding to the sum of the two public keys associated with the two initial private keys! <\/p>\n

This sounds convoluted, but the implication is simple: Alice and Carol, when CoinJoining, could add up their individual signatures and broadcast just the sum, which everybody could verify against the sum of their public keys! Since, as we said, signatures are the \u201cheaviest\u201d part of transactions, the possibility of broadcasting just one instead of many would save up a lot of resources. External observers would end up suspecting every transaction of being a CoinJoin, since many users could be after efficiency gains. This assumption would break most of the forensic heuristics.<\/p>\n

<\/figure>\n

Even without this further improvement, the UTXO model already somehow increases scaleness: Unlike state changes in the account model, it allows validation to be efficiently batched and parallelized.<\/p>\n

<\/figure>\n

So far, you\u2019ve learned:<\/p>\n