Topic: Access funds on legacy address related to segwit addr to which I got access to (Read 386 times)

Funny to see the address "1s2iywx94HudryMHsU2g1K9x8DB1cahGc" pop up here. I had it already flagged since my block parser choked on the coinbase transaction where this address is used. These two transactions were the only cases where I saw the OP_RETURN in the output before the actual payout. So I already figured this was some custom made script for the coinbase transaction. A message in the coinbase refers to "MiningCore".

Reading the entire topic: this seems to be an expensive mistake!

OP: Were you using this: https://github.com/coinfoundry/miningcore ?

Thats the problem with low quality software which hasn't been tested properly and extensively.
A lot of people are looking to save a few hundred/thousand bucks when hiring a developer to create a software.

Unfortunately those people will never understand that investing a few more bucks into the software will safe you way more money in the later run 

Additionally it seemed like the software hasn't been tested at all    A simple unit test would have shown the inconsistency in the first run..


@OP: If you have a purchase contract regarding the software, you probably can claim damages towards the developer.
Each software has to be tested properly before being delivered. And such a mistake definitely stands out..

But, if you tried to save a few bucks.. well.. that was your own fault then i'd say.. 

Oh, man. I though I've got the hang of Scripts in bitcoin. I have to go back and review things now.
Thanks, I fixed the comment too.

a fatal mistake on his pool software about 25 BTC worth of $175,000 currently
we should add this address to the list of lost bitcoin for "collider group" out there  
do we have a maintained list of such thing yet?

No, this is wrong.

First of all, 0x05 does not mean segwit, it means P2SH. Bitcoin Core by default creates addresses that are P2WPKH nested inside of a P2SH address. That is why you see embedded in the getaddressinfo output.

Your pool software is incorrect here, and that is the source of the problems. The scriptPubKey that you should have used is a91409763cb05dcea0f98f53b0f08651f92c5d2d2f3887 which maps to the address 32Z3eXSPgxcHj2fnQy8d6dg66eVtZfxrBM. The 09763cb05dcea0f98f53b0f08651f92c5d2d2f38 part is the hash160 of the redeemScript. Since this is a P2WPKH nested in a P2SH, the redeemScript is 00142ee67d879ccf17daec87b4ed4a6cecdd9b3f64a0. However, what your pool software did was it ignored the version byte (the 0x05) which indicates that the hash160 encoded in the address should use a P2SH scriptPubKey. Instead, it made a P2PKH scriptPubKey using the provided hash160 which is why you see that the coins were sent to 1s2iywx94HudryMHsU2g1K9x8DB1cahGc.

It is missing because the pubkey does not exist in your wallet. What it is looking for is a pubkey that has a hash160 of 09763cb05dcea0f98f53b0f08651f92c5d2d2f38. But what you have is a redeemScript that has a hash160  of 09763cb05dcea0f98f53b0f08651f92c5d2d2f38. The pubkey that is in that redeemScript is unrelated to this address entirely.

The address is unrelated to the pubkey.

Your coins are lost, you cannot recover them. You would need a public key which hashes to 09763cb05dcea0f98f53b0f08651f92c5d2d2f38 and its associated private key. All you have is a redeemScript that has that hash. That redeemScript is not a public key. Thus you cannot get those coins as you cannot spend them.


No No No! You are horribly mistaken and completely wrong. That is not how P2WPKH is nested in P2SH. Doing this will cause your coins to be lost. P2WPKH nested in P2SH uses the scriptPubKey of the P2WPKH output as the redeemScript. It does not use the keyhash as the hash in the P2SH scriptPubKey. The P2SH address OP has is correct, his pool software is just broken.

I am not an expert but here is what I see, your program was broken and made a mistake.
You have a private key which has the public key:

The hash160 of your public key is:

Which means your ScriptPubKey is if you use P2WPKH (bc1q9mn8mp.... address):

---

Edit:
This part was indeed wrong. So here is the fix, thanks to achow101 (below comment)

The  P2WPKH nested in P2SH is going to hash the ScriptPubKey of P2WPKH
So RIPEMD160(SHA256(00142ee67d879ccf17daec87b4ed4a6cecdd9b3f64a0)) and the result is: 0976<...>2f38 and the scriptPubKey will be:

---

If you treat 0976... as a hash160 then you get the following address:
Which is why blockchain.info shows it, and probably why your program sent the funds there.

