[2021-06-12] Bitcoin Taproot upgrade finally locked-in, activation set for Novem

[Woodie]

Bitcoin Taproot upgrade finally locked-in, activation set for November

The Taproot upgrade has achieved the first significant milestone on the road to activation as 90% of the Bitcoin (BTC) mining hash rate signaled for the protocol improvement within the current difficulty epoch.

Data from Taproot.watch, a webpage created by Bitcoin developer Hampus Sjöberg, shows the lock-in stage is now completed.

All recognized mining pools signaled for the upgrade with Slush Pool being the first to do so. It is perhaps fitting that Slush Pool also mined block 687285 that sealed the Taproot lock-in.

AntPool and F2Pool — the top two Bitcoin mining pools by hash rate share — were also among one of the earliest supporters of the Taproot activation in the BTC mining arena

Read more https://cointelegraph.com/news/bitcoin-taproot-upgrade-finally-locked-in-activation-set-for-november

[1714126649]

1714126649

[1714126649]

1714126649

[o_e_l_e_o]

Congrats to gmaxwell and everyone who has worked on this.

You should ahead over to https://taproot.watch/ and watch the celebration video they posted if you haven't already. Gave me a good chuckle. Also very cool that the speedy trial method was successful. Hopefully the same can be used in the future to speed up the deployment of various upgrades.

Obviously Taproot is good for a number of reasons, but I'm most excited about being able to open and close Lightning channels without any external party being able to tell that's what I've done. In terms of the small scalability improvement it brings, does anyone have a rough figure of how much space would be saved in each block if every transaction adopted Taproot?

[acquafredda]

Congrats to gmaxwell and everyone who has worked on this.

You should ahead over to https://taproot.watch/ and watch the celebration video they posted if you haven't already. Gave me a good chuckle. Also very cool that the speedy trial method was successful. Hopefully the same can be used in the future to speed up the deployment of various upgrades.

Obviously Taproot is good for a number of reasons, but I'm most excited about being able to open and close Lightning channels without any external party being able to tell that's what I've done. In terms of the small scalability improvement it brings, does anyone have a rough figure of how much space would be saved in each block if every transaction adopted Taproot?

I am with you on that o_e_l_e_o: I cannot wait until we will be able to go in and out of LN without revealing anything to the outside lurkers. This very important change will make LN more and more appeailing to bitcoiners for their everyday transactions.
By the way, today the mempool is extraordinarily empty, go and consolidate if you guys need to.

[buwaytress]

In terms of the small scalability improvement it brings, does anyone have a rough figure of how much space would be saved in each block if every transaction adopted Taproot?

Actually was looking for this myself some weeks ago too. Does anyone know of any documentation of how it'll impact the end user in terms of visible changes? Most obvious would be the size of tx I guess but any other visible/obvious changes? Everything I find out there is high level but doesn't actually show me what I as an end user will/could do different.

[o_e_l_e_o]

Actually was looking for this myself some weeks ago too. Does anyone know of any documentation of how it'll impact the end user in terms of visible changes?

