Closed i1skn closed 5 years ago
perhaps related https://github.com/mimblewimble/rust-secp256k1-zkp/issues/40
Can you pull the latest https://github.com/mimblewimble/rust-secp256k1-zkp and try running the tests again? I have a feeling that the pointer being sent into C from Rust was pointing at something that was silently going out of scope (i.e. in a way that Rust doesn't notice), which may explain inconsistent failures.
Unfortunately, tests are still failing.
Okay, I think I have it reproduced, give me a few hours and I’ll ask you to try it again
@yeastplume thanks a lot!
It seems, that it actually worked, tests are failing, but it stores the correct ProofMessage on iOS!
Great! I'm going to try and fix all tests and then integrate changes into grin
Okay, would you mind running the tests one more time? Should no longer be failing
@yeastplume Just tested - all passed! Awesome work, thanks! We can close this one.
Background: when I perform a transaction on iOS wallet (which use grin codebase compiled for iOS), and later on I restore the wallet - each transaction maps to a weird BIP32 account:
I've started to dig in and understood, that we are using a bulletproof message to store the BIP32 path for identifying the account during restore. Then, I observed that when I create a bulletproof with
ProofMessage(00000000000000000000000000000000)
as a message toffi::secp256k1_bulletproof_rangeproof_prove
(passed as the last parameter) and later callrewind_bullet_proof
with the just created bulletproof I got a different message, likeProofMessage(800da21d66b30000c2001b3a29f0c041)
. So, I assume, the message I pass toffi::secp256k1_bulletproof_rangeproof_prove
for some reason get distorted.I've tried to run the tests on iPhone using https://github.com/snipsco/dinghy, and they are failing with the following:
I would appreciate any clues how I can fix this, thanks in advance!