Closed katsucodes247 closed 6 months ago
Another potentially interesting observation, when I parse a hex string the scripts parses it correctly, but when serializing, it serializes it into a different hex string?
>>> WitnessScript.parse(BytesIO(bytes.fromhex("52935487")))
OP_ADD OP_4 OP_EQUAL
>>> WitnessScript.parse(BytesIO(bytes.fromhex("52935487"))).is_witness_script()
False
>>> WitnessScript.parse(BytesIO(bytes.fromhex("52935487"))).raw_serialize().hex()
'935487'
>>> WitnessScript.parse(BytesIO(bytes.fromhex("52935487"))).serialize().hex()
'03935487'
>>> Script.parse(BytesIO(bytes.fromhex("52935487")))
OP_ADD OP_4 OP_EQUAL
>>> Script.parse(BytesIO(bytes.fromhex("52935487"))).serialize().hex()
'03935487'
>>> Script.parse(BytesIO(bytes.fromhex("52935487"))).raw_serialize().hex()
'935487'
>>> TapScript.parse(BytesIO(bytes.fromhex("52935487")))
OP_ADD OP_4 OP_EQUAL
>>> TapScript.parse(BytesIO(bytes.fromhex("52935487"))).serialize().hex()
'03935487'
>>> TapScript.parse(BytesIO(bytes.fromhex("52935487"))).raw_serialize().hex()
'935487'
I've found an issue with OP_1 -> OP_16 range.
| word | int | hex |
|---------------|-------|-----------|
| OP_1NEGATE | 79 | 0x4f |
| OP_1, OP_TRUE | 81 | 0x51 |
| OP_2-OP_16 | 82-96 | 0x52-0x60 |
And this is how buidl does it:
>>> from buidl.op import *
>>> encode_num(2)
b'\x02'
>>> encode_num(2).hex()
'02'
>>> from buidl.op import *
>>> stack = []
>>> op_2(stack)
True
>>> stack
[b'\x02']
Closing this because. I shouldn't have passed in 2 and 4 ints. I was confused because script = Script([2, 147, 4, 135])
evaluated into OP_[2] OP_ADD OP_[4] OP_EQUAL
and I thought that 2 got changed into OP_2
but it turns out OP_2
!== OP_[2]
.
>>> Script.parse_hex('52935487')
OP_2 OP_ADD OP_4 OP_EQUAL
>>> Script.parse_hex('52935487').commands
[82, 147, 84, 135]
>>> Script([2, 147, 4, 135])
OP_[2] OP_ADD OP_[4] OP_EQUAL
>>> Script([2, 147, 4, 135]).commands
[2, 147, 4, 135
Hi, I've been trying to create taproot script path spend transaction but have been hit a wall. I can't say with certainty if the issue is in the library or with how I use it.
Then I serialize the tapleaf in order to include to
tx_in.wintness.items
but I get an unexpected serialize data which also fails to get decoded correctly when using bitcoin-cli'sdecodescript
.When I decode
02930487
using bitcoin-cli I don't get the expected result (which isOP_2 OP_ADD OP_4 OP_EQUAL
:I've tried to make sense if the problem is in the way I use the library or not, but haven't been successful so far. Any pointer would be greatly appreciated.