More privacy for Bitcoin with Taproot

Taproot should significantly increase Bitcoin’s privacy. This approach relies on multi-signatures, to be exact, on Schnorr multisigs.

In the worries about price developments, ETFs and the trench (r)ampf between Bitcoin and Bitcoin Cash one forgets that Bitcoin is also developing technically. Beyond these public debates, the developers have not only activated Segregated Witness or advanced the Lightning Network. They are working on things like Smart Contracts, Tokenized Assets or privacy on the Bitcoin blockchain.

The latter is something very important. On the one hand, privacy is essentially one of the ideals of the cypher punks, and on the other, it is only through this that the fungibility of Bitcoin can be increased. Even Bitcoin maximumists have to admit that crypto currencies like Monero that rely on anonymity are currently ahead of the field here. It’s understandable that the Bitcoin community wants to catch up here.

Taproot – More privacy with multi-signatures

Taproot is an idea that Gregory Maxwell presented in the Bitcoin developer mailing list at the end of January. The core of the idea is the use of multi-signatures. We briefly discussed multi-signatures in connection with Schnorr signatures. The idea is that transactions related to previously created multi-signatures on the blockchain look like other transactions.

The concept is quickly described: Let’s say Alice has the public key Pub_A and Bob has the public key Pub_B. We can make a mutisig C = Pub_A + Pub_B from it. From this and a timelock script a combined public key is generated. The timelock script is primarily available, similar to payment channels, to allow Alice and Bob, if their agreement breaks apart, to access their funds again after a fixed time. Alice and Bob can now form a 2/2 signature over P, that is, a multi-signature that requires consent from both. With this multi-signature, transactions can be initiated in which it is not known whether Alice or Bob were behind it. Only the combined public key is stored on the block chain.

Such a development would not only improve the privacy of Alice and Bob. Similarly, the transaction history of a token on the Bitcoin blockchain would no longer be as transparent, which would be an important step forward in terms of fungibility.

Schnorr Signatures: The Stumbling Block for Taproot

If Taproot is actually the solution for a central problem of Bitcoin, the question arises: Why hasn’t this solution been implemented yet? The problem is that you need Schnorr multi-signatures for Taproot. Without Schnorr multi-signatures you cannot transform multiple keys into a single key. In this respect Taproot waits for Schnorr.

Though it goes on this front. Since the beginning of July, several developers have been working on a Bitcoin improvement proposal for Schnorr signatures. There are also other project ideas like Graftroot, MAST or SIGHASH_NOINPUT that require Schnorr signatures. Accordingly, one could hopefully say that this high demand for the new signature type would speed things up.

The problem, however, is prioritization. Implementing all these ideas at the same time is too complicated and risky. On the other hand, the different projects would each result in a small soft fork and often end in a change of address format. Apart from the hurdles for Bitcoin users, privacy would be at least initially gone, especially in the case of Taproot.

You can see that the Bitcoin developer community is struggling with logistical rather than fundamental problems with regard to Schnorr signatures. Although the developers, partly for security reasons, partly because of difficulties in reaching a consensus, are not exactly known for quick decisions, there is a lot going on in the community, so that one can be curious when Schnorr, Taproot and the other projects will become real.

Comments are closed.

Post Navigation