Unfortunately, this is not the case.
The output will be 15GzCaKf9Bd5DEvJpLnStzt4aL2QDBuTwW for Compressed and 1GY6bTT89Vw4DAzKsJ43g2CoDzDpE8JxKx for Uncompressed.

---

Indeed and also, when you click the HASH 160 link of the SegWit Address format from a blockexplorer that didn't support SegWit like blockchain.com,
it will redirect you to address: 1s2iywx94HudryMHsU2g1K9x8DB1cahGc.

In my opinion, it was the pool's fault why it was sent to that address.

Your funds may be recoverable, try Abdussamad's tool.

Everybody, thanks a lot for the answers. We are currently looking into suggestions and solutions you've proposed. I'll post an update on this thread later, when things will get clear, so that if anybody encounters such problem in future could use that topic as the starting point.

Core should be keeping track of all addresses including p2pkh ones. If it isn't you can always dump the private key and import it into another wallet like electrum.

edit: AFAICT the uncompressed p2pkh address of the public key of 32Z3eXSPgxcHj2fnQy8d6dg66eVtZfxrBM is 1GY6bTT89Vw4DAzKsJ43g2CoDzDpE8JxKx so it turns out that the private key for 32Z.. does not unlock the outputs sent to 1s2iywx94HudryMHsU2g1K9x8DB1cahGc . So you need to find out which pubkey was used

Note scriptPubKey is not the same as public key.

I wrote a script to convert between the various key types using the electrum libraries. If you install electrum and python3 you can use it: http://termbin.com/jm3l

your segwit address:  32Z3eXSPgxcHj2fnQy8d6dg66eVtZfxrBM
your fund in: 1s2iywx94HudryMHsU2g1K9x8DB1cahGc

I can only provide some insight,
your current private key works only for segwit address and compressed legacy address
I played around with your redeem script, and found 15GzCaKf9Bd5DEvJpLnStzt4aL2QDBuTwW
while the address you mentioned (1s2iywx9...) is an uncompressed legacy address  
so you need to find the uncompressed private key to access your fund
you can use bitaddress tool to find it, or some other tools that can convert several types of private keys

edit: my bad... I just realized my mistake, I believe Coding Enthusiast is in the right direction
it seems you can't recover your bitcoin unless you can find private key for 1s2iywx9...

The situation

Hello. Our company running BTC pool. We've been mining BTC for a while and used segwit address  32Z3eXSPgxcHj2fnQy8d6dg66eVtZfxrBM as pool adress.

But when we finally found a first block (actually - two blocks) for some reason block reward got sent to different address: 1s2iywx94HudryMHsU2g1K9x8DB1cahGc

Here are links for both generation transactions with rewards: https://btc.com/12a1910bbc1fd95410045e86fecf90a601d1c9c93ea338e884e7188cdb54a3d4 and https://btc.com/12a1910bbc1fd95410045e86fecf90a601d1c9c93ea338e884e7188cdb54a3d4

The problem

We cannot get access to funds on 1s2iywx94HudryMHsU2g1K9x8DB1cahGc- we simple can't see that balance on the wallet.

The question
How can we access those funds on 1s2iywx94HudryMHsU2g1K9x8DB1cahGc?

More info

Using Bitcoin Core client command we can inspect both addresses:

Output for 32Z3eXSPgxcHj2fnQy8d6dg66eVtZfxrBM is


Output for 1s2iywx94HudryMHsU2g1K9x8DB1cahGc is


I can see three interesting points here:

1. scriptPubKey for both addresses contains 09763cb05dcea0f98f53b0f08651f92c5d2d2f38 part, which is, afaik, actuall public key. First byte differs, which makes sense, since it's prefix, 00 for legacy and 05 for segwit respectively.

regarding output for 1s2iywx94HudryMHsU2g1K9x8DB1cahGc :

2. pubkey property is missing, which is weird, because usually its included for legacy addresses

3. isMine property equals false, wich means that wallet does not recognize this address relation to wallet PK.

So, can anyone please provide some insight and tell us if (and how?) we can access those funds, or we've lost them for good? Thanks in advance.

P.S.

When I use base58 decode on both 32Z3eXSPgxcHj2fnQy8d6dg66eVtZfxrBM and 1s2iywx94HudryMHsU2g1K9x8DB1cahGc I get

and

respectively.

Again, you can clearly see same bytes, so addresses are definitely related.