Can someone explain Accumulator-based revocation? Ideally, please relate it to some real-world experience like the old credit card revocation books. TIA, - Adrian On Mon, May 4, 2020 at 9:29 AM Manu Sporny <msporny@digitalbazaar.com> wrote: > On 5/4/20 5:33 AM, Tobias Looker wrote: > > We are however as Mike has alluded to working on an implementation using > > cryptographic accumulators that we think offer enhanced privacy > > guarantees when they are required. > > Yes, +1 to the above. > > This isn't an either/or decision... it's an *and* decision. > > Bitstring-based Revocation Lists are appropriate for a set of use cases, > Accumulator-based revocation mechanisms are appropriate for another set > of use cases. There is a significant overlap between the two sets of use > cases. I'd argue that the latter is a superset of the former. > > If we can get Accumulator-based revocation mechanisms into the > mainstream using the techniques that Mike L. mentioned, then great, we > can probably drop the Bitstring-based Revocation Lists as archaic and > less performant than the Accumulator-based revocation mechanisms. That > said, we're not there yet, so we need something that's going to be > usable in the near term (next several months), while we wait for the > Accumulator-based revocation mechanisms to be formalized. If we're > lucky, they are formalized at the same time... I can see a few ways that > could happen. > > The community should dual-tracking this stuff to hedge our bets... if > both get standardized around the same time, great, if not, one might be > standardized a year or two before the other one. > > -- manu > > -- > Manu Sporny - https://www.linkedin.com/in/manusporny/ > Founder/CEO - Digital Bazaar, Inc. > blog: Veres One Decentralized Identifier Blockchain Launches > https://tinyurl.com/veres-one-launches >
Received on Monday, 4 May 2020 13:39:34 UTC