mimblewimble / rust-secp256k1-zkp

ZKP fork for rust-secp256k1, adds wrappers for range proofs, pedersen commitments, etc
Creative Commons Zero v1.0 Universal
56 stars 51 forks source link

Problem with a bulletproof message on iOS #41

Closed i1skn closed 5 years ago

i1skn commented 5 years ago

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:

____ Wallet Accounts ____

 Name      | Parent BIP-32 Derivation Path
-----------+-------------------------------
 account_0 | m/540140409/3298754560
 account_1 | m/543567437/4159635456

Command 'account' completed successfully

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 to ffi::secp256k1_bulletproof_rangeproof_prove (passed as the last parameter) and later call rewind_bullet_proof with the just created bulletproof I got a different message, like ProofMessage(800da21d66b30000c2001b3a29f0c041). So, I assume, the message I pass to ffi::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:

thread #2: tid = 0x3cd272, 0x0000000101056e18 Dinghy`secp256k1_fe_set_b32(r=0x000000016f239528, a="") at field_10x26_impl.h:324, name = 'pedersen::tests::test_bullet_proo[15/558]
ig', stop reason = EXC_BAD_ACCESS (code=1, address=0xa7974c91c050)
  frame #0: 0x0000000101056e18 Dinghy`secp256k1_fe_set_b32(r=0x000000016f239528, a="") at field_10x26_impl.h:324
  frame #1: 0x0000000101057d64 Dinghy`secp256k1_pedersen_commitment_load(ge=0x00000002833180a0, commit=0x0000a7974c91c030) at main_impl.h:31
  frame #2: 0x000000010105f110 Dinghy`secp256k1_bulletproof_rangeproof_prove(ctx=0x0000000283b00000, scratch=0x0000000283018120, gens=0x0000000280204060, proof=0x0000000000000000
, plen=0x0000000000000000, tau_x=0x0000000000000000, t_one=0x000000016f23df30, t_two=0x000000016f23df70, value=0x000000016f239b10, min_value=0x0000000000000000, blind=0x000000028
001c020, commits=0x000000028001c030, n_commits=1, value_gen=0x000000010114a3e1, nbits=64, nonce="bdnW\ #\xab\xa342\xb6.(\x93f", private_nonce="𧜒\x8cV5%\xb1K(iVƥ\x02\xa9c;\x19RT\
xb5\\\xba\xb7, extra_commit=0x0000000000000000, extra_commit_len=0, message=0x0000000000000000) at main_impl.h:252
  frame #3: 0x000000010101e538 Dinghy`secp256k1zkp::pedersen::_$LT$impl$u20$secp256k1zkp..Secp256k1$GT$::bullet_proof_multisig::h5ef5f4a8d3562320(self=0x000000016f23dce8, value=1
2345678, blind=(__0 = "\n\xbfDL?]K[\vF\x01\x1e\xac$hv\xb0\x1c\x8c\x9foMg\x02\x1f\x86$]bdnW\ #\xab\xa342\xb6.(\x93f"), nonce=(__0 = "bdnW\ #\xab\xa342\xb6.(\x93f"), extra_data_in=
Option<alloc::vec::Vec<u8>> @ 0x000000016f23f410, message=Option<secp256k1zkp::pedersen::ProofMessage> @ 0x000000016f23f428, tau_x=Option<&mut secp256k1zkp::key::SecretKey> @ 0x0
00000016f239b18, t_one=Option<&mut secp256k1zkp::key::PublicKey> @ 0x000000016f239b20, t_two=Option<&mut secp256k1zkp::key::PublicKey> @ 0x000000016f239b28, commits=Vec<secp256k1
zkp::pedersen::Commitment> @ 0x000000016f23f458, private_nonce=Option<&secp256k1zkp::key::SecretKey> @ 0x000000016f239b30, step='\x01') at pedersen.rs:876
  frame #4: 0x0000000100fe4bcc Dinghy`secp256k1zkp::pedersen::tests::test_bullet_proof_multisig::_$u7b$$u7b$closure$u7d$$u7d$::hc44612881ad44945((null)=0x000000016f248c8f, v=1234
