value of type `secp256k1_surjectionproof` has no member `data` about secp256k1.swift

[csjones]

Hey @mattiaferrari02 👋

Would you mind sharing the relevant code? It's difficult to understand the compilation error without seeing how the secp256k1_surjectionproof is created in the first place.

[mattiaferrari02]

Ok sorry, this is a function that takes in input the secp256k1_surjectionproof data and creates the serialized version of the data used

@objc(proofSerialize:usedInputs:proofdata:)
    func proofSerialize(_ nInputs: NSNumber, usedInputs: NSString, proofdata: NSString) -> NSString {
        let context = secp256k1_context_create(UInt32(SECP256K1_CONTEXT_SIGN | SECP256K1_CONTEXT_VERIFY))!
        defer { secp256k1_context_destroy(context) }
        var proof: secp256k1_surjectionproof = secp256k1_surjectionproof()
        
        var parsedNInputs = nInputs as! Int
        var output = [UInt8](repeating: 0, count: 8258)
        var outLen: Int = Int()
        memcpy(&(proof.n_inputs), &parsedNInputs, MemoryLayout<size_t>.size)
        try! memcpy(&(proof.used_inputs), (usedInputs as String).bytes, 32)
        try! memcpy(&(proof.data), (proofdata as String).bytes, 8224) // This row causes compilation error
        
        secp256k1_surjectionproof_serialize(context, &output, &outLen, &proof)
        
        return String(bytes: output) as NSString
    }

[csjones]

Looking over the API, I think you'll need to call secp256k1_surjectionproof_initialize and secp256k1_surjectionproof_generate before you get valid data from secp256k1_surjectionproof_serialize. If you're trying to load the struct with data, you'll need to use secp256k1_surjectionproof_parse and the package provides simple data copying functions so that you don't need memcpy.

[mattiaferrari02]

Well ok, but the thing is that i can't ever use 'proof.data' because it isn't somehow recognised

[csjones]

That's is odd because the secp256k1_surjectionproof struct doesn't seem to have a different access type when comparing to other structs supported by this package (likesecp256k1_ecdsa_recoverable_signature). When attempting to access the data property from secp256k1_ecdsa_recoverable_signature Swift, there are no issues which is what I would expect for you with secp256k1_surjectionproof.

You might have an issue exposing the Surjection Proof module to the codebase you're working in. I'll try and reproduce this issue from with this package. It's possible that we are missing something from the upstream secp256k1-zkp repo.

[mattiaferrari02]

I find it quite weird myself, but i guess as a workaround i'll need to write this code directly in c...
FYI i tried modifying manually the header file containing the struct of the secp256k1_surjectionproof, I replaced the length of the array with a much lesser number and then magically xcode didn't show the error anymore. At this point I think that's an error with the bridging header from c that somehow doesn't understand an array of that length.
Thanks for the help

[mattiaferrari02]

That's is odd because the secp256k1_surjectionproof struct doesn't seem to have a different access type when comparing to other structs supported by this package (likesecp256k1_ecdsa_recoverable_signature). When attempting to access the data property from secp256k1_ecdsa_recoverable_signature Swift, there are no issues which is what I would expect for you with secp256k1_surjectionproof.

You might have an issue exposing the Surjection Proof module to the codebase you're working in. I'll try and reproduce this issue from with this package. It's possible that we are missing something from the upstream secp256k1-zkp repo.

Reguarding this, it seems that this is the reason https://developer.apple.com/forums/thread/125614
The swift bridge transforms the c arrays into tuples and there is a limitation of 4096 bytes to them, so the surjectionproof struct has an error because the length of data is 8224 but it should be interpreted correctly at compiler level

[csjones]

but could you please try to call secp256k1_surjectionproof_parse with this hex string as input?

Hey @mattiaferrari02 do you still need help with this? I haven't made much progress

Reguarding this, it seems that this is the reason https://developer.apple.com/forums/thread/125614 The swift bridge transforms the c arrays into tuples and there is a limitation of 4096 bytes to them, so the surjectionproof struct has an error because the length of data is 8224 but it should be interpreted correctly at compiler level

This is a good find, thanks for sharing!

[mattiaferrari02]

but could you please try to call secp256k1_surjectionproof_parse with this hex string as input?

Hey @mattiaferrari02 do you still need help with this? I haven't made much progress

Yeah, still need help...
The serialized proof should be this 01000183c9c42d29f97befd28bc079a105ead7d36c5118cc4c1f542381cda81871bf121dfa5abc8ff90e4ad013c0666e6437dafc6a637f1853a6debc4c802b381032d8. This is 67 bytes long, is that correct? I read the code in of secp256k1_surjectionproof_parse but I did not understand how this string should become the 8224 bytes proof data

[csjones]

Yeah, still need help... The serialized proof should be this 01000183c9c42d29f97befd28bc079a105ead7d36c5118cc4c1f542381cda81871bf121dfa5abc8ff90e4ad013c0666e6437dafc6a637f1853a6debc4c802b381032d8. This is 67 bytes long, is that correct? I read the code in of secp256k1_surjectionproof_parse but I did not understand how this string should become the 8224 bytes proof data

Are you using a reference implementation for Surjection Proof? I'm not aware of an official BIP that would tell us the expected bytes length.

[mattiaferrari02]

I don't know, everytime i tried it resulted like that

[csjones]

@mattiaferrari02 I've started a draft PR with an initial implementation here: #325

Feel free to suggest any feedback you have 😁

EDIT: I'm still working through this documentation: https://elementsproject.org/features/confidential-transactions

[csjones]

It's been a while since there was any activity on this thread. To keep issues organized, I'll be closing this thread. If you have any further questions or concerns related to this, please feel free to reopen it or create a new thread.