Unknown error / unknown output script type #323
Unanswered
gomesalexandre
asked this question in
Help & Support
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Summary
gm!
While I was trying to debug some issue with BTC sends with
signPSBTbeing broken for some addresses (i.e popup shows just fine, but after clicking confirm,signPSBTthrows), I eventually ran out of luck re:-32603 unexpected error.Digging deeper, while running Devtools in Phantom, I saw this error which wasn't exposed:
Transaction/output: unknown output script type, there is a chance that input is unspendable. Pass allowUnknownOutputs=true, if you surewhich seems to come fromscure-btc-signerWondering if we could bubble those errors up to consumers instead of "unexpected error" to help with future debugging?
And indeed, while running a breakpoint on the affected line of scure-btc-signer, script type was unknown.
Now, the really weird part here is
bc1qsdeav5z8pt307euz742xla97gackhgpkz27dh5, but was not happening while testing with another,bc1qxzntwam7733myh5vryz5dptpqg79d0kn80clmtaccount_index, both are zpubs (SegWit native), and obviously both are 0thaddress_indexas that's the only one that Phantom ever uses (no next receive address with Phantom)bc1...dh5) was failing while trying to send to any address, while the second could send to any (self-send, or outputs going to external addresses)unknownscript in the affected line inscure-btc-signerwhile debugging Phantom extension.This is what the
psbtlooked like for the affected Tx:{ "data": { "inputs": [ { "unknownKeyVals": [], "nonWitnessUtxo": { "type": "Buffer", "data": [ 2, 0, 0, 0, 0, 1, 1, 99, 244, 189, 225, 182, 162, 184, 136, 131, 135, 83, 164, 110, 255, 116, 143, 104, 69, 120, 197, 145, 96, 197, 244, 56, 115, 185, 157, 155, 18, 242, 255, 0, 0, 0, 0, 0, 255, 255, 255, 255, 3, 229, 41, 0, 0, 0, 0, 0, 0, 22, 0, 20, 149, 64, 248, 25, 104, 211, 1, 203, 77, 72, 122, 27, 209, 191, 77, 34, 9, 159, 180, 35, 55, 73, 0, 0, 0, 0, 0, 0, 22, 0, 20, 131, 115, 214, 80, 71, 10, 226, 255, 103, 130, 245, 84, 111, 244, 190, 71, 113, 107, 160, 54, 0, 0, 0, 0, 0, 0, 0, 0, 66, 106, 64, 61, 58, 69, 84, 72, 46, 69, 84, 72, 58, 48, 120, 55, 48, 49, 54, 101, 54, 98, 99, 51, 99, 52, 101, 53, 52, 57, 53, 51, 101, 55, 48, 99, 49, 53, 53, 50, 100, 51, 55, 102, 52, 101, 100, 97, 49, 55, 51, 98, 48, 54, 51, 58, 50, 52, 53, 57, 49, 53, 58, 115, 115, 58, 48, 2, 71, 48, 68, 2, 32, 8, 39, 151, 20, 116, 17, 5, 42, 83, 254, 121, 40, 190, 232, 71, 96, 226, 194, 188, 92, 212, 20, 22, 66, 189, 55, 121, 204, 192, 50, 3, 56, 2, 32, 24, 119, 37, 220, 235, 179, 197, 1, 149, 14, 125, 92, 49, 254, 88, 72, 166, 103, 201, 90, 164, 214, 103, 182, 176, 21, 4, 108, 39, 143, 193, 41, 1, 33, 3, 153, 146, 159, 150, 179, 189, 66, 81, 205, 111, 182, 161, 29, 127, 254, 129, 155, 106, 200, 168, 6, 188, 98, 175, 156, 94, 140, 55, 49, 151, 45, 128, 0, 0, 0, 0 ] } } ], "outputs": [ { "unknownKeyVals": [] }, { "unknownKeyVals": [] } ], "globalMap": { "unsignedTx": {} } } }And
inputsToSign:[ { "address": "bc1qsdeav5z8pt307euz742xla97gackhgpkz27dh5", "signingIndexes": [ 0 ], "sigHash": 1 } ]FYI, this is our internal data structure that we massage to conform to Phantom:
{ "coin": "Bitcoin", "inputs": [ { "addressNList": [ 2147483732, 2147483648, 2147483648, 0, 0 ], "scriptType": "p2wpkh", "amount": "18743", "vout": 1, "txid": "447eceea134ee90f5f126f3ab462846daf1b263d468309420b4a1a8675603567", "hex": "redacted" } ], "outputs": [ { "addressType": "spend", "amount": "1037", "address": "bc1qsdeav5z8pt307euz742xla97gackhgpkz27dh5" }, { "addressType": "change", "amount": "15898", "addressNList": [ 2147483732, 2147483648, 2147483648, 1, 0 ], "scriptType": "p2wpkh", "isChange": true } ] }Kind of a long shot here as we're more trying to understand the actual heuristics to repro and whether or not this is an internal Phantom issue, rather than the fix (fix in this case is to do a send through Phantom, though obviously more of a bandaid than anything else).
I noticed this comment from @adamdelphantom in the only similar issue I could find https://github.com/orgs/phantom/discussions/284#discussioncomment-10546475 - wondering if this could be a similar issue, and I assume the issue is Phantom having trouble with specific UTXO sets?
Example
No response
Steps to Reproduce
See above, not so much in terms of steps to reproduce as that's what we're actually trying to understand here!
Phantom Version
24.26.0
Is there an existing discussion for this?
Beta Was this translation helpful? Give feedback.
All reactions