Taproot proposal

[arulbero]

A question:
the current hardware wallets (like Ledger Nano, Trezor, ... ) don't support taproot and schnorr signatures.

Will a software update be enough?

[gmaxwell]

A question:
the current hardware wallets (like Ledger Nano, Trezor, ... ) don't support taproot and schnorr signatures.

Will a software update be enough?

Yes, though the fact that some use their own custom crypto libraries due to altcoin support and it may take them a little while to get around to writing it.

[Bttzed03]

I just came across this tweet that Binance said yes to Taproot.



How much more is needed before it's activated? Is 91.05% not enough?

[Carlton Banks]

i doubt it's activated before Bitcoin Core (and other full node client) have option to signal taproot activation.

there is nothing to activate until nodes begin to run using code that implements BIPs 340-342, there is currently a tiny number of nodes (less than 100 out of 60-70,000) running the 0.21.0 release candidate, and as far as is publicly known, no-one (working on either Bitcoin Core or at the pools/miners) has what anyone considers a final version of activation logic either. So I agree, activation is rather doubtful before the release of a final version of Bitcoin 0.21.1, let alone Bitcoin 0.21.0

as far as 90% being enough to activate, I suspect it will be for the same reasons that I thought 80% would be: miners will take the conservative route of signalling the fork, so long as nodes adopt 0.21.0, not doing so carries the risk of getting any blocks they solve being orphaned from the blockchain using the BIP91 logic that is a part of BIP8 (the candidate activation logic for new soft forks for Bitcoin)

[acquafredda]

i doubt it's activated before Bitcoin Core (and other full node client) have option to signal taproot activation.

there is nothing to activate until nodes begin to run using code that implements BIPs 340-342, there is currently a tiny number of nodes (less than 100 out of 60-70,000) running the 0.21.0 release candidate, and as far as is publicly known, no-one (working on either Bitcoin Core or at the pools/miners) has what anyone considers a final version of activation logic either. So I agree, activation is rather doubtful before the release of a final version of Bitcoin 0.21.1, let alone Bitcoin 0.21.0

as far as 90% being enough to activate, I suspect it will be for the same reasons that I thought 80% would be: miners will take the conservative route of signalling the fork, so long as nodes adopt 0.21.0, not doing so carries the risk of getting any blocks they solve being orphaned from the blockchain using the BIP91 logic that is a part of BIP8 (the candidate activation logic for new soft forks for Bitcoin)

However, to have now a big majority of pools signalling some sort of support towards the upgrade can be considered a good sign. While we wait for the right release for the activation, we might enjoy some mining pools consensus 

[gmaxwell]

Progress here is waiting on the deployment of 0.21.0 which is delayed, I think because it was discovered at the 11th hour that some P2P protocol update caused all existing BTCD software to instant-disconnect due to it erroneously hanging up on unexpected messages.

After 0.21.0 is out and stable then a 0.21.1 could be done with taproot activation.

[fillippone]

0.21 is out, as widely anticipated Schnorr/Taproot code is now included, albeit not yet activaded.

We read the release notes.

