This Tool Can Protect Your Privacy When Using Bitcoin

There is a new privacy tool coming to town: coinswaps on statechains. The original statechain design was proposed by Ruben Somsen at Scaling Bitcoin 2018 in Tokyo. I will summarize quickly, but Aaron van Wirdum has a very thorough explainer of the original concept here. The general idea is to have a facilitating entity (the statechain operator) create a 2-of-2 multisig address with a user to facilitate the off-chain transfer of a UTXO. The user then transfers their private key for the 2-of-2 to a new user. The statechain entity would be informed of when this happens and at that point will only allow the new owner to transfer the funds out. So the whole idea is to transact by literally transferring the private key itself and have the state chain operator enforce current ownership.

And just like Lightning Network channels, each user has a pre-signed transaction allowing them to take unilateral control of the UTXO after a time lock has expired. This way if the statechain operator were to disappear, the funds wouldn’t be trapped in that 2-of-2 forever. But this backup option has to be balanced against the risk of one of the parties trying to misuse their pre-signed transaction to steal the funds. Somsen’s proposal depends on eltoo in order to facilitate the new owner replacing the previous owner’s pre-signed closure transaction in the event that the previous owner tries to steal back the funds. The last major part of the statechain design is a chain of signatures from one owner to another that starts with the original owner and goes all the way to the current one. This is passed from one owner to another and appended in parallel with each transaction so everyone can keep a local copy proving legitimate transfer and, in the case of the current owner, that they are in fact the legitimate owner.

Because of the dependence on eltoo and the fact that soft forks tend not to happen overnight, CommerceBlock began work on implementing a variant of statechains in 2020 that does not depend on eltoo. In place of eltoo allowing the most recent transaction to replace prior ones, they have implemented a decrementing nLocktime scheme called Mercury. The idea is that the original owner’s closure transaction is timelocked to a period of x blocks into the future; they cannot execute their transaction to take back the funds until the blockchain has reached this threshold. And then on the next ownership transfer, the new owner’s transaction is timelocked to x-1. This allows the current owner to submit their closure transaction to the chain before the original owner’s becomes valid to submit. As further ownership transfers take place, the timelocks continue decrementing (x-2, x-3, etc), guaranteeing that the current owner can always act before any of the previous owners’ transactions unlock. This removes the requirement for eltoo, but introduces a limitation in transferring statechains between owners: you can only decrement the timelocks so many times before it cannot be lowered anymore; at some point, the future, minus some amount of time (blocks), becomes equal to the present (the nLocktime is the current blockheight). At this point users must close out the statechain or older owners will be able to steal the coins as those earlier nLocktime transactions reach their locktime maturity and become valid.

Another key difference between Somsen’s original design and Mercury is how the key generation is handled. Instead of using an obvious 2-of-2 multisig script, Mercury implements ECDSA-MPC (elliptic curve digital signature algorithm multi-party computation). You can think of this as functionally similar to a MuSig address using Schnorr, except in Schnorr’s case users simply add two public keys together in order to create an address both are required to sign for. With ECDSA-MPC, the key generation is a more interactive process with multiple steps. In the end they functionally produce the same result: a single public key that is not obviously a multisig and where both parties involved have a share of the matching private key needed to sign a transaction.

The transfer process utilizing ECDSA-MPC is an interactive process where instead of the original owner explicitly transferring an existing private key as described in Somsen’s proposal, the statechain operator and the sender collaborate through ECDSA-MPC to generate a private key via keyshares. Crucially, there is more than one set of possible keyshares that can generate that same private key. So the statechain operator then recreates the private key with the recipient, but by making different keyshares. The statechain operator then deletes the keyshare they held that corresponds to the previous owner. CommerceBlock enforces this with an HSM (hardware security module), although this doesn’t remove all trust. This way if the statechain is operating honestly, it is literally incapable of signing a closure transaction with a past owner because the keyshare it currently holds does not work with past owner’s keyshare to create a valid signature. Also in the case of such collusion, public proof would be publishable showing that the statechain entity has acted dishonestly. This is a reputational disincentive to do so.

How does the public proof work? CommerceBlock has previously designed a variation of Opentimestamps called Mainstay. Opentimestamps is just a protocol for taking any arbitrary data and including it in a very large merkle tree with the root committed to a Bitcoin transaction. The problem with Opentimestamps is that the tree is completely unordered; things just get added to the end of the tree as they come in. This means it provides no guarantees that conflicting information isn’t committed to by the same anchoring transaction in the blockchain. What Mainstay does is effectively assign canonical “slots” in the merkle tree for specific pieces of data, for example an oracle attesting to the outcome of a sports game. Everyone can know which “slot” to check for that specific oracle and can then ignore any conflicting timestamps not in that slot. This allows people to attest to something with a timestamp without leaving open the possibility of timestamping conflicting things to reveal selectively (if you can write anywhere in the merkle tree, you could have the real timestamp in one place while pointing to a bogus one elsewhere). Every transfer of a Mercury statechain is attested to in a specific mainstay slot in order to provide a timestamped proof of current ownership that can be published if the statechain entity acts dishonestly.

