Implement SIP9 #136
Implement SIP9 #136
Conversation
braydonf
force-pushed
the
sip9
branch
2 times, most recently
from
d70adb7
to
21a0296
Compare
| token: { | ||
| type: String, | ||
| required: false, | ||
| unique: true |
There was a problem hiding this comment.
The token is generated by the farmer rmd160sha256(crypto.randomBytes(512)).
Over time the farmer will generate the same token more than once. 160bit random is no garanty. Unique constraint violation
There was a problem hiding this comment.
True that 160bit is not as much as 256bits, however it's still huge. 160bit hashes are used for pay-to-public-key hash for Bitcoin transactions, and issues have been raised before and addressed with segwit updates, but the attack is still very impractical.
There was a problem hiding this comment.
Ethereum nodeIDs are also 160bits
There was a problem hiding this comment.
Bitcoin has only 900K unique addresses. The same address can be generated twice.
The storj network is different. Every farmer will "brute force token generation" 24/7. My farmer is generating 50K tokens per month. Lets say we have only 10K active farmer. A total of 500M brute force tokens per month. Even if the chance is very low we have to deal with so many tokens that I would expect a few collisions.
There was a problem hiding this comment.
It would take roughly 243,583,606,200,000,000,000,000,000,000,000,000,000 years to have collision at that rate. There are 2 ^ 160 possible tokens with 160 bits. Furthermore there isn't a restriction on length, and it could be 32 bytes instead of 20 bytes (another topic).
|
Rebased on latest master |
- Have users be an array. Mirror storage events of a shard that multiple users have uploaded will have multiple users interested. This will provide an ability to track how long the mirror should be held. When one user deletes the shard, the user will be removed from the storage event. When there is only one user the storeEnd will be updated to terminate the storage of the shard. - Seperate user and client, thus it's possible to have a client and user for mirror actions, so that it's possible to query storage events of mirrors by a user.
- Mirrors will be created without a user and only a client - Queries can fold all storage events based on the hash and determine all users and storage time frames
``` z = 0.9999 // target percentage y = 5 // number of nodes z = 0.841510681 // node percentage -------- 1 - ((1 - x) ^ y) = z -------- 1 = z + ((1 - x) ^ y) -------- 1 - z = (1 - x) ^ y -------- (1 - z) ^ 1/y = 1 - x -------- 1 - ((1 - z) ^ 1/y) = x -------- ``` Meeting notes: https://github.com/Storj/dev-meetings/blob/master/2017-12-06-summary.md
|
Found a potential issue with the See https://github.com/storj/service-storage-models/pull/136/files#diff-6cde9fa75ac789afe7ff15f670cfc049R434 compared to https://github.com/storj/service-storage-models/pull/136/files#diff-6cde9fa75ac789afe7ff15f670cfc049R461 |
This is to make sure that the cron service is able to not repeat proccessing over storage events that have already been processed. While this doesn't cause an issue with resolving the event, it will contribute to incorrect rates of reports being saved to the user, in the case that an event is process more than one time.
We were already updating both timestamps at the same time anyways so having two values was unnecessary.
lib/models/contact.js
Outdated
| ContactSchema.methods.resetTimeoutRate = function() { | ||
| const now = Date.now(); | ||
| const window = 259200000; // 72 hours | ||
| if (this.lastTimeout < now - window) { |
There was a problem hiding this comment.
Date.now() is expensive. How about this:
if (this.timeoutRate && this.lastTimeout < Date.now() - window)
That should call Date.now() only if the farmer has a timeoutRate that could be reset.
|
Okay, ready for round of testing. |
Implements: https://github.com/Storj/sips/blob/master/sip-0009.md