Tag: bitcoin

Merge Mining and Auxiliary Proof of Work

merge mining
Figure 1: Mining on two blockchains at once

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.

merge proportion
Figure 2: Proportion of Bitcoin blocks with auxiliary POW (source: BitMEX Research).

Continue reading “Merge Mining and Auxiliary Proof of Work” →

Atomic Swaps and HTLCs

Atomic swaps are a method of exchanging one asset for another, such as two cryptocurrencies, even if they exist on distinct blockchains. The idea is to do this in a trustless way, avoiding counterparty risk, so that the swap either goes ahead and both parties receive what was agreed, or the whole thing is cancelled. It should not be possible for one ‘leg’ of the exchange to go through on its own without the corresponding payment. So, we can treat the entire exchange as a single trade which either goes through or not. As separate blockchains exist in isolation, and cannot directly communicate, atomic swaps are a useful cross-chain solution. They help to build a more interoperable ecosystem of interacting blockchains. Furthermore, atomic swaps can also be used with off-chain payments such as on the lightning network, connecting these with on-chain transactions.

atomic
If Alice hands over her bitcoin first, can she trust Bob to give her the ether?

Consider the scenario: Alice owns bitcoin, which she wants to use to purchase ether from Bob. The exchange rate (BTCETH) at the time is about 13. So, they agree to a swap where she sends one bitcoin to Bob and, in return, he sends 13 ether to Alice’s Ethereum account address.

This is fine in theory but, before sending her payment transaction to the Bitcoin blockchain, she has second thoughts. What happens if Bob does not submit his corresponding transaction? In that case, she will have sent him the bitcoin with nothing in return. Can he really be trusted? So, she asks Bob to submit his transaction first. However, Bob is also not really sure that he can trust Alice. If he submits his Ethereum transaction before Alice’s payment is confirmed, how can he be sure that he will be paid? To be safe, both parties in this transaction want the other to confirm their payment first. Consequently, they do not go ahead with the exchange.

What can be done to resolve the issue of trust and counterparty risk? This is not something specific to cryptocurrencies. Whenever two parties want to exchange any items of value, there is the possibility that one of them will not follow through with their side of the agreement. Here are three possible solutions. Continue reading “Atomic Swaps and HTLCs” →

A Smart Contract Platform on Bitcoin?

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.

smart contracts
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?” →

Proof of Transfer

PoX chain

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.

stacks blockchain
Figure 1: Stacks chain secured on the Bitcoin blockchain.

Continue reading “Proof of Transfer” →

Lightning Channels

lightning

The Lightning network is a layer 2 solution allowing for cheap and near-instant bitcoin payments. As with standard ‘on-chain’ transactions, it works in a peer-to-peer fashion without requiring trust in third parties. This network is built up from a collection of connected payment channels between pairs of individuals, each of which operates by exchanging zero-confirmation bitcoin transactions which are not actually submitted for inclusion in the blockchain. This reduces load on the chain, and allows settlement to occur in fractions of a second — much less than the 10 minutes average block production time.

Here, I concentrate on explaining how a single payment channel between two parties operates. The method by which these channels are connected to route payments will be explained in a separate post. I did previously discuss the use of zero-confirmation transactions to speed up payments, and the considerations leading to the idea of Lightning channels. Now, I will give a more detailed description of how this works. For more information, see the Lightning whitepaper. Also, medium.com has a pretty good explanation of how and why payment channels work in the way that they do.

To aid the exposition, let us suppose that two parties named Alice and Bob set up a payment channel between themselves. It is initially funded with 100 coins, with 50 from each of the two parties. At today’s prices, 100 bitcoin would be rather a lot to commit to a channel. I choose this quantity simply for a nice round number, and you can suppose that it is in units of 0.0001 bitcoin or 10,000 Satoshi, for more reasonable values.

Next, Alice and Bob start making payments to each other. As they already have coins locked up in the channel, this can be done by simply updating the quantities of these coins belonging to each party. See figure 1 below where, once the channel is funded, one payment is made on each of four days. They keep a tally of the amount of coins owed to each person, updated after every transaction. After this, the channel is closed and Alice and Bob receive back their current balance of coins.

