Info

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

Voting

22

Comments

Multi-signature wallet implementation.

1. wallet-code.fc - A smart contract code
2. new-multisig-wallet.fif - A script to create multi-signature smart contract.
3. add-wallet-public-key.fif - A script to add more public keys to existing new wallet query. After enough signatures is collected the wallet query file can be send to to TON via lite-client.
Please beware that address changes for every newly added public key as it is assumed to be stored in persistent data of smart contract via StateInit structure.
The new address should be send to all the parties who put their keys before.
4. new-order.fif - Create a new order with a single signature
5. sign-order.fif - Sign previously created order and store a new order file.
6. merge-orders.fif - Merge 2 order files with a union of their signatures if the internal message is the same
7. show-order-info.fif - Show detailed information about specific order loaded from boc file.
8. show-orders.fif - Show all pending orders loaded from the state of the multi-singature wallet. The state of the smart contract can be fetched via lite-client saveaccountdata method
9. restore-order.fif - Restore and sign the order loaded from the state of the multi-signature wallet.
**Notes**:
The smart contracts multi-signatures are used only for internal messages while another single signature is always needed to sign the whole external message together with seqno and validity timeout value to prevent attacks of double sent transactions.
Order validity timeout is usually bigger and stored internally together with order message to be sent while whole message validity should be set smaller.
You have not added any comments yet...
by rating

Issues

Magic Python Nov 4, 2019 at 10:54
plus:
All required features are implemented.
accept_message() is called only after one signature was verified.

minus:
I could not create a wallet. Too much gas is used during creation before accept_message. (n=16, k=10)
Very slow get_matching_keys function.
11
You signatures sign only expiration and actual message cell. If one of the keys gets compromised I can resend any of previously sent message any number of times.
1
Earnest Cow Oct 21, 2019 at 09:04
Thanks for your feedback!
Indeed you can resend a message but not any - only within a certain expiration timeout.
To be honest I see it difficult to implement it other way and meet the initial input requirements (e.g. add signatures in a chain via email or merge existing signatures).
I saw some pepople also signed the seqno, but then it becomes unconvenient as it may happen the seqno is changed while you are collecting the signatures via email and that means you need to repeat this procedure again for all the participants.
Probably the best solution would be just to reject the same body and same expiration date messages as someone implemented within this contest.
But then again there is a restriction and unconvenience: you can not create same orders with the same amount, destination address and timeout. And of course you need to spend more gas on storing and processing the history.
Magic Python Oct 22, 2019 at 15:41
Could you please create a wallet with n=16 and k=10, and send one transaction with ten signatures from it?

I tried but it doesn't work for some reason. I hope it is my mistake.
Earnest Cow Oct 23, 2019 at 07:30
Well, actually the same for me with n>8 (and it's always ok with n<=8). While it works fine locally with runvmctx for any n. Looks like a bug, requires additional investigation. I'll have a look today.
Magic Python Oct 23, 2019 at 08:02
I would guess get_matching_key? requires too much gas. More than 10 000 before accept_message is called.
Earnest Cow Oct 23, 2019 at 11:01
True, just realized keys could have been indexed =(
Nobody added any issues yet...