Initially, not very much. Nothing changes with the current address types (P2PKH/P2SH/P2WPKH), which all continue to function as they do currently. If you want to make use of Taproot address and transactions, then you will need whatever wallet you are using (if it isn't Bitcoin Core) to first implement support for Taproot addresses, create a Taproot new wallet, and send coins from your legacy/Segwit addresses to your new Taproot addresses.

Once you've done that, nothing should really change in terms of how you receive or spend bitcoin, other than the new address type, which will start with "bc1p" and be longer than the addresses we are used to. If swapping from a standard native SegWit wallet to Taproot, you won't really see any difference in terms of transaction size. Your transactions will be notably smaller if you use multi-sig or some other script.

I've seen some suggestions that if every transaction swapped to Taproot we would save up to around 30% of the space in each block, but I've not seen any actual data to back up this claim.

[Carlton Banks]

I've seen some suggestions that if every transaction swapped to Taproot we would save up to around 30% of the space in each block, but I've not seen any actual data to back up this claim.

that's a generalisation at best

Multisig vastly improves. BIP34 multisig (which was a space-performance improvement on the older multisig scheme) required every possible combination of keys to be published for every spend, despite only one combination being used (I think the limit is 14 out of 15 keys). The worst case there was 15 ^ 2 * 73 bytes (16KB), which is pretty big (but unlikely that all 15 sigs would be 73 bytes, or that a 2 of 15 scheme would be at all common). Schnorr with musig uses one 64 byte signature in all cases, and taproot collapses all the possible branches down to just one. I think the limit on the number of signers has been changed/removed for musig, but can't actually remember accurately.

Lightning open/mutual closes are cut over 50%; schnorr more than halves it, and taproot also more than halves it. Unilateral closes are a slightly bigger script than open/mutual close, but still benefits from schnorr, and from only recording one script branch on-chain.

But regular transactions will save just 8 bytes using 64 byte schnorr sigs, which is less than 5%. Sadly, no possible gains to be had from sig additivity or excised script branches when there's just one signature and one script

But not everyone can use it anyway; it's taken over 4 years for people to move 10% of the Bitcoin supply to native segwit addresses (although usage just hit 70% in blocks). I expect alot of coins will still be resting in the 2010-era P2PKH addresses in another 4 years

[o_e_l_e_o]

that's a generalisation at best

Oh, absolutely. What I was hoping someone could provide would be something along the lines of "X transactions in the last 1000 blocks were multi-sig, using an average of Y vbytes of space. If all these swapped to Taproot, it would save an average of Z vbytes of space in each block".

But regular transactions will save just 8 bytes using 64 byte schnorr sigs, which is less than 5%. Sadly, no possible gains to be had from sig additivity or excised script branches when there's just one signature and one script

The reduction of 8 bytes (actually 9 if you include the absent first byte on the public key) is only when comparing legacy signatures to Taproot signatures. If you compare an entire legacy transaction to an entire Taproot transaction, then (assuming no multi-sig) your standard 1-input-1-output legacy transaction is 192 bytes/192 vbytes, with the equivalent Taproot transaction being somewhere around 178 bytes/111 vbytes, for a saving of 81 vbytes. When you compare a Taproot transaction to a native Segwit transaction, the Taproot transaction (although smaller in terms of raw bytes) is actually marginally larger by 1 or 2 vbytes.

[Carlton Banks]

that's a generalisation at best

Oh, absolutely. What I was hoping someone could provide would be something along the lines of "X transactions in the last 1000 blocks were multi-sig, using an average of Y vbytes of space. If all these swapped to Taproot, it would save an average of Z vbytes of space in each block".

right, but taproot/schnorr/musig savings may change everyone's behavior anyway (plus all the other factors)

But regular transactions will save just 8 bytes using 64 byte schnorr sigs, which is less than 5%. Sadly, no possible gains to be had from sig additivity or excised script branches when there's just one signature and one script

The reduction of 8 bytes (actually 9 if you include the absent first byte on the public key) is only when comparing legacy signatures to Taproot signatures. If you compare an entire legacy transaction to an entire Taproot transaction, then (assuming no multi-sig) your standard 1-input-1-output legacy transaction is 192 bytes/192 vbytes, with the equivalent Taproot transaction being somewhere around 178 bytes/111 vbytes, for a saving of 81 vbytes. When you compare a Taproot transaction to a native Segwit transaction, the Taproot transaction (although smaller in terms of raw bytes) is actually marginally larger by 1 or 2 vbytes.

good points. What's accounting for the difference in virtual size between segwit and taproot txs? the witness discount being less effective, I would suggest. if it was exactly 2 vbytes difference, then that would make sense

[buwaytress]

If you want to make use of Taproot address and transactions, then you will need whatever wallet you are using (if it isn't Bitcoin Core) to first implement support for Taproot addresses, create a Taproot new wallet, and send coins from your legacy/Segwit addresses to your new Taproot addresses.

Here's me hoping my good old Electrum keeps consistent with adoption of new upgrades. Switching to native segwit was a natural progression for me, but admittedly only because Electrum supported it.

But not everyone can use it anyway; it's taken over 4 years for people to move 10% of the Bitcoin supply to native segwit addresses (although usage just hit 70% in blocks). I expect alot of coins will still be resting in the 2010-era P2PKH addresses in another 4 years

On my own anecdotal evidence, I don't know a single one of the services or clients I've had since 2017 whose made the full switch to native segwit (most have supported withdrawals to at least) although a couple of new ones I picked up since did.

And to be fair, I've also still retained P2PKH addresses -- haven't had to use it in a while but not ready to discard as it's still got a few of my old signing addresses.

[o_e_l_e_o]

What's accounting for the difference in virtual size between segwit and taproot txs? the witness discount being less effective, I would suggest. if it was exactly 2 vbytes difference, then that would make sense

A Segwit input is larger than a Taproot input thanks to the smaller signature and absence of including the public key with Taproot. An average Segwit input has 107 bytes of witness data, made up of item count (1), signature length (1), signature (71), pubkey length (1), pubkey (33), whereas Taproot has 65 bytes made up of signature length (1), Schnorr signature (64). Since this is witness data, this difference of 42 bytes equates to Taproot inputs being 10.5 vbytes smaller.

However, a Schnorr public key is 12 bytes larger than a public key hash, making a Taproot output larger.

So all in, for a 1-input-1-output transaction, Taproot will be 1.5 vbytes larger than Segwit (although this can fluctuate slightly depending on the size of the signature fluctuating by a byte or two).

[Carlton Banks]

I would point out here that the witness is discounted only for fees, not for actual storage (storing 3/4 of a signature is not very useful ). So taproot transactions will ease blockchain growth and provide a little more user privacy, but are directly a fraction of a percent more expensive to spend (but only for basic 1 in 1/2 out on-chain transactions).

As I said before, taproot/schnorr brings changes in the economics of multisig and other bitcoin contracts, so we can expect the market's use of such transactions to increase in accordance with that. Whether that means transactions will actually become cheaper in absolute terms is another question altogether; we can expect continuing growth of Bitcoins userbase, particularly payment channels (i.e. lightning), so predictions are not easy.

Some might say that taproot inputs will drive fee growth, because people will probably choose the largest anonymity set in the end (i.e. do all transactions using taproot regardless of fees). To me, that's just validating the idea of pricing and weighting the witness data (specifically sigops) differently. A blockchain using more taproot transactions makes the possible maximum size of blocks smaller, and the difference will be much more pronounced if cross-input aggregation is implemented (this would mean all signatures for separate transactions in a single block would be summed to a single 64 byte signature, fantastic)