This is a smart-contract for TON blockchain implementing basic multi-signature wallet.

Multi-signature wallet is a wallet managed by some number N of private keys (fixed at the moment of wallet creation). It accepts requests for money transfers (or any other internal message from this wallet), signed by any subset of those keys.

If a request was signed by M keys, where M > some number K (fixed at the moment of wallet creation as well), the corresponding message will be sent. Otherwise it will be stored as a pending request.

Owners of the wallet can add their signatures to pending requests at any moment.

Each request can optionally have expiry time set, so it will be void after that moment (even if missing signatures will arrive). Current implementation will keep it among pending requests until the next valid message will arrive.

For more details about usage of this smart contract, please refer to the included README.md file.

The content of the submitted archive is also available at https://github.com/deNULL/ton-multisig

plus:
The author thought about a lot of details and the code is very nicely written.
All required features are implemented.
A request may contain just hash of a query
Getters are in a separate file (would not be used in a real case, but a good idea)
Bitmask and bit count of signers are stored and incrementally updated.
Despite being (almost) correct it is fast (0.039G for a transfer with n=16, k=10).
It is possible to add a signature to order without modifying seqno.
accept_message() is called only after one signature was verified.
A root signature is used to sign the whole message.
Tests

minus:
Garbage collection could take quadratic time.
A replay of messages is possible between different smart contracts that share keys.
There is no protection from a malicious owner of a smart contract.

It is really good. The only thing that isn't clear is why do you keep track of pending_count if you don't use it?

Oh... about throws. After throw contract state is reverted (including seqno). So that message will be replayed. No attacker is needed. As I understand network will happily replay message that caused an error until there is no funds left.

Hello Hip Hyena, good submission, especially I liked your fift libraries (utils). I remember you from previous contests and wish you good luck!

You can run quite heavy computations (e. g. scanning dictionary) in get methods. They are not executed on-chain but instead client downloads state and code of contract and executes them locally.

There is owner variable which initially is set to the message sender. Then at the end of do-while loop it is replaced by additional signature owner. There is also a bigger while loop allowing to send two batches of additional signatures. So on next iteration you assume that owner is still referencing the message sender, when in fact it's referencing last signature owner from previous batch.

It's not exploitable because it's already read. That bigger while loop isn't really working I guess.

Is it possible to create a query with valid_until > req_expiry?
Given that one uses only supplied fift scripts?

I was worried about the case when valid_until > now > req_expiry and an otherwise valid message would lead to throw after accept_message. But it seems that the script takes valid_until from req_expiry, so in practice they always will be equal.

Why all files are for OSX? Any for Win10?