search

PirateNetwork / pirate

Pirate Chain (ARRR) - Untraceable, Anonymous, Private Cryptocurrency
https://piratechain.com
Other
112 stars 27 forks source link

Treasure Chest: "Invalid Payment Address" error #109

Closed warelock2 closed 3 months ago

warelock2 commented 6 months ago

@CryptoForge

Problem: Any merchant using Pirate URIs will not be able to embed that URI such that the payment request details get properly sent to their customer's running instance Treasure Chest.

Client system details:

Steps to reproduce:

  1. Open Treasure Chest
  2. Copy a valid address (ie. "zs1...")
  3. Open a new window in a web browser
  4. Construct a basic Pirate URI as follows: pirate:zs1...
  5. Open the URI in the web browser
  6. Accept the request to send the URI to Treasure Chest
  7. Get an error of "Invalid Payment Address" in Treasure Chest

The code generating the error message is here.

I first noticed this issue when trying to use the Cryptocurrency Checkout Marketplace. I was trying to see how their workflow is laid out when trying to use Pirate Chain to buy something through that payment processing service. You get the same error from that process, as well.

Linux command line example of how to replicate this issue (stolen from the Cryptocurrency Checkout Marketplace):

xdg-open "pirate:zs14l5qpyh7vf94f3vwuqmgrfm9ja8692ps7ztzl5e9xk7u8et0jd99f8k326rqt2htk42kz4y6q4p?amount=59.40111793&message=AMZNGIFT&label=RockinPricesCrypto"
warelock2 commented 5 months ago

@CryptoForge Is the issue that the Pirate URI handler code treats the Pirate Chain address as base58-encoded, rather than Sapling Bech32-encoded? What encoding scheme do Pirate Chain addresses use?

https://zips.z.cash/zip-0173

CryptoForge commented 5 months ago

I checked this out and was able to update the encoding to use the right scheme, but then I ran into the problem of what the URI did if the wallet was already open. I need to do some more research to figure out how to get the URI to send the message to an open wallet.

warelock2 commented 5 months ago

@CryptoForge I had previously posted what I thought was an issue with Treasure Chest, where the OS appeared to want to fire up a new instance of Treasure Chest, even though an existing instance was already running, resulting in a lock conflict. That was just a temporary glitch on my part. I just restarted Treasure Chest and the behavior went back to normal, with the existing Treasure Chest instance grabbing the event and trying to handle the Pirate URI itself, which is the expected behavior, even if it's the existing error message that I reported. Sorry for the confusion.

warelock2 commented 5 months ago

I checked this out and was able to update the encoding to use the right scheme, but then I ran into the problem of what the URI did if the wallet was already open. I need to do some more research to figure out how to get the URI to send the message to an open wallet.

@CryptoForge Just curious: What is the proper encoding scheme for Pirate Chain addresses? Bech32?

CryptoForge commented 5 months ago

@warelock2 This is fixed on the dev branch here https://github.com/PirateNetwork/pirate/commit/873eb4a2716497e30b4df9c52306151585dd397f

warelock2 commented 4 months ago

@CryptoForge Thanks for fixing that. At least it now doesn't outright reject valid Pirate Chain Z-addresses. As discussed, the behavior is now that it pops up a dialog box for a fraction of a second, then just stops the Pirate URI handling workflow altogether.

warelock2 commented 3 months ago

@CryptoForge Native Pirate URI handling has been fixed in Treasure Chest v5.8.2. Closing this issue.