At the last Scaling Bitcoin conference in Stanford, which took place in November 2017, the head of Blockstream research, Andrew Poelstra, described the concept of “scriptless scripts” that will relieve the Bitcoin blockchain, removing smart contracts from it and executing them on the principle of (almost) normal transactions. This article will delve into how it will all work.


The concept of smart contracts that perform a transaction under certain conditions was first described by the famous cryptographer and computer scientist Nick Szabo in 1994. Subsequently, with the advent of cryptocurrencies, his ideas were modified and developed into a working system, and Ethereum remains the most popular implementation of the platform of smart contracts.

Despite the fact that Ethereum, which was launched in 2015, is considered by many to be the first platform of smart contracts, the basic functionality of smart contracts has always been supported by Bitcoin. “The cool part about bitcoin isn't just that you can send coins around, but also that you can attach various conditions to their spending. You can look for hash preimages, you can do multi-signatures, you can do fun things that build up "smart contracts" I guess is the buzzword regarding these features,” Poelstra said.

Technically, even a normal Bitcoin transaction can be considered a smart contract, since funds are transferred on the condition of providing a valid cryptographic signature. More complex smart contracts, which include multi-signatures or timelocks, are used in second-level solutions (for example, Lightning Network).

Smart Contract Issues

The use of smart contracts involves a network load and risks for the parties involved. As the contract becomes more complex, its resource consumption increases (that is, the consumption of computing power and ultimately, energy). This is especially problematic because every node of the network must fulfill every smart contract, and not only interested parties.

This, in turn, means a lack of privacy: the entire network can find out the details of your smart contract. Furthermore, if it contains a vulnerability, it can be detected and attacked in order to steal the assets in the contract.

Another threat is that alternative software can interpret the details of the contract in a slightly different way, which will make it harder for the nodes to reach consensus.


Last year, during the Scaling Bitcoin conference at Stanford, Poelstra introduced the concept of scriptless scripts, with which you can use smart contracts on a Bitcoin network, but completely remove them from the blockchain. Under the system described by Poelstra, contracts should no longer be executed by the entire network, but only by direct participants in the transaction. The rest of the network will be able to make sure that the network rules are not violated and the transaction is valid, however, since the blockchain will “see” the smart contract as a normal transaction. “People can verify the state of the system without loading all the background data. In a certain way, it is possible to compress all transactions. Many of the data are redundant, and you don’t need to check them all publicly,” Poelstra says.

In his presentation, Poelstra elaborated on two technologies, Mimblewimble and scriptless scripts. But for their explanation, he touched on a few more topics.

Confidential Transactions and Commitment Scheme

This system was described by one of the main Bitcoin Core developers and former member of the Blockstream team Gregory Maxwell. Everything functions as in conventional Bitcoin transactions, but the transfer amounts are hidden and replaced by obligations of the same type (a cryptographic method that allows confirmation of non disclosed values). Thus, the scheme of obligations of the same type makes it possible to verify a transaction, that is, to verify that the sum of the inputs is equal to the sum of the outputs, without disclosing any specific financial information.

The commitment scheme consists of the actual amount of the transaction and other blinding factors that are used to hide the amount. “To make a transaction, you need to know the number of blinding factors to enter . . . This means that you cannot create a transaction without knowing the secret,” explains Poelstra.

In this case, using only the commitment scheme as a blinding factor may not be enough to protect the data. In a real transaction, the inputs are what came from someone, and the outputs are what are sent to someone else. “There are two unrelated and untrusting sides that supposedly should not know each other’s blinding factors. Therefore, if you use the same type of obligations here (the sum of the inputs is equal to the sum of the outputs), you will have a problem, because the owner of the exit will know the amount of the blinding factor of the input and vice versa . . . All participants in the transaction will know all the blinding factors, and therefore, they will have all the exits,” says Poelstra.


In the MimbleWimble protocol, this problem is solved by adding a special zero-value output called a “kernel.” The kernel cannot be spent, which makes it impossible to compromise such a transaction, because in order to make a successful payment, it is necessary to know the number of expendable outputs.

Multi-signatures and the zero-output commitment scheme are two components of the “magic of MimbleWimble,” as Poelstra calls it.

Mimiblewimble was presented by Poelstra at the Scaling Bitcoin conference, but a year earlier in 2016. At the same time, the authorship of the proposal is unknown. The white paper was published via a server hidden using Tor and “reset” to the IRC channel Bitcoin wizards. “The author just dumped it, exited a minute later and never returned, as far as we know,” said Poelstra.

