search

leather-io / desktop

Manage STX tokens and Stacking
https://leather.io/
191 stars 71 forks source link

Different Bitcoin reward address showing after confirmation then supplied #1191

Closed 314159265359879 closed 1 year ago

314159265359879 commented 1 year ago

Because pox-2 is currently disabled we can't test/reproduce until there is a Stacks 2.4 testnet live with PoX-3 activated. Making an issue here so we keep an eye on it.

A user reported the following prior to Stacks 2.2 activation: _The address I submitted for rewards was: bc1qfxe7tuxhrwupygvg7j729ahhs58x34lm0yn90r

The address it displayed as my registered rewards address after confirmation was: 17ihqYubbRHakgy4kAhFMPWhJHEKB9hbXx

The stack transaction does display hashbyte version 0x04 which indicates native segwit, right? https://explorer.hiro.so/txid/0xad5510c04fc595a4ba7b6aad783698372577e692bc273774a808ddf2543a5e16?chain=mainnet

As stated previously... when I used my seed phrase in electrum, using BIP39 and m/44’/0’/0' .... I also tried m/44’/5757’/0’ And looked at addresses (seems they list 30 of them or so).... None of them matched that rewards address. So I have no idea where it came from?_

As far as the specific issue I referenced, I was using wallet version 4.9.1, windows desktop. I opened the wallet tonight, and because my STX is no longer stacked... it doesn't show the rewards address. Below is a screenshot of what I see now. When I was stacked, there was a rewards address listed in the area I circled in red. image

We expect the input address to display, after confirmation, as shown in the flow before signing the Stack transaction. image

I am not sure what happened here.

markmhendrickson commented 1 year ago

cc @friedger in case he has ideas

markmhendrickson commented 1 year ago

@314159265359879 you've heard only one of these reports so far, correct?

314159265359879 commented 1 year ago

@314159265359879 you've heard only one of these reports so far, correct?

Yes, one so far.

friedger commented 1 year ago

If I remember correctly the version of the reward address is hard coded.

314159265359879 commented 1 year ago

If I remember correctly the version of the reward address is hard coded.

I tested with the testnet wallet looks like it is dependent on the address: Legacy image

0x04 for native segwit image

0x06 for taproot image

The user reporting this had 0x04 in their transaction, so it is odd it would show something other than a native segwit address after confirmation right?

Or do you mean the confirmation address-version is hardcoded @friedger?

friedger commented 1 year ago

I was wrong. The representation is not hard coded, but it is not supported, only version bytes 0 and 1 are supported: https://github.com/hirosystems/desktop-wallet/blob/43fa4bd4d1b9945892df08219b5c25b3d746043a/app/utils/stacking.ts#L7

314159265359879 commented 1 year ago

Would this explain what the user saw and can you fix it?

Do we have to go back to only allowing legacy and wrapped segwit here or can it be extended to allow native segwit and taproot too?

friedger commented 1 year ago

It can be extended.