Info

Sexy Chameleon
Author
Download ZIP (84.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.

Voting

77

Comments

Sexy Chameleon Oct 16, 2019 at 11:33
An asynchronous payment channel implemented in Func with a command line interface in Fift.
8
Sexy Chameleon Oct 16, 2019 at 11:33
It allows two parties to send payments off-chain wihout trusting each other. “Asynchronous” means that the payments do not need receipt confirmations, are allowed to arrive in any order, and can even get lost without affecting the final settlement, as long as the last payment in each direction arrives or the party that sent it participates in the closing procedure.

You may want to start by following the Tutorial in `doc/Tutorial.md` or going through the protocol specification in `doc/Payment-channel.md`.

Cheers!
8
Sexy Chameleon Oct 16, 2019 at 12:10
We would also like to present our second submission, which we unfortunately failed to properly submit to the bot in time (even though it was ready by the deadline).

It is a DSL for Fift Assembler embedded into Haskell. It heavily uses Haskell’s advanced type system to guarantee that the stack is correctly typed after executing each instruction.

Then we use this eDSL to implement a copy of the standard wallet and a multisig wallet contract.

You can find the source code here: https://github.com/serokell/fift-asm-dsl/tree/georgeee/signed-nonce
11
Sexy Chameleon Oct 16, 2019 at 12:29
Just to top it off, a bunch of PRs that we made:

https://github.com/ton-blockchain/ton/pull/51
https://github.com/ton-blockchain/ton/pull/55
https://github.com/ton-blockchain/ton/pull/58

(and there are others to be made, but, of course, these won’t be part of our submission)
8
Sexy Chameleon Oct 23, 2019 at 08:48
During our internal audit of the payment channel contract (which, unfortunately, we performed only after submitting the solution due to limited time) we discovered an issue with the cli. Since no one has reported it yet, we would like to self-report it here. The issue is that the cli tool does not compare the wallet address in the IOU message with the one that it uses to locate the state of the wallet. This is an issue with the cli, not with the contract and not with the protocol (the specification does not specify how the cli locates the state; we could have chosen not to ask the user to provide the address when receiving a payment and then this issue would not be possible). You can find more details here: https://github.com/serokell/ton-paychan/pull/19.
2
You have not added any comments yet...
by time

Issues

Keen Fox Oct 16, 2019 at 12:46
A great work actually.
But upvote spamming is meh.. (:
24
Sexy Chameleon Nov 15, 2019 at 20:39
Yes, we are Sexy!
Groovy Fly Oct 16, 2019 at 21:24
Run into issue with make:

[ 1][t 0][1571260814.111481190][words.cpp:2856] Fift.fif:1: //: -?

[ 1][t 0][1571260814.111542225][fift-main.cpp:172] Error interpreting standard preamble file `Fift.fif`: error interpreting included file `Fift.fif` : Fift.fif:1: //: -?

Check that correct include path is set by -I or by FIFTPATH environment variable, or disable standard preamble by -n.

make: *** [compile] Error 2

Nevertheless, build/paychan.asm.fif was generated.
MacOS
1
Sexy Chameleon Oct 17, 2019 at 00:27
Yes, this happens because we decided to include Fift.fif right before submitting in order to make it easier for others to test, and we added a copyright notice as we always do. What we have not taken into account is that the comment syntax in Fift is not built into it but rather is defined in Fift.fif itself. We are sure you will be able to work this unfortunate problem around.
Magic Python Oct 22, 2019 at 14:47
About multisig. I tried to send a message with 0 grams. The transaction failed during action_phase with no_funds error.

And also this message was replayed several times, so now account balance is almost zero. Probably it is because you've sent an internal message without a +2 flag.

The address is kQBKB4lY_t7S6VtURW-6wYi9JnkkQdbKsPFzKpz_zycqAXAn
Sexy Chameleon Oct 23, 2019 at 08:44
Yes, sending a message with 0 Grams will fail, as it won’t be able to pay for its own forwarding; if you want to send 0 Grams, you need to have `0x1` in the sending mode. You are right in that retries most likely happen because `0x2` is not set. Our original plan was to let the user include the desired mode with the message, just as the regular wallet does, but we did not implement this feature due to time constraints, as we decided to focus on other aspects of the contract.
Magic Python Oct 28, 2019 at 13:28
Got the following error during "chan close".
It fails during mkCloseMsgBody.
My guess, it is because of Alice got no iou from Bob.

----
runalice paychan chan close $addr

+ cd alice
+ paychan chan close 0-dd9af4e8f088b9bc56552312ae11142ba5c4dfe083b44f812989fbe887984859

Loading secret key from file `alice.sk`

[ 1][t 0][1572268456.244788170][words.cpp:2906] Main.fif:17: cmdline_main: integer does not fit into cell

[ 1][t 0][1572268456.244848251][fift-main.cpp:196] Error interpreting file `/Users/arseny30/Downloads/contest/entry404/ton-paychan/src/cli/Main.fif`: error interpreting included file `Main.fif` : Main.fif:17: cmdline_main: integer does not fit into cell
1
Sexy Chameleon Oct 28, 2019 at 16:16
Yes, you are right, thank you for catching this! Fixed in https://github.com/serokell/ton-paychan/pull/20.
Magic Python Oct 28, 2019 at 13:56
Am I right that there is no way to get more than fine if the other party disappears?

It would be reasonable to expect that if I have Iou from the other party, I would be able to receive at least that much after the account is closed.
Sexy Chameleon Oct 28, 2019 at 15:55
The closing flow is the following: you first submit a regular close request, and then, if the other party does not submit their close request in time, you submit a timeout request. The code path that is triggered is the same as in the regular payout case (assuming that the disappeared party “submitted” a close request without an iou from you), so if you included an iou with your original closing request, it will be taken into account and you will get at least as much as the other party promised to you before disappearing + their fine deposit.
Magic Python Nov 4, 2019 at 10:59
Multisig wallet
plus:
A very interesting infrastructure is written for the task. DSL for TVM assembly looks very beautiful and promising.
The resulting code is very readable despite being essentially an assembly code.
Garbage collect scans only expired entries.
Our test (one transfer with n=16, k=10) works.

minus:
Message by default is sent without flag 2.
Sadly, the resulting smart contract is quite slow. Not sure why. (0.125G for a transfer with n=16, k=10)
Not all features are implemented (merge signatures).
11
Sexy Chameleon Nov 4, 2019 at 18:17
Thank you!

We have to admit that we have not put any effort into optimising the performance at all, as it was clear that we won’t have enough time, given the amount of work that went into the DSL, so we only aimed at having a working implementation. We have no doubt that the contract's performance can be improved a lot by rewriting some parts of it in a more optimal way, and we also had previously obtained good results by implementing automatic optimisation passes for a similar DSL.
Magic Python Nov 6, 2019 at 12:52
Async channel:
plus:
Greate documentation.
Readable and well-structured source code.
Non-obvious guarantees like "Reliable settlement for honest parties".
The message contains signed address of smart contract (protection from replay in other smart contracts)
Some bugs were fixed after the end of the contest.
Actually works on the blockchain.

minus:
Scripts do not check if the share is enough to make a transaction.
Some (minor) bugs were found after the end of the contest.
2
Sexy Chameleon Nov 7, 2019 at 11:13
Thank you for your review!

“Scripts do not check if the share is enough to make a transaction” – the script does check that the share is enough, but, unfortunately, there is a bug in this check. (Fixed now: https://github.com/serokell/ton-paychan/pull/21.)
Nobody added any issues yet...