The “blinding” referred to in the summary is different from traditional blind signature DBC’s which normally require fixed denominations, eg as described in the “Scrit” whitepaper. What we have recently implemented is based on “Confidential Transactions” used in monero and bitcoin elements sidechain, except using BLS for (multisig) encryption. In this scheme amounts are encrypted by sender/reissuer so that only the recipient (holder(s) of secret key) can view them, regardless of who sees the DBCs. Even the mint nodes never see the amounts. The sum of outputs is proved equal to the sum of inputs with pedersen commitments and a bulletproof proves that the amount is non-negative. This adds a great deal of privacy, however I should point out that it does NOT make the transactions unlinkable by mint nodes in the way that a blinded DBC would. For that, something like ring signatures or perhaps snarks of some type may be indicated. In practice this may not be such an issue because no single mint node sees all the Tx, and also (perhaps) the mint nodes will keep the info private, though we should not rely on them doing so, and auditing / proof of payment without public disclosure of reissues remain open issues. Also though, linking together amountless, single-use-key tx does not provide much information by itself.
Another privacy improvement we are considering is to enforce/require the use of one-time public keys, which is a bit similar to “stealth” addresses but conceptually a bit simpler as it does not require a diffie-helman exchange.
With regards to traditional blinded DBCs, the mint only processes fixed amounts, eg 1, 10, 100, 1000, etc. Like cash. For each amount, the mint has a unique key with which it signs and validates DBCs. So the privacy pool is the total number of DBC issued with that amount, which could actually be quite small for very large amounts. (In Scrit, the privacy pool is even smaller because there is also a concept of epoch/expiry.) The blinded mint is unable to link transactions (reissues) together, however it CAN see/log/publicize the amount of every DBC, along with date/time, maybe even IP in a naive implementation. We feel that the route we are taking offers a stronger privacy path going forward, as we have just achieved strong (information theoretic) amount hiding and “good enough” unlinkability seems possible.