Bulletproofs epic

[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:

1. Grin bulletproofs: 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 original secp256k1zkp C 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 implementation lnpbp_secp256k1zkp created with the only aim to prevent unpredictable changes from the Grin library we have no influence on.
2. Dalek bulletproofs: 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.
3. Elements: a new effort by Blockstream to implement newer version of bulletproofs (named bulletproofs++) in C as a part of secp256k1zkp ElementsProject library. The work there lasts for the last 4 years - but the most recent PRs finally demonstrate some sort of activity which may indicate that soon this work might be merged (in 1 week - or in another 4 years). One may play the wheel of fortune and bet on the deadlines here:
   • Bulletproofs++: Norm argument BlockstreamResearch/secp256k1-zkp#205
   • Bp++: Rangeproof PR BlockstreamResearch/secp256k1-zkp#207
     This implementation was never used anywhere - but I assume someday it would get into Liquid (will require a hardfork though).
4. Sanket: 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

Library	Standard	Production	Language	Curve	Speed	Maintained	Team
Grin	non-standard	yes	C -> Rust	Secp256k1	slow	no	Grin
Dalek	standard	no	Rust	Ristretto255	ultrafast	no	ZCash
Elements	new standard	planned	C	Secp256k1	slow	yes	Blockstream
Sanket	new standard	not recommended	Rust	Secp256k1	slow	no	Blockstream

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:

• leverage the fact that bulletproofs data are not part of the consensus commitments in RGB and can be replaced later;
• for now keep the revealed amounts when doing consignment transfers, i.e. do not conceal them.

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:

• Ensure zk improvements are all in place #127
• Allow bulletproof implementation upgradability in RGB schema #126
• Use secp256k1-zkp for bulletproofs & Pedersen commitments #9
• Use Curve25519 based confidential amounts instead of Secp256k1 #85
• Remove bulletproofs from consensus commitments #78
• Make bulletproof validation part of the schema #75

[cryptoquick]

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]

How difficult would it be to fork the Dalek library so it runs on secp?

Like rewriting it from scratch, so it is a non-go.

Also, Peter Todd got sued by Zcash??? Do you have any links so I can get more background on that situation?

I prefer not to comment on this situation in a public space knowing how much these ppl can be abusive with their litigations.