--- Log opened Fri May 28 00:00:21 2021
04:31 <@dr-orlovsky> kanzure: thanks for making me an operator back! I will proceed with registration now (before was not able since was a non-op)
04:33 <@dr-orlovsky> registered
04:34 -!- dr-orlovsky changed the topic of #lnp-bp to: Developers channel for LNP/BP standards, specifications, proposals and library development for the protocols on top of Bitcoin and LN (LNP/BP stands for Lightning Network Protocol / Bitcoin Protocol). The channel is managed by LNP/BP Standards Association. To learn more pls check https://github.com/LNP-BP.
05:13 <@dr-orlovsky> I am considering of moving RGB from using Secp256k1-based pedersen commitments and bulletproofs to Curve25519-based. The main reason is the fact that current secp256k1-zkp library by Blockstream/ElementsProject does not provide bulletproof implementation and I had to use Grin fork of it, which significantly diverged and which I do not trust much: it is not really tested at the same level like Curve25519-based bulleproffs used in Monero for 
05:13 <@dr-orlovsky> a long time already and A. Poelstra told that Grin’s bulleptroof implementation does not follow the standard.
05:13 <@dr-orlovsky> While A. Poelstra works on Bulletproofs in Elements’ secp256k1-zkp since 2018, this work is still pending to be merged for abot a year for now, and we can’t wait for it longer, since we finalize RGB at this point and need to take decision which bulleproof implementation to use this/next month, leaving no time to wait for secp256k1-zkp to be completed
05:13 <@dr-orlovsky> Overall, my initial idea was not to increase the number of elliptic curves used by RGB, and stick to the same curve for confidential amounts as used in bitcoin (Secp256k1) expecting that when RGB will be ready to be finalized they will get bulletproofs working there. This has not happen and we already need Curve25519 for some other applications, like Tor addresses, so we link to that library anyway and the move will not increase the number 
05:13 <@dr-orlovsky> of our dependencies.
05:13 <@dr-orlovsky> From the security perspective, if Curve25519 will be broken (and Secp256k1 not), RGB will be in a bad position, so this increases the number of cryptographic assumptions we are relying onto. Oon the other side, Curve25519 bulletproofs are more compact AFAIR, so this provides some advantage
05:14 <@dr-orlovsky> * Telegram @giacomozucco: I've no issue with this. Your arguments for the choice seem rational. Just out of curiosity, did Andrew provide any feedback about this choice?
05:14 <@dr-orlovsky> * Telegram @FedericoTenga: I also find your arguments valid, not sure if there are other trade-offs on the table other than the amount of testing of the two options, but with my understanding moving to Curve25519 sounds rational, especially if it doesn't impact the number of dependencies
06:30 < kanzure> libsecp256k1-zkp does not have a bulletproof implementation?
06:30 < kanzure> have you asked andytoshi about that
--- Log closed Sat May 29 00:00:22 2021