Author: Andrew Poelstra 2021-03-16 13:28:34
Published on: 2021-03-16T13:28:34+00:00
Luke Dashjr and Andrew Poelstra have been discussing the potential issues with Taproot. While Dashjr does not intend to NACK Taproot, he expresses frustration at having to rehash the discussion after so many years. Poelstra argues that Taproot would save significant CPU time and bandwidth. However, Dashjr is concerned about how it will affect all nodes, especially those without sufficient bandwidth. Poelstra claims that Taproot keys, when used in accordance with BIP-0341, are already hashes of their internal keys. This makes Taproot outputs more quantum-resistant than legacy outputs. Additionally, adding another hash would be redundant. However, Dashjr argues that adding an extra hash would prevent attackers from obtaining the original key and creating a new private key. Poelstra disagrees and says that if there is a quantum computer, Bitcoin is screwed anyway. Furthermore, adding an extra hash would reduce privacy, create confusion and delays for people implementing Taproot, and slow down Bitcoin nodes that would have to validate the additional material. However, Taproot has distinct benefits over legacy outputs, including the ability to provide extra data to prove in a QC-hard way, even if the internal key is compromised. Taproot keys can also be chosen to be provably unspendable except by a DL break.
Updated on: 2023-06-14T19:32:27.602115+00:00