1) Multi-signature wallet - with all fift scripts (merge messages, add signature to message, etc.)
2) Auto DNS Resolver
3) Manual DNS Resolver via prefix dictionary
4) Manual DNS Resolve via hashmap
5) Synchronous two-party payment channel

What if one party start unilateral finalization with some valid but very old state?
Is there a way for the other party to force the smartcontract to use some newer state?

Multisig wallet:
plus:
All required features are implemented.

minus:
Sadly it didn't work on our test (n=16, k=10).

UPD:
You are right, sorry. There is some garbage collection.
Newer order won't be collected during queries to an older one, but it is more or less ok.

Also, you use 16 bits pending_queries dictionary. It won't work with 32-bit seqno when seqno will be big enough.

And yes, It didn't work because of the gas limit.

Automatic DNS:
+ Correct price calculation.
+ Domain sanity checks.
+ Adds zero to domain name, preventing basic denial of service attacks.
+ Returns domain owner in the whois method.
- seqno is checked for internal messages, so it is really hard to change two domains simultaneously.
- If category -2 is not defined, then anyone can edit domain.
- There is no way to prolongate domain.
- No garbage collection for expired domains.
- There is no way to customize domain fees.
- There is no way to customize domain expiration time.

Manual DNS:
+ Domain name sanity checks.
- There is no way to completely delete expired domains.

Prefix dictionary implementation:
- "ph.telegra" can't be found by "ph\0telegra\0" and it is not possible to add it as "ph\0telegra" because of sanity checks .
Hash implementation:
+ Support for storing of a domain and its subdomains.
- All dictionary keys are 256-bit, so there could be high storage costs.

First of all - great job, I like your organization structure, readability and amount of work! The best application I've seen so far

Doubts:
1. accept_message() shouldn't be used in recv_internal. I see it in examples of TON fc (going to raise an issue), but it will lead to depletion vulnerability - send message with small amount of grams that contains an error
2. dnsresolve matches "acom" as subdomain of "com"

Hello Merry Ant
1) It's just my opinion, in fact maybe I"m wrong. I've raised the issue on github and ton doesn't think that it's problem

2) I didn't expect that you request domain with zero at the end explicitly. Then sorry for that. I discussed mostly the case when you have "organium\0" domain and request "org" without "\0" at the end. But looks like it's not related to your cause you support only such interface. What most interesting for me - now you showed me a stylish way to avoid the problem with such domains - I did it in a cycle, but was needed just to add \0 in dnsresove, so simple! Cause I resolve domain with dots and add nothing at the end

As far as I see there are no validation that parties submitted amount configured using `new.fif`.

3) Also when I try to reproduce your case that we discussed in section 2, I've noticed another thing - you override existed Hashmap with a new value on every call, so it's not possible to add new categories, but only override whole existed dict

> I discussed mostly the case when you have "organium\0" domain and request "org" without "\0" at the end. - Vice versa

Concerning AUTO DNS: Finally someone who correctly recursively evaluated size of data.

But here you overshot with it a bit. Your in_msg_copy also contains 32-bit action and 32-bit seqno numbers that are not stored in any way but counted in the price. Also, the in_msg cell itself will be included in addition to two cells of key and value (last two are reasonable).
This way price will be at least 64 * PPB + 1 * PPC higher than the actual price that is used for storage.
If consider the condition that only price of value should be stored then the price is overestimated by 64 * PPB + 2 * PPC + key_bits * PPB.

The code also does not abide the smart contract guidelines in part of data structure (query id) and data processing result (replying with specific messages with query ids and ops).
Also, unused remainder of message balance is not sent back (strongly linked with previous issue about guidelines).

Also, prolonging domain without providing full domain value (dictionary) is not possible (just providing which domain want to prolong). I dont see reason to use action = 2 at all here, while action = 1 allows change of domain data and at the same time prolongs it (except for the price difference), and there is problem that it does not prolong domain actually, it overrides expiration date with now() + lifetime while it should prolong it with lifetime: the new value should be sub_expired_at (current expiration) + lifetime. Otherwise it just throws away the remainder of current domain's expiration life.

You count signatures by comparing outgoing message, you have not included mode (although had it stored). So I can first collect enough signatures except one. And then send my last confirmation with mode 128 which will carry all contract remaining balance out.

#issue9035
Domain prolongation is extension of domain lifetime without other changes. In your implementation left expiration time is lost, because lifetime is added to now() instead of sub_expires_at. The owner also needs to pay full price for registering new domain and pass the whole domain state.