Bullet proofs and supply chain transactions

[arthurgreef]

Hi Andrew - we have been looking at using bullet proofs for proof of location knowledge, and proof of environment knowledge (temperature/humidity) in supply chain transactions. I was wondering if you could help us out with our questions.

1. The Confidential Transactions API provide a min/max range but the bullet proof API only seem to provide a min range API. Is there a reason for this or are we missing something.

2. Once we have a range proof we would like to pass this proof down a chain of suppliers and customers in a way that observers of the public data on the blockchain cannot trace back up the chain to reveal the addresses of the participants in the chain of supplier and customers. Something like what is described here: http://dspace.mit.edu/bitstream/handle/1721.1/35401/31311897-MIT.pdf;sequence=2
   We are not sure if there is a library that can help with this or if there is more recent research that we should be looking at.

Thanks

[apoelstra]

1. Bulletproofs always use a 64-bit range. It is complicated to produce smaller ranges with Bulletproofs, and in our applications the only reason to do so would have been performance, which is no longer a concern.
2. Bulletproofs are non-interactive proofs of knowledge which are innately transferrable. The referenced paper appears to talk about making interactive proofs transferrable while reblinding along the way. It is not applicable to Bulletproofs or blockchains -- non-interactive proofs can't be reblinded by third parties, and the linkage created by a blockchain will likely undermine any such attempts anyway.

[arthurgreef]

Regarding comment #2. Do you have an idea or a reference that can help us understand how we transfer bullet proofs so that they cannot be used to trace the chain of transfer?

[apoelstra]

No, Bulletproofs are meant to be public data that cannot be modified after the fact without invalidating the proof.

[FrankC01]

With respects to the first question:

Scenario: Want to verify that a temperature did not exceed an upper value (say 90 degrees)

So, should the Confidential Transactions API be used instead of the bulletproof or am I missing some aspect of bullet proof where that can be verified?

Sorry for butting in on the thread.
Frank

[arthurgreef]

OK we'll have to dig into something like zCash commitments and nullifiers to prevent transaction tracing. Thanks.

[apoelstra]

@FrankC01 yes, if you want to use maximums you should use the CT API rather than Bulletproofs.
@arthurgreef yes, you'll need to do something like that to prevent transaction tracing; BP rangeproofs are not powerful enough.

[FrankC01]

@apoelstra Thanks for the feedback. BTW, with respects to the shared library exposing the 'g' and 'h' generators would you like me to do a pull request?

[apoelstra]

@FrankC01 Yes, sorry for not getting on that - if you make a PR I'll accept it.

[FrankC01]

Done: 'patch_1`, not a very inventive name but I didn't find any ROE for PRs