- - This release implements the proposed Taproot consensus rules
  ([BIP341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) and
  [BIP342](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki)),
  without activation on mainnet. Experimentation with Taproot can be done on
  signet, where its rules are already active. (#19553)

On his usual new release review:

Bitcoin Core 0.21.0 Released: What’s New

Aaron van Wirdum describes for the less technical of us: 

Schnorr/Taproot Code and Signet/Regtest Deployment


Schnorr/Taproot is poised to be Bitcoin’s first protocol upgrade since Segregated Witness (SegWit) in August 2017. Having been in development for well over two years, the Schnorr signature algorithm is considered an all-round improvement over Bitcoin’s current ECDSA signature algorithm. In combination with Taproot — a clever trick to hide various conditions to spend coins in a cryptographic hash tree — the upgrade promises to offer more smart contract flexibility in a scalable and privacy-preserving manner.

The Schnorr/Taproot code is now included in Bitcoin Core 0.21.0. Barring unexpected developments, this means it will not be subject to any more change, which for example means that application developers could start designing software around the upgrade. In addition, Schnorr/Taproot is now available on Signet (a newer and more reliable variant of testnet, used by developers to test new Bitcoin software) and potentially also on Regtests (additional local testnet variants).

Schnorr/Taproot will not, however, be available on Bitcoin’s mainnet just yet. For this, the upgrade will first need to activate, which requires activation logic that isn’t yet included in this Bitcoin Core release. Activation logic is expected to be included in a minor Bitcoin Core release, possibly somewhere in the next months.

[Karartma1]

Come on, then! Let's get 0.21.1 underway so that this very much needed update can get finally activated.
I see in the release notes many Tor improvements too, which is good. Cool.

[9kek]

46% of nodes already upgraded to 0.20.1:

[9kek]

Am i missing your point? 0.20.1 is older version and doesn't have schnorr/taproot code. 0.21.0 have schnorr/taproot code, but don't have activation signal/logic.

oops, my fault, I read "News: Latest Bitcoin Core release: 0.20.1 [Torrent]" in the header and I tough it was the most recent version.

0.21.0 it's at 8th place (about 2.9% of nodes):

[xmready]

When Taproot+Schnorr becomes activated, will we need to create new addresses to benefit from the privacy? Will old addresses that broadcast transactions benefit? Will using the features provided by the upgrade be automatic or will we have to specify when creating transactions?

[gmaxwell]

When Taproot+Schnorr becomes activated, will we need to create new addresses to benefit from the privacy? Will old addresses that broadcast transactions benefit? Will using the features provided by the upgrade be automatic or will we have to specify when creating transactions?

For these questions the applicable time is not when it's activated-- it's when your wallet supports it which will be sometime after the activation.

After your wallet supports it, new addresses will use it.  Maybe in the first versions it will be optional and off by default but eventually it'll just be a default behaviour and you won't have to do anything to get it (besides request new addresses, which you should already be doing for each txn).

Unrelated,  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018370.html

[xmready]

For these questions the applicable time is not when it's activated-- it's when your wallet supports it which will be sometime after the activation.

After your wallet supports it, new addresses will use it.  Maybe in the first versions it will be optional and off by default but eventually it'll just be a default behaviour and you won't have to do anything to get it (besides request new addresses, which you should already be doing for each txn).

Unrelated,  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018370.html

Appreciate the insight, thank you.

For power users of Bitcoin I understand that creating a new address for every txn is common sense, thus new upgrades will apply to them. Can you expand on how these upgrades affect people who required assistance making a paper wallet and only use one address as a "savings account"? These types of users don't follow or understand fully the protocol and it's relevant upgrades. All they know is they have a QR code to load the address whenever they buy and a private key or seed under lock and key. Even if you explain protocol to them, they tend to forget. If I'm interpreting your response correctly, these users won't benefit from upgrades like this when they spend their coin unless they transfer their savings to a new address first.

Are there significant downsides to these users using the same address every time they buy from an exchange since the exchange already has their KYC info? Hopefully this last question isn't too off topic here.

[Carlton Banks]

Are there significant downsides to these users using the same address every time they buy from an exchange since the exchange already has their KYC info? Hopefully this last question isn't too off topic here.

one significant downside should perfectly align with the incentives of such a user (who presumably is only interested in the value of their BTC savings): if they want to send an amount that's bigger than the largest unspent utxo, then it's more expensive to do so, because they need more than one tx input to do so. and there are also the obvious privacy issues (which harm everyone's privacy to a lesser extent).

Ideally, custodial services (e.g. exchanges) would permit BIP79 transactions for client withdrawals (and also use them for client deposits). This would save transaction fees, as well as defeat passive analysis of the blockchain to track utxo ownership. A few (not many) custodial services support BIP79 (aka P2EP/Payjoin), hopefully more will in future. Wallet support is also lacking, so it's a chicken & egg problem

[xmready]

if they want to send an amount that's bigger than the largest unspent utxo, then it's more expensive to do so, because they need more than one tx input to do so. and there are also the obvious privacy issues (which harm everyone's privacy to a lesser extent).

If they are sweeping the entire balance from the exchange with no utxo, would this be irrelevant?

Ideally, custodial services (e.g. exchanges) would permit BIP79 transactions for client withdrawals (and also use them for client deposits). This would save transaction fees, as well as defeat passive analysis of the blockchain to track utxo ownership. A few (not many) custodial services support BIP79 (aka P2EP/Payjoin), hopefully more will in future. Wallet support is also lacking, so it's a chicken & egg problem

Even if the paper withdrawal address doesn't change, as long as it's segwit, can these types of users benefit from BIP79 transactions without taproot+schnorr? I don't see it as a requirement on the pull request.

the incentives of such a user (who presumably is only interested in the value of their BTC savings)

I think these users can share an interest in value alongside an interest in BTC being good for the world. They can remember banks=bad and freedom=good, but not protocol details. They can remember how to use a hot wallet on their phone, but not how to re-setup their cold storage.

[pooya87]

0.21.0 it's at 8th place (about 2.9% of nodes):

2.9% of nodes listed on bitnodes.io which they claim are "reachable nodes" not all full nodes. Also a lot of their 0.20 nodes are fake.

According to https://luke.dashjr.org/programs/bitcoin/files/charts/software.html there are 6776 nodes running 0.21 out of 83327 core nodes (8.1%). Although it doesn't provide any IP list so it can not be validated.
There is also an increase in number of existing nodes (near 2x rise) in January from around 46k to 85k which seems interesting.

[xmready]

But there's another way. We could encourage them to use wallet/software which generate Taproot address by default, they could enjoy the benefit without even realizing it.

Running wallet software on their daily driver is a solution, but risky. This type of user runs a major hacking risk by storing large amounts on an online wallet capable of generating new addresses. For an example, lets use the parents of a friend I help with computer stuff. They have been phished multiple times, not learning from their mistakes. Even though they understand Bitcoin is freedom, banks are bad, and custodial risk is real, it doesn't make them better at computers or evaluating attack vectors.

They could use a linux USB to generate new wallets/addresses offline and have a watch only wallet on their daily driver. But they would need someone to help them every time there is an upgrade that requires user action. Doing it on their own is as unreasonable as asking them not to get hacked or figuring out a hardware wallet.

This is the biggest problem I see with protocol upgrades that require user action. Non power users will either fall behind without consistent help from someone, or their coins will fall subject to hacker/custodial risk. Maybe this is unsolvable or maybe in the future it will be easier for them to generate new addresses from their online computer without risk. Am I missing something?

[ABCbits]

But there's another way. We could encourage them to use wallet/software which generate Taproot address by default, they could enjoy the benefit without even realizing it.

Running wallet software on their daily driver is a solution, but risky. This type of user runs a major hacking risk by storing large amounts on an online wallet capable of generating new addresses. For an example, lets use the parents of a friend I help with computer stuff. They have been phished multiple times, not learning from their mistakes. Even though they understand Bitcoin is freedom, banks are bad, and custodial risk is real, it doesn't make them better at computers or evaluating attack vectors.

They could use a linux USB to generate new wallets/addresses offline and have a watch only wallet on their daily driver. But they would need someone to help them every time there is an upgrade that requires user action. Doing it on their own is as unreasonable as asking them not to get hacked or figuring out a hardware wallet.

This is the biggest problem I see with protocol upgrades that require user action. Non power users will either fall behind without consistent help from someone, or their coins will fall subject to hacker/custodial risk.

I agree with you, but this problem apply to technological change/development in general.

Maybe this is unsolvable or maybe in the future it will be easier for them to generate new addresses from their online computer without risk.

Risk always exist, but it could be mitigated if future OS is designed with very strict security. Android already take first step by enforce sandboxing and permission.

[cygan]

This is the first in a series of posts about about covenants in Bitcoin using Taproot and a (hypothetical) CAT opcode. Historically, and as has been implemented in Elements, CAT has been considered to be a covenant opcode only in conjunction with CHECKSIGFROMSTACK. In this post, which will be much mathier than later ones, we'll talk about how to abuse the math of Schnorr signatures to emulate the functionality of CHECKSIGFROMSTACK.

https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298

[Karartma1]

This is the first in a series of posts about about covenants in Bitcoin using Taproot and a (hypothetical) CAT opcode. Historically, and as has been implemented in Elements, CAT has been considered to be a covenant opcode only in conjunction with CHECKSIGFROMSTACK. In this post, which will be much mathier than later ones, we'll talk about how to abuse the math of Schnorr signatures to emulate the functionality of CHECKSIGFROMSTACK.

https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298

Interesting, particularly where the author himself ask a revelant question here

are these sighash-templating covenants powerful enough to actually do anything, given the consensus limits of Script?

After reading that article I remember a discussion I read on that specific matter on the bitcoin dev mailing list that can be found here
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016996.html
Would be interested to read a few comments on this by some of you guys.