This is an opinion piece by Shinobi, a self-taught educator in the Bitcoin space and tech-oriented Bitcoin podcast host.
This time, I’m going to break down and discuss how chains of transmission work; they were originally proposed in 2015. Of all the proposals discussed so far, the transmission chains are the oldest and most fleshed out in terms of specific implementation and design details, documented in BIPs 300 and 301 Paul Sztorc, the creator of the concept, had a few main design goals in mind, and while this is by no means exhaustive, here are a few:
- Isolate each side chain so that any failures or issues only affect those using it.
- Allow sidechains to spin without needing a new fork for each.
- Enable bitcoin transfer in and out of a sidechain with a two-way peg.
- Allowing free experimentation in design, he hopes, would make the need for altcoins obsolete.
There are two main aspects to the whole design, which is why there are two separate BIPs. The first is the ankle mechanism (BIP300), which allows two-way ankle operation. Sztorc has designed something called a hash rate escrow, which in the most basic terms allows miners as an amorphous group to collectively hold coins across all side chains. The second is a “blind” merged mining scheme, where the goal is to allow bitcoin miners to be the block producers at a consensus level without having to validate the sidechain to do so. These two coins together present a two-way peg mechanism and a way for bitcoin miners to participate in sidechain mining while trying to mitigate the risk of centralization it presents.
BIP300 specifies logic for proposing a new sidechain, activating a new sidechain, proposing a grouped set of withdrawals, approving such a set of withdrawals, validation logic for transactions actual withdrawal rates and validation for deposit transactions.
Activating a new sidechain as part of the transmission chain proposal is very similar to the process of a soft fork activated by miner signaling. The main difference is, of course, that it is not really a soft fork – a single fork to activate the chain of transmission consensus rules allows miners, at any time, to report the activation of a new side chain. in chain of transmission consensus rules. To propose the activation of a new sidechain, a miner must place an OP_RETURN data in its coinbase output which includes a unique identifier for this sidechain, a public key to be used in deposit operations, version data, readable descriptions by humans and client software hashes and GitHub history (there is no consensus application here, just data for humans to reference).
When a miner proposes to activate a new sidechain and include all the necessary data in their coinbase, it becomes a kind of “minor signaling” period regarding whether or not to create this new sidechain from the point of view of the main chain consensus. A miner can use a special format to include a proposal in their coinbase outputs, and other miners can create another output following a second format to signal activation. A new sidechain proposal requires 90% of blocks in a hard time to report activation for a new sidechain creation to be confirmed. This creates the peg mechanism to activate the sidechain, but the interaction between sidechain and mainchain is more nuanced than that.
At this point, anyone can anchor coins in the sidechain. To connect to the sidechain, a user simply creates a two-entry transaction with its own entry and the UTXO corresponding to the sidechain balance with a single exit attributing everything to the sidechain. This ensures that the sidechain only ever has one UTXO containing all the funds locked there. Withdrawals are managed by the vote of minors. The mainchain does not know who owns what on the sidechain, and the mainchain will consider valid any withdrawals approved by miners under the voting mechanism. For this reason, there is a long delay in the withdrawal process. There are two phases in the process of withdrawing from a sidechain: a withdrawal proposal (bundle), then the withdrawal voting phase. Miners must create an OP_RETURN output in their coinbase transaction with a hash of the proposed withdrawal transaction to offer a withdrawal. This hash, however, similar to sighash, signals that it only commits to part of a transaction instead of the whole. It does not commit to the input UTXO which represents funds locked in a transmission chain or the output which returns anything not withdrawn to a special UTXO side chain. This is because any deposit in the transmission chain would create a new UTXO and thus invalidate the commitment to the withdrawal transaction when people went to validate it.
From there, the voting period for minors on the withdrawal proposal begins. Once a bundle has been proposed, miners can vote to approve it or not. Each block mined allows that miner to increment an approval counter, up or down by one, or two to refrain from doing anything. There are some specific limitations on top of that, as it is possible to have more than one bundle for a single sidechain – if a miner chooses to vote “yes” (increase counter by one) for a withdrawal bundle for a sidechain, it to have to vote “no” (decrease the counter by one) for each other bundle associated with that specific sidechain.
This is to ensure that there are no “double withdrawals”, where someone has a multi-batch exit that would earn them more bitcoins on the mainchain than they are owed.
On the other side, minors are also allowed to vote no for each proposed package. This is supposed to work as a kind of alarm to everyone that a miner validating these withdrawals (making sure they are coins legitimately held on the withdrawn sidechain) has noticed something invalid happening. was producing. Remember that a key point of this design is that miners don’t have to validate anything on the sidechain, so unless they choose to do so anyway, many miners can vote for bundles they don’t verify. This alarm feature is designed to alert them that they need to check the packages to ensure that no fraudulent withdrawals are occurring.
Once a bundle reaches the required threshold (13,150 blocks, or approximately 90 days), the transaction actually processing the withdrawal becomes valid and can be confirmed. But what do people do if miners approve a fraudulent withdrawal that steals money from the sidechain? Sztorc’s proposal is to engage in a user-activated soft fork (UASF) to invalidate the invalid peg transaction. This presents a huge consensus risk to the main chain. UASF in 2017 was a high risk move that barely succeeded and Bitcoin was much smaller than it is today. The larger Bitcoin grows, the more difficult these actions will be to coordinate.
If you remember the space warps article, this design was based on blind merged mining (BMM). Ruben Somsen’s BMM design is actually the second variant of this, the first being Sztorc’s design as stated in BIP301. The BMM specification in transmission chains is composed of two messages: a request message and an acceptance message. The two are coordinated through a special transaction type on the mainchain and a special exit in a miner’s coinbase transaction respectively.
The request transaction is built by whoever creates the sidechain blocks. The point of BMM is that this person can be someone who is not mining, so the request transaction is there for them to pay miners to confirm their proposed sidechain block. The sidechain block proposal constructs a transaction that includes the hash of the sidechain block, the ID assigned to the sidechain when it was created, and the last four bytes of the previous mainchain’s block header. Three additional consensus rules apply to these types of transactions. First, a request transaction is not valid unless there is also a corresponding accept output in that block’s coinbase transaction. This ensures that miners cannot collect fees on the request without also accepting and operating the sidechain block. Second, for each sidechain, only one request transaction is allowed to be included in a mainchain block. This ensures that only one block from any side chain can actually be mined per block from the main chain. Finally, the last four bytes of the previous main string block must match. This ensures that a request is only valid to be mined in the next block, and that such transactions cannot be mined later and steal money from a sidechain block proposer after someone’s block another was mined.
The accept output is very simple: the message header data and the sidechain block hash. If a miner is running a transmission chain node themselves, they can simply ignore request transactions and still include their own accept output in their coinbase to mine their own sidechain blocks. Together, these two aspects allow miners to mine a sidechain node themselves, or another non-miner to do so and pay the miner to mine their blocks. The idea is that, if the miners themselves are not managing the sidechains and incurring the additional validation costs, then someone else can do it for them. If there is competition from non-miners trying to earn fees on the sidechain, they will likely continue to bid on the fees they are willing to pay miners in their request transaction until They account for the majority of the fees they earn, with non-miners keeping only a small percentage of the profits and paying the rest to the miners.
This is the mechanics behind how drive chains work. Next, the federated side chains, and then, after that, a breakdown of all the downsides and downsides each design may have.
This is a guest post from Shinobi. The opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.