Open Alrighttt opened 4 years ago
@Alrighttt could you post the output of zeno version
?
zeno 0.2.3.0 master@c97e6a44 Jun 17 (commit 189) (dirty)
It may be that one of the other participating nodes is on an older version. I will do some research and figure out which signature is bad.
The second vin of the transaction from Tony's node returns with a false stack element, indicating the signature is malformed. Doesn't really tell us how or why.
{
"txid": "37e9d210096d9f5d80d4bc73bf391d9656708ac5163efdc1b463fb03c094c7ad",
"vout": 2,
"scriptSig": {
"asm": "3045022100b1fc3878a851565fc7f77f0cd58007181b4dc3572b2922522266d683dd8e3be10220717da620c69756d385e8e1998cea6c540075716ac6248318ac6d62b78f95dda5[ALL]",
"hex": "483045022100b1fc3878a851565fc7f77f0cd58007181b4dc3572b2922522266d683dd8e3be10220717da620c69756d385e8e1998cea6c540075716ac6248318ac6d62b78f95dda501"
},
"sequence": 4294967295
},
It fails at this check: https://github.com/KomodoPlatform/komodo/blob/e7e81457214f0f4ce7a7b8dcc9877fc17ce282f5/src/script/interpreter.cpp#L1522
@tonymorony if possible, could you tell us which commit your node was on at 11:33 UTC June 18 (yesterday)
@Alrighttt
cat zeno.log | grep master@ -a1
0.2.2.1
zeno 0.2.2.1 master@76fe06bb Jun 16 (commit 181) (dirty)
[17:50:48][Info] Loading bitcoin config: /root/.komodo/TXSCLZ3/TXSCLZ3.conf
--
bump version
zeno 0.2.2.2 master@1560f2c9 Jun 16 (commit 186) (dirty)
[22:42:27][Info] Loading bitcoin config: /root/.komodo/TXSCLZ3/TXSCLZ3.conf
--
remove stray printf
zeno 0.2.3.0 master@db0f30ed Jun 17 (commit 188) (dirty)
[05:37:32][Info] Loading bitcoin config: /root/.komodo/TXSCLZ3/TXSCLZ3.conf
--
fix bug in proposer round robin config
zeno 0.2.3.0 master@c97e6a44 Jun 17 (commit 189) (dirty)
[12:00:31][Info] Loading bitcoin config: /root/.komodo/TXSCLZ3/TXSCLZ3.conf
I think I was on zeno 0.2.3.0 master@c97e6a44
@Alrighttt and I have been looking into it, and we verified that there is a bad signature and it's not a problem of the sighash being generated wrongly.
I have pushed a change in 0.2.3.1
which updates the upstream secp256k1 wrapper, since it previously had a bug which could result in wrong signatures being generated, so we'll see if that fixes it.
I experienced this on my TXSCLZ3 node. I believe it indicates an issue with one of the signatures.