Now that the details of the statechain implementation are out of the way, onto the interesting part: coinswaps. The general distinction historically made between coinjoins and coinswaps are that a coinjoin is an explicit and publicly visible use of privacy enhancing techniques occurring in a single transaction, while a coinswap is generally thought of as covert and, in the cooperative case of success, not a publicly-visible use of a privacy technique occurring across multiple separate transactions. The whole world can see when a UTXO goes into a coinjoin, but if implemented as generally discussed previously, no one except the participants would know when a UTXO is involved in a coinswap.

The coinswap implementation built on top of Mercury statechains breaks this clear distinction between coinjoins and coinswaps in terms of this overt versus covert privacy property. Transfers of statechains are recorded in the Mainstay commitments, so adversarially you have to assume that it’s public knowledge each time a statechain changes owners. But each transfer could also be a coinswap with any other statechain transferred in the same block interval. So in terms of anonymity tools, this becomes a sort of Frankenstein’s monster combining the anonymity properties of coinjoins while using the mechanism of a coinswap to conduct the exchange of UTXOs off chain. It uses a “coinswap” off chain on top of a statechain to emulate similar anonymity properties of a coinjoin without incurring an on-chain fee for each swap.

Coinswaps on Mercury statechains are essentially just regular statechain transfers with some fun cryptographic magic to make them anonymous. When you register a UTXO for a typical coinjoin (like Whirlpool or Wasabi), you register a UTXO as an input and then receive a blinded cryptographic credential you can use to create an output in the coinjoin to get your coins back over a new network connection to protect your privacy against the coordinator. This same coordination is approximated in Mercury’s scheme by registering statechains, receiving blind tokens and then querying the coordinator to be randomly assigned a new address to transfer their statechain to. There is even a chance of receiving your own statechain back to yourself. It’s random. After that it’s essentially just everyone signing off on their statechain transfers atomically, just like a coinjoin.

In the end what we have here is something very counterintuitive and at a strange point in the “trust spectrum” of Bitcoin tools that people probably aren’t used to considering deeply. Strictly speaking on a technical level, what is happening is a coinswap; coins are covertly being swapped without leaving a direct on-chain fingerprint that a swap of UTXOs is happening. But because of the Mainstay commitment to all transfers and the heuristic analysis potential of which statechains transferred owners in different time periods, you can infer the coinswap occurred, thereby reducing the anonymity set gains to be equivalent to a standard coinjoin. But you don’t have to pay fees on chain for each “coinjoin.”

To really drive home the point of the “strange point,” arguably with a single entity functioning as the statechain operator you could view this as approximating a custodial arrangement. But because of the HSM-enforced keyshare deletion, Mainstay attestations and the pre-signed closure transactions, users always have a path of unilateral exit from the system as long as the operator doesn’t collaborate with a prior statechain owner to defraud the legitimate owner.

The best way I can think to describe the trust model is to paraphrase Tom Trevethan from CommerceBlock: “This aims to occupy the middle ground between a fully custodial mixer and a fully trustless coinjoin in terms of privacy tools.” There is undeniably some degree of trust in the statechain operator, in this case CommerceBlock, to act honestly. But there are also mechanisms in place to publicly alert users of dishonest behavior from them and clear privacy benefits to be gained with a potential fee saving versus pure on-chain coinjoins.

It’s not quite trustless, but it’s also not quite completely trust based. It’s a new spot in the spectrum in terms of privacy tools. Personally, given the underappreciated fact of how widely used centralized mixers still are, I’m interested in seeing where this fits into that ecosystem. There’s a new kid in town.

This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC, Inc. or Bitcoin Magazine.


Tagged : / / / / / /

How Bitcoin’s Taproot Upgrade Will Improve Technology Across Bitcoin’s Software Stack

Bitcoin’s Taproot upgrade is (basically) a shoe-in as Bitcoin stakeholders figure out the best way to bring it online. 

Digital signatures are created from the private keys that control bitcoin wallets and are required to approve transactions. Taproot addresses will use Schnorr signatures, rather than Bitcoin’s current signature algorithm, the elliptic curve digital signature algorithm, or ECDSA for short. 

In terms of data and processing, Schnorr signatures are smaller and faster than ECDSA signatures and also have the added benefit of being “linear,” which means Schnorr-based smart contracts can be optimized for functions that ECDSA signatures cannot.

These differences have made Taproot a highly anticipated upgrade because it will give Bitcoin a boost to transaction privacy and allow for more lightweight and complex “smart contracts” (an encoded contract with self-executing rules).

The tooling and coding improvements Taproot brings will be largely under the hood and will be a boon to developers. Regular Bitcoin users, however, will also benefit from usability, performance, and privacy improvements to multisignature (multisig) technology, privacy software and even scaling tech like the Lightning Network.

Without Taproot, applying the following upgrades to these softwares would either not be possible or not be as viable.

MuSig2: Boosting privacy and efficiency of multisig transactions

