P2TR Spending Bug - Signing Transaction Failed #31589

issue Pttn openend this issue on January 2, 2025
  1. Pttn commented at 2:04 am on January 2, 2025: contributor

    Is there an existing issue for this?

    • I have searched the existing issues

    Current behaviour

    Some Segwit Version 1 Addresses generated with Achow101’s Rust-Vanitygen, or more generally some random Addresses imported using the tr(<WIF Private Key>) Descriptor, cause an issue when spending coins using them. Generally, the “Signing transaction failed” error occurs and the transaction is not created. Though, a workaround still allows to spend the coins.

    I don’t know if the issue is exclusive to P2TR, but never encountered such problems with Vanity Version 0 Addresses in the past… I also did not encounter such issue with P2TR Addresses directly generated in Bitcoin Core with getnewaddress or so.

    Maybe it is the same issue as #5828, which was however not been reported with a concrete and reproducible example, and was closed since long… If so, then it would mean that other Address Types may be affected as TapRoot did not exist at this time. I have not found other duplicates, but sorry if I missed one…

    Expected behaviour

    Being able to spend using these Addresses without workarounds.

    Steps to reproduce

    • Optional: Generate a Vanity P2TR Address with the Achow101’s Rust-Vanitygen, modding it or converting the Private Key from Mainnet to Testnet if necessary. Or simply some random WIF Private Key. Some Addresses will work, others exhibit the present issue… It seems that there is a significant proportion falling in the second case…
    • For convenience, you can simply use this one made for this Bug Report:
    0internal_privkey: cNKAo2ZRsaWKcP481cEfj3astPyBrfq56JBtLeRhHUvTSuk2z4MR
    1internal_pubkey: ac414af4b822d67307fe81bef0a72ddf0be9e6ff129eb1270b1168126f619619
    2Address: tb1ptestamfzz5zguhrad6xuf7afua0csz5m6k2qclpnpkvsl20t856sxz2d89
    
    • Import the Address, for example in Testnet4 via the Bitcoin-Qt Console:
    0importdescriptors '[{"desc": "tr(cNKAo2ZRsaWKcP481cEfj3astPyBrfq56JBtLeRhHUvTSuk2z4MR)#vhsk8sfh", "timestamp":0}]'
    
    • Optional: get some coins from a Testnet4 Faucet (or any other source) for this tb1ptestamfzz5zguhrad6xuf7afua0csz5m6k2qclpnpkvsl20t856sxz2d89 Address. When I submitted the Issue, there were some coins left…
    • Optional: Send some amount involving this Address. Immediately after importing the Address, it appears that there is no particular issue. See Transaction a301d660523de70542d30490052f9e04ba3f9b5e26482745c7dbdc952802f103.
    • Restart Bitcoin Core, and try sending again some amount. The interface now shows a “Signing transaction failed” dialog followed by “Transaction creation failed!”. Or, in the Console,
    0sendtoaddress tb1qn9rvr53m7qvrpysx48svuxsgahs88xfsskx367 0.0001
    1Signing transaction failed (code -6)
    
    • However, if a new Wallet is created, and the Descriptor is imported again as above, sending coins is possible again (until Bitcoin Core is restarted again). The process can be repeated to further reuse the Address (which is obviously not practical).

    Relevant log output

    No response

    How did you obtain Bitcoin Core

    Compiled from source

    What version of Bitcoin Core are you using?

    master@228aba2c4d9ac0b2ca3edd3c2cdf0a92e55f669b

    Operating system and version

    Debian 13 Testing

    Machine specifications

    No response

  2. achow101 commented at 4:12 am on January 2, 2025: member

    It looks like this is due to the pubkey evenness bit. The internal key is 03, and this information is known and in memory after importing. But after reloading the wallet, the evenness bit is lost and since the public descriptor stored in the wallet only has the xonly pubkey, so it defaults to 02. Then the signing code is looking for the privkey to the 02 pubkey rather than the 03, is unable to find it, and therefore fails to sign.

    This should only be a problem for tr() descriptors with a non-BIP32 key. This isn’t a problem for the automatically generated descriptors because those all use BIP 32 derivation. Since this also only is an issue for 03 pubkeys, the issue should only happen half of the time.

    I’ve opened #31590 to fix this issue.

  3. bitcoin deleted a comment on Jan 2, 2025


Pttn achow101


github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2025-01-21 09:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me