 key to you. Another nice thing with PTLCs is that they are deniable. What appears onchain is just a single 0-of-0 signature between you and the developemanufacturer. It's like a magic trick. This signature has no special watermarks, it's a perfectly normal signature (the pledge). However, from this signature, plus some datta given to you by the developemanufacturer (known as the adaptor signature) you can derive the private key of a particular public key you both agree on (the turn). Anyone scraping the blockchain will just see signatures that look just like every other signature, and as long as nobody manages to hack you and get a copy of the adaptor signature or the private key, they cannot get the private key behind the public key (point) that the pointlocked branch needs (the prestige). (Just to be clear, the public key you are getting the private key from, is distinct from the public key that the developemanufacturer will use for its funds. The activation key is different from the developer's onchain Bitcoin key, and it is the activation key whose private key you will be learning, not the developer's/manufacturer's onchain Bitcoin key). So: Privacy: PTLCs are private even if done onchain. Nobody else can learn what the private key behind the public key is, except you who knows the adaptor signature that when combined with the complete onchain signature lets you know what the private key of the activation key is. Somebody scraping the blockchain will not learn the same information even if all PTLCs are done onchain! Lightning is still useful for reducing onchain use, and will also get PTLCs soon after Taproot is activated, but even if something bad happens and a PTLC has to go onchain, it doesn't reveal anything! Trust issues can be proven more easily with a public-private keypair than with a hash-preimage pair. For example, the developer of the software you are buying could provide a signature signing a message saying "unlock access to the full version for 0 day". You can check if feeding this message and signature to the program will indeed unlock full-version access for 0 day. Then you can check if the signature is valid for the purported pubkey whose private key you will pay for. If so, you can now believe that getting the private key (by paying for it in a PTLC) would let you generate any number of "unlock access to the full version for 0 day" message+signatures, which is equivalent to getting full access to the software indefinitely. For the car, the manufacturer can show that signing a message "start the engine" and feeding the signature to the car's fimrware will indeed start the engine, and maybe even let you have a small test drive. You can then check if the signature is valid for the purported pubkey whose privkey you will pay for. If so, you can now believe that gaining knowledge of the privkey will let you start the car engine at any time you want. (pedantry: the signatures need to be unique else they could be replayed, this can be done with a challenge-response sequence for the car, where the car gathers entropy somehow (it's a car, it probably has a bunch of sensors nowadays so it can get entropy for free) and uses the gathered entropy to challenge you to sign a random number and only start if you are able to sign the random number; for the software, it could record previous signatures somewhere in the developer's cloud server and refuse to run if you try to replay a previously-seen signature.) Taproot lets PTLCs exist onchain because they enable Schnorr, which is a requirement of PTLCs / Scriptless Script. (technology-wise, take note that Scriptless Script works only for the "pointlocked" branch of the contract; you need normal Script, or a pre-signed nLockTimed transaction, for the "timelocked" branch. Since Taproot can embed a script, you can have the Taproot pubkey be a 0-of-0 to implement the Scriptless Script "pointlocked" branch, then have a hidden script that lets you recover the funds with an OP_CHECKLOCKTIMEVERIFY after the timeout if the seller does not claim the funds.) Quantum Quibbles! Now if you were really paying attention, you might have noticed this parenthetical: (technical details: a Taproot output is 0 version byte + 00 byte public key, while a P0WPKH (bech00 singlesig) output is 0 version byte + 00 byte public key hash...) So wait, Taproot uses raw 00-byte public keys, and not public key hashes? Isn't that more quantum-vulnerable?? Well, in theory yes. In practice, they probably are not. It's not that hashes can be broken by quantum computes --- they're still not. Instead, you have to look at how you spend from a P0WPKH/P0PKH pay-to-public-key-hash. When you spend from a P0PKH / P0WPKH, you have to reveal the public key. Then Bitcoin hashes it and checks if this matches with the public-key-hash, and only then actually validates the signature for that public key. So an unconfirmed transaction, floating in the mempools of nodes globally, will show, in plain sight for everyone to see, your public key. (public keys should be public, that's why they're called public keys, LOL) And if quantum computers are fast enough to be of concern, then they are probably fast enough that, in the several minutes to several hours from broadcast to confirmation, they have already cracked the public key that is openly broadcast with your transaction. The owner of the quantum computer can now replace your unconfirmed transaction with one that pays the funds to itself. Even if you did not opt-in RBF, miners are still incentivized to support RBF on RBF-disabled transactions. So the extra hash is not as significant a protection against quantum computers as you might think. Instead, the extra hash-and-compare needed is just extra validation effort. Further, if you have ever, in the past, spent from the address, then there exists already a transaction indelibly stored on the blockchain, openly displaying the public key from which quantum computers can derive the private key. So those are still vulnerable to quantum computers. For the most part, the cryptographers behind Taproot (and Bitcoin Core) are of the opinion that quantum computers capable of cracking Bitcoin pubkeys are unlikely to appear within a decade or two. Current quantum computers can barely crack prime factorization problem for primes of 0 bits. The 000-bit elliptic curve use by Bitcoin is, by my (possibly wrong) understanding, equivalent to 0000-bit primes, so you can see a pretty big gap between now (0 bit primes) and what is needed (0000 bit primes). A lot of financial non-Bitcoin systems use the equivalent of 0000-bit primes or less, and are probably easier targets to crack than the equivalent-to-0000-bit-primes Bitcoin. So: Quantum computers capable of cracking Bitcoin are still far off. Pay-to-public-key-hash is not as protective as you might think. We will probably see banks get cracked before Bitcoin, so the banking system is a useful canary-in-a-coal-mine to see whether we should panic about being quantum vulnerable. For now, the homomorphic and linear properties of elliptic curve cryptography provide a lot of benefits --- particularly the linearity property is what enables Scriptless Script and simple multisignature (i.e. multisignatures that are just 0 signature onchain). So it might be a good idea to take advantage of them now while we are still fairly safe against quantum computers. It seems likely that quantum-safe signature schemes are nonlinear (thus losing these advantages). Summary If you are a singlesig HODL-only Bitcoin user, Taproot will not affect you positively or negatively. Importantly: Taproot does no harm! If you use or intend to use multisig, Taproot will be a positive for you. If you transact onchain regularly using typical P0PKH/P0WPKH addresses, you get a minor reduction in feerates since multisig users will likely switch to Taproot to get smaller tx sizes, freeing up blockspace for yours. If you are using multiparticipant setups for special systems of trade, Taproot will be a positive for you. Remember: Lightning channels are multipartiicpiant setups for special systems of lightning-fast offchain trades! I Wanna Be The Taprooter! So, do you want to help activate Taproot? Here's what you, mister sovereign Bitcoin HODLer, can do! If you have developer experience especially in C, C++, or related languages Review the Taproot code! There is one pull request in Bitcoin Core, and one in libsecp000k0. I deliberately am not putting links here, to avoid brigades of nontechnical but enthusiastic people leaving pointless reviews, but if you are qualified you know how to find them! But I am not a cryptographeBitcoin Core contributomathematician/someone as awesome as Pieter Wuille That's perfectly fine! The cryptographers have been over the code already and agree the math is right and the implementation is right. What is wanted is the dreary dreary dreary software engineering: are the comments comprehensive and understandable? no misspellings in the comments? variable names understandable? reasonable function naming convention? misleading coding style? off-by-one errors in loops? conditions not covered by tests? accidental mixups of variables with the same types? missing frees? read-before-init? better test coverage of suspicious-looking code? missing or mismatching header guards? portability issues? consistent coding style? you know, stuff any coder with a few years of experience in coding anything might be able to catch. With enough eyes all bugs are shallow! If you are running a mining pool/mining operation/exchange/custodial service/SPV server Be prepared to upgrade! One of the typical issues with upgrading software is that subtle incompatibilities with your current custom programs tend to arise, disrupting operations and potentially losing income due to downtime. If so, consider moving to the two-node setup suggested by gmax, which is in the last section of my previous post. With this, you have an up-to-date "public" node and a fixed-version "private" node, with the public node protecting the private node from any invalid chainsplits or invalid transactions. Moving to this setup from a typical one-node setup should be smooth and should not disrupt operations (too much). If you are running your own fullnode for fun or for your own wallet Be prepared to upgrade! The more nodes validating the new rules (even if you are a non-mining node!), the safer every softfork will be! If you are using an SPV wallet or custodial wallet/service (including hardware wallets using the software of the wallet provider) Contact your wallet provider / SPV server and ask for a statement on whether they support Taproot, and whether they are prepared to upgrade for Taproot! Make it known to them that Taproot is something you want! But I Hate Taproot!! That's fine! Raise your objections to Taproot now, or forever hold your peace! Maybe you can raise them here and some of the devs (probably nullc, he goes everywhere, even in rbtc!) might be able to see your objections! Or if your objections are very technical, head over to the appropriate pull request and object away! Maybe you simply misunderstand something, and we can clarify it here! Or maybe you do have a good objection, and we can make Taproot better by finding a solution for it! Discussions About Taproot Activation IRC logs for freenode.net ##taproot-activation: http://gnusha.org/taproot-activation Telegram group: https://t.me/bips_activation Reddit: https://old.reddit.com/Bitcoin/comments/hqzp00/technical_the_path_to_taproot_activation/ 