Taproot activates - A time/block line

I thought I would collect together the highlights from Taproot activating for those strange Bitcoin history buffs (including myself). If you’d rather watch in video form 0xB10C provided an excellent livestream [0] showing blocks and transactions in the run up to and directly after Taproot activating.

Back in July [1] 0xB10C (with the help of F2Pool) spent from Taproot (P2TR) outputs months before Taproot activated. Taproot rules weren’t being enforced and hence these spends were treated as anyone-can-spend. Hence I won’t treat these as the “first” Taproot spends as they didn’t need to meet Taproot consensus rules.

Block 709631: The last block before Taproot rules were enforced was mined by AntPool. By this point there were various P2TR outputs in blocks, some timelocked for higher than block 709631 but others not timelocked. These non-timelocked P2TR outputs were in effect anyone-can-spend like the ones 0xB10C spent from in July as Taproot rules were not yet being enforced. No P2TR outputs were spent immediately before activation as far as I can tell.

Block 709632: The first block where full nodes started enforcing Taproot rules was mined by F2Pool. It seems [2] F2Pool wasn’t enforcing Taproot rules and did not include any Taproot spends (some with high fee rates) in this block. More seriously an invalid Taproot spend included in this block could have cost them the block reward and caused a re-org when full nodes (and miners) enforcing Taproot rules rejected this block. Given they didn’t include any attempted Taproot spends (valid or invalid) in the block this protected them from that but it does lead to discussions for a later time on whether Speedy Trial signaling was effective if some mining pools signaled readiness months previous but then did not enforce the new soft fork rules on activation.

Block 709633: Mined by AntPool. Similar to F2Pool they didn’t include any Taproot spends in this block and one would assume that they also weren’t enforcing Taproot rules though this has not been confirmed.

Block 709634: Also mined by AntPool.

Block 709635: The first block which included (numerous) valid Taproot spends (and no invalid Taproot spends) was mined by Foundry USA.

The first Taproot spend [3] was completed by bitbug42. It was a key path spend and the OP_RETURN in this first Taproot spend contained the message “I like Schnorr sigs and I cannot lie”.

Andrew Chow had the second Taproot spend [4] but the first script path spend. He also spent from two Taproot vanity addresses beginning bc1ptapr00t which were presumably generated using his Rust Bitcoin Vanity Address Generator [5].

Pieter Wuille had the third Taproot spend [6]. He also had the bronze medal for SegWit spends on SegWit activation in 2017 [7], he was third then too. However, his vanity address game stepped up for Taproot. For SegWit he spent from one vanity address beginning 35Segwit. This time he spent from vanity addresses beginning bc1ptapr00tearly, bc1pay2tapr00t, bc1pmyusetapr00t, bc1partytaptap and this isn’t including all the vanity addresses that were sent to. He (with Greg Maxwell’s help) searched 2.4 quadrillion keys in a week [8].

BitGo had the fourth Taproot spend [9] and the first Taproot multisig spend via the script path. The script used OP_CHECKSIG and OP_CHECKSIGVERIFY which have been modified with the Taproot upgrade to check Schnorr signatures but it didn’t use the new opcode OP_CHECKSIGADD that has been introduced for threshold (and multi) signatures. It contained an OP_RETURN message with “Thx Satoshi! ∞/21mil First Taproot multisig spend -BitGo”

jaoNoctus claimed the fifth Taproot spend and narcelio and ottosch claimed the sixth and seventh Taproot spends.

The first use of OP_CHECKSIGADD on mainnet was completed [10] by Alekos Filini using modified code [11] from the BDK (Bitcoin Dev Kit) library.

Any errors are my own and I will gladly correct. Thanks to 0xB10C, Greg Maxwell, Pieter Wuille, Murch, Andrew Chow, BitGo, Daniel McNally, Rearden Code, Alekos Filini, Chun, pinheadmz for highlighting these various events online. Thanks to the various block explorers (Esplora, mempool.space etc) that were very useful for monitoring Taproot activation. And thanks to the community as a whole for participating and engaging with this successful upgrade. Without participation and engagement these upgrades are meaningless and it is a great sign for Bitcoin’s future that there was so much interest and scrutiny of this upgrade.

[0]: https://www.youtube.com/watch?v=1jijKVB1cNA, https://www.twitch.tv/0xb10c/video/1204909643 [1]: https://b10c.me/blog/007-spending-p2tr-pre-activation/ [2]: https://twitter.com/satofishi/status/1459868549674065926?s=20 [3]: 33e794d097969002ee05d336686fc03c9e15a597c1b9827669460fac98799036 [4]: 37777defed8717c581b4c0509329550e344bdc14ac38f71fc050096887e535c8 [5]: https://github.com/achow101/rust-vanitygen [6]: 83c8e0289fecf93b5a284705396f5a652d9886cbd26236b0d647655ad8a37d82 [7]: https://twitter.com/0xB10C/status/1459592608305582090?s=20 [8]: https://twitter.com/pwuille/status/1459778731548057603?s=20 [9]: 905ecdf95a84804b192f4dc221cfed4d77959b81ed66013a7e41a6e61e7ed530 [10]: 2eb8dbaa346d4be4e82fe444c2f0be00654d8cfd8c4a9a61b11aeaab8c00b272 [11]: https://gist.github.com/afilini/7c2c33af095ea975f52f5d68302c91d6