This is, of course, a much simplified example. In practice, many thousands of payments could be completed before the channel is closed. Also, multiple payments could be made per second, rather than just once per day as here.

Time Event Alice Bob
Start Channel open 50 50
Day 1 Alice pays Bob 5 45 55
Day 2 Alice pays Bob 7 38 62
Day 3 Bob pays Alice 20 58 42
Day 4 Alice pays Bob 6 52 48
End Channel close 52 48

Figure 1: Channel payments.

How does this look, in terms of transactions actually submitted for inclusion in the blockchain? The situation is shown in figure 2. There are only two on-chain transactions. The first of these is to fund the channel and has two inputs, one from Alice and the other from Bob, so they both must sign for it to be valid. The output is to a multi-sig address requiring both Alice and Bob to sign to release the coins.

channel on-chain
Figure 2: Lightning channel on-chain transactions.

Nothing further is done on-chain until the channel is closed. At this time, a single transaction is made from the multi-sig address and paying each of Alice and Bob their closing channel balances. Since it is multi-sig, both Alice and Bob must sign this transaction. Continue reading “Lightning Channels” →

Zero-Confirmation Transactions

The Lightning network is gaining in adoption, and is currently being used worldwide to enable fast and cheap bitcoin payments. I will describe some of the issues that led to its invention, and hopefully help to understand why it works in the way that it does.

Picture the scene. As the owner of a coffee shop, you make the decision to start accepting bitcoin payments. Your first customer, Alice, enters the shop and orders a coffee. She takes out her mobile phone, opens the app for her bitcoin wallet, and scans the QR code for your bitcoin address which you have displayed by the counter. All she needs to do now, is to send the correct payment. Easy!

coffee shop

Well…not quite so easy. To be certain that the transaction is secure, we should really wait for it to have the requisite six confirmations before giving Alice the coffee. That is, it should be added to the blockchain, and have a further five blocks added on top. As it takes an average of ten minutes for each block to be produced, we can expect to have to wait around one hour. This is rather a long time to keep people waiting.

What can be done? As it is just for a coffee — not a major payment — we might be ok with fewer confirmations. Maybe just one will be sufficient, meaning that we simply wait for the transaction to be included in a block. It still takes ten minutes though, and remember that this is just the average. The time taken for a block to be produced is random so, if we are unlucky, it could take considerably longer. An hour for a block is not unheard of.

We really want to be able to accept Alice’s payment within a few seconds. There is no way around it, we are going to have to accept zero-confirmation bitcoin transactions. Either Alice sends her transaction to the network, and we monitor Bitcoin nodes to check that it has been received, even if it has not made its way into the blockchain yet. Alternatively, Alice can send her transaction directly to us and we will make sure that it is transmitted to the network to be included in a block.

Accepting transactions with zero confirmations does leave us vulnerable to double spend attacks, which is one of the main things that the blockchain was invented to solve. This is where Alice, possibly with an accomplice, spends the same coins multiple times with different counterparties. Even if we were to do this, and risk losing payments to double spends, we still need to ensure that the bitcoin transaction fee is sufficiently large to be accepted by miners for inclusion in a block. So, Alice will be rather upset that this fee is several times larger than the cost of the coffee she is buying. More fundamentally, the Bitcoin blockchain simply does not have the capacity to include lots of such small every-day payments by millions of people around the world.

busy road

Scalability Problems

Summarizing the issues raised so far, the following three problems need to be solved in order for Bitcoin to be useful as a mechanism for small, quick and common payments such as buying a coffee.

  • Speed. We should be able to accept payments in a matter of seconds.
  • Cost. The fee for a transaction should be small. No more than a few cents at most.
  • Capacity. The network should be able to handle millions of people around the world making such transactions regularly.

Continue reading “Zero-Confirmation Transactions” →

Alternative Signed Scripts?

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.

That is all there is to my hypothetical ASS upgrade. Continue reading “Alternative Signed Scripts?” →

Proof of Stake

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.

building a blockchain
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” →

Taproot

carrot beetroot

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” →