redeem BRD gifts : decoding breadwallet URLs (BTC gift, base64 -> base58 -> ?)

[satstakka]

I'm looking for help decoding the string representation for BTC gifts created (but not redeemed) from BRD wallet. (breadwallet)

This has nothing to do with NFTs, BRD tokens or dumb coinbase gifts/marketing. This is for BTC funds, stored in a wallet that breadWallet created when using the "Gift BTC" option of (2021/2022) breadWallet builds.

There's at least one unredeemed BTC URL in it for you, if you can provide the details that successfully allow me to accomplish this redemption.

Context:
Coinbase bought BRD
Coinbase shut down BRD (circa March 2022) along with (?) the web API that would redeem said URL from brd.com using the wallet (mobile) app.

Gifts (BTC) created in breadwallet are thus held hostage by coinbase.
Coinbase refuses (or is insufficiently competent) to assist in redemption of funds.

The gift URL from breadwallet takes the form

https://brd.com/x/gift/someBase64String.....

the base64 string can be decoded with standard base64 tools & appears to result in a base58 string.

This resulting base58 string does not take the form of a WIF Private Key. (doesn't commence with K,L,5)

I'm looking for help decoding the base58 string to (presumably) the private key. I don't know what additional decode is required or what might be represented by the raw base58 string.

The bread codebase is posted on GitHub

https://github.com/breadwallet

Here's an example base64 string from one such URL.

Code:

VDkzQVozZjFMbVBQbktiUXJSaFZENEZERWhNTTFVMVVmWFFickI2WktkWGNBSFd6b0dhQQ==

This decodes to the following (base58 string) as follows;

Code:

echo 'VDkzQVozZjFMbVBQbktiUXJSaFZENEZERWhNTTFVMVVmWFFickI2WktkWGNBSFd6b0dhQQ==' | base64 -d

T93AZ3f1LmPPnKbQrRhVD4FDEhMM1U1UfXQbrB6ZKdXcAHWzoGaA

Equivalent HEX from the base58 (pls check me on this) would be

Code:

B0B29B59EF7BA9DB3E124EFAA7FD3B55AA0728AD3ADC8165EAD177B45A8CF9DCB801

What's required to further decode the above (recall this is for BTC transferred by breadwallet)?

FWIW: I also retain the corresponding addresses where the funds currently reside. If you're able to ID same from the above, I think we're on the right track.

[1714880026]

1714880026

[1714880026]

1714880026

[PawGo]

What is the result of call to "https://brd.com/x/gift/someBase64String....."?

I may be wrong, but I think the information encoded in "someBase64String" are not sufficient, if they store information about sender, recipient and amount on the server side.

[LoyceV]

I don't think I've seen this before, so I'm intrigued This is all I know about weird private key formats. Your HEX string is 68 characters, if it would be 64 you could enter it into Bitaddress.org's Wallet Details tab to get the address and WIF key.
Are you sure this is non-custodial? If it isn't, you can't possibly recover it without the current owner (Coinbase).

[satstakka]

What is the result of call to "https://brd.com/x/gift/someBase64String....."?

I may be wrong, but I think the information encoded in "someBase64String" are not sufficient, if they store information about sender, recipient and amount on the server side.

I'm already out of my depth with respect to sniffing the HTTP between the hosts. If this seems fruitful, I'm open to suggestions for same.

A simple curl on the URL

Code:

https://brd.com/x/gift/VDkzQVozZjFMbVBQbktiUXJSaFZENEZERWhNTTFVMVVmWFFickI2WktkWGNBSFd6b0dhQQ==

Regarding the additional info you suggest, I do have the (current & former) address of the BTC funds, txid (amounts etc.)


The plot thickens!

For anyone interested to try an alternate path, see if you can beat me to the $

Specifically, start here;

https://github.com/breadwallet/breadwallet-ios/blob/f90e2083ee1e908fa5793b8f3d659754166513c2/breadwallet/src/Models/QRCode.swift#L48

Using the following URL as your data

Code:

https://brd.com/x/gift/VDkzQVozZjFMbVBQbktiUXJSaFZENEZERWhNTTFVMVVmWFFickI2WktkWGNBSFd6b0dhQQ==

If you can report the on-chain address (& key) and I successfully replicate the method, I'll send you another URL & you can keep/sweep the entire BTC contents.

[moderator's note: consecutive posts merged]

[Rickorick]

Seems like it has already been redeemed.

[satstakka]

Seems like it has already been redeemed.

Can I ask what you're basing that conclusion on?

ie. If you're trusting the (degraded by coinbase) breadwallet, for this info - bear in mind, it now erroneously reports the same status (redeemed) for all valid gift redemption attempts (even those that haven't moved from their address since being created).

[satstakka]

...Are you sure this is non-custodial? ...

I'm presuming as much from the fact the URL alone is (was) enough to redeem the funds. (no passwords or other auth required).
That said, it's possible there may be some other cryptographic secret only BRD (now coinbase) retains.

Hence, why I was hoping someone smarter than me might take a peek at the code (GitHub linked in this thread) & weigh in.
Specifically, tracing the gift redemption path which appears to originate at the QR code logic linked here:

https://github.com/breadwallet/breadwallet-ios/blob/f90e2083ee1e908fa5793b8f3d659754166513c2/breadwallet/src/Models/QRCode.swift#L48

It interprets a (padded) base64 as the payload to distill a key, but I can't figure out if it's salted with something additional, or pretty much raw (& if I'm just screwing up the basics of unwinding the base58 etc.)

[Btcspot]

 I think i found the answer, also found an address here 17yWTcnCbSpHVXGusgiiodFXhD587xWLdG. I hope you see what i mean. How many url do you have?

[pooya87]

It looks like the Base64 string you have is modified for some reason and 2 mistakes were introduced in it.
1) The code seems to be using no Base64 padding to encode the key whereas the string you posted contains the padding.
2) The code is simply encoding the Base58 WIF decoded as UTF8 then encoded using Base64. And unless the encodeAsPrivate() method has some weird bug it should use the correct first byte and end up with an uncompressed WIF starting with L or K.

