I plan to attack the name service (for free) once the network and test-safecoin go live.
[The Name Service] is a simple use case for
Unified Structured Data(see RFC XXXX). In this case we require to set three items
The
type_tagshall be type4The
Identityshall be theSha512of the publicly chosen name (user chooses this name)The
datafield:
struct dns {
long_name: String
encrytion_key: crypto::encrypt::public_key
// service, location
HashMap<String, (NameType, u64, bool, bool)
// As Directories are identified by a tuple of 4 parameters (NameType, tag, if private/encrypted, if versioned) it makes sense to have the 4 identifies stored for better scalability.
}To find this information an application will
Hash(Hash(public_name) + type_tag))and retrieve this packet.
ā @dirvine - RFC 0002 āName Serviceā
Plan
- Continuously register accounts
- Register domain names with those accounts using their SC PUT allocation credits
- Continue until the free SC PUT allocation is canceled
- There is (as of yet) no plan on how or when to do so.
- Either profit or undermine the network
Math
Assumptions
- Three years of free SC PUT allocation
- Account registration and all PUTs spent on domain names within 60 seconds (and thatās generous)
Pseudo-code
number_of_minutes = 1576800 # for three year example
sc_equiv_allocation = 50
StoreCost = (farming_rate * total_clients) / GROUP_SIZE # @anon86652309 & @dirvine
domain_names_per_account = sc_equiv_allocation / StoreCost
alphanumeric_characters = 36
min_domain_length = ln(number_of_minutes * (domain_names_per_account)) /
ln(alphanumeric_characters)`
Real-time variables
Storage per Safecoin
The conclusion below assumes that 1SC will purchase 1MB ImmD or 100Kb SD for the duration of the three years. This is not necessarily true.
Therefore a safecoin will purchase an amount of storage equivalent to the amount of data stored (and active) and the current number of vaults and users on the network.
*-- @dirvine & @anon86652309 - RFC 00015 āSafecoin Implementationā
Therefore, the domain names I may be able to obtain per account are exponentially larger than 50.
Number of machines performing this attack
This conclusion is only assuming that one machine is performing this attack. (New Login, 50x Registers, Logout, Repeat) There may be multiple machines that I control that are able coordinate to play out this attack, or by that time I can gather together a decent-enough sized botnet to amplify this attack significantly.
Conclusion
At the end of three years at the aforementioned static PUT cost, min_domain_length = 5.074. Meaning that all domain names (as yet unregistered) with an alphanumeric length of 5 characters or less will belong to me. If I only use alphabetic characters, Iāll be halfway to 6 characters by then, with 1 through 5 being obtained at a substantially increased rate (this rationale follows a logarithmic curve).
Unsuccessful Mitigation
Different Free PUT or Free Safecoin implementation
Any free PUT or free Safecoin implementation is exposed to this attack. As long as Proof of Unique Human remains infeasible, this attack will continue to be successful.
Limit creation of domain name per account
If a limitation such as this was introduced, then my implementation of the attack may be slightly different, however the core premise would still be viable. Also, that would create an arbitrary limit in an otherwise limitless system. This is not to be desired.
Successful Mitigation
No Free PUT or Safecoin
The issue has been discussed in depth on these forums, and amongst the devs as well Iām sure. The decision has been made to give free PUT allocation (using a magic number) to new accounts. If this decision were to be reversed, that would nullify my attack.
However that would not prevent moneyed interests from pursuing a similar type of attack. This solution only pertains to average users such as myself.
Petname System
This prevents two identities using the same name, is this really the best way to go[?]
ā @dirvine - RFC 0002 āName Serviceā
I think that it is not. A system that does not prevent two identities from using the same name would completely nullify my attack. This system that functions in a decentralized environment is most commonly referred to as the Petname System.
The answer in [Petname Systems] is that all applications have to teach users to recognize two different ways of displaying names. One way is for Petnames and the other way is for ārandom insecure stuff I show youā. And users have to be able to tell the difference or they will do insecure things (like send a message to the wrong Joe).
ā Yaron Y. Goland (founder of Thali)
