Our goal is (and has been) to make the most fungible and efficient token that we can. As such, we have looked at and experimented with any technology that is promising in that direction including blind signatures, ring signatures, and even (a little bit) zk-snarks.
Blind signatures are neat because they offer provable unlinkability. Unfortunately they require the use of denominations, which expose the transaction amounts, make the anonymity set smaller, and require many more DBCs (and network operations) to represent any given amount. In short, there are considerable tradeoffs. We explored them first (with exception of amount hiding) because they are relatively simple to implement with BLS cryptography and we did not have the necessary primitives (or expertise) to implement ring signatures at the time. So we proved out the concept and fully explored both the features and drawbacks, even going so far as to implement a novel denominations system and amount representation. Always though the blind sigs code was on a branch in our sn_dbc repo… it never even graduated to master. In the end, we were not satisfied with revealing the amounts and with the performance characteristics. We also (importantly) did not (yet?) have a solid solution for auditing that no double-spends occurred, eg if a section somehow became compromised. If we had no other option, we would have gone forward with it but…
A month or so ago David Rusu dove head first into the mathematics of bls and ring signatures and over the past month has created the blst-ringct crate along with improvements to blstrs crate and adapting the bulletproofs crate to use the bls curve. He really has put in an amazing effort. To be clear, no one has combined bls cryptography with ring signatures in this way before, at least not to our knowledge. So this combination opens up the door to achieve quite good fungibility with highly obfuscated links plus perfect amount hiding. We also should be able to support m-of-n multisig more cleanly than monero can, and offer very fast settlement times.
I realize these different DBC development branches (forks) can be confusing for the community, and sorry for that. At the same time, I hope people can understand we are trying our best to bring about fungibility, strong privacy, fast settlement, and good performance in a decentralized and novel (dbc) cryptocurrency with sharding. This is not a well trodden path, so sometimes we have to evaluate and make adjustments. We maintained both branches for several months in order to nourish each and prove out which would give the best outcome. Now it seems likely the ringct approach will be the winner.
At present, work has begun to start integrating blst-ringct into sn_dbc itself. Hopefully in the next week or two we can start testing out the dbc+ringct, which is pretty exciting. (clarification: internally testing, not a testnet yet)
My own outlook on all this is a little bittersweet because the blind-sigs was my fork/baby. However, when David’s ring sig work began showing promise I was the first to say, yeah let’s run with this. Because I just want the best system we can possibly have.
I hope that helps provide some perspective.
ps: with regards to Monero, I personally have a deep respect for the Monero technology, developers, ethos, and community. I don’t believe I’ve ever said anything to the contrary. It is true that ring signatures are not provably unlinkable the way that blind sigs (or zk-snarks) are, however in practice it seems to work about as well especially in recent years as ring size have increased and a few holes have been plugged. There is a reason that Monero is replacing bitcoin in darknet markets and also I recently saw it ranked 5th amongst all cryptocurrencies in terms of acceptance by merchants.