Continuation of the response to the Judge (due to 1000 characters limit, for AUTOMATIC DNS):

* (About the possible hash collision): It may be possible also to use chained 32-bit expiration dict -> prefix dict, but that would incur way higher storage costs, but will result in 100% collision resiliency, or inner linked list (may increase gas costs). Nevertheless, despite very slim probability of the collision the point is reasonably valid.

* (About the prices change impossibility): That way, it is not possible to allow subsequent price change without introducing contract owner - which may effectively move "automatic" resolver into a more "automated" one. But allowing owner just to change prices may be somehow reasonable, if to be required. I had doubts about impossibility of subsequent price change, but aforementioned points outweighted this problem for my vision.

Thank you for your long-awaited judgement. Nevertheless, I have several comments concerning the negative points:

* Concerning the 32-bit hash, it is a reasonable compromise of storage costs and anticollision. The hash length may be increased to decrease probability of colliding if extremly heavy-duty is to be expected, which will increase storage costs. 32-bit hash should provide collision resilience for several million registration per second (outlined in documentation, not only 32 bit hash is in dict, but only 32-bit time prefix). .....

* About the prices changing, the automatic DNS resolver has no owner by design - it is a self contained script, that works by itself on strictly defined manner in code (thats how I know "automatic" strictly is defined). .....

!!! I have more comment to say concerning the points, so continuation is in separate reply to MANUAL DNS (due to 1000-characters limit)

Thank you for your precise clarifications.

Was very silly of me to forget about B.P. (precisely, 77163 regs = 50% coll. prob. for 2^32), and block time interval. Yes, that would be the simplest solution. The closest possible migitiation is that expired domain can be registered again and therefore be used and eventually purged, with obvious drawback (registration and storage fee is to be paid).

!!! I could not stop thinking about a good solution to this, so I designed effective algorithm, which is now attached as a picture. !!!

Very good point, as a security researcher I planned and developed SCs from a "security-first" point of view of SC itself. I did not actually expect contract's gas usage to highly explode due to primary prefix tree or expiration timer tree grow (as the structures are highly optimized and, as I understand, have (sub-?)logarithmic time complexity), however I therefore agree that being able to change prices may be crucial.

Hello, thank you for nice words. Initially this counter was introduced just to filter names with multiple zero-code characters, but later, at the penultimate day, it was repurposed with a very nice result.

Thank you for your review.

As per contest requirements I expected that automatic (not automated, automatic, which means that operates without any interaction from controlling operator) resolver does not actually have owner, it is operated entirely by itself and therefore does not permit balance withdraw (having owner who can withdraw balance can put the automatic nature at risk, because the owner could cause harm to contract by withdrawing too much from it).

However, I too was in doubt about this point, but considered finally that registration price is anti-spam/flood measure - that is, to register domain you need to pay some reasonable value.

But I appreciate your point, it may be possible to calculate safety margin (balance minus storage expenses) and allow owner to withdraw some safe amount of funds not threatening contract functionality.