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




Multi-signature wallet.
k - num required signaturesπŸ–‹, 1 <= k <= 10
n - num participants/max πŸ–‹, 0 < k <= n <= 100

Each participant🐷 has indexed public keyπŸ”‘ and sends messagesπŸ“© which contains orderπŸ“¦ to be sent to some destination when required number of signaturesπŸ–‹ collected.

SignatureπŸ–‹, signer index, valid untilπŸ•—, seqno, send mode, orderπŸ“¦ (bounce bits, etc, dest addrπŸ“ͺ, grams πŸ’Ž, bodyπŸ“„)

Sample state, 3 participants sent some orders:
πŸ“©+πŸ“¦A-----πŸ“©+πŸ“¦B ----πŸ“©+πŸ“¦A

πŸ”‘0πŸ”‘1πŸ”‘2..., seqno, k, n, pending orders

Pending (partially signed) order
key: hash(πŸ“¦)2️⃣5️⃣6️⃣
πŸ•—expires 3️⃣2️⃣
πŸ–‹sig count 1️⃣6️⃣ (A 2, B 1)
πŸ–‹sig bitmask 1️⃣2️⃣8️⃣ (A 0101, B 0010)
βœ… Fast access to πŸ”‘ by index from πŸ“©
βœ… Cheap & fast bit mask storage for πŸ–‹πŸ–‹πŸ–‹
βœ… Expired orders garbage collection when k > 1
βœ… Get all pending orders
βœ… Get all signed or unsigned orders by particular πŸ”‘
βœ… No need to store orders, the one from inbound message is used when arrives with last required πŸ–‹
βœ… Easy debug via debug.fif and
⚠️ Only one signature supported per πŸ“©
⚠️ Parties have to repeat exact orderπŸ“¦ for each signature.
⚠️ Very first message sets πŸ•—, further expirations ignored.
⚠️ same order might be sent twice if o > k orders sent for the signing purpose, but they not only sent first one, but also created next one, and so on.
🐞 seqno hardcoded to 77 (forgot to fix it 😬)
πŸ’‘ partially signed orders dict better to be moved to the beginning to avoid skipping bytes in get methods
😬 new wallet script not ready
😬 new and existing order scripts not ready
You have not added any comments yet...
by rating


What is the purpose of seqno, if it is hardcoded?
Sequence number is needed to have different hashes of the same messages to avoid attacks, because these messages are "from nowhere", according to the TON documentation.

Or, did you mention this, like a bug? To be honest, it is hard to understand these emojis.
Sweet Hamster Oct 17, 2019 at 14:22
I just forgot to correct it before submission (compare stored vs inbound). It is definitely not to be hardcoded.

> Or, did you mention this, like a bug? To be honest, it is hard to understand these emojis.

Yes :) A Bug emoji means a bug.
Actually you have two seqno checks. Do I read it correctly that if you can't find public key you just let it pass without signature?

Apart from this major but silly mistake I actually like it. You dropped "list of signatures" requirement and so avoided related replay issues. And although there are bunch of debug lines, it still looks clean and easy to reason about.
Sweet Hamster Oct 23, 2019 at 11:46
Thanks for the feedback!

> Actually you have two seqno checks.

oh, right, my bad, first one was for debugging

> Do I read it correctly that if you can't find public key you just let it pass without signature?

Haha, yes, that's my silly mistake, good catch

> You dropped "list of signatures" requirement

Right, I decided to implement at least some MVP, and set to extend it with multiple signatures if time permits. But time shortage forced me to skip that, and .fif scripts and even code cleanup :)

I believe the best solution would be still one signature, but aggregated, like here:
Magic Python Nov 6, 2019 at 15:44
Only one signature at a time is supported. This incidentally makes this smart contract very safe, as accept_message is called only after all work is done.
Nobody added any issues yet...