From 15c9a634bc484ece1896e11b1a1db28eecc0a215 Mon Sep 17 00:00:00 2001 From: Robert Francis Date: Sat, 26 Jan 2019 15:53:30 +0000 Subject: [PATCH] adds faqs section to readme with questions on uniqueness and updating records #10 --- README.md | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/README.md b/README.md index e695576..c640ef7 100644 --- a/README.md +++ b/README.md @@ -327,3 +327,40 @@ iex> buff |> Base.encode64 With a Base16 character set and **32 character** of ID length, ![base16-32-chars-probability](https://user-images.githubusercontent.com/194400/49407836-f2a34c80-f751-11e8-9d61-694c139808fc.png) + +# FAQs + +### How can we guarantee the the CID generated will be unique? + +We will be using the SHA256 hash which _to date_ has not incurred a single +[hash collision](https://learncryptography.com/hash-functions/hash-collision-attack). +256 bits of data is used by _most_ crypto currencies. Enough "smart people" have +done the _homework_ on this for us not to worry about it. + +This is a good video on **256 bit** hash collision probability: +[![image](https://user-images.githubusercontent.com/194400/49812120-9c8b6600-fd5c-11e8-9b1b-2c599d810f40.png)](https://youtu.be/S9JGmA5_unY) +https://youtu.be/S9JGmA5_unY + +This video does not cover the "Birthday Paradox" see: +https://github.com/nelsonic/nelsonic.github.io/issues/576. But again, for the +purposes of this answer and indeed any project we are likely to work on in our +_lifetime_, when dealing with 256 bit hashes, the chance of a "birthday attack" +creating a collision is "_ignorable_". + +### If all unique content creates a unique CID, how do we update content in our database? + +The update version of content would be linked to the _previous_ version using a +**`prev`** field the way it happens in IPFS, Etherium and Bitcoin (_so it will +be **familiar** to people_) + +**`prev: previous_cid`** address _example_: + +| `inserted ` | **`cid`**(PK)1 | **`name`** | **`address`** | **`prev`** | +| ----------- | ----------- | ----------- | ----------- |-----| +| 1541609554 | **gVSTedHFGBetxy** | Bruce Wane | 1007 Mountain Drive, Gotham | null | +| 1541618643 | smnELuCmEaX42 | Bruce Wane | [Rua Goncalo Afonso, Vila Madalena, Sao Paulo, 05436-100, Brazil](https://www.tripadvisor.co.uk/ShowUserReviews-g303631-d2349935-r341872180-Batman_Alley-Sao_Paulo_State_of_Sao_Paulo.html "Batman Alley ;-)") | **gVSTedHFGBetxy** | + +When a row does _not_ have a **`prev`** value then we know it is the _first_ +time that content has been inserted into the database. When a **`prev`** value +is defined in a row we know this is a new _version_ of a previously inserted +content and we can "traverse the tree" to see all previous versions.