The white paper is written under the pseudonym Tom Elvis Jedusor (Voldemort's name in the French editions of "Harry Potter"), and the author says that "he called his creation “MimbleWimble” because it is used to prevent the blockchain from babbling out user information” (in the book “Harry Potter and the Deathly Hallows,” “MimbleWimble” is a spell that binds the tongue of the victim, not allowing a word to be said).

MimbleWimble improves Bitcoin privacy and scalability but does not support scripts, that is, bits of code contained in Bitcoin transactions that are responsible for the basic functions of smart contracts in Bitcoin. The scripts described by Poelstra combine the functionality of scripts and MimbleWimble.

Scriptless Scripts

"Scriptless scripts [that] were developed during 2017 and still [are being developed] are a very large-scale research project. It is a way to use the kernel and the kernel signature to set conditions for them without modifying the system so that the reviewers do not have to understand the new rules,” Poelstra said, explaining that participants can choose which contract or protocol they want to fulfill, and as a result of honest execution, they will create a valid signature, so that the blockchain and the miners will be able to confirm the validity of the signature, without having any specific details of the transaction.

“You lay out the rules and then publish clear evidence that these rules were followed,” says Poelstra. “Historically, it came from MimbleWimble . . . But in fact, any system that supports Schnorr signatures or some other signature scheme with linear data can perform this scriptless script technique.”

The idea that a public blockchain should have privacy functionality has already been developed by a number of projects, and many community members have noted that it is the viewability of all operations that makes blockchain unattractive for financial organizations.

“We care about the privacy and interchangeability of public cryptocurrencies, in which each transaction is published and can be downloaded by everyone. And this is very bad for privacy and commercial confidentiality, especially if your funds are on the blockchain. This makes it difficult to do business when you disclose all of your financial information, and this compromises any method of commercial use of this system. Using scriptless scripts, we avoid contract disclosure, because everything that comes to the chain is public keys and signatures,” as Poelstra notes.

Signatures play a key role in the scriptless script engine. When someone signs, it looks like an acknowledgment of a normal Bitcoin transaction, but it contains a smart contract that is not stored on the blockchain, and is correctly executed upon receipt of this signature.

Schnorr Multi-Signatures

It is they who make such concealment possible. This type of signatures has not yet been implemented in the Bitcoin protocol, but perhaps their support will be added within a year.

Schnorr Signatures allow combining several signatures. There are several stakeholders, so users need to create a signature that would be the same for all of them. Each user has a separate public key. These keys are connected, and you get a single public key, then you only need to create a private signature for it.

“The philosophical moment is that such multi-signatures are already partly scriptless scripts in the sense that you can have a group of people, each of whom has their own public key, and they merge them together to get a single key. They get a single key and single signatures. External observers who did not participate in this did not know how many people were involved in it, and also that more than one person participated in it. And they, of course, do not know the original values ​​. . . You leave a share of the signature instead of a full signature, and it all works magically,” comments Poelstra.

Linear mathematics is used when generating multi-signatures of Schnorr. Let us consider how this works in a very simplified way:

Private keys and signatures are numbers, and the latter are formed from the first. Since these are simplified examples, imagine that the private key is 10, and half the Schnorr signature formed from this key is 10,000. The second private key is 15, the second half of Schnorr's signature is 15,000. Based on this data, the Schnorr signature will be 25,000 (10,000 plus 15,000).

And since these are numbers, mathematical calculations can be made with them. For example, the difference between the values ​​of two private keys in our case is 5,000 (15,000 minus 10,000).

In practice, everything is, of course, more complicated, but this is one of the examples of calculations that the linear mathematics of the Schnorr signatures allows for.

Consider this mechanism on the example of a specific smart contract. Suppose a smart contract is programmed so that when someone listens to a song, the reward is immediately sent to the performer.

In this case, under the terms of the smart contract, the song will be played only if the performer gives his signature to the server on which the musical composition is stored. In our simplified scenario, the “song signature” is 7,000. And the “listener” wants to pay one Bitcoin for listening to it.

To do this, both parties create a normal Bitcoin transaction, which sends one Bitcoin from the listener to the performer, provided that both provide their halves of the Schnorr signature to create a single “whole” signature.

The artist, of course, knows what his signature looks like. For example, 8,000. He also knows what the song's signature looks like: 7,000. By owning this data, he can calculate the difference between them: 1,000. This is called a “signature adapter,” or a connecting signature.

From a technical point of view, it works like this: “Instead of sending his nonce R to a multi-signature protocol, [the participant] sends R + the blinding factor T . . . [Himself] T he also sends. This is strange because he does not try to hide nonce. All he does is correct it with a value he knows . . . you will get a signature that is almost valid — it is valid if you can correct it with a secret value t that only one side knows. If you know the signature adapter, knowledge of a valid signature with the same nonce (since the hash is the same) is equivalent to knowledge of t.”

The performer transmits this signature to the listener, and the listener can ascertain that this signature is, in fact, the difference between the half of the performer’s signature and the song’s signature. And this is despite the fact that the listener does not yet have access to both of these signatures (a typical example of zero-knowledge proof).

Now, having verified the signature adapter, the listener can provide his half of the signature of the Shnorr to the performer. When the performer uses this half to create a whole signature and transmits it to the Bitcoin network, he automatically thereby makes visible to the listener and his own half of the signature (8,000).

Now, using half the signature of the performer, the listener can subtract the signature adapter 1,000 from half the signature of the performer's Schnorr. So he learns the signature of the song at 7,000 and can listen to it. In other words, by sending a transaction that amounts to one Bitcoin, the performer automatically sells the song signature to the listener and this is a smart contract.

For the blockchain (and everyone who is viewing it), the transaction looks completely normal. No details about the smart contract, with the exception of the usual “settlement transaction” to pay for the song, are recorded on the blockchain. No one will ever know that behind this record is a completed smart contract. In addition, no one but two parties should perform calculations within the framework of a contract or store its data on the blockchain.