----Players:----- #S=> sender (buyer) any user using @my #R=> recipient (seller/owner) any user using @my #O=> Operator special or any user/s using @op #A=> attacker/s ----Processes:----- to work on the thread communication with https://github.com/agl/pond Authentication: The communication (such as by otr/tor.. github.com/agl/pond) is encrypted, where the pub-key is attached with the chain of hash of the thread of the communication which is starting in hashcach. all transaction and notification are in performed in this communication, also when the #S first sends encrypted the pic together with the map (of composition as a string of rectangles) and then showing her/him self live, so that #R can recognize if the one in the pic is the one in the live claiming to be #S, and if so, then first use the map to hash each rectangle and hash of all of them to one hash and then test if the hash matches the id(#S). #S should prove ownership over the coin by: 1. by the id(coin) coinid in CoinsID@op to goto rand indexing the Log@op in which the value has the id of #S as an owner where N is the number of rehashing the idcoin on Nhash (this is like saying the coin has the owner) . 2. showing the exact corresponding Rand and prev rand in log@op for to prove continuity of the movement from the re(cyceling) sate of the coin (but only if all members using that coin participate by using their Wallet@My). -------------------------------------------------------------------------------- ||------------------------||------------------------||------------------------|| || table: || @Op || @My || ||Key=> || || || ||[col1(value1,value2)| || || || ||col2(value3)] || || || ||------------------------||------------------------||------------------------|| || Movements in || Coins: 2blob of all || || || recycling || valid and expired || || || || Hash(Id(coin)) || || ||------------------------||------------------------||------------------------|| ||------------------------||-------------------||-------------------|| || Movements in || CoinsID:hash(id(coin)) ||Wallet:hash(id(coin))=> || || Payment || =>[(Rand,N)] ||[(Rand, RandPrev, || || || ---- || Coin, id(payer), || || || || pub-key(id(payer)))] || || ||------------------------||------------------------|| || ||--------------------||----------------------|| || || Log:hash(Rand)=> || || || || [(Nhash(id(Coin)), || || || || si[Payer](Rand, || || || || id(Owner)), Chain)] || || ||------------------------||------------------------||------------------------|| ||------------------------||-----------------------|<*>|----------------------|| || Values in Calculation ||Treasury:LastDate=> || Worth:LastDate=> || || || [CoinLifetime( || [CoinLifetime( || || || SumStartValue, || SumStartValue, || || || TheirAmount)|...|] || TheirAmount...)|...|] || ||------------------------||------------------------||------------------------|| || Identities in ||---||----||-------||----|| || Authentication || || || || ||Users:hash(triplepin)=> ||Payers:hash(triplepin)=>| || ||[(register=ALL(hash( ||[(id=hash(pic),pubkey)]|| || || pic(member)),,))] || ---- || || || ---- ||Self:CreatingDate => || || ||Profiles:hash(register)=>|| [(pic of mine)] || || ||[(personal info in common|| || || || pubkey, id=hash(pic,,)] || || ||------------------------||-------------------------||-----------------------|| notes: The use of hash(index) between tables is for adding complexity with more records. The data is stored in encrypted directory including this app in 2 db: the My_db and the Op_db, where the My_db is used by any member, the Op_db is used by one or more operators being members. (and hence when each member is also an operator, the app is a p2p app, when being operator is rotated between members the app is democratic, otherwise centric). The Communication of threads between members is by asymmetric keys, where * threads, per each message n in an otr conversation, are defined so that * t[n]=(message[n],date,hash(t[n-1])), hash(t[n]) is indexed by public_key(sender) and t[0]=(id(receiver),date,x), where, as in hashcach K(hash(t[0]))==0, K is defined by number of bits to be examined and x is a random. The triplepin is the unique id of the member, which is given only in community depended conditions, such as only after having some recommenders for the uniqueness and the form of meeting with the member and of the recommenders. id(coin) is a unique&random int. Payer is the previous Owner of a coin. id(member)=hash(pic(member));Changeable + retrievable by triplepin(member)* The owner in payment should first see the payer then type the triplepin * by which the pic is retrieved, and only after the pic matches the payer, * that pic should be hashed and used/compared as an id. Hence such protocol* is based on a human recognition (and not on the one of machine). Rand, used as a transaction id in the distributed log, is a unique and random number, which is used as a receipt. It is produced by the Payer distributing that record; So that in payment, when paying and after proving ownership, the payer sign the new owner's id with the payer's rand, to create her/his new distributed record(rans). Rcoin's log protocol: Chain=(hash(ChianPrev),hash(RandPrev,Id(Owner))) hash(pic)==id(user) triplepin is a unique number used as a key for all such pic, making each pic able to be changed Not as in the biometric info! N is the number of hashes implemented on itself beginning in id(coin) and ending in Nhash , for creating a prove of continuity. So, having the id(coin) and N you can create the Nhash of the N, where Nhash(N) =hash(Nhash(N++)) . The Prove of ownership by id(coin), where op has in CoinsId@op Rand equals the Rand the owners pull from Log@op by her/his Wallet@My: the Rand or RandPrev has the id(coin) and the owner verifies the signature and produces both: the Chain and the hash(Id(Owner) of the ChianPrev, which is the Chain in RandPrev. The use of the composition is as a key for hashed picture. The composition is a set of the pair of arguments: (diagonal, angle), together defining a sequence of rectangles, such that: Each rectangle is hashed separately in the crop defined by its arguments; The composition is given separately (in a specific transaction) and all rectangles in their order define together the reference to the picture and reference could be hashed again for to be squeezed again to a predefined size (used as an id); Overlapping means hashing part of hidden rectangle with the shown one; Per each corner the shortest rectangle on wall defines the highest of all others; The first two zeros define the containing rectangle and each other zero define changing direction until the pair of zeros that define the end after which the next 2 pairs are of the original picture (first of the position of its top left corner and the second of itself) and then terminate. eg: (0,0)(0,0)(45,400) is the non-overflowing composition of only the original being a square of which diagonal=400 pixels.