Many thanks for your help!
Topic: Problems with P2SH transaction (Read 118 times)
This is exactly the information I was missing!
Many thanks for your help!
Many thanks for your help!
I have not yet understood the decoding of this script.
Which part of the script shows "witness" or P2WPKH?
There are two parts to this question, if you want to know how scripts are evaluated then you have to check the code found in interpreter.cpp. Or you look at my code in Script.cs but unlike the c++ code here the evaluation and execution are performed separately.Which part of the script shows "witness" or P2WPKH?
If you want to know how this is considered P2WPKH, I have to say it is like a contract. We agreed that any script that is between 4 and 42 bytes long and starts with a number OP (like OP_0, OP_5, OP_16, etc.) and is immediately followed by one and only 1 data push is a witness script and that number OP indicates the witness version. For version 0 the data being pushed to the stack (witness program) must either be 20 bytes (ie. P2WPKH) or 32 bytes (ie. P2WSH) and everything else is invalid and rejected.
My goal was actually to do a legacy transaction from address "2NAceVvLJopK7uSmsrSeig8F4EWYaxAK4tS" without witness data.
You can't because this address is defining a "locking mechanism" that can only be "unlocked" by providing a valid signature as its witness the way I explained above. This can not be changed since the public key script aka the lock aka the P2WPKH wrapped in P2SH address is already defined and the balance of it are protected by that "lock".
Ok, now I'll try to analyze this script:
"16 00 14 404c836c0ecbc42d1b20b999814319b17327100f"
This "OP_0" is included as a feature.
Is this the sign for a P2WPKH transaction?
"16 00 14 404c836c0ecbc42d1b20b999814319b17327100f"
Code:
16 = script length
00 = OP_0, OP_FALSE
14 = length of the following data
404c836c0ecbc42d1b20b999814319b17327100f = 20byte data (Hash160)
Is this the sign for a P2WPKH transaction?
Code:
0014404c836c0ecbc42d1b20b999814319b17327100f
It's all about this last point.
I'm trying to break this script down with:
Code:
decodescript 0014404c836c0ecbc42d1b20b999814319b17327100f
{
"asm": "0 404c836c0ecbc42d1b20b999814319b17327100f",
"reqSigs": 1,
"type": "witness_v0_keyhash",
"addresses": [
"tb1qgpxgxmqwe0zz6xeqhxvczscek9ejwyq02cv0nk"
],
"p2sh": "2NAceVvLJopK7uSmsrSeig8F4EWYaxAK4tS"
}
Which shows that it is indeed a "witness" script.
I have not yet understood the decoding of this script.
Which part of the script shows "witness" or P2WPKH?
My goal was actually to do a legacy transaction from address "2NAceVvLJopK7uSmsrSeig8F4EWYaxAK4tS" without witness data.
Like in this transaction: 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192
But it seems that this is not possible at all.
So the problem is with the signature script, right?
No, your signature script is actually fine. The problem is the missing witness items, there needs to be 2 items a public key and an ECDSA signature.The signature script of the transaction in the blockchain at that time is: 255121029b6d2c97b8b7c718c325d7be3ac30f7c9d67651bce0c929f55ee77ce58efcf8451ae
My created script is: 160014404c836c0ecbc42d1b20b999814319b17327100f
Now the first difference is that mine is shorter.
The size is not important, what the script is "translated" into is. I'll explain below.My created script is: 160014404c836c0ecbc42d1b20b999814319b17327100f
Now the first difference is that mine is shorter.
My assumption was that the OP_HASH160 of this script is compared with the one in the PK script.
I have therefore recorded the content of the Scriptest as an irrellevant.
It is but only on first step.I have therefore recorded the content of the Scriptest as an irrellevant.
Your statement is now that the content of the SigScript is decisive and leads to a statement as to whether it has to be signed with a Witness-TX or not. is that correct?
Basically this is what happens:1. We take the pubkey script from the UTXO (the inputs of the transaction we are evaluating)
2. Evaluate what type this pubkey script has
2.A. If it is not any special types then move to signature script, run that then run pubkey script then move to last step to see if tx is valid (top stack element has to be true)
2.B. If it is a witness script (OP_NUM
2.C. If it is P2SH then the signature script must be all data pushes and at least 1 is needed (the last one is interpreted as redeem script). Some initial checks are done (running signature script then pubkey script) Then we start evaluating that redeem script:
2.C.A. If it is not any special type then just execute the script and move to last step
2.C.B. If it is a special type (ie. witness scripts) then continue evaluation based on that type.
In case of your transaction we take the pubkey script
Code:
a914be8755917b4c5b783d11ed205c277f9a2788785387
Code:
160014404c836c0ecbc42d1b20b999814319b17327100f
Finally that stack element that was stored is evaluated as a script called redeem script.
Code:
0014404c836c0ecbc42d1b20b999814319b17327100f
Thank you so far, that takes me a step further!
So that there is no misunderstanding, I would like to repeat my understanding here again.
So the problem is with the signature script, right?
The signature script of the transaction in the blockchain at that time is: 255121029b6d2c97b8b7c718c325d7be3ac30f7c9d67651bce0c929f55ee77ce58efcf8451ae
My created script is: 160014404c836c0ecbc42d1b20b999814319b17327100f
Now the first difference is that mine is shorter.
My assumption was that the OP_HASH160 of this script is compared with the one in the PK script.
I have therefore recorded the content of the Scriptest as an irrellevant.
Your statement is now that the content of the SigScript is decisive and leads to a statement as to whether it has to be signed with a Witness-TX or not. is that correct?
If this is correct, can you tell me which part or which bytes this statement makes? Or is it even more complex?
Edit:
Ok i see it.
I will now examine the scripts and their statements in more detail only once and then contact me again if there are still questions.
Until then, thank you very much!
They have great help and great software! :-)
So that there is no misunderstanding, I would like to repeat my understanding here again.
So the problem is with the signature script, right?
The signature script of the transaction in the blockchain at that time is: 255121029b6d2c97b8b7c718c325d7be3ac30f7c9d67651bce0c929f55ee77ce58efcf8451ae
My created script is: 160014404c836c0ecbc42d1b20b999814319b17327100f
Now the first difference is that mine is shorter.
My assumption was that the OP_HASH160 of this script is compared with the one in the PK script.
I have therefore recorded the content of the Scriptest as an irrellevant.
Your statement is now that the content of the SigScript is decisive and leads to a statement as to whether it has to be signed with a Witness-TX or not. is that correct?
Edit:
Ok i see it.
I will now examine the scripts and their statements in more detail only once and then contact me again if there are still questions.
Until then, thank you very much!
They have great help and great software! :-)
Since the lock script is a legancy P2SH script, I would expect that the Tx can be created in the legancy transaction format (without witness).
Your assumption is wrong here. It doesn't matter that the output that is being spent was P2SH and looks like legacy, what matters is that what the "S" (script that got hashed) was and since your redeem script was a witness script then the transaction must contain the required witness on top of the program pushed as a redeem script in signature script.Since the Sig-Script was successfully tested with a script analysis tool from Coding-Enthusiast (BitcoinTransaktionsTool),
I apologize for the the inconvenience but that project is old and obsolete (I will update its readme for clarification, although it is mentioned in issues).Try my newer project that fully supports Segregated Witness.
This is where the magic happens: https://github.com/Autarkysoft/Denovo/blob/master/Src/Denovo/ViewModels/VerifyTxViewModel.cs
If you fill the boxes with correct values and set the block height (top right corner) to the imaginary block that would contain this tx (affects consensus rules) you get the following:
As an example there is a transaction in the MainNet: "6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192" which has the same properties, and since it is in the blockchain, it is obviously also valid.
That is not the same.If you look at the redeem script (last and only push in signature script) you realize that the type of it is a simple 1of1 legacy multi-sig whereas your redeem script is a P2WPKH one.
Problem description
I have created a P2SH transaction for the testnet that I cannot send.
Source transaction:
My created transaction that cannot be sent successfully.
Expected behavior:
Since the lock script is a legancy P2SH script, I would expect that the Tx can be created in the legancy transaction format (without witness).
Since the Sig-Script was successfully tested with a script analysis tool from Coding-Enthusiast (BitcoinTransaktionsTool), I would expect that the Tx can be successfully sent in the testnet.
As an example there is a transaction in the MainNet: "6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192" which has the same properties, and since it is in the blockchain, it is obviously also valid.
Actual behavior:
When trying to send the Tx, the following error occurs: Error code:"Witness program hash mismatch"
The error code seems questionable to me because a similar transaction of the same type already exists in the mainnet in the blockchain.
Previous troubleshooting of the transaction:
Script investigation:
The script is composed as follows:
+
This script ends with "true"
I have created a P2SH transaction for the testnet that I cannot send.
Source transaction:
Code:
Hex: 02000000000102e4ce41397cfed83b5fe407f5ce752749266a507a5dc092da0c6efebe9dcdbadf000000001716001466906f03529b19783761e8aa2020fe0c514e6e74feffffffd112a0eafebf15f6a5d59d291189c088b2b3b1da104b6f94a2009b780bd507f8000000001716001466906f03529b19783761e8aa2020fe0c514e6e74feffffff01692f47000000000017a914be8755917b4c5b783d11ed205c277f9a278878538702483045022100c990771bbd45bb22830662eefba407911219cfaed297ff97e022a8a02069ea7f022001c298df486f08e1df55f157d7189f5c629417a411fc118c9221da7ccdd3d2bd0121027c63e51800340b89947285500153d3012d24e72e8bd7b1ecfbc05c80d6c697590247304402200341f19dcc3bbbcea1275f1948efdc1f8d6475a23568e425f2bb3998aa62767c0220321a13a20c00131d4b4f88852469eb3b99a50e6a14fbb9c4a4e038018f13d5cb0121027c63e51800340b89947285500153d3012d24e72e8bd7b1ecfbc05c80d6c6975957ff1f00
TxHash: 08b1726fa16f74aaeee9cb6995ee917710a1a6e30676786bfd85126793adff28
Version: 2
Witness: true
Tx-In count: 2
Tx prev Hash 0: dfbacd9dbefe6e0cda92c05d7a506a26492775cef507e45f3bd8fe7c3941cee4
Tx prev Hash 1: f807d50b789b00a2946f4b10dab1b3b288c08911299dd5a5f615bffeeaa012d1
Tx Out Indx 0: 0
Tx Out Indx 1: 0
Sig.Script 0: 16001466906f03529b19783761e8aa2020fe0c514e6e74
Sig.Script 1: 16001466906f03529b19783761e8aa2020fe0c514e6e74
Sequence 0: feffffff
Sequence 1: feffffff
TxOut count: 1
Value: 0: 0.04665193
PK.Script 0: a914be8755917b4c5b783d11ed205c277f9a2788785387 <<<<<<<<<<<<<<<<<<<<< PK-Script which one is used.
Hash160 0: be8755917b4c5b783d11ed205c277f9a27887853
Bit.Addr: 0: 2NAceVvLJopK7uSmsrSeig8F4EWYaxAK4tS
Witness: 02483045022100c990771bbd45bb22830662eefba407911219cfaed297ff97e022a8a02069ea7f022001c298df486f08e1df55f157d7189f5c629417a411fc118c9221da7ccdd3d2bd0121027c63e51800340b89947285500153d3012d24e72e8bd7b1ecfbc05c80d6c697590247304402200341f19dcc3bbbcea1275f1948efdc1f8d6475a23568e425f2bb3998aa62767c0220321a13a20c00131d4b4f88852469eb3b99a50e6a14fbb9c4a4e038018f13d5cb0121027c63e51800340b89947285500153d3012d24e72e8bd7b1ecfbc05c80d6c69759
LockTime: 57ff1f00
My created transaction that cannot be sent successfully.
Code:
Hex: 010000000128ffad93671285fd6b787606e3a6a1107791ee9569cbe9eeaa746fa16f72b1080000000017160014404c836c0ecbc42d1b20b999814319b17327100fffffffff012f2b4700000000001976a91466906f03529b19783761e8aa2020fe0c514e6e7488ac00000000
TxHash: b9f7be44de4b460c4991d3ebd2ae1c9a3395c97fb5d1cd6a356a8302f24fb2d1
Version: 1
Witness: false
Tx-In count: 1
Tx prev Hash 0: 08b1726fa16f74aaeee9cb6995ee917710a1a6e30676786bfd85126793adff28
Tx Out Indx 0: 0
Sig.Script 0: 160014404c836c0ecbc42d1b20b999814319b17327100f <<<<<<<<<<<< SigScript which one is used.
Sequence 0: ffffffff
TxOut count: 1
Value: 0: 0.04664111
PK.Script 0: 76a91466906f03529b19783761e8aa2020fe0c514e6e7488ac
Hash160 0: 66906f03529b19783761e8aa2020fe0c514e6e74
Bit.Addr: 0: mpsGF3dv63xqFyjyiYGscJYtyhxDvwj8W1
Witness:
LockTime: 00000000
Expected behavior:
Since the lock script is a legancy P2SH script, I would expect that the Tx can be created in the legancy transaction format (without witness).
Since the Sig-Script was successfully tested with a script analysis tool from Coding-Enthusiast (BitcoinTransaktionsTool), I would expect that the Tx can be successfully sent in the testnet.
As an example there is a transaction in the MainNet: "6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192" which has the same properties, and since it is in the blockchain, it is obviously also valid.
Actual behavior:
When trying to send the Tx, the following error occurs: Error code:"Witness program hash mismatch"
The error code seems questionable to me because a similar transaction of the same type already exists in the mainnet in the blockchain.
Previous troubleshooting of the transaction:
Script investigation:
The script is composed as follows:
Code:
SigScript. 16 0014404c836c0ecbc42d1b20b999814319b17327100f
PK-Script: a9 14 be8755917b4c5b783d11ed205c277f9a27887853 87
Entire script: <0014404c836c0ecbc42d1b20b999814319b17327100f> OP_HASH160OP_EQUAL
This script ends with "true"
Jump to: