Download ZIP (2.5 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.




Proof of Concept for Multisig TAPP

Allows two friends to create multisig wallet and sign transactions together

1) Both friends generate keypairs
2) First friend share his public key with second friend
3) Second friend compiles multisig contract given two keys
4) One of friends sign transaction and share his signature with another
5) Another friend sign the same transaction and broadcast message given two signatures
Smart contract designed to be used by non-technical users in Telegram, when Telegram enables run-time execution of custom fift scripts
Additionally, companion bot enable users to exchange signatures and keep history of transactions
You have not added any comments yet...
by rating


Storing in slice 1024+ bits. Won't work.
Night Zebra Oct 17, 2019 at 07:36
Thank you, I really appreciate your feedback!
I am aware that slice can contain up to 1023 bits and 4 references to other cells, accordingly contract store all state in one cell of size 256*2+2 (two public keys and seqno)
In difference, `slice in_msg` expected to be 512*2+32 bits (two signatures and seqno) without references, that's compiled without errors and deployed
So do you mean that we cannot pass over 1024 in external message and what are workaround you could suggest then?
Not actually a multisig, but rather a 2/2 wallet, an extension of simple wallet by another signature.

Unfortunately is valid, so let me shed some light on author's questions:

> compiled without errors and deployed

you will get a runtime exception, e.g. "handling exception code 5: integer out of range"
you can compile even load_bits(1000000);

> So do you mean that we cannot pass over 1024 in external message and what are workaround you could suggest then?

1023 bits + up to 4 refs is a single cell limit.
So you can use multiple cell refs or a dictionary to store multiple signatures.
Night Zebra Oct 25, 2019 at 07:13
Thank you for clarification!
Also you are reading the message that will be sent from cs1, but cs1 isn't signed by signature2. So signature2 may sign one message, and then signature1 will add his message first and send completely different one.
Night Zebra Oct 25, 2019 at 07:13
Can you clarify by example?
Sorry I was wrong. The idea was to sign message [sig1, out_ref_1, sig2, out_mode, out_ref]. Tricking send_raw_message(cs1~load_ref()), because it was reading out_ref from cs1. But now I realize that it doesn't work at all for one more reason.

So either next bits after sig1 is sig2 (cs2 = cs1; cs2~load_bits(512)). Or 8 bits of message mode (cs1~load_uint(8)). You just have to read message from cs3. I just noticed that cs1 is pointing to a portion of slice signed only by sig1.
Night Zebra Nov 14, 2019 at 12:02
Thank you!
Nobody added any issues yet...