5678, nonce=(__0 = "bdnW\ #\xab\xa342\xb6.(\x93f\t\xad\x1b3i\t\xa843;TqG\x1bv\x9d}Y\x1b\xa905T\\\x85Y\xb0b\t\x9d\r\x15\x17ۊ\x9ed\\"\x03C\x05\x82Y\x12\"\x19\x94\x15\xa1\xacV\x83Ov
\x1f\xaem\n\\AOAXK\r\xa0ވ\xb5Ǐ"), ca=(__0 = "\t\xad\x1b3i\t\xa843;TqG\x1bv\x9d}Y\x1b\xa905T\\\x85Y\xb0b\t\x9d\r\x15\x17ۊ\x9ed\\"\x03C\x05\x82Y\x12\"\x19\x94\x15\xa1\xacV\x83Ov\x8\x1f\xaem\n\\AOAXK\r\xa0ވ\xb5Ǐ"), cb=(__0 = "\t\x9d\r\x15\x17ۊ\x9ed\\"\x03C\x05\x82Y\x12\"\x19\x94\x15\xa1\xacV\x83Ov\x84\n\xbfDL?]K[\vF\x01\x1e\xac$hv\xb0\x1c\x8c\x9foMg\x02\x1f\x1f\xaem\n\\AOAXK\r\xa0ވ\xb5Ǐ"), msg=Option<secp256k1zkp::pedersen::ProofMessage> @ 0x000000016f24a248, extra=Option<alloc::vec::Vec<u8>> @ 0x000000016f24a308) at pedersen.rs:1497
  frame #5: 0x0000000100fcf8e4 Dinghy`secp256k1zkp::pedersen::tests::test_bullet_proof_multisig::hf9efca6961c2e153 at pedersen.rs:1611
  frame #6: 0x0000000100fe45e4 Dinghy`secp256k1zkp::pedersen::tests::test_bullet_proof_multisig::_$u7b$$u7b$closure$u7d$$u7d$::he12b73a0ec3b3e1c((null)=0x000000016f24e8de) at pedersen.rs:1467
error: need to add support for DW_TAG_base_type '()' encoded with DW_ATE = 0x7, bit_size = 0
  frame #7: 0x000000010103cd70 Dinghy`core::ops::function::FnOnce::call_once::hab10037076c9bf16((null)=closure @ 0x000000016f24e8de, (null)=<unavailable>) at function.rs:238
  frame #8: 0x000000010108505c Dinghy`_$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h7cd9458e96c61134 [inlined] test::run_test::_$u7b$$u7b$closure$u7d$$u7d$::hcfb9d86a7c3d2c96 at lib.rs:1468 [opt]
  frame #9: 0x0000000101085058 Dinghy`_$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h7cd9458e96c61134 [inlined] core::ops::function::FnOnce::call_once::h4391d3a834d88d8b at function.rs:238 [opt]
  frame #10: 0x0000000101085058 Dinghy`_$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h7cd9458e96c61134 at boxed.rs:672 [opt]
  frame #11: 0x000000010113ca84 Dinghy`__rust_maybe_catch_panic at lib.rs:102 [opt]
  frame #12: 0x00000001010a1b20 Dinghy`std::sys_common::backtrace::__rust_begin_short_backtrace::hfba72662a42f7cac [inlined] std::panicking::try::h732fe36cab73cb41 at panicking.r
s:289 [opt]
  frame #13: 0x00000001010a1af8 Dinghy`std::sys_common::backtrace::__rust_begin_short_backtrace::hfba72662a42f7cac [inlined] std::panic::catch_unwind::hac4e2f50e06b27fe at panic.
rs:392 [opt]
  frame #14: 0x00000001010a1af8 Dinghy`std::sys_common::backtrace::__rust_begin_short_backtrace::hfba72662a42f7cac [inlined] test::run_test::run_test_inner::_$u7b$$u7b$closure$u7
