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

Storing in slice 1024+ bits. Won't work.

Not actually a multisig, but rather a 2/2 wallet, an extension of simple wallet by another signature.

Unfortunately https://contest.com/blockchain/entry406#issue5590 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.

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.

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.