have it in text

table:Key=> [col1(value1,value2)| col2(value3)] @Op @My
Movements in recycling Coins: 2blob of all valid and expired Hash(Id(coin))
Movements in Payment <id(coin)>, <Rand> CoinsID:hash(id(coin)) =>[(Rand,N)]
Log:hash(Rand)=> [(Nhash(id(Coin)), si[Payer](Rand, id(Owner)), Chain)]
Wallet:hash(id(coin))=>[(Rand, RandPrev, Coin,id(payer),pub-key(id(payer)))]
Values in Calculation <sameformat> Treasury:LastDate=>[CoinLifetime( SumStartValue, TheirAmount)|…|] Worth:LastDate=> [CoinLifetime( SumStartValue, TheirAmount…)|…|]
Identities in Authentication <register> <triplepin> <pic> Users:hash(triplepin)=>[(register=ALL(hash(pic(member)), , ,))]
Profiles:hash(register)=>(personal info in common pubkey, id=hash(pic,,)]
Self:CreatingDate => [(pic of mine)] ]

The Worth is calculated per each day such that: Today=the date of today, per each tablename: Dif=LastDate-Today, pech each columunname: Ratio=Dif/CoinLifetime and per each row: Sum+=startValue*Ratio.

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.

id(member)=hash(pic(member));Changeable + retrievable by triplepin(member)

Payer is the previous Owner of a coin.

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

See also hashcomposition:a-seperated-key-for-hashed-picture
By pilepile, on 03 Jan 2014 15:24 history Tags:


~~Page's End!~~ Ignore ads by installing ublock.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License