Michael Folkson [ARCHIVE] on Nostr: 📅 Original date posted:2022-01-20 📝 Original message:Hi I'd just like to bring ...
📅 Original date posted:2022-01-20
📝 Original message:Hi
I'd just like to bring some attention to this blog post from the Suredbits team who when implementing Taproot in bitcoin-s found a mainnet output that did not conform to the BIP 340 specification [0] (invalid x coordinate) and hence were burned.
https://suredbits.com/taproot-funds-burned-on-the-bitcoin-blockchain/
To be clear this is was an error made by an unknown developer rather than a bug in the Taproot BIPs or Core implementation.
I'd certainly encourage the community to share with this list mistakes they make or things they find confusing (i.e. stump them for long periods of time) when re-implementing Taproot or supporting Taproot in wallets. I suspect things like eliminating the key path [1] or eliminating the script path [2] will end up being common sources of confusion for wallets.
I'm also open to ideas on how there can be greater information sharing so Taproot implementers don't end up making the same mistakes or spending hours confused over the same things.
I've heard some feedback on a number of occasions now that the Taproot BIPs although thorough and exhaustive aren't geared directly towards implementers and adopters. We discussed this at an online Socratic last year [3] with Craig Raw an early Taproot adopter with Sparrow Wallet. The transcript of that links to a bunch of existing resources (StackExchange posts, the Optech series "Preparing for Taproot", Optech workshop etc) that may be useful for implementers.
wumpus also suggested that a new informational BIP might be a good idea as a first port of call for Taproot implementers who find BIP 340-342 dense and difficult to parse. This is certainly something we can do once it becomes clearer what that informational BIP should contain.
Of course the Libera IRC channels #bitcoin-dev (for general Bitcoin development) and #bitcoin-core-dev (for Core related development) are there for discussion and questions. And as many will already know Murch is tracking P2TR support on the Bitcoin wiki [4].
Thanks
Michael
[0]: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#design
[1]: https://bitcoin.stackexchange.com/questions/99722/taproot-eliminating-key-path
[2]: https://bitcoin.stackexchange.com/questions/99325/how-do-i-construct-a-p2tr-address-if-i-just-want-to-use-the-key-path
[3]: https://btctranscripts.com/london-bitcoin-devs/2021-07-20-socratic-seminar-taproot-rollout/
[4]: https://en.bitcoin.it/wiki/Bech32_adoption
-- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220120/3e6a6d5a/attachment.html>;
📝 Original message:Hi
I'd just like to bring some attention to this blog post from the Suredbits team who when implementing Taproot in bitcoin-s found a mainnet output that did not conform to the BIP 340 specification [0] (invalid x coordinate) and hence were burned.
https://suredbits.com/taproot-funds-burned-on-the-bitcoin-blockchain/
To be clear this is was an error made by an unknown developer rather than a bug in the Taproot BIPs or Core implementation.
I'd certainly encourage the community to share with this list mistakes they make or things they find confusing (i.e. stump them for long periods of time) when re-implementing Taproot or supporting Taproot in wallets. I suspect things like eliminating the key path [1] or eliminating the script path [2] will end up being common sources of confusion for wallets.
I'm also open to ideas on how there can be greater information sharing so Taproot implementers don't end up making the same mistakes or spending hours confused over the same things.
I've heard some feedback on a number of occasions now that the Taproot BIPs although thorough and exhaustive aren't geared directly towards implementers and adopters. We discussed this at an online Socratic last year [3] with Craig Raw an early Taproot adopter with Sparrow Wallet. The transcript of that links to a bunch of existing resources (StackExchange posts, the Optech series "Preparing for Taproot", Optech workshop etc) that may be useful for implementers.
wumpus also suggested that a new informational BIP might be a good idea as a first port of call for Taproot implementers who find BIP 340-342 dense and difficult to parse. This is certainly something we can do once it becomes clearer what that informational BIP should contain.
Of course the Libera IRC channels #bitcoin-dev (for general Bitcoin development) and #bitcoin-core-dev (for Core related development) are there for discussion and questions. And as many will already know Murch is tracking P2TR support on the Bitcoin wiki [4].
Thanks
Michael
[0]: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#design
[1]: https://bitcoin.stackexchange.com/questions/99722/taproot-eliminating-key-path
[2]: https://bitcoin.stackexchange.com/questions/99325/how-do-i-construct-a-p2tr-address-if-i-just-want-to-use-the-key-path
[3]: https://btctranscripts.com/london-bitcoin-devs/2021-07-20-socratic-seminar-taproot-rollout/
[4]: https://en.bitcoin.it/wiki/Bech32_adoption
-- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220120/3e6a6d5a/attachment.html>;