Difference between revisions of "Taproot"

From CryptoWiki

wiki_crypto>Zeb.dyor
 
m (1 revision imported)
 

Latest revision as of 09:01, 23 January 2022

Basics

"Up til now, I have been talking about Schnorr signatures and how you can combine these to have arbitrary complex policies or protocols. It's one key, one signature. The idea behind taproot is that if you can really do so much with one key and one signature, why don't we just make all the outputs in bitcoin be one key and all the witnesses be one signature? Instead of bringing in this whole script evaluation apparatus, then we can bring in one key one signature and then that's great. Your validation condition is a nice little algebraic equation and there's little room for weird consensus edge cases. You also get batch validation. I should mention that this is kind of how mimblewimble works: you only have an ability to verify signature. Historically, this whole adaptor signature business came out of mimblewimble and in particular the question of how to add scripting to mimblewimble. As soon as I came up with this idea, I brought it to bitcoin and forgot about mimblewimble. As soon as I could do it with bitcoin, I ran away.

But bitcoin isn't mimblewimble, and people use scripts like timelocks and lightning channels. petertodd has some weird things like coins out there that you can get if you collide sha1 or sha256 or basically any of the hash functions that bitcoin supports. You can implement hash collision bounties and the blockchain enforces it."

"The main benefit we can expect is decrease in privacy leaks and block space costs for closing lightning network channels. Right now opening a Lightning Network channel is just a normal Bitcoin output. But closing it actually requires to expose the multi-sig + HTLC contract. While after Taproot a cooperative channel closing, which is the most frequent kind of closing, will just look like a normal single-sig Taproot transaction. This will certainly decrease the size of the closing transaction, making it relatively less expensive. And it will also increase its privacy, but only its privacy in relation to the anonymity set of the new kind of Taproot transaction. So, for the very first phase of this change, a Lightning channel opening and closing with Taproot will stand out even more, because nobody will be using Taproot at the beginning, so the anonymity set will be very small. But when it increases, it will include both normal single signature on-chain transfers and multi-sig cooperative situations (possibly including Lightning Network channel closings) that will look just the same.

Of course, this is easier said than done, because people will have to redesign the Lightning Network standards in order to be expressible as a Taproot script. So it’s not something that we will get automatically after the activation. There will be a lot of work in redesign and in actual development of the Lightning implementations, wallets, tooling, and everything else that is needed."

"According to the parameters set forward by “Speedy Trial,” if at least 90% of the blocks mined in any of the designated two-week difficulty periods “signal” their support for the upgrade, then the activation process can begin. Now that the Taproot soft fork upgrades are locked in, the next phase of activation is basically a five-month waiting period. During this time, miners and nodes will have ample opportunity to update their software to Bitcoin Core 0.21.1, the newest version of Bitcoin Core that contains activation logic for the Taproot soft fork (and some other improvements).

Finally, in November, when Bitcoin reaches a specified “block height” (Bitcoin block 709,632), Taproot will activate; that is, the Bitcoin Improvement Proposals (BIPs) relevant to Taproot and contained in Bitcoin Core 0.21.1 will automatically kick in."