cryptoquick
commented
1 year ago Wow, this is an excellent overview, and your insight into a path forward is quite sensible. I appreciate your thinking towards moving things along by making tradeoffs, while designing a pathway to maintain privacy once a better solution is found.
How difficult would it be to fork the Dalek library so it runs on secp? The work doesn't need to be upstreamed if it's unmaintained and isn't copyleft.
Also, Peter Todd got sued by Zcash??? Do you have any links so I can get more background on that situation?
dr-orlovsky
Use of bulletproofs is an Achilles tendon of RGB protocol: they are required to prevent hidden inflation with the use of Pedersen commitments - but today there is no a single bulletproofs implementation without a significant tradeoffs.
This issue is created to put a modest proposal for this ongoing problem.
Bulletproofs implementations
First, I'd like to start with the analysis of existing bulletproof implementations:
grin_secp256k1zkp. Implementation is node by a Grin (mimblewimble) team in a fork of secp256k1-zkp on top of some preliminary work from Blockstream in the originalsecp256k1zkpC library - and not maintained anymore... It is the only implementation which is used in production with a value-containing network; though the value in that network is highly questionable. Andrew Poelstra (one of Bulletproofs co-author) also indicated that the implementation is diverged from Bulletproofs standard and he is not sure whether it is not buggy at all. Today RGB Core uses a fork of this implementationlnpbp_secp256k1zkpcreated with the only aim to prevent unpredictable changes from the Grin library we have no influence on.bulletproofs. Implementation by ZCash guys, including infamous person who tried to sue Peter Todd. Not maintained; uses different curve (Ristretto255, based on Curve25519/Edwards26619) but fast and pure rust.bulletproofs-pp, a proof-of-concept pure rust implementation of the Bulletproofs++ by the same person who works on C version at Blockstream as described above.Comparison
Discussion & proposal
From the above it is quite clear that this is a choice without a choice: each of the solutions is worse than the rest - no matter which one you will pick. C-libraries are, BTW, probably non-WASM compatible, etc.
My proposal is the following: avoid the choice by doing two things:
With that, we keep all bulletproof and Pedersen commitment business logic in RGB untouched - and can use any bulletproof library no matter how insecure it is! The moment we will see that the situation has changed, we release a new version which will construct a proper bulletproofs and conceal all historic data once and forever.
TL;DR: In RGB we can keep the zk data revealed - in this case bulletproofs are not created. Later we can conceal them - and at that time the bulletproof is constructed. It can be done by a different person than the current owner, i.e. by some future owner for all historical data. I.e. we do not need to select specific bulletproof implementation today for the RGB release.
Appendix A
Previous bulletproof-related issues to feel the pain of the choice from previous years: