Closed champo closed 2 years ago
@champo thanks for reporting, we currently looking into. @catenocrypt will provide an update on this issue/fixes.
@champo , could you check that this tx output looks correct, and is spendable? https://mempool.space/tx/5df51e13bfeb79f386e1e17237f06d1b5c87c5bfcaa907c0c1cfe51cd7ca446d
@catenocrypt I'll ask the owner of the wallet to spend it. The output looks correct in the explorer.
@catenocrypt There's our user also run into this case, the address ended up turning into a native Segwit address, which started with bc1q. Who does this parsed address belong to and is there any chance that this user get his fund back?
Describe the bug p2tr address bc1ptmsk7c2yut2xah4pgflpygh2s7fh0cpfkrza9cjj29awapv53mrslgd5cf is sent as the invalid bc1qtmsk7c2yut2xah4pgflpygh2s7fh0cpfkrza9cjj29awapv53mrs4ldaq4. This means that funds are lost since the two address types are not equivalent.
To Reproduce Steps to reproduce the behavior:
Expected behavior Funds be sent to original address.
Screenshots The UI shows the original address:
But the block explorer differs: https://mempool.space/tx/ff55aa5455f9bc47710b3e261e936d2385f4d54fdbf2f301e2e1751059cce2fa
Additional context The issue seems to be that witness version byte is not being propagated when the output is constructed. The invalid address has the same witness program as the valid one but with witness version 0. A quick check in the TX building code indicates this is the case.