https://github.com/breadwallet/breadwallet-android/blob/a6b8add794ced98b2ea77c3dcecaadd7a91dfdd7/ui/ui-gift/src/main/java/CreateGiftHandler.kt#L81-L85

So essentially decoding such strings shouldn't be a big deal, you just put them into bitaddress.org tool to get the WIF and addresses assuming they aren't modified like what you posted here. Otherwise you simply do a Base64.Decode(), fix the mistakes followed by Base58.EncodeCheck() to get the WIF.

P.S. The address @Btcspot (17yWT...) posted is ignoring the mistake in OP's string and just takes the 32 byte key out of the decoded result.

Your HEX string is 68 characters,

That's the byte array length of a compressed private key: 1 byte version + 32 byte key + 1 byte compressed flag = 34 byte * 2 = 68 hex chars.

[LoyceV]

...Are you sure this is non-custodial? ...

I'm presuming as much from the fact the URL alone is (was) enough to redeem the funds. (no passwords or other auth required).

The fact that it's an URL instead of a code makes me think it needs the server to release funds. In other words: in that case it's custodial.
But if each "URL" has it's own address, that might not be the case.

Hence, why I was hoping someone smarter than me might take a peek at the code

Sorry, I can't do that I would love to add the solution to my overview though!

[o_e_l_e_o]

P.S. The address @Btcspot (17yWT...) posted is ignoring the mistake in OP's string and just takes the 32 byte key out of the decoded result.

But this address has a transaction history - received 0.00098806 BTC and then sent it out again a few hours later. It would be incredibly unlikely that wrongly decoding the string OP provided would result in a valid and already used private key.

So it seems all OP has to do is decode the base64 string to hex as he has done, strip off the first and last bytes, and then convert the resulting 64 characters to a WIF key to import in to his wallet.

[pooya87]

P.S. The address @Btcspot (17yWT...) posted is ignoring the mistake in OP's string and just takes the 32 byte key out of the decoded result.

