You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A very deeply hidden bug appears only on GCC/G++ 11.x when the internal libsnark is compiled using highly optimized assembly implementations. It is not the default compilation behavior for Komodod from the KomodoPlatform, but it was always (implicitly) the default build behavior for KomodoOcean.
Steps to reproduce:
Install Ubuntu 22.04.2 LTS, which have g++ (Ubuntu 11.3.0-1ubuntu1~22.04.1) 11.3.0 by default.
Preprocessor directive USE_ASM is default for KomodoOcean, as it used in other sources, not libsnark only, and it set from config/bitcoin-config.h by default.
Try to sync SUPERNET assetchain or any other chain which have sprout involved transactions:
return false on valid transaction, i.e. ProofVerifier::check on perform_verification returns false from r1cs_ppzksnark_online_verifier_strong_IC.
Of course, the chances that somebody will try to use assembly optimisations for libsnark are very low, but the fact is that in KomodoOcean they are used by default. Furthermore, libsnark compiled even with these optimisations has not had any issues when compiled with gcc 10 from Debian 11. However, gcc 11 seems to have introduced some bug in the library. Additionally, we (and it seems ZCash as well) do not have any proper tests to catch this libsnark behavior and that is the point to consider.
The text was updated successfully, but these errors were encountered:
DeckerSU
added a commit
to DeckerSU/KomodoOcean
that referenced
this issue
Jul 11, 2023
It always was default behavior to build KomodoOcean with `-DUSE_ASM=1`
which is set by default through `config/bitcoin-config.h`. This flag
used not only by `libsnark`, but also by the hardrware SHA256 optimisations
in other sources, etc. However, it turns out that on g++ 11.3.0 enabled
optimisations for libsnark makes ibzcash::PHGRProof (SproutProofVerifier)
not working, and as a result when users tried to sync old chains which
had `sprout` transactions in history, like `SUPERNET`, the verification
of valid transactions throw an error:
```
2023-07-11 15:01:07 ERROR: CheckTransaction(): joinsplit does not verify
2023-07-11 15:01:07 ERROR: CheckBlock: CheckTransaction failed
```
While on gcc/g++ 10.x there was no such error. That's why we decided to
disable `libsnark` optimisations at all, by "shadowing" `USE_ASM` in
internal libnark implementation and rename it to `USE_ASM_SNARK`, to
avoid build with ASM optimisations, which are "unstable" on modern compilers.
More details here:
KomodoPlatform/komodo#591
A very deeply hidden bug appears only on GCC/G++
11.x
when the internallibsnark
is compiled using highly optimized assembly implementations. It is not the default compilation behavior forKomodod
from theKomodoPlatform
, but it was always (implicitly) the default build behavior for KomodoOcean.Steps to reproduce:
Ubuntu 22.04.2 LTS
, which haveg++ (Ubuntu 11.3.0-1ubuntu1~22.04.1) 11.3.0
by default.master
branch.libsnark
build by build daemon with:Preprocessor directive
USE_ASM
is default for KomodoOcean, as it used in other sources, notlibsnark
only, and it set fromconfig/bitcoin-config.h
by default.SUPERNET
assetchain or any other chain which havesprout
involved transactions:Which means that:
return false on valid transaction, i.e.
ProofVerifier::check
onperform_verification
returns false fromr1cs_ppzksnark_online_verifier_strong_IC
.Of course, the chances that somebody will try to use assembly optimisations for
libsnark
are very low, but the fact is that inKomodoOcean
they are used by default. Furthermore,libsnark
compiled even with these optimisations has not had any issues when compiled withgcc 10
from Debian 11. However,gcc 11
seems to have introduced some bug in the library. Additionally, we (and it seems ZCash as well) do not have any proper tests to catch thislibsnark
behavior and that is the point to consider.The text was updated successfully, but these errors were encountered: