Download ZIP (26 KB)

Testing and Issues

You can test this entry and submit issues during the testing period of the Blockchain Contest contest.

Entries with serious issues will not be able to win the contest, but even minor issues might be important for overall results.




Automatic and manual DNS resolvers
You have not added any comments yet...
by rating


Clever Turkey Nov 4, 2019 at 18:50
Manual DNS:
+ Mostly good baseline implementation.
- There is no way to completely delete expired domains.

Automatic DNS:
+ Support for sending back excessive grams.
+ Support for standard error responses.
+ Ability to withdraw earnings.
+ Ability to receive donations.
- It is possible to drain contract balance using chargeless domain edits.
- No sanity checks for domain names, so anyone can completely block adding new domains to prefix dictionary.
- No garbage collection for expired domains.
- There is no way to change prices after the contract is created.
- storage_price doesn't account for storage of the intermediate dictionary tree cells and their data.
Crazy Gnu Nov 4, 2019 at 20:07
Thanks for review!
Some notes on manual DNS:

1) dns entries can only be added one by one, which is not very efficient, and can't be deleted,

2) subdomains can't be deleted, which is an issue because if you have "a.b" registered, and want to instead have "a.b.c" and "a.b.d", you are out of luck ("a.b" is a prefix of a new key),

3) dnsresolve should return no. of bytes not bits,

4) new-subdomain.fif accepts <dns-record> as command line argument, so it must be a printable string and not arbitrary data,

5) update-public-key.fif assumes one person has access to both private keys, which is not always true; only new public key is needed.
Crazy Gnu Oct 19, 2019 at 08:40
1,2,4) Agree, i have changed that in automatic-dns-resolver, so it accepts a file with records.

3) In contest requirements it says that you should return 8*m where m is the number of bytes + 1. So i think the result should be in bits, not bytes.
Deleted Account Oct 18, 2019 at 19:55
When subdomain is found 8*(len+1) integer should be returned. Instead, only 8*len is returned.
Besides, it seems like delimiter ('\0') is not taken into account. Thus registration of domain "a" will block registration of any domain which begins with "a" (since prefix dict is used). Not sure, though.
Crazy Gnu Oct 19, 2019 at 06:53
Thanks for response, I agree with the first point. I assumed that \0 byte is implicitly added before making request and hence +1 byte in length is already accounted in response. Meaning if user tries to resolve "", the client must convert it to "org\0ton\0test\0" and make a request. Since \0 is added to the end, it is already +1 byte in lenght. But maybe i got it wrong.
Not sure what you mean by '\0' delimiter is not taken into account. Domain 'a' will be saved as 'a\0' in prefix dict. I am converting dots to '\0' and adding terminating zero byte in fift script (when constructing request).
Deleted Account Oct 19, 2019 at 14:29
Regarding issue "delimiter ('\0') is not taken into account":
if I send request to register domain "a" (without ending "\0") it will be registered. And if it will be registered it will block any other domain which starts with "a"
Crazy Gnu Oct 19, 2019 at 14:47
Thanks, yeah, you are right, there is no such protection.
Storage price seems to do not account for storage of the intermediate dictionary tree cells and their data themselves, only values on leaves.

It may be possible to attack the resolver by specially constructed tree that will try to use as much cells and data bits as possible (non-optimal tree) to deplete automatic resolver of it's balance.

Also, iterating N times on idict may be very expensive (it seems that each next operation requires two partial tree searches).
Crazy Gnu Oct 21, 2019 at 16:45
Thanks for review. Right, i see, it does not account for nested cells. However, not sure about your point on expensive iteration, do you mean that manual recursive ref iteration is significantly cheaper? Or am i missing something?
Moreover, the new_storage_price - old_storage_price, while being fair, may also provide a way for balance exhaust: in case old and new prices are equal (lets put down the previous problem for this moment, lets consider for example equal length dictionaries with some characters in value changed), then contract will pay for storing new data and processing message, but (msg_value - 0) will be sent back, which may actually take some bits from the contract's balance itself (accounting for aforementioned costs).
Nobody added any issues yet...