Here you can see the balances of initiator (ak_2mwRmUeYmfuW93ti9HMSUJzCk1EYcQEfikVSzgo6k2VghsWhgU) and responder (ak_fUq2NesPXcYZ1CcqBcGC3StpdnQw3iVxMA3YSeCNAwfN4myQk) as 4999999999997000 and 3000 respectively.
Now take a look at the signed decoded transaction after calling close()
If you look at the amount which I was passing, I think it is so less that when closing the channel you can’t even pay the fee and hence giving the error: Unexpected message received although this error should be proper message.
Now if I provide the responder fee as 0 the channel is still able to create. Which in my pooint of view, should not. It should give me error which creating the channel itself that there should be some minimum deposite amount that both the peers has to provide.
See I am able to create a channel even if one of the peer amount is 0
My Suggestion: What I feel is there should be proper validation of config param before creating the channel. I think we can do it on JS-SDK side otherwise the money will get stuck into the channel forever. (I understand there is way to handle this problem using deposit but still)
Maybe I am totally getting you wrong, but to my knowledge the channel close tx is not paid from the deposited funds, so why should it be an issue if one party deposits 0 ?
hey I think it gets paid from the deposit fund. See this decoded transaction post channel close. It takes 20000000000000 as fee. If one of the peer balance left is 0 then whole fee gets deducted from the other peer. But if both as sufficient amount left then the fee gets distributed among both of them equally.
Ok, so a lot of stuff here, I will try covering those one by one.
Balances checks
The check @vishwas_hypermine is talking about is already there. At channel opening time there is a variable called channel_reservedocs. I see in the JS SDK it is called channelReserve. From the docs:
Name
Type
Description
channel_reserve
integer
the minimum amount both peers need to maintain
This is the minimum amount of tokens any participant must always have while the channel is alive. This is their stake in it and it is intended for them to wish to either continue using the channel or close it.
You had set that to 0 and then any of the participants having an initial balance of 0 is fine. If you had used a greater value for the channelReserve - the check would have passed and you would have had bad time opening the channel. You can see the open errors here. Hint: in case of insufficant amount, you would see a Value too low error.
Initial balances
There is no issue if participants open the channel with some small amounts and then deposit more tokens in it. Also if you go to the coffeeshop - you don’t expect them to lock cash for your visit, I guess same logic could be applied with tokens in channels: the responder is likely to be the service provider and they could open the channel dedicating 0 tokens if that’s what both parties agree upon. So from practicality point of view - I don’t see why we should impose any further restrictions here (bearing in mind the channelReserve described above).
Close mutual transaction fees
Usually fees are payed by whoever posts the transaction (called origin). The channel_close_mutual_tx is somewhat special in that regard - since it is a subject of mutual agreement and both participants are expected to be equally benefiting from it - it is the channel that actually pays the fee (and @nikitafuchs.chain is wrong, sorry). The flow is the following: participants had locked totalAmountX tokens in the channel. Once they reach agreement on the final distribution of them, let’s say: amountA, amountB and fee, the following must be true:
amountA + amountB + fee =< totalAmountX
If for some reason they decide they want to redistribute less tokens than they’ve locked - they can, the excess amount is stored in a special burn address (so the inflation is not impacted).
How participants reach to this point is a completely different matter. What the FSM does is it simply splits the fee between them equally. If the fee is an odd number, the initiator pays 1 aetto more than the responder. What is important here is that this fee is being payed by their off-chain (locked in the channel) balances. If someone does not have enough tokens to cover their share of the fee - the other participants pays the difference. I believe this is what surprised you.
I will validate what happens when participants try closing the channel with a higher fee than they have provided in the channel and will write a followup comment.
Docker logs
At docker start time, you can mount a volume so you can access node’s internal logs. It would be something along the lines -v <absolute path to your local dir>:/home/aeternity/node/log. Then you can access all the logs:
$ ls
aestratum.log aeternity.log aeternity_metrics.log aeternity_mining.log aeternity_pow_cuckoo.log aeternity_sync.log crash.log
Usually when asking for logs, we need either parts of the aeternity.log and maybe the whole crash.log (if not empty).
A follow back comment: I’ve traced the reported Internal error message. Indeed there was a small bug (actually - two of them). When the fee provided exceeds the amounts available to participants in the channel, now the API will return a better error
