We examine the nature of the Chaum solution for the bank in order to identify the details that we will need in a capability blinder.
This older note introduces the concept which we extend here.
There is a public key for each bank and for each bill denomination.
It would not do for a bank to be unsure of the denomination of the bills it redeemed.
I propose a blinding object (BO) to correspond to the public key used by the Chaum scheme.
Access to a BO would be disseminated as is a Chaum public key.
Each BO, upon creation, is bound to its validator, an object that can validate the class of object that that particular BO deals in.
A BO keeps a set of capabilities, each of which it has validated via its validator.
In addition there are BO claim checks (BOCC’s).
Each BOCC is associated with some particular BO.
A BO is like a hat check service that purposely mixes up the hats that it keeps.
You can submit a hat to the BO and receive a BOCC in return.
You can later submit the BOCC and retrieve one of the unretrieved hats.
A BOCC is good for just one invocation.
The BO Specs
On the BO creator there is an order NewBO(validator vx).
This returns a new BO whose validator is vx.
Orders on a BO:
- Deposit(zot)
- zot is verified by the BO to be valid according to its validator.
If it is valid a claim check to this BO is returned and zot is added to the heap of BO.
- ReclaimZot(CC c)
- The BO verifies that c is a claim check that it has issued and not canceled, and if so removes and returns a random element from its heap.
It also cancels c by adding c, or its hash, to a list that it keeps.
- IsThisABO(BO x)
- Reports whether x is a BO (something created by the BO creator).
I think that this is the correct analog to Chaum blinding.
It causes me to note two down-sides to both schemes:- One ramification is that if a bank has low volume in some denomination it may well be the case that one bill is issued and redeemed without any intervening issues of that denomination.
In this case the bank knows full well whose money was redeemed.
- There is another negative incentive to doing business with a low volume bank, You may come under suspicion because there was an interval of time when there were just two $1000 bills outstanding from a bank and one was spent to buy an assassination.
You will be one of the suspects!
It has ramifications which are not analogous however:- The other significant observation is that one must trust the BO as much as trusting the bank.
In particular the quality of blinding is good only when the bill is left in the BO for a long time.
DH’s that are distributed for reliability may not solve this problem.
Things of value
If the BO is a place to keep things of value and the clients of the BO do not trust each other, then it seems likely that the BO must check that the capabilities it keeps are distinct.
The KID makes this easy.
The validator may well requires that kept objects are durable in some sense.