Add support for sendMessageReturnHash

[xssnick]

Add support for sendMessageReturnHash

[xssnick]

Hi, wallet already has method SendManyGetInMsgHash, it will return message hash immediately after sending. Wallet also has FindTransactionByInMsgHash method, with allows you to wait confirmation by msg hash.

If you want to get message hash for manual external message sending you could do like that:

msg := &tlb.ExternalMessage{
    DstAddr: addr,
    Body:    data,
}
hash := msg.Body.Hash()

api.SendExternalMessage(ctx, msg)

[akme]

Oh, that's interesting, thank you for clarification, will try your approach.

[akme]

Hey there!
Unfortunately, we found out that this approach doesn't work well in some cases.
It works well for withdrawals confirmation, but we can't use it for "move to hot" actions with contract destruction, because we don't provide any amount and it's calculated on the node side.
I'm wondering if sendMessageReturnHash could help with such issues by providing hash calculated by node for further confirmation checks.

[xssnick]

Hey, have you tried to use 128 + 32 send mode with 0 in amount? I think msg hash should match for that

[akme]

We are doing exactly this, but no hashes are matching, is there any chance that for V3R1 hashes should be calculated differently?

[xssnick]

No, hashes for v3r1 should be same, i will check this case later

[xssnick]

I researched this case and did some tests. The problem is actually not with message hash, but with account destruction (32 msg mode). When account is destroyed - liteserver drops account's transaction history, so we cannot find transaction. LS is doing it because after next activation, transaction chain cannot be proven using list transactions, each transaction should have reference on previous one, but destroying is breaking this chain.

So the solution is simple, just use 128 without + 32, then account keeps active without balance for some time and will be frozen automatically later.