Given claim_script does not match the given Bitcoin transaction.
Closed this issue · 9 comments
Describe the issue
I can't find a way to claim the peg-in on the liquid network and give the following error:
Given claim_script does not match the given Bitcoin transaction.
If any more information is necessary, ask me. Thanks for your help.
What version of bitcoin-core and elements-core are you using?
Bitcoin Core v26
Elements Core v22.1.1
Contents of elements.conf
server=1
listen=1
txindex=1
validatepegin=1
mainchainrpccookiefile=/media/data/.cookie
nrpccookiefile=/media/elements/data/liquidv1/.cookie
maxconnections=20
Reproduction of the issue
The funds were sent from an electrum wallet to the address generated by getpeginaddress. At this time blockstream indicates that the transaction has 107 confirmations.
I put "raw" and "proof" with the result from getrawtransaction and gettxoutproof "yourTXID"
elements-cli claimpegin <raw> <proof> <claim_script>
error code: -8
error message:
Given claim_script does not match the given Bitcoin transaction.
elements-cli createrawpegin "<raw>" "proof" "claim_script"
error code: -8
error message:
Given claim_script does not match the given Bitcoin transaction.
Update
Subsequent actions
getpeginaddress generated the "mainchain_address": "3PAoFxiMsa8tgv6dDvYVqRSyweMyTpVxcZ" probably because the node was not completely synchronized. I imported an electrum wallet into Bitcoin Core, synchronized the node again and now it gives me the following error.
without claim_script
elements-cli claimpegin <raw> <proof>
error code: -8
error message:
Failed to find output in bitcoinTx to the mainchain_address from getpeginaddress
"mainchain_address": "3PAoFxiMsa8tgv6dDvYVqRSyweMyTpVxcZ"
txid 712ebc922cc4ba2054519afb00f0c9742fd86f546425ad78aaba33392223dc07
I have gone over all the points of the process, both peg-in and claim, and I don't see where I am making the mistake.
It seems that after two weeks of patiently waiting for a response and there is no one who has time to respond. I thought this project was serious, and invested my time for nothing. And I can't claim my lost btc with your project either. It has given search engines like Google time to index it. I find it incredible.
@jomagalo sorry that you're having issues with your peg-in. I don't see any way we can help other than checking that you really have the right claimscript for you peg-in. In any case, please don't share your claimscript with anybody.
@psgreco Thanks for answering. I have the corresponding claimscript but it doesn't seem to match.
I have generated a getpeginaddress again with the latest version of elementsd and now the mainchain_address it gives me starts with bc1xxx. With the version that getpeginaddress generated previously it gave me a mainchain_address 3PAxxx.
That's very strange, liquid moved away from legacy addresses over a year ago. Was the node fully updated when you did the initial getpeginaddress?
Indeed it is very strange and it is driving me crazy, I must have encountered some type of bug that no one knows about. Can I publish the mainchain_address here?
I can't remember if the node was fully synchronized or not. The version was 22.1.1
Indeed it is very strange and it is driving me crazy, I must have encountered some type of bug that no one knows about. Can I publish the mainchain_address here?
I can't remember if the node was fully synchronized or not. The version was 22.1.1
Bug doesn't seem likely, and the version is not the problem, 22.1.1 is perfectly usable. I think the problem is that you executed getpeginaddress when the chain was not updated, so you tried to do the peg-in to an address that's not valid anymore. You can publish the address, but please don't paste the claimscript
"mainchain_address": "3PAoFxiMsa8tgv6dDvYVqRSyweMyTpVxcZ"
In any case, getpeginaddress should not be able to be executed if the node is not synchronized.
Is there any solution for this?
Yes, there is, but not an easy one, please send me an email to psgreco@gmail.com so we can coordinate somehow. I don't want you putting sensitive data in a public venue.
Issue handled offline, closing