Mention activation heights in BIP 341 🥕

[maflcko]

While this change isn't needed, I think it is nice for the reader to tell if and when the deployment activated.

ping @sipa, @jonasnick, @ajtowns for ACK or NACK

[michaelfolkson]

It definitely activated by block 709635. I guess we have to ask the mining pools (F2Pool, AntPool) of blocks 709632-709634 whether they were enforcing Taproot rules and just didn't include Taproot spends in those blocks or whether they weren't enforcing Taproot rules. You'd guess the latter given the fee rates that were available.

We are also in the same boat as earlier activation param discussions where BIP authors are being asked to be the authority on the activation height of their own soft fork. Doesn't seem ideal to me.

ACK (with reservations on repeating this process for any future soft forks)

[maflcko]

It definitely activated by block 709635.

Just because no taproot spend txs were included in previous blocks that already enforced the rules, doesn't mean the deployment activated later. If you were running a full node that implements BIP 341 (the bip that this patch is modifying), then that full node absolutely activated and enforced taproot at 709632.

I guess we have to ask the mining pool

Just because those pools had initial issues including taproot spends (or still have) doesn't mean they didn't or don't enforce taproot. I personally had issues relaying my taproot spends on the network. I sent them on one node, but couldn't observe them on another node. Also, some taproot supporting block explorers didn't show them. So most likely those are just p2p relay issues, as taproot spends won't be relayed by network peers that don't understand taproot. In any case this is irrelevant to the changes here.

BIP authors are being asked to be the authority on the activation height

This patch is clarifying the activation height given the already existing activation method and deployment parameters in this BIP. This activation height is assuming that BIP-143-aware miners signalled readiness for it. If you want to discuss the BIP process, it might be better discussed in a separate thread.

[michaelfolkson]

Just because those pools had initial issues including taproot spends (or still have) doesn't mean they didn't or don't enforce taproot. I personally had issues relaying my taproot spends on the network. I sent them on one node, but couldn't observe them on another node. Also, some taproot supporting block explorers didn't show them. So most likely those are just p2p relay issues, as taproot spends won't be relayed by network peers that don't understand taproot.

The hypothesis that none of the Taproot spends reached those mining pools seems like an unlikely one to me, it would be good to find out for sure though. Whether it was that or not being ready despite signaling readiness months previous, we wouldn't want either to be repeated for any future soft fork ideally if we can avoid it.

[michaelfolkson]

It appears F2Pool hadn't upgraded and didn't enforce Taproot rules on 709,632. I don't know if the lesson is we need to do better on communication (an invalid Taproot spend could have cost them a lot of money) or the period between lockin and activation of Speedy Trial was too long. Mining pools just flipped the version bit during signaling but activation was so far away it didn't mean anything perhaps.

[sipa]

It definitely activated by block 709635.

When, and whether mining pools updated, and when the first taproot spend is mined is irrelevant here. The network of BIP341 compliant nodes started enforcing taproot consensus rules in block 709632.

A discussion can be had about what caused miners to not update and/or accept taproot transactions until later, but that has nothing to do with activation.

[sipa]

ACK 9fe7260

[maflcko]

@luke-jr @kallewoof

[jonasnick]

ACK 9fe7260