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).