Bitcoin development hub Blockstream is developing a new multisig software, MuSig2, which will make multisig transactions more efficient, cheaper and more private.

Unlike usual Bitcoin wallets, which only require a single signature from a private key, multisig wallets require at least two or more signatures from different private keys to approve a transaction. The idea is to distribute the risk of a wallet among multiple keys and, if needed, multiple parties.

Under the current design with ECDSA contracts, multisig transactions record the signature of each multisig participant individually. Schnorr signatures would allow each signature to be recorded as one signature on the blockchain, making the transactions more lightweight in data, and thus cheaper.

“[Taproot] benefits multisig wallets such as Blockstream Green because using MuSig2 is cheaper and more private than current multisig setups,” Blockstream developer Jonas Nick told CoinDesk. 

The Bitcoin upgrade will also raise the limit on signers a multisig wallet allows from 15 to a “much higher number,” said Bitcoin developer Chris Belcher.

Schnorr-signature based transactions are more private because, thanks to so-called scriptless scripts, all Taproot transactions have the same digital footprint. That means a single signature transaction and a multisig transaction look the same on the blockchain under Taproot’s rules.

This privacy improvement spills over into other areas of Bitcoin’s development, too.

“MuSig2 also improves efficiency of multi-party contracts such as Lightning Channels, CoinSwaps or discrete log contracts, and improves the privacy of routing in the Lightning Network by enabling ‘scriptless scripts.’ This also means that the anonymity set of regular transactions would become larger because, for a blockchain observer, it could just as well be part of a multi-party contract or multisig wallet,” Nick said.

CoinSwap: Disguising mixed coin transactions

All of the softwares Nick referenced rely on multisig wallets to bind market participants in cryptographically reinforced rules of engagement called smart contracts.

One of these, the privacy protocol CoinSwap, is widely considered to be the best successor to CoinJoin, currently the most popular software for “mixing” bitcoins to obscure their transaction history. 

One shortcoming of CoinSwap’s precursors including CoinJoin is such transactions show up as distinctly different from normal ones. This makes it easier for blockchain analysis to pinpoint CoinJoins on-chain, thwarting any privacy benefits. 

According to Belcher, Bitcoin’s Taproot upgrade will fix this problem.

“A good benefit of Taproot is also that it allows scriptless scripts. As you may know, protocols like Lightning Network and CoinSwap depend on so-called hash time locked contracts. Currently these contracts are visible on the blockchain. The thing that scriptless scripts allows is for those contracts to also look exactly the same as a Taproot single-sig transaction.”

Point Time Lock Contracts: Making Lightning More Private

As Belcher points out, Bitcoin’s Lightning Network uses hash time locked contracts (HTLCs) to facilitate transactions. But Schnorr Signatures would pave the way for point time lock contracts (PTLCs), an improvement on HTLCs that allow for more private and efficient smart contracts for Lightning.

The privacy gain comes from a modification to how Lightning Network nodes “route” transactions. Lightning transactions must be sent directly and peer-to-peer on what are called “payment channels.” Otherwise, lacking this direct connection, payments must be routed through peers to which both the sender and receiver are connected.

Lightning Network nodes route transactions by passing on a hash of the payment to each node on that payment’s path. PTLCs alter this hash by adding random info at each hop to make the payment less traceable to any party conducting blockchain surveillance. 

Additionally, PTLCs will enable more complex smart contract logic to facilitate unprecedented blockchain escrow conditions and to improve oracles. (Since a blockchain can’t process data outside of its network, an oracle feeds this data to it.)

“Technically, [PTLCs] could be done today with ECDSA but it doesn’t have the same proven security, and if it was implemented it would have to be redone once we get Taproot,” Ben Carman, a developer at Suredbits, told CoinDesk.

Other Taproot improvements

Carman and his colleagues at Suredbits have been working on discrete log contracts (DLCs), a fairly new smart contract logic for Bitcoin that, while working today, will be more flexible and easier to use when Bitcoin’s Taproot upgrade kicks in.

Belcher told CoinDesk that Schnorr signatures will also enable “batched validation” wherein a Bitcoin full node could “validate 1,000 Taproot signatures in nearly the same time it takes to validate one [ECDSA] signature.” This scaling solution would significantly speed the time it takes a node to verify all signatures in a block.

Additionally, Taproot could use “ring signatures” to give users the ability to prove they own certain coins without having to reveal the public key associated with those coins.

“That means someone could prove that they own a certain coin without revealing which exact coin. For example, it would be possible to prove you own at least 1 BTC (or any amount) by doing a ring signature over all the Taproot [unspent transactions] worth more than 1 BTC, and yet it doesn’t actually reveal which is yours,” Belcher said.

This has implications particularly for Lightning Network node operators who want to prove payment channel ownership without sacrificing privacy.



Tagged : / / / / / / / /
Bitcoin (BTC) $ 41,923.23 4.19%
Ethereum (ETH) $ 2,252.69 1.86%
Litecoin (LTC) $ 73.44 0.90%
Bitcoin Cash (BCH) $ 250.36 8.80%