search

ExchangeUnion / xud-simnet

The XUD Simulation Network, a nicey nice playground with monopoly money
GNU Affero General Public License v3.0
1 stars 1 forks source link

Raiden todo's #28

Closed kilrau closed 5 years ago

kilrau commented 5 years ago
offerm commented 5 years ago

@michael1011 Here are some tips for raiden channel management:

  1. Seperate the bot tasks into 3 different, separated, and unrelated tasks:

    • channels opening
    • channel balancing
    • channels closing

  2. if possible query xud for supported raiden currencies (I don't think there is a an RPC for this). If not, use config file. You need to know which tokens to use and the deposit amount for each token. It can also be hard coded for now.

  3. channels opening for this, hold in-memory data structure of peers for which you already tried to open a channel. This data structure should prevent a loop of failed open channel and also prevent an overrun of two open channel. you can populate the data structure with all existing channels so you will not need to query raiden every time. Data structure should automatically cleaned and rebuild every N (24) hours.

kilrau commented 5 years ago

if possible query xud for supported raiden currencies (I don't think there is a an RPC for this)

I believe you can use https://api.exchangeunion.com/#listcurrencies and just discard btc & ltc.

--notify via slack

Good point, bot notifications are still in slack. Should all be switched to discord, @michael1011 has experience in doing this. I propose to have a NOTIFICATIONS channel section with channels for simnet, testnet, mainnet same as in the other project. We'll have some statistics & similar from xud instances we run ourselves pushing into testnet / mainnet.

kilrau commented 5 years ago

Looks like https://api.exchangeunion.com/#listcurrencies doesn't return everything we need (token address, digits). So I suggest to hardcode for now. Opened an issue to enhance the listcurrencies call, once that's done the raiden open channel bot can use it: https://github.com/ExchangeUnion/xud/issues/1067

kilrau commented 5 years ago

Raiden bot needs to open direct channels from and to all 3 cloud nodes, to support direct channel check for raiden. Also simplifies things, since there is no need for raiden channels between the 3 cloud instances and rebalancing. See https://github.com/ExchangeUnion/xud/pull/1065#issuecomment-505861669.

offerm commented 5 years ago

We need raiden nodes between the seed servers since the seed server may also swap between them. This will happend automatically once the bot knows how to deal with raiden channels.

To have the 3 nodes opening channels we somehow need to move WETH and DAI from test1 to test2 and test3. This can be added as a task in the list above (@kilrau )

michael1011 commented 5 years ago

Data structure should automatically cleaned and rebuild every N (24) hours.

Why should we do that? Unless someone manually opens a channel the data structure should contain all data and by rebuilding it we could loose some channels that are pending during the cleanup process.

offerm commented 5 years ago

To avoid the need to restart the bot if something went wrong.

On Wed, Jun 26, 2019 at 9:31 PM michael1011 notifications@github.com wrote:

Data structure should automatically cleaned and rebuild every N (24) hours.

Why should we do that? Unless someone manually opens a channel the data structure should contain all data and by rebuilding it we could loose some channels that are pending during the cleanup process.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ExchangeUnion/xud-simnet/issues/28?email_source=notifications&email_token=ACKDI4STOVKS47TJ2CCDVNDP4OYXBA5CNFSM4HWUMBD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYUNTQY#issuecomment-505993667, or mute the thread https://github.com/notifications/unsubscribe-auth/ACKDI4Q4XC3NLOTKKUPSNETP4OYXBANCNFSM4HWUMBDQ .

michael1011 commented 5 years ago

@offerm in order to send the ETH I would like to use this API endpoint of geth: https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_sendtransaction

Will this be possible on the seed nodes? Do the geth instances have the private keys of the addresses to which you send the mined coins?

offerm commented 5 years ago

We have a single geth instance running in our simnet cluster. I see no reason why you should not be able to sign a transaction and provide to geth for execution.

geth don't have the private keys of the other nodes. Why should it have them?

On Thu, Jun 27, 2019 at 10:27 PM michael1011 notifications@github.com wrote:

@offerm https://github.com/offerm in order to send the ETH I would like this API endpoint of geth: https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_sendtransaction

Will this be possible on the seed nodes? Do the geth instances have the private keys of the addresses to which you send the mined coins?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ExchangeUnion/xud-simnet/issues/28?email_source=notifications&email_token=ACKDI4RWKI32ADHXQO6M2ZDP4UIBLA5CNFSM4HWUMBD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYYEFIA#issuecomment-506479264, or mute the thread https://github.com/notifications/unsubscribe-auth/ACKDI4SSKOUI7VEYJKZRTFDP4UIBLANCNFSM4HWUMBDQ .

michael1011 commented 5 years ago

@offerm So if there is just a single geth instance in the cloud: does that instance have the private key for the address to which you send the mined coins? Can the aforementioned API endpoint be used on that instance in the cloud or do I have to sign the transactions with the geth golang library in order to send a transaction?

offerm commented 5 years ago

The geth instance don't the the private keys of the seed nodes and/or the remote nodes. It has the address (public key) of test1 that gets all the block rewards coins. I believe that you need to sign the transaction locally before you send it to geth for execution. Only the local instance has access to the private key so it must be done locally.

Note that the geth instance mine ETH for test1. test1 is also the owner (and main holder ) of WETH and DAI. We need to find a way for one time transfer part of these tokens to test2 and test3 so they will be able to open the channels

kilrau commented 5 years ago

Honestly, we can also just shutdown xud2 & 3..

kilrau commented 5 years ago

Since everything depends on one miner and xud1 to distribute funds, xud2 & 3 don't make much sense after all. If it makes things easier - just go ahead and shut them down. @michael1011 @offerm

offerm commented 5 years ago

No need to do that. Channels should be with test1 only.

On Sun, 30 Jun 2019 at 13:46 Kilian Rausch ⚡️ notifications@github.com wrote:

Since everything depends on one miner and xud1 to distribute funds, xud2 & 3 don't make much sense after all. If it makes things easier - just go ahead and shut them down. @michael1011 https://github.com/michael1011 @offerm https://github.com/offerm

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/ExchangeUnion/xud-simnet/issues/28?email_source=notifications&email_token=ACKDI4WQECIF4YM2XGLICT3P5CFJXA5CNFSM4HWUMBD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY4JWRY#issuecomment-507026247, or mute the thread https://github.com/notifications/unsubscribe-auth/ACKDI4SVUPZQYJKOEK7O5WLP5CFJXANCNFSM4HWUMBDQ .

kilrau commented 5 years ago

Then https://github.com/ExchangeUnion/xud/pull/1065 direct channel check would need to be switched off for simnet. @michael1011

Reminder: we decided to go with config option, checks on by default, clear warnings on this restriction in setup (https://github.com/ExchangeUnion/xud/wiki/docker#beware)

kilrau commented 5 years ago

Raiden channel check not important enough. Closing.