Xud: Raiden lock time follow-ups

[sangaman]

This tracks open issues persisting after #1082 for us to properly have swaps with raiden as the first leg.

The main issues for now are:

• expiration is currently an absolute block number, which can't be used by xud because we don't currently have a way to get to the ethereum block height. Passing in the height on the resolve request would allow us to calculate a delta.

• Ensure that raiden is properly setting the lock time. In testing with @erkarl, the values we got for the settle and reveal timeouts, as well as expiration, were lower than expected and lower than the lock_timeout we set on the raiden token payment call.

[offerm]

result of my checks:

a. expiration is working fine. It is a block number by which the lock will expire.
b. I will add the current height to the resolver request. With this you can calculate the delta and find the lock_duration that was used by the payer.
c. settle_timeout and reveal_timeout are the "default" values which is not relevant in our case. Extracting the real values (from the channel) is more complicated and should be done only if needed. I currently don't see a need for it in the resolver. As such, I'm going to remove these from the http call to the resolver.

Next steps:
a. @sangaman to confirm
b. I will add current block to resolver call and deploy.
c. @sangaman / @erkarl to implement xud changed using the current block so we can properly check cltv. also make sure that settle and reveal timeouts are not being used by xud.
d. deploy new xud
e. I will remove settle and reveal timeouts from resolver call.

@sangaman please take care of a. above

[sangaman]

Sounds good, I'm just still confused as to why we saw low values for expiration in tests, if anything without accounting for the height we should be getting back unexpectedly high values for expiration. To confirm what you saw, if you passed in a lock_timeout of X and the block height is Y, you would see X+Y for expiration correct?

Everything else makes sense though.

[sangaman]

@erkarl just ran some tests with me, we got an expiration value that was 5 blocks lower than expected based on the height. Any ideas why? Block height was 1399, lock_timeout was 7360, and expiration was 8754 instead of 9759 8759.

Logs are here: https://paste.ubuntu.com/p/wh7VmKHgzG/

[erkarl]

and expiration was 8754 instead of 9759

8759 was the expected expiration

[offerm]

Yes.
Raiden does not consider the most current block as valid until it has some history. So when the height is 1399 raiden is looking at block 1394. If you add to this 7360 you get 8754.

The lock will expire when the height will be 8759. at that time, raiden will look at 8754.

Once I add the height to the resolver call, you should get the block number that raiden considers as height (1394) and the expiration - 1394 should give you the lock_number

[erkarl]

So when the height is 1399 raiden is looking at block 1394. If you add to this 7360 you get 8754.

Makes sense. Is the look-back static value of 5 or does it change dynamically?

[offerm]

Fixed

DEFAULT_NUMBER_OF_BLOCK_CONFIRMATIONS = 5

[offerm]

Implemented step "b" above. raiden code should be updated and raiden should restart.

Seed nodes already updated and restated.

If you run native xud-simnet you can do:

xud-simnet-restart

or you can just fresh install.

log now shows this:

18/08/2019 21:09:03.282 [HTTP] debug: http server request json: {"token":"0x46af55c4320d37bcea9a3cf6f0fe18fff7d9685b","secrethash":"0xc53adebfd98e554f33fe45c881d019a3aa582b8e42ca2427e88ee410f70e27fc","amount":100000000000000000,"payment_identifier":6269988339677432,"payment_sender":"0x5abdc825187ab181697c78ac7d8754465fc0f0dc","expiration":3519568,"payment_recipient":"0x7ed0299fa1ada71d10536b866231d447cdfa48b9","chain_id":4321,"chain_height":3510608,"reveal_timeout":50,"settle_timeout":500}

note this at near the end - "chain_id":4321,"chain_height":3510608,

@sangaman @erkarl step "c" is yours.

[erkarl]

@offerm should we also remove reveal_timeout and settle_timeout from the resolve request to xud since they're not being used?

[offerm]

Yes, see steps c and e above.