But this address has a transaction history - received 0.00098806 BTC and then sent it out again a few hours later. It would be incredibly unlikely that wrongly decoding the string OP provided would result in a valid and already used private key.

So it seems all OP has to do is decode the base64 string to hex as he has done, strip off the first and last bytes, and then convert the resulting 64 characters to a WIF key to import in to his wallet.

Yes, this was the reason why I guessed that the initial Base64 string is modified and also considering that the code doesn't seem to do such a thing, there is a good chance that what OP had was actually some sort of a puzzle that could have been solved this way.

[dimi2gem]

@satstakka so what is the solution then?

I also have an unredeemed BRD QR code (brd.com/x/gift/somebase64string).
What are the steps to take to decode it into the a base58 WIF private key?

[digaran]

@satstakka so what is the solution then?

I also have an unredeemed BRD QR code (brd.com/x/gift/somebase64string).
What are the steps to take to decode it into the a base58 WIF private key?

Is it QR code? If it is then why don't you scan it already?
Do you know the address and the balance? I'd suggest you to listen to the two members posted above your post, they are trustworthy.

OP never came back to post an update about the situation, I doubt he will ever do.

[o_e_l_e_o]

@satstakka so what is the solution then?

Assuming your string takes the same format as OP's, then the solution is given above in the posts from pooya87 and myself.

• Take your base 64 string.
• Decode it, and you should end up with a Base58 string.
• Convert that back to the original hex, and strip off the first byte and last bytes to end up with a 64 character raw private key.
• Convert that to a WIF key and import it in to your wallet.

[dimi2gem]

@satstakka so what is the solution then?

Assuming your string takes the same format as OP's, then the solution is given above in the posts from pooya87 and myself.

• Take your base 64 string.
• Decode it, and you should end up with a Base58 string.
• Convert that back to the original hex, and strip off the first bytes and last bytes to end up with a 64 character raw private key.
• Convert that to a WIF key and import it in to your wallet.

Ah thanks. i got it now.
I was tripped up when doing the base58 to hex conversion.
Online converters produced an extra 8 characters (76 in total), and I had to first remove the last 8 to get 68 characters, then remove the first 2 and last 2 hex characters to get the 64 character private key, before I enter it into bitaddress.org for the WIF key.

Thanks so much!

For those who are searching for a solution on how to redeem BRD gift BTC from a QR code:

• Use a QR code scanner to extract the URL from your QR code. Best to use an offline QR code scanner.
• It should be in the format of: https://brd.com/x/gift/{somebase64string}
• In the terminal, do: cat {somebase64string} | base64 -d > base58.txt
• Convert the base58 string to hex using: https://www.better-converter.com/Encoders-Decoders/Base58Check-to-Hexadecimal-Decoder
• The base58 string should have 76 characters. Remove the last 8 to get 68 characters first.
• Then remove the first 2 and last 2 characters to get your 64 character private key.
• Go to https://www.bitaddress.org/ and go to the Wallet Details tab (you need to move your mouse around to generate an initial address first)
• Enter your private key and view details
• The lower right hand corner Private Key WIF Compressed is what you can use to sweep/import into your wallet.
• Check this page for a list of wallets that support sweeping private keys: https://99bitcoins.com/bitcoin-wallet/paper/private-key-sweep-import/
• These BRD QR codes are essentially like paper wallets containing a single address private key. If you want to sweep it into your hierarchical deterministic (HD) wallet, you must make an on-chain transaction.
• Mycelium is one of those few wallets that can import and handle separate single address private keys. The UI is not very user-friendly though.

[o_e_l_e_o]

All I would add is that it is better to do all of this offline rather than exposing your private key to the internet and entering it in to random websites to convert it to other formats, which puts you at risk of having your coins stolen. Once you've converted to hex locally, then you should download and verify bitaddress from its Github page and run it offline in order to turn your raw hex key in to a WIF key.

Electrum is also a good choice for importing individual private keys. You should obviously then sweep all the funds within to a more secure wallet.