Aaquantum card

The learning steps lead to a concrete proposal which is enormously useful, only I can do and disclose convincingly. The aacard proposed here is a credit card implemented using aalan., the aaquauantum language which only I can do, since it is built around sqrt of 1000 bit integers which only I can do and in fact can be done safely and engineering-irreversibly on  the cloud. There are three reasons for considering me

1.       All depends on IBE. Based on sqrt in 1000 bit field, only I can, on earth!

2.       Any IBE can be used. It is not a monopoly not doable any other way. Therefore, anti-trust cannot apply.

3.       There is NO sale of someone else’s development. Only things sold by me on cloud-like are the results of sqrt computations my way.

Communication to the cloud is a message [who-for: en-name, operation: en-tuple, args: en-tuple, reply-to: en-name, permit: en-new-permit], all encryptions are in public of receiver. The results, even if void are returned to reply-to which could be the sender or someone else. This is a basic property of aalan which allows -> to suffix a reply-to list in which each sender pops the list. Any part of aalan may be embedded in clock-loop, and any identity, pipe or communication only may be encrypted or decrypted.

Done +&= en {decrement-balance, order, sender-permit, sender-name, amount, digest-match}  -> list {keeper-clouds, me}

Done +&= en {increment-balance, order, sender-permit, receiver-name, amount, digest-new-unique} -> list {keeper-clouds, me}

Not needed explicitly are order, sender-permit sender-name. Auto en if en {keeper-clouds}!

Done +&= decrement-balance (amount, renew transaction) -> list {keeper-clouds, me}

Done +&= increment-balance (amount, transaction) -> list {keeper-clouds, me}

 Here is why atomic broadcast works –

1.       Everyone can verify the end-mining message.

2.       Every one defers to the winner’s order.

3.       The send and receive are distinct messages. There is no need to save the matching sender. In fact, the sender can break up the amount into a number of pieces on send, another on receive and only ensure decrements and increments match up, on summing. In this case, the digest is same for all pieces.

4.       ALL messages have to be decrypted in that case. One can implement this cloud on a multi-processor with distinct teams responsible for different parts. This way, any adversary has to penetrate lot of teams to destroy the privacy.

5.       Traffic analysis can be destroyed by all keepers send ghost amounts as transactions that sum to zero.

Resilience of aacard

Resilience is twofold, fork and join. What happens if the keeper set breaks into two? At joining, every holder is allowed to designate percent in each account. Thereafter, the holder has two disconnected accounts. Failure of a keeper or more is not a problem! The system is solid against failure. Here the nodes have not failed but are disconnected!

Join is trivial too. The balances in joining parts to the same holder are simply added in the composite account.

Rename of a holder is also easy.

What is the general case? Every account maintains a vector. Fork is a vector of functions, each taking the account vector and splitting it into two parts. Join is a vector of functions, each taking the tuple of two vectors. Credit card was easy, since each function was a plus, and arguments to plus were two index values for join and percent and old index value for fork. Now suppose each account number is some Chinese-remaindering representation and the fork is some subset of the basis. System is trivial to fix after a join or result of a fork. This has value in military systems which will split and join in very chaotic ways!

Protection of identities

There is automatic protection of identities, each is simply a public, private pair. Global 0x1001 could be used as exponent. Mod identifies the semi prime of the coin say M for aacoin. Now

Signature-1^0x1001% M-one = semi-prime

Signature-2^0x1001% M-two = semi-prime

Signature-3^0x1001% M-three = semi-prime

Two problems make it crypto-hard, three works on unknown methods. Rather easy if factors of M-j known. These three can be safely published, need checking, say once a year

 Signature-1 ^0x1001% M-one = digest identity

Signature-2 ^0x1001% M-two = digest identity

Signature-3 ^0x1001% M-three = digest identity

The triple works for all identities. For tuples, the right side is

Digest (tuple)

With tuple elements separated, say by null. Knowing the elements of tuple do not help in predicting subsequent bit changes, as length of string digested in part of digest

To executive readers

Despite TBI, I can be civil and voluble for 1 hour. If you have friends who are mystified by bitcoin and particularly what is the problem  (privacy) and one way it can be fixed using well-known IBE constructs without Zcash complications or cryptoNote ring signatures, as in aaquantum coin, as described, please call me for advice (travel & stay only, rest to US Social security, just tell me).