d$$u7d$::h006e4850988c9367 at lib.rs:1423 [opt]
  frame #15: 0x00000001010a1a5c Dinghy`std::sys_common::backtrace::__rust_begin_short_backtrace::hfba72662a42f7cac at backtrace.rs:136 [opt]
  frame #16: 0x00000001010a23d4 Dinghy`std::panicking::try::do_call::h4daf77ea764d46fd [inlined] std::thread::Builder::spawn::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d
$$u7d$::hdf44bf80f31b708f at mod.rs:409 [opt]
  frame #17: 0x00000001010a23ac Dinghy`std::panicking::try::do_call::h4daf77ea764d46fd [inlined] _$LT$std..panic..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce
$LT$$LP$$RP$$GT$$GT$::call_once::hfe8230c624f93446 at panic.rs:313 [opt]
  frame #18: 0x00000001010a23ac Dinghy`std::panicking::try::do_call::h4daf77ea764d46fd at panicking.rs:310 [opt]
  frame #19: 0x000000010113ca84 Dinghy`__rust_maybe_catch_panic at lib.rs:102 [opt]
  frame #20: 0x000000010109189c Dinghy`_$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h9f47ca2e7bc599f5 [inlined] std::panicking::try::h25ee5a857b5a665a at panicki
ng.rs:289 [opt]
  frame #21: 0x0000000101091840 Dinghy`_$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h9f47ca2e7bc599f5 [inlined] std::panic::catch_unwind::hb4be13ae309c1f2b at panic.rs:392 [opt]
  frame #22: 0x0000000101091840 Dinghy`_$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h9f47ca2e7bc599f5 [inlined] std::thread::Builder::spawn::_$u7b$$u7b$closure$u7d$$u7d$::hc8e2b8523d8822bb at mod.rs:408 [opt]
  frame #23: 0x000000010109181c Dinghy`_$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h9f47ca2e7bc599f5 at boxed.rs:672 [opt]
  frame #24: 0x0000000101132334 Dinghy`std::sys::unix::thread::Thread::new::thread_start::h53cadc7a8d993d1d [inlined] _$LT$alloc..boxed..Box$LT$$LP$dyn$u20$alloc..boxed..FnBox$LT$A$C$$u20$Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$RP$$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::h1550d5c67ef40595 at boxed.rs:682 [opt]
  frame #25: 0x000000010113232c Dinghy`std::sys::unix::thread::Thread::new::thread_start::h53cadc7a8d993d1d [inlined] std::sys_common::thread::start_thread::ha4b13f99b17bd904 at thread.rs:24 [opt]
  frame #26: 0x0000000101132320 Dinghy`std::sys::unix::thread::Thread::new::thread_start::h53cadc7a8d993d1d at thread.rs:90 [opt]
  frame #27: 0x00000001c06e825c libsystem_pthread.dylib`<redacted> + 128
  frame #28: 0x00000001c06e81bc libsystem_pthread.dylib`_pthread_start + 48
 ERROR cargo_dinghy                > Error: LLDB returned error code Some(255)

I would appreciate any clues how I can fix this, thanks in advance!

hashmap commented 5 years ago

perhaps related https://github.com/mimblewimble/rust-secp256k1-zkp/issues/40

yeastplume commented 5 years ago

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.

i1skn commented 5 years ago

Unfortunately, tests are still failing.

yeastplume commented 5 years ago

Okay, I think I have it reproduced, give me a few hours and I’ll ask you to try it again

i1skn commented 5 years ago

@yeastplume thanks a lot!

i1skn commented 5 years ago

It seems, that it actually worked, tests are failing, but it stores the correct ProofMessage on iOS!

yeastplume commented 5 years ago

Great! I'm going to try and fix all tests and then integrate changes into grin

yeastplume commented 5 years ago

Okay, would you mind running the tests one more time? Should no longer be failing

i1skn commented 5 years ago

@yeastplume Just tested - all passed! Awesome work, thanks! We can close this one.