Info

Source on GitHub

https://github.com/rainydio/wallet23

Smart Contract Address

0QC1ltMXhcAgo2klq0RkDOyABrpBN8joJ2b6hJt3qX7UreTh

Testing and Issues

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

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

Voting

Comments

2/3 multisig. It is small, but relatively sophisticated contract written in ASM. Original submission had one error in internal message handler. It bounced any message (except sent by contract itself) with unauthorized error.

After deadline:

Improved third key handling in external message handler.
Replaced internal message handler. Now pretending it isn't there unless message was sent by contract itself.
Replaced get methods. Now they are actually helpful.
Comments in ASM.
Simple examples.
Example bash implementation.
Detailed readme.

It is finished.

PS: I may change get methods, there is still room for improvement.
You have not added any comments yet...
by rating

Issues

I would suggest working on user-friendly console application!
Chic Dolphin Dec 25, 2019 at 17:43
I added wallet.sh instead. It isn't that user-friendly, but still. Here is example usage: https://youtu.be/1Si--TuRiTE
Magic Python Dec 25, 2019 at 13:39
Quick question about your tests. If I understood right, you test every sequence of three consecutive queries. If some query leads to an exception, you don't print anything about it.

My question is:
why K1_MSG1 K2_MSG2 K1_MSG2 leads to error, but
K1_MSG1 K3_MSG3 K1_MSG3 leads to MSG3 being sent?

Also, where is K1_MSG1 K3_MSG1?
Chic Dolphin Dec 25, 2019 at 14:43
I did not included K3_MSG1 and K1_MSG2 and it is super confusing.
https://github.com/rainydio/wallet23/blob/a655b1acb3853b8fa33c34909a43d8e80b977bca/test.fif#L21

Most of the time I was developing using a smaller subset of messages. Otherwise it takes ages to run the tests. But when I finally tried to include all of the messages, I ran into fift 30s timeout. You got me, I slacked and didn't wanted to deal with it. I pushed updated version which executes the test in three stages.

>  If some query leads to an exception, you don't print anything about it.

Only if it's an error that I throw (seqno, replay, signature, etc). But I do print unexpected errors (not a cell slice, etc)
Magic Python Dec 25, 2019 at 15:39
What happens is the first query will throw an error? Could it lead to an infinite replay of this first message?

UPD:
My bad. No problems with your contract.
I was worried by some reason about <{ SETCP0 ACCEPT nonce INT "code.fif" include PUSHREF SETCODE }>c but it is ok.

Another interesting fact is that the first message (if included both code and query) will be applied twice (the first time to update the code, and the second time to actually handle this message) and this is correct behavior.
Chic Dolphin Dec 25, 2019 at 20:34
If I understood question correctly. Because I don't test message again after an error it is possible this may lead to replay issues in contract.

Well in this particular contract no, not possible simply due to the fact that ACCEPT is the very last command.

But after thinking about it more, it makes way more sense to try and send additional message if previous was accepted. That is most natural condition. So I just pushed the change which intercepts accept_message and set_gas_limit calls and sends more messages then.

Nothing had changed in report (huh), but it's more useful approach which would work for any external message handler.
Magic Python Dec 26, 2019 at 15:06
It is an excellent short, but a fully functional smart contract.
It solves all known problems of a multisig wallet.

Some interesting ideas about its usage are also presented.
E.g. "third party protection service" looks quite promising to me.

It is quite hard to reason confidently about the correctness of raw TVM ASM code.
But the code is kept very clean and straightforward and looks good in general.
And it has a quite extensive testing suit.

I also like the idea of having a "fast path" for cases when two of the three keys are used interchangeably.

Internal commands are implemented as internal messages sent by smart-contracts to themselves.
It is an excellent idea, but I should note that this will lead to an unnecessary commission for message forwarding.
It doesn't look like a problem to me, as it is quite a rare operation, and such a decision simplifies the code.
Chic Dolphin Dec 28, 2019 at 06:53
Thank you

> It is quite hard to reason confidently about the correctness of raw TVM ASM code. But the code is kept very clean and straightforward and looks good in general.

I just added a lot of comments into external message handler explaining every decision that was made.
https://github.com/rainydio/wallet23/blob/master/code.fif
Nobody added any issues yet...