No, I haven’t gone crazy. Named after a Harry Potter spell rendering the target incapable of speaking coherently, mimblewimble is a blockchain protocol which scrambles up the transaction quantities and addresses, giving both a high degree of privacy and an efficient representation allowing massive savings on block space. According to its anonymous inventor, “I call my creation Mimblewimble because it is used to prevent the blockchain from talking about all user’s information”. Remarkable properties include not just hiding transaction quantities, but also allowing all transactions to be merged into a single big transaction, and spent outputs combined with their corresponding inputs and stripped from the blockchain. This last point has potential huge savings on blockchain space and validation time.
The protocol was implemented by the Grin and Beam cryptocurrencies, launched in January 2019. More recently, it was introduced into Litecoin in the MWEB upgrade (Mimblewimble extension block). This formally locked in on 3 May 2022 and went live a couple of weeks later.
Merge mining or merged mining is the process of mining more than one blockchain simultaneously. This is possible for some proof-of-work (POW) chains, where a miner puts the same hash power to work creating blocks on multiple chains and earns the associated rewards on each of them, without having to pay separate energy costs for each. Here, I explain the ideas behind merge mining.
For a blockchain incorporating the proof-of-work protocol, miners use hash power in order to win the chance of appending their block. For leading chains such as Bitcoin, this is an energy intensive process where each individual hash has a minuscule chance of winning. They need to perform a huge number of hashes to be in with any chance. Where there are multiple proof-of-work chains available, the miner needs to choose which one to contribute his hash rate towards. So long as his hardware is compatible with the specific hashing algorithms used (such as SHA256), he is free to mine on either chain, and switch between them as desired. Usually, it is not possible employ the same hash power simultaneously on both chains. This is because each hash is applied to the block header for the chain in question, so can only be used for solving the POW problem for that specific blockchain. However, if the protocol for all (or, all but one) of the blockchains in question have been designed to specifically to allow for it, then it can be possible for each hash function application to contribute to the proof of work on each chain simultaneously. This is known as auxiliary proof-of-work (AuxPOW).
There are several blockchains that can be merge mined along with Bitcoin. The first such case was Namecoin (NMC), which was created in April 2011 and upgraded in October 2011 to support merge mining. Another example is Rootstock (RSK), which was created in January 2018 and is a sidechain of Bitcoin supporting smart contracts. According to the article The Growth of Bitcoin Merge Mining from October 2020, over 90% of the Bitcoin hashrate is involved in merge mining. This is shown in figure 2 below, borrowed from the same article and showing the proportion of Bitcoin blocks which contain an auxiliary proof-of-work in the coinbase transaction, indicating that it was merge mined along with another blockchain. One notable example not involving Bitcoin is Dogecoin, which is merge mined along with Litecoin, using the scrypt hash function.
Figure 2: Proportion of Bitcoin blocks with auxiliary POW (source: BitMEX Research).
Consider the following question. Is it possible to use the Bitcoin blockchain for smart contracts? By this, I am not asking how far we can push the rather limited functionality of the native Bitcoin Script. Rather, can we write code for something like the Ethereum Virtual Machine (EVM), which is a Turing complete computation engine used by the Ethereum blockchain, and run on Bitcoin? This would enable a great variety of different uses for Bitcoin, such as ERC20 tokens, decentralized exchanges (DEX), NFTs, zk-STARKS, and any of the many different types of contract used by Ethereum.
While your first answer to the question above is probably “no, this is not possible”, there is one way in which it can be done with, albeit, a rather large caveat. Bitcoin transaction outputs incorporate a script, which is a simple stack-based programming language used to restrict how the coins can be spent. Output scripts starting with the OP_RETURN opcode cannot be spent in any way. More than this, they are provably unspendable, so are ignored by Bitcoin nodes which do not even record such outputs in the UTXO set. The output quantity would likely to be set to zero, so as to avoid irretrievably destroying any bitcoin associated with the output. This means that we can include any arbitrary data following the OP_RETURN to be recorded on the blockchain, which is simply ignored by all validating nodes. This is one of the uses of Bitcoin, as an immutable and decentralized store of data.
Figure 1: Smart contract transactions in OP_RETURN statements.
So, all we have to do, is to include smart contract code in OP_RETURN outputs using whatever language, such as EVM, that we want. Ok, this does not form part of the protocol, so is ignored by Bitcoin nodes. Blockchain explorers would show the code as raw data, but would not interpret the contract language. This is a rather large caveat, and you may well reply that it is not really ‘running’ on Bitcoin and, really, all that we are doing is using the blockchain as data storage. However, it is interesting to consider and, even if due to reasons to be discussed below, it is not very efficient, these methods are implemented by the Omni Layer and also lead on to ideas such as Proof of Transfer. Continue reading “A Smart Contract Platform on Bitcoin?”→
I will discuss an interesting blockchain protocol — or consensus mechanism — in which blocks are constructed on one blockchain by transferring assets on an entirely separate one. This is used by Stacks, where bitcoin needs to be spent in order to add blocks to the Stacks chain. Benefits include recycling the considerable proof-of-work of Bitcoin to secure additional chains, and can extend its functionality by introducing features such as smart contracts closely linked with Bitcoin.
As described in previous posts, decentralized cryptocurrencies such as Bitcoin require a protocol in order to regulate construction of the blockchain and to ensure immutability. Blocks of transactions are appended, one by one, to the end of the chain. The protocol helps decide who gets to assemble each block and receive the associated reward, as well as ensure immutability so that confirmed blocks remain unchanged in the chain for perpetuity. The focus of this post will be on the consensus mechanism itself, rather than any additional features of the blockchain in question such as support of smart contracts.
Most well-known is the proof-of-work (PoW) protocol used by Bitcoin as well as by many other leading cryptocurrencies. This requires miners to compete by expending computational power in order to gain the chance to create a block. Currently, the main competitor to proof-of-work is proof-of-stake (PoS), which requires validators to lock up units of the underlying chain asset in order to be selected to create blocks. Examples include Cardano and Solana. Both kinds of consensus mechanism function by requiring the prospective block-builders to spend some resource in order to win the chance of building a block, and receiving a block reward paid on-chain. These approaches gain their security from the idea that an attacker would need to gain control of more than half of the global resource in order to be able to control the network, known as a 51% attack.
For proof-of-work, the resource in question is hash rate or computational work, which boils down to using sufficient energy. This is external to the blockchain since the energy exists independently of the blockchain. For proof-of-stake, the resource is the blockchain asset itself or, more precisely, its opportunity cost because it is only required to lock up the asset for a period of time. This is internal to the blockchain. Since the resource used for security itself depends on the security of the network, it can introduce some circularities or difficulties when trying to analyse properties of the blockchain such as immutability and possible attack vectors.
There is a third kind of protocol, which is the focus of this post. Specifically, a blockchain can be secured by requiring validators to spend a resource existing on a separate blockchain. Since this approach gains its security from a ‘base’ blockchain to which it refers, it makes sense to use what is considered the most secure and decentralized chain. Namely, Bitcoin. The idea is quite general, and other chains such as Ethereum could be used be used in exactly the same way. As of writing this article, there is one blockchain using such a consensus mechansim. This is Stacks, which gains its security by validators spending bitcoin in order to build Stacks blocks. As such, I will use this as the canonical example demonstrating the approach. The name ‘proof-of-transfer’ (PoX) is used by the Stacks team. This makes sense, since validators are effectively transferring bitcoin in exchange for native Stacks coins when constructing blocks. The important point, though, is that they are spending a resource on the Bitcoin blockchain in order to build blocks on the Stacks one.
Figure 1: Stacks chain secured on the Bitcoin blockchain.
The soon-to-be live Taproot upgrade introduces the possibility of associating a collection of ‘alternative’ scripts to a Bitcoin address. These allow coins to be locked into a contract containing a collection of different clauses by which they can be unlocked and, when spending, we only reveal the script corresponding to the specific clause being activated. So long as all parties to the address authorise the transaction, a standard Taproot spend can be used simply by providing the digital signature, in which case, none of the alternative scripts need to be used or represented on the blockchain at all. As I described in an earlier post, the scripts are represented by a Merkelized Alternative Script Tree (MAST, for short). The Merkle root is used to modify the public key and, when activating a particular script for spending, it, along with its Merkle proof, is included in the spending transaction’s witness field.
There is another, simpler, way in which alternative scripts could have been incorporated, which I will refer to as Alternative Signed Scripts (or ASS, if you prefer…). This is a suggestion as to how it could easily have been done, and not a description of the actual Taproot implementation as it is. Hence the question mark in the post title — why did Bitcoin devs not implement the method which I will describe here? Is there a particular reason, or was it just not considered?
First, recall that a Taproot address contains a public key in the scriptPubKey of the sending transaction, and the corresponding Schnorr signature in the witness field of the spending transaction.
P2TR — Pay to Taproot
witness
<signature>
scriptPubKey
OP_1 <pubKey>
To be a valid spend, the signature needs to be valid for the provided public key and with the transaction as the message. To spend using an alternative signed script, we would have exactly the same Taproot format for the scriptPubKey associated with the Bitcoin address. The only difference is in the witness field of the transaction spending the coins.
P2TR — Pay to Taproot
witness
<sig_1> … <sig_n><script><signature>
scriptPubKey
OP_1 <pubKey>
Here, <script> is a serialization of the alternative spend script to be used, and <signature> is a Schnorr signature for the spend script. When validating the spend, we first use the public key to check that the signature is valid using the specified script as the message. Next, the items <sig_1> through <sig_n> are pushed onto the stack. Finally, <script> is deserialized and executed. As usual, if the value at the top of the stack is True then the spend is valid, otherwise it is invalid.
I previously described how Bitcoin is secured by a Proof of Work (PoW) protocol. Now, I describe an alternative method of achieving the same goal — Proof of Stake (PoS). This is currently being used for some blockchains, such as Cardano, and there are also plans for Ethereum to move from its current PoW incarnation to a PoS system. Both methods have their benefits and drawbacks, with PoS requiring much less energy but, on the other hand, is more complex with more possible attack vectors. Opinion is divided on which is the better,with defenders of either system having very strong convictions. In this post, I concentrate on describing how proof of stake works and only briefly touch on the possible benefits of one method over another. There are many different implementations of proof of stake so, here, I give an overview of the methods used without concentrating on any one particular utilization.
As explained in an earlier post, whichever method is used to secure a blockchain, it should require miners to spend some resource in order to build blocks. For PoW chains like Bitcoin, this resource is computing power or hashrate. For PoS chains, the resource is the underlying tokens or cryptocurrency represented by the blockchain itself. More precisely, as it just requires miners to lock up coins for a period, it is the opportunity cost of these coins that they spend. This is an internal resource of the blockchain rather than an external one as with PoW. Before going any further, there is a slight matter of terminology. The people who build blocks for a proof of work chain are called miners whereas, in proof of stake, they are called validators. Other terms, such as forgers, are also in use. Personally, I think it would have been simpler to use the same word regardless of the protocol but, to be consistent with the common usage, I will refer to block builders as validators.
Let’s just refresh our understanding of what a protocol needs to do. It should;
allow anyone with the necessary resources to participate in building the blockchain.
allow the network to reach agreement on a single global blockchain state at each time.
(immutability) ensure that, once a block is added and considered to be confirmed, then it will remain in the chain indefinitely.
Furthermore, these properties should continue to hold even in the event that a minority of validators are acting dishonestly or, even, are collaborating to attack the network.
In proof of stake, individuals register to become a validator by locking up a quantity of the blockchain asset. The protocol then divides up time into a sequence of successive slots, one for each block. It needs to assign one validator per slot, and do this in a way such that, on average, the number of slots assigned to each validator is in proportion to their stake size. Then, when their time slot is reached, it is the job of the validator to collect together transactions from the mempool, and construct a valid block to append to the chain. In return, they receive a reward which can be one of, or a combination of, the transaction fees in the block and the block reward.
Figure 1: Validators building a blockchain.
Each block is appended to the one constructed in the previous time slot so that, as time progresses, the validators continually add blocks on top of blocks, building the chain. Figure 1 shows this procedure with the cryptopunks acting as validators. Unlike with PoW where anyone who is able to create a valid block can submit it for inclusion, here the protocol needs to verify that the block used in each time slot has indeed been created by the validator assigned to it. This can be achieved with public key cryptography where, when they purchase a stake, each validator has to supply a public key. They then sign their blocks using the associated private key, proving that they were created by or, at least, approved by the assigned validator. Continue reading “Proof of Stake”→
What is a blockchain? For Bitcoin, it is a distributed ledger recording all transactions, and updated in real-time as new blocks of transactions are added. It has the important properties that anyone with the necessary private keys is able to create valid transactions to be added and, conversely, uses cryptography to ensure that only those with the necessary private keys are able to create such transactions. Other important properties include that there is a single valid blockchain state, and this state is accessible to anyone connected to the network. Furthermore, immutability requires that once a transaction has been added to the chain and is considered ‘confirmed’, then it should exist unchanged in all future blockchain states. More generally, a blockchain can be thought of as a kind of distributed database with a single shared state, which can be updated via the addition of blocks of transactions.
Let us look at the process of building a blockchain, whether it be Bitcoin, Ethereum, or something else. Users submit transactions to the network for inclusion on the blockchain. Then, miners (or similar) collect these transactions together into blocks, and add any additional required information such as the previous block hash, timestamp, hash root of the transaction data, or nonce required by the proof of work protocol. As long as the block is valid according to the protocol, this is then transmitted to the network for inclusion in the chain. This procedure is graphically displayed in figure 1 below.
Figure 1: Constructing a blockchain as a sequence of transaction blocks.
The highly anticipated Bitcoin upgrade Taproot is locked in and set to be activated in November 2021. This will have various advantages, such as supporting Schnorr signatures and incorporating multiple possible unlocking scripts in an efficient fashion. The aim is to increase scalability, privacy and security, especially with more complex ‘smart’ transactions. These updates are all about how bitcoin utxos (unspent transaction outputs) can be spent, by introducing new ways of parsing the scripts. I previously posted about Bitcoin Script, describing both the legacy and SegWit methods. The current post extends the description to include Taproot.
The first thing to note, is that Taproot is a kind of SegWit implementation. This means that the scriptPubKey in the transaction output takes a standard form, and the witness field of the corresponding transaction input is used to validate the spend. As with other SegWit methods, the scriptSig of the transaction input is not used, so is left empty. The standard Taproot spend method is then as follows.
P2TR — Pay to Taproot
witness
<signature>
scriptPubKey
OP_1 <pubKey>
The Bitcoin core script recognizes a scriptPubKey of this special form, consisting only of the version number OP_1 followed by a 256 bit (32 byte) public key, and interprets as a Taproot spend. Then, for a witness field consisting of a single command, this is interpreted as the standard Taproot spend method with the witness field containing just the signature. To be valid, the signature needs to be a valid Schnorr signature using the provided public key and using the spending transaction as the message.
Note that this is very similar to the standard SegWit P2PKH method, with three main differences.
The scriptPubKey contains the public key itself, rather than a hash of it.
Schnorr signatures are used, instead of the legacy ECDSA signatures.
The scriptPubKey has version number 1 instead of 0.
I note that Taproot is a soft fork, since any Bitcoin node which does not include the Taproot upgrade will see the P2TR scriptPubKey as being an ‘anyone can spend’ address. As it would be interpreted as putting the public key on the top of the stack, such spends will still be seen as valid. This avoids a fork of the blockchain where non-upgraded nodes would potentially disagree with upgraded nodes on which is the valid chain. However, non-upgraded nodes would not be completely validating Taproot spends (potentially accepting invalid spends from Taproot addresses), reducing their effectiveness in securing the integrity of the blockchain.
Already, the simple spend method described above has some advantages, due to the use of the Schnorr signature method which can incorporate key aggregation to allow multisig to be used, as well as allowing more efficient batch validation of a collection of transactions in one go. However, the power of Taproot is in it incorporating alternative spend scripts, described below. Continue reading “Taproot”→
Some blockchains, such as Ethereum, use an account model to represent the quantities of an asset held by each party, and transactions between them. This is an alternative to the UTXO model described in an earlier post. The idea is straightforward. At any time, we have a set of accounts, each with a unique identifier and an associated quantity of the asset. A transaction consists of, at least, the following:
From: The account to be debited.
To: The account to be credited.
Value: The size of the transfer.
Fee: A fee for processing the transaction.
Figure 1 gives an example where Alice is paying Bob 30 units, with a transaction fee of 2 units.
Figure 1: Applying a transaction in the account model.
Processing the transaction consists of adding the transaction value to the ‘To’ account and subtracting the transaction value and the fee from the ‘From’ account, to obtain the new state. Since the value of an account cannot drop below zero, we must have,
Transaction Value + Transaction Fee ≤ From Account Value.
There are some additional fields that are required in order to be able to validate a transaction, although they do not have any effect on the state of the accounts.
Signature: Only Alice should be able to spend the contents of her account which, as with the UTXO model, is done using public key cryptography. Each account should have an associated public key. Alice can sign the transactions from her account using the private key and, then, validation requires using the public key to verify that the signature is valid. In Ethereum, the account name is just a hash of the public key.
Nonce: Figure 1 above shows a transaction from Alice to Bob of 30 units, with a fee of 2 units. What happens if she wants to repeat this payment? She could try submitting the exact same transaction again. However, this cannot be accepted by the network. If it was possible for the same transaction to be applied more than once, then anyone could just take Alice’s original transaction and re-submit it as many times as they like, until her account has been drained. This can be avoided by including a nonce field (‘number used only once’) in the transaction. Then, Alice can submit a new transaction with the same value and fee, but with a different nonce. In Ethereum, the nonce is required to start at 0 for the first transaction from an account, and increase by 1 for each subsequent one, so is always equal to the total number of previous transactions from that account.
Cryptocurrencies such as Bitcoin make use of public key cryptography, in order to restrict the ability to spend a coin to the owner. Recall the idea from the earlier post on this subject: A prospective Bitcoin holder — Alice — has to first select a key pair. This consists of a private key, which must be kept secret, and a public key. If she purchases some bitcoin from another party — Bob — he needs to create a transaction on the blockchain paying this to an address corresponding to the public key. When Alice is ready to spend her coins, she creates a new transaction with the input, and signs it using her private key. Using the public key, anyone can verify that the digital signature is valid but, since only Alice can create a valid signature, only she is able to spend her coins.
For added flexibility, Bitcoin does not hard-code this procedure and, instead, makes use of a simple stack-based programming language called Script. A program, or script, in this language consists of a sequence of commands, usually written from left to right and which are executed in order. Each command in this language takes one of two forms. They can be of the form <data>, which simply adds the hardcoded data to the top of the stack. Such data is always a byte vector, which can also be used to represent a variable length integer or a Boolean true/false flag. Or, it is one of a finite set of defined opcodes, written with the prefix OP_. An example program performing digital signature verification can be written with just three commands.
<sig> <pubKey> OP_CHECKSIG
The first two commands push the digital signature ‘sig’ and the public key ‘pubKey’ onto the stack. The final OP_CHECKSIG performs signature verification, using the signature and key from the stack. The result is that it removes these from the stack and replaces them with True if the signature is valid, and False if it is not. So, the result of this program is that we have True or False on the stack depending on whether the signature is valid or not.
Note, I did skip a rather important part of digital signatures. The whole idea is that Alice is signing a message, so the verification procedure clearly requires this message as an input. However, the OP_CHECKSIG opcode only takes two arguments, the signature and the public key. This is simply because it implicitly uses the transaction that is spending the coins as the message.
I will not go over the full specification and possibilities of Script here but, instead, outline some of the ways in which it is used. For more details, see the Bitcoin Wiki.
I start by describing the original (or legacy) approach, before explaining the more recent segregated witness method. The idea is that a transaction output contains some script which plays the part of the public key restricting how the coin is spent, and is called a locking script, or the ‘scriptPubKey’. The corresponding transaction input spending these coins contains a redeem script corresponding to the digital signature, called the ‘scriptSig’. This is as in figure 1 below, showing two transactions and their input and output fields.
Figure 1: Bitcoin transaction input and output fields.
When validating the transaction, we execute them in turn, first the scriptSig from the transaction input and then the scriptPubKey from the corresponding transaction output. If the script finishes execution with the item at the top of the stack equal to True, then the transaction input is valid, otherwise it is rejected as invalid. Also, Script does not contain any loop constructs, and is always executed from left to right. This means that it is not Turing complete, but is a very important part of the design. As each command can only be executed at most once, it is not possible to have scripts that take a long time to run, and possibly never terminate, which would cause serious problems for validation.
We can take the final two commands of the simple script above (i.e., everything other than the signature) as the scriptPubKey, so that Bob includes this in his transaction output. To spend this coin, Alice creates a transaction with the digital signature <sig> as the scriptSig. Together, they create the three line script above, which validates only if Alice creates a valid signature. Alice could use a more complicated scriptSig if she likes but, in order for it to validate, it needs to leave a correct signature on the stack, and nothing else. So, scriptPubKey is a function determining if the transaction input is valid, and scriptSig simply pushes the required arguments on the stack.
This very simple type of locking script described above is known as P2PK, or pay to public key, but is considered obsolete.
Cryptocurrencies such as Bitcoin make use of public key cryptography, in order to restrict the ability to spend a coin to the owner. Recall the idea from the 
Zero Knowledge 