Thanks, Michael, for writing this up. I agree that it's good to archive events like, for example, soft-fork activations in an ML post.

All bigger pools have now included multiple P2TR spends in their blocks. I have a few comments on what happened at F2Pool and to some extend also at AntPool. These were pool number three and pool number five to signal taproot readiness. I'm not affiliated with them but was happy to help F2Pool out and return the favor[1] when they asked for help debugging why they don't include P2TR spends. I have the permission to share some pool internals and hope this can help make future soft-forks even smoother.

Please take my comments with a grain of salt. On the one hand, it could be that I'm naive in believing what the pools have told me in private communication. On the other hand, I'm not as marked from the blocksize war as others might be.

On 11/15/21 3:42 PM, Michael Folkson via bitcoin-dev wrote:

> [..]
>
> Block 709632: The first block where full nodes started enforcing
> Taproot rules was mined by F2Pool. It seems [2] F2Pool wasn’t
> enforcing Taproot rules and did not include any Taproot spends (some
> with high fee rates) in this block. [..] but it does lead to
> discussions for a later time on whether Speedy Trial signaling was
> effective if some mining pools signaled readiness months previous but
> then did not enforce the new soft fork rules on activation.
>
> Block 709633: Mined by AntPool. Similar to F2Pool they didn’t include
> any Taproot spends in this block and one would assume that they also
> weren’t enforcing Taproot rules though this has not been confirmed.
>
> Block 709634: Also mined by AntPool.
>
> Block 709635: The first block which included (numerous) valid Taproot
> spends (and no invalid Taproot spends) was mined by Foundry USA.
>
> [..]
>
> [1]: https://b10c.me/blog/007-spending-p2tr-pre-activation/
> [2]: https://twitter.com/satofishi/status/1459868549674065926
> <https://twitter.com/satofishi/status/1459868549674065926?s=20>
>
> [..]

While F2Pool responded they "Will upgrade soon" [2] to my question if they haven't upgraded their nodes yet, I think they were primarily buying time as they them-self weren't sure what the issue is. "We are looking into it" could have been a better and more fitting response.

An F2Pool engineer reached out on the 16th (two days after activation), mentioning they had been running Bitcoin Core v0.21.1 for a few weeks now and upgraded to v22.0 today (on the 16th) in the hope that this would fix their problem of not including P2TR spends. They asked if I could create and _not_ broadcast a P2TR spending transaction for them to check with testmempoolaccept/sendrawtransaction/getblocktemplate.

I constructed and sent a P2TR spend and asked them to check the versions of their nodes peers too. testmempoolaccept returned "allowed": true (expected as they were running >= v0.21.1). However, it turned out that they weren't connected to any P2TR-spend-relaying peers. They didn't receive any P2TR spending transaction and couldn't include them in their block templates. It seems like this was caused by a) using addnode to directly connect to known, external peers that hadn't upgraded. But more importantly, b) by applying a custom patch to their node's peer selection behavior based on a heuristic that worked for a few years but at some point broke without being noticed (I'm not publishing details on purpose). F2Pool has fixed this. With connections to >= v0.21.1 nodes, they started receiving and constructing blocks with P2TR spends.

I haven't been in contact with AntPool directly and don't know details about their situation. Alejandro De La Torre (@bitentrepreneur) communicated with them and said I can include the following:

"I spoke with antpool after I noticed from b10c’s tweet that they had not included P2TR [spends]. They were quick to react when I inquired. They had not updated to bitcoind 22.0, but had tested it and were planning to update soon. The next day they indeed updated and were able to include a tx with a P2TR spend."

and

"[Anpool] said that the old peer issue that F2Pool faced 'may be the issue'."

AntPool didn't provide more information to Alejandro. It's not clear to me what the actual issues and fixes were.

I'll leave it to someone else to properly reflect on speedy trial. I, however, want to add: F2Pool mentioned that they "upgraded to v0.21.1 several weeks ago". This indicates that they were signaling without being ready. I don't blame them and assume they were not the only pool just setting the version bit. IMO some of the motivations for fake signaling: a) Immense community pressure (e.g., on Twitter) to just set the bit and then get ready in the next six months. b) Running nodes with custom patches. These require longer to upgrade, especially if you want to ensure there aren't any bugs in your patches...

It's out of the scope of the Bitcoin Core project to consider people's custom patches, and it's impossible if they are unpublished. In this particular case, upstreaming the patch does not make sense.

However, with only just above 50% of taproot nodes[3] (more than a week after activation), there might still be motivation for having a feature (sometime before the next soft-fork) to alert/warn a node operator if his node does not have any peers relaying soft-fork X transaction. Should PROTOCOL_VERSION be bumped to show support for soft-fork transaction relay? Or does a service flag for relay makes sense (it seems complicated to decommission service flags reliably)? Parsing the subver (e.g. "/Satoshi:0.21.1/") doesn't make sense as there are not only Bitcoin Core nodes on the network. Could there be a message that is exchanged between two nodes to indicate soft-fork readiness?

How a node operator can be alerted, besides logging, is an implementation detail of Bitcoin Core. Maybe a getnodealerts RPC that a node operator can hook up to his monitoring?

Additionally, for the next soft-fork where relay is affected, instructions for mining pool signaling could state: "Upgrade to version Z and make sure you have a few version Z peers before starting to signal readiness".

Thanks, 0xB10C

[3] http://azure.erisian.com.au/~aj/taproot/taproot.html