Need Help! Funds Gone / Wrong Address

Hey everyone, I've been trying to set up a payment processor for myself. I came across this script that claims to generate all the standard Bitcoin address types. I tried it out and the legacy addresses worked fine, so I thought I was good to go. But then I started generating other types of addresses like bech and segwit (the ones starting with bc and 3) and sent some transactions to those addresses. That's when I noticed the bech address was invalid. I figured I might have messed something up. When I tried to import the private keys I created, I found out those addresses were different from what the script had generated. Here's the repo I used: https://github.com/BRO200BS/Bitcoin-Address-Generator Check out this key I just generated: 'private_key': '188ffa83fc4f665b4fb24460d560540e635ea824ad1576e27644f7835600c85b' 'WIF': '5J16zh1Mktz1iWEavJFT8nVRBscDCLQDzChYTeYxU33cQDRnty5' 'p2pkh_address': '1EcW6UVqRCpsww7RA8moBjx6RypYnnraDA' 'compressed_p2pkh_address': '16cSkuPktoD5u9aN3ttnNf9YYb1jvK4Sjw' 'p2sh_address': '3JKyqNxb5Wb9uh5NUX4S5PhMZTddEiY92n' 'bech32_address': 'bc1qq2tvlagcm8zdwf9h0mjhzu9m6s3q84w8kpsj83wvj' As you can see, the bech address starting with "bc1qq" doesn’t look valid. Plus, I couldn't get my private key to match the p2sh address either. I tried this service to check what the output would be: https://secretscan.org/PrivateKeySegwit When I put that private key into the site, I got this address: 32kecU8BJMWCiDbCxCR4EaYc3fZx5bDPpy, and the same goes for when...

It is certain that your coins are lost. This is because coins sent to the wrong bitcoin wallet address cannot be retrieve unless, the owner of that wallet choose to send them back to the address that sent him those coins. In your own case, you sent your coins to an invalid address, it is lost forever. There is always a warning that bitcoin transaction is irreversible. Sorry for your lost mate. Be careful next time to make sure that you are sending your coins to the right wallet address.

It's lost if you send it to an address that you don't fully control. How did you import it to Electrum? If you imported the private key to Electrum in a wrong way it would gives you a different address usually legacy address. If I were you try adding the script type before importing the private key check the guide below as sample Next time use BTCpayserver as your payment processor or blockonomics you don't need to develop anything you just need to import your wallet master public key and all invoice(BTC addresses) generated should be came from your master public key that you fully control.

AFAIK, one master key can generate all three types of addresses, and the reason why you see two different address is because you are using two different derivation path. As long as the address generated using that private keys should have the funds that you send, please try importing the private key again.

The correct information of the private key in the example you give is below. I suggest you use a correct library, I use pycoin for python get well soon, thank you

It is an invalid address. None of the addresses you've shared have coins. I assume you meant - 3JKyqNxb5Wb9uh5NUX4S5PhMZTddEiY92n - as p2sh-segwit, and as anyone can notice from a block explorer it has never received any coins. You can't send coins to an invalid address. An address is (usually) an encoded version of the witness public key hash. If the address is invalid, then it means decoding it will not result in an acceptable locking script.

As of 2 months ago this was a known issue with that script: https://github.com/BRO200BS/Bitcoin-Address-Generator/issues and as @BlackHatCoiner pointed out you can't send coins to an invalid address so there is something else going on. What was the actual address that you generated that had coins sent to it? And do you have the TXID of that transaction? -Dave

The following warning is a day late and a dollar short. Let me share my point of view, having written some similar script myself: Don't! Don't! Don't use scripts that are not properly tested, qualified and used. Open source is fantastic because it allows many pairs of eyes to review the same code. However, it's not a panacea. Most of the time, these pairs of eyes distinguish corner cases and issues. In your particular occasion, as DaveF said above, there was an open issue in the code. So, when using open source, we should at least check: 1. the open issues. 2. the number of forks / stars. 3. the number and quality of open merge requests. 4. the number of contributors.

Seems to generate the correct legacy address in ZPyWallet too: I do not have a P2SH generation routine to test against. Neither of the above bech32 addresses match up with yours even slightly. How are you creating the bech32 addresses? I use Pieter Wuille's reference implementation. I think you are also using the same one. However, your P2SH and Bech32 address generation routines are wrong: First of all, your script hash is supposed to be just the public key by itself, not the entire redeem script. The opcodes are only to be added right before the Base58 encode. (those opcodes are not even bytes, you made them ASCII characters.) Your second mistake is not resetting the hash160 when you are done so you are using the already incorrect P2SH script hash to create the bech32 address... And even the bech32 calculation itself also has another mistake, you are adding 0x00 0x14, the witness program at the beginning of the address. Why are you adding the witness program into the bech32 address? You are not supposed to do that. Anything that's supposed to be a script opcode is not supposed to be encoded into an address. This is why it's making an invalid qq address. You did not lose any funds unless your coins were sent to the invalid P2SH address, which is the reason why I don't like P2SH-P2WPKH in the first place. Why are you debugging with mainnet addresses anyway? Testnet would've caught this error in a less expensive way.

What address from ? You sent funds ?

It's lost, and honestly, it sounded like you didn't know what you were doing.