A new privacy tool is coming to town: currency exchange in the statechain. The original state chain design was proposed by Ruben Somsen at Scaling Bitcoin 2018 in Tokyo. I will summarize soon, but there is a very thorough explanation of the original concept of Aaron Van Wardum here. The general idea is that a convenient entity (statechain operator) creates 2 of 2 multisig addresses with the user to facilitate the off-chain transfer of a UTXO. The user then transfers their private key to a new user for 2-of-2. The statechain entity will be notified when this happens and will allow the new owner to transfer funds at that time. So the whole idea is to literally transfer the private key itself to the transaction and apply the current ownership to the state chain operator.
And like the Lightning Network channel, each user has a pre-signed transaction that allows them to take unilateral control of UTXO once a time lock is over. Thus if the statechain operator disappears, the funds will not be stuck in that 2 of 2 forever. But this backup option must be balanced against a party’s risk so that their parties try to misuse the pre-signed transaction to steal funds. Somsen’s proposal relies on Eltu for the convenience of the new owner to replace the previous owner’s pre-signed closed transaction if the previous owner tried to steal funds. The last major part of state chain design is a chain of signatures from one owner to another that starts with the original owner and goes all the way to the present. It is transmitted from one owner to another and attached in parallel to each transaction so that everyone can keep a local copy proving a valid transfer and in the case of the current owner they are actually the legitimate owner.
Because of its reliance on Eltu and the fact that soft thorns cannot occur overnight, CommerceBlock began implementing a variant of StateChain in 2020 that does not rely on Eltu. Allowing the latest transactions to replace the previous ones instead of Eltu, they have implemented a reducing unlocktime scheme called Mercury. The idea is that the closing transaction of the original owner is timelocked for a future x block period; They cannot run their transactions to get the funds back until the blockchain reaches this limit. And then in the next transfer of ownership, the new owner’s transaction is timelocked at x-1. This allows the current owner to submit their closed transaction to the chain before the original owner’s deposit becomes valid. As more ownership transfers occur, timelocks continue to decline (x-2, x-3, etc.), guaranteeing that the current owner can always work before unlocking previous owners’ transactions. This eliminates the need for eltoo, but introduces a limitation on statechain transfers between owners: it can no longer be reduced before you simply reduce the timelocks many times; At some point, the future, minus some time (block), becomes equal to the current (nLocktime is the current blockhight). At this point users will have to close the state chain or older owners will be able to steal coins as previous unlocktime transactions reach their locktime maturity and become valid.
Another key difference between Somsen’s original design and Mercury is what generations are managed. Instead of using the explicit 2-of-2 multisig script, Mercury applies ECDSA-MPC (elliptical curve digital signature algorithm multi-party calculation). You can think of it as a MuSig address using Schnorr, in the case of Schnorr users can simply add two public keys together to create an address that requires signing. With ECDSA-MPC, the original generation is a more interactive process with multiple steps. In the end they produce virtually the same result: a single public key that is clearly not a multisig and where both parties have a piece of matching private keys to sign the transaction.
The transfer process using ECDSA-MPC is an interactive process where an existing private key described in Somsen’s proposal is explicitly transferred instead of the original owner, creating a private key via keychain in collaboration with the statechain operator and sender ECDSA-MPC. Importantly, there are multiple sets of potential keystrokes that can create the same private key. So the statechain operator recreates the private key with the recipient, but creates different keyshares. The statechain operator then deletes the keys held by them which match the previous owner. CommerceBlock implements this with an HSM (Hardware Security Module), although it does not remove all trust. Thus if the statechain works honestly, it is literally unable to sign the closing transaction with the past owner because the key-share it currently holds does not work with the past owner’s share to create a valid signature. Also in the case of such conflicts, public evidence will be disclosed which shows that the statechain entity has misbehaved. It is a disrespectful act to do so.
How does public proof work? CommerceBlock has previously created a variation of the OpenTimeStamp called Mainstay. OpenTimeStamps is a protocol for receiving arbitrary information and it includes a very large Merkel tree with the promised origin of a bitcoin transaction. The problem with opentimestamps is that the tree is completely uncontrolled; Things just get attached to the end of the tree. This means that it does not guarantee that conflicting information is not committed by the same anchor transaction in the blockchain. What Mainstay does is allocate canonical “slots” into the Merkel tree to effectively cut certain pieces into pieces, for example an oracle attesting to the results of a sports game. Everyone can figure out which “slot” to check for that particular Oracle and then ignore any conflicting timestamps that are not in that slot. This allows people to attest something with a timestamp without the possibility of selectively expressing the opposite of timestamping (if you can write anywhere in the Merkel tree, you may have the actual timestamp in one place while pointing to a fake in another place). Each transfer of the Mercury State Chain is attested to a specific mainstay slot in order to provide timestamped proof of current ownership that may be revealed if the Statechain entity misbehaves.
Now that the details of the state chain implementation are out of the way, in the interesting part: coinswaps. The common distinction that has historically been made between coinjoins and coinswaps is that a coinjoin is a clear and universally visible use of privacy enhancement strategies for a single transaction, whereas a coinswap is generally considered a secret and, in the case of a cooperative of success, not a single individual. Publicly visible use of a privacy strategy throughout. The whole world can see when a UTXO goes to a coinjoin, but if discussed in general before, no one but the participants will know when UTXO is also involved in a coinSwap.
The implementation of the currency exchange built on the Mercury State Chain breaks down the clear distinction between coinjoins and coinswaps in terms of this explicit vs. confidentiality property. The transfer of the statechain is enshrined in the promise in the mainstay, so adversely you have to assume that it is universal knowledge every time the owner of the statechain changes. But each transfer can be a currency exchange with any other statechain transferred at the same block interval. So in the case of anonymity tools, it becomes a kind of Frankenstein monster, while UTXO manages the exchange using the currency exchange process. It uses a “Coinswap” off-chain on top of the statechain to mimic anonymous features similar to a coinzine without an on-chain fee for each exchange.
Coinsoaps in the Mercury statechain can basically hide their names with some fun cryptographic magic by simply transferring the regular statechain. When you register a UTXO for a common currency (such as Vortex or WASAB), you register a UTXO as an input and then get a blind cryptographic certificate that you can use to create an output with the addition of currency to get your currencies back to a new network connection Can. To protect your privacy against the coordinator. This same combination will register the state chain in the Mercury scheme, accept the blind token and then ask the coordinator to randomly assign a new address to transfer them to the statechain. There is even a chance to get your own statechain back. It’s random. It then basically everyone signs their statechain transfer atomically, like a coin.
In the end what we have here is the very opposite and a strange point of the “trust spectrum” of bitcoin tools that people are probably not accustomed to considering deeply. Strictly speaking at a technical level, what is happening is a currency exchange; Coins are being secretly exchanged without leaving a direct on-chain fingerprint that is a swap of UTXO. But because of Mainstay’s commitment to all transfers and the possibility of heuristic analysis that transfers state chain owners over different periods, you can guess the currency exchange phenomenon, so that anonymous set gains could be the equivalent of an ideal coinjoin. But you don’t have to pay a chain fee for each “coinjoin”.
To really drive home the point of the “weird point,” you can reasonably assume it is a single entity that acts as a statechain operator. But due to the removal of HSM-applied keychain, attestation and pre-signed closure transactions in Mainst, users always find a way to unilaterally exit the system, unless the operator cooperates with the previous statechain owner to deceive the legitimate owner. .
The best way I can think of to describe the trust model is to explain to Tom Trevathan from the Commerceblock: “The goal is to take the middle ground between fully trustworthy currency and fully trustworthy currency in terms of privacy tools.” Commerceblock to work honestly, in this case there is no doubt about the statechain operator. But there are also measures to warn users about dishonest behavior from users and to clear privacy benefits with potential fee savings in exchange for pure on-chain currency.
It’s not quite believable, but it’s not entirely believable. This is a new place in the spectrum when it comes to privacy tools. Personally, given the unconventional truth of how much centralized mixtures are still used, I’m curious to see where they fit into this ecosystem. There is a new boy in town.
This is a guest post from Shinobi. The opinions expressed are entirely their own and BTC, Inc. Bitcoin Magazine.