[Overview] Prepare XUD for ERC20<>Lightning swap

[offerm]

In parallel to extending Raiden with swap support we can enhance XUD to make sure we are ready.

Need to take care for the following:

• Make gRPC work for Raiden (gRPC enhancement for Raiden #792)
• Staring Raiden - need to have account with tokens and ETH, keystore file , EndpointRegistry address, SecretRegistry address, TokenNetworkRegistry address, and eth-rpc-endpoint. I can share a startup script when needed.
• Create a channel with a peer PUT /api/(version)/channels
• implement XUD to Raiden connectivity (like we do with LND). Make sure we have a connection and we are ready to trade. Need configuration support.
• Create an XUD currency for the raiden Token. Should include the Token address
• Get to the point where Swap agreed and the taker initiates the swap by using POST /api/(version)/payments/(token_address)/(target_address)

Suggest to gave a separate issue for each step once we start the implementation.

[kilrau]

Alright, I think we all agree that this is our overall top prio at the moment (by far). So my idea would be that we double check again that the list above. Make sure it is complete - definitely needs your input @offerm . And then the 3 of you divide (open & assign issues for each point) and conquer (start working on these while leaving everything else aside, with @offerm offer until feedback from the raiden team comes in) with the goal to raiden working with xud by the end of this milestone in 10 days from now. I bet @offerm will find a way to demo a BTC<-> WETH swap with this.

Completely unreasonable? 😎 Other suggestions? @offerm @sangaman @erkarl

[offerm]

Lets break this to internal and external tasks (from XUD POV):

External:

• Create an Ethereum chain
• Have a miner
• Block reward to go to the system accounts
• Create raiden smart contracts
• Create a token (start with one, multiple later)
• register the token with the raiden contracts
• start raiden server (need one for each xud - so each xud will have lnd-btc, lnd-ltc, raiden). Use a remote ETH instance by the raiden instances so we avoid a long sync time.
• fund remote raiden accounts somehow
• automatic creation of channels (like we do with LND) + funding
• make the minder smarter.

With these changes XUD can use raiden.

Internal:

• Connect to raiden (use HTTP put/get API) - may need some additional parameters
• create currency which is raiden based
• LND vs Raiden handling of the swap
• More (for @sangaman ) to complete

For now, I'm working on the external items. Note sure this is doable in 2 weeks. Lets see
@sangaman should lead the internal one.

[erkarl]

Good news is that the external and internal steps that @offerm mentioned are completely independent of each other and can be done in isolation.

Connect to Raiden

Via REST API - https://raiden-network.readthedocs.io/en/stable/rest_api.html

Breaking it down into smaller steps for implementation:

• init/start
• getInfo
• verifyConnection
• sendPayment POST /api/(version)/payments/(token_address)/(target_address)
• getAddress GET /api/(version)/address
• connectPeer
• listChannels GET /api/(version)/channels/(token_address)
• openChannel PUT /api/(version)/channels
• closeChannel
• close/exit
• queryRoutes?
• deploy/registerToken? PUT /api/(version)/tokens/(token_address) - do we need this? is W-ETH deployed automatically?

LND vs Raiden handling of the swap

As of now the swaps module of xud is hardcoded to support BTC/LTC clients. There's work to be done there (needs further scoping).

Also, how will we handle unknown rHash resolving within Raiden?

[offerm]

currently there is no good way to deal with unknown rHash. Basically the caller would need to block until timeout. We will need to do something about it but it is less urgent. About the API, better to check what we need. For example, connectPeer, closeChannel, deploy/registerToken we don't need. QueryRoutes we do.

…

On Wed, Mar 6, 2019 at 7:48 PM Karl Ranna ***@***.***> wrote: Good news is that the external and internal steps that @offerm <https://github.com/offerm> mentioned are completely independent of each other and can be done in isolation. Connect to Raiden Via REST API - https://raiden-network.readthedocs.io/en/stable/rest_api.html Breaking it down into smaller steps for implementation: - init/start - getInfo - verifyConnection - sendPayment POST /api/(version)/payments/(token_address)/(target_address) - getAddress GET /api/(version)/address - connectPeer - listChannels GET /api/(version)/channels/(token_address) - openChannel PUT /api/(version)/channels - closeChannel - close/exit - queryRoutes? - deploy/registerToken? PUT /api/(version)/tokens/(token_address) - do we need this? is W-ETH deployed automatically? LND vs Raiden handling of the swap As of now the swaps module of xud is hardcoded to support BTC/LTC clients. There's work to be done there (needs further scoping). Also, how will we handle unknown rHash resolving within Raiden? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#797 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJQ0ci9z3a7h2e3XI942n9Mbs5BaFogFks5vT_9qgaJpZM4aVgqo> .

[kilrau]

For example, connectPeer, closeChannel, deploy/registerToken we don't need.

All one-time actions like deploy/registerToken definitely not, but closeChannel we'll need in production I believe (don't think SimNet!).

[kilrau]

I think you are pretty clear about the external (SimNet) tasks, so full-steam ahead @offerm ! Your concern about the timeline is definitely valid, let's try tho!

Let's try to compile an exhaustive list for the internal tasks below and divide (just pick what you'd like to do) @erkarl @sangaman

[erkarl]

currently there is no good way to deal with unknown rHash. Basically the
caller would need to block until timeout. We will need to do something
about it but it is less urgent.

I understand you have done the heavy lifting in terms of adding Raiden support. Thanks to you Raiden now has support to include secret and secret hash as part of payment request and response. Awesome work :).

Can you please elaborate on caller blocking until the timeout?

About the API, better to check what we need. For example, connectPeer,
closeChannel, deploy/registerToken we don't need. QueryRoutes we do.

In order to clarify what exactly needs to be done I started:
#826

[kilrau]

What else needs to be done here? @erkarl Checking your list from above..

[sangaman]

We do need the raiden address of our peers to be shared in the handshake and to be returned in the ListPeers response. I was mistaken earlier in thinking we already shared the raiden address in the handshake, but I've started working on this piece and will have a PR soon. It's not a major change.

[erkarl]

There's also: #846
and #853 for the raiden swap-resolver http endpoint.

[kilrau]

We do need the raiden address of our peers to be shared in the handshake and to be returned in the ListPeers response. I was mistaken earlier in thinking we already shared the raiden address in the handshake, but I've started working on this piece and will have a PR soon. It's not a major change.

Is this merged? @sangaman I could only find raiden address updates: #858

[sangaman]

Is this merged? @sangaman I could only find raiden address updates: #858

Yes, it's handled in #857 which is now merged.