by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 26 2017 14:34
    @LefterisJP banned @poojasingh940_twitter
  • Dec 12 2017 13:36
    @LefterisJP banned @Nedu_Onyeanuna_twitter
  • Oct 10 2017 21:40
    @LefterisJP banned @etherchamp1_twitter
  • Aug 11 2016 13:48
    @heikoheiko banned @primehat23
Jacob Stenum Czepluch
@czepluch
@lullis I believe we used to have this in the past, but removed it to avoid users accidentally revealing their private keys, but I don't see other reasons than that to not add it back. Especially not if it's helpful to some other project to allow for this.
Raphael Lullis
@lullis
Yeah, especially considering docker-based deployments where the safest/easiest approach is to have secrets coming from a vault and inject as an environment variable.
christianbrb
@christianbrb
Hey @lullis Maybe you want to have a look at raiden-network/raiden#4239 as an alternative. @andrevmatos might have an idea
Marcos Martínez
@marcosmartinez7

Hi guys, im trying to find an explanation about onchain unlocks for when there is a malicious node. Basically the scenario is when a node sends wrong information during settlement.

Explanation:

-Alice is a malicios node willing to cheat someone.
-Alice sends a payment to Bob, but never gives him the balance proof. She then closes the channel.
-Bobs sends the secret, in order to claim the tokens Alice chain. He doesn’t have any balance proof, so this is the only way.
-But Alice counts 500 blocks before him, and settles the channel with empty locks root, meaning no transaction was registered on chain
When Bob tries to unlock those tokens, the computed merkle root is not the same as the one sent by Alice:

(computed_locksroot, unlocked_amount) = getMerkleRootAndUnlockedAmount(
merkle_tree_leaves
);

// The sender must have a non-empty locksroot on-chain that must be
// the same as the computed locksroot.
// Get the amount of tokens that have been left in the contract, to
// account for the pending transfers sender -> receiver.
unlock_key = getUnlockIdentifier(channel_identifier, sender, receiver);
UnlockData storage unlock_data = unlock_identifier_to_unlock_data[unlock_key];
locked_amount = unlock_data.locked_amount;

// Locksroot must be the same as the computed locksroot
require(unlock_data.locksroot == computed_locksroot);

So its fails in the final line of aboves code. Preventing Bob from receiving the tokens.

So.. i want to know if the unlock is related with this scenario or not. I found important that when a node cheats on the settlement data, the other node can recover it founds.

image.png
I think im missing something, since the protocol must handle the situation for when a node cheats on the settlement info, but im not understanding how the unlock will solve this and why it fails anyway
Karl Bartel
@karlb
@marcosmartinez7 When you say "but never gives him the balance proof", you mean not giving him the unlocked BP, right? Bob must have the BP with the locked amount and the secret, otherwise the payment did not actually happen. He can use that BP to update the channel between close and settle, which will cause the locked amount not to be payed out to Alice. Bob can then unlock the tokens after the settlement.
Dennis Kaefer
@dankke_gitlab
Hi guys, I'm trying to run RSB node on mainnet, but on exec of a script ./register-service-provider I get some issue. Could you help me out, and point me to a right direction ?
formerly luehrsFred
@fredo

Hey @dankke_gitlab

How can I help you? can you provide more information about the issue you got?

2 replies
PWNSAUCE
@STAKINGSEUSS_twitter
Hello! My name is Phil, I'm a full time cryptocurrency researcher, recently I have been looking into Raiden after hearing about Stakenet's plans to integrate the protocol into their DEX soon. I have a couple questions on the token supply and distribution though...
Jacob Stenum Czepluch
@czepluch
@STAKINGSEUSS_twitter this is room is mostly for dev questions, but try asking them and we will see if we can answer
PWNSAUCE
@STAKINGSEUSS_twitter
What is the state of the coins held at this address: 0x00C7122633A4EF0BC72f7D02456EE2B11E97561e
are they locked?
Jacob Stenum Czepluch
@czepluch
They are not locked per say. They are in a wallet controlled by company developing Raiden. The tokens it holds are not counting towards the total market supply though.
PWNSAUCE
@STAKINGSEUSS_twitter
I understand they are not counted toward the circulating supply. But what assurance can you give new investors that price appreciation wont be counteracted by dev sell pressure? (sorry to be critical, I like the project, but part of my job is asking hard questions)
Jacob Stenum Czepluch
@czepluch
@STAKINGSEUSS_twitter Did you read this blogpost: https://medium.com/raiden-network/the-raiden-network-token-rdn-launch-is-set-to-october-18th-5e9a2ffd7960
It explains among other things that the devs didn't receive tokens. Devs only got tokens if they themselves participated in the token sale and that would be part of the 50% pool.
PWNSAUCE
@STAKINGSEUSS_twitter
Thank you for the link, I'll check it out
Raphael Lullis
@lullis
Hey guys... Quick question: is the documentation on the deposit limits per channel up-to-date? Maximum of 0.075 WETH per channel?
Jacob Stenum Czepluch
@czepluch
No, I think that's something we forgot to update. According to the deployment data here it's 4683182690956770000
Raphael Lullis
@lullis
Ah, ok. Thanks! So it is ~4683 WETH and 1000 DAI? Why such an arbitrary number? :)
Jacob Stenum Czepluch
@czepluch
No, I think 4.683 WETH.
Raphael Lullis
@lullis
>>> 4683182690956770000000 / 10 ** 18
4683.18269095677
Jacob Stenum Czepluch
@czepluch
The number you use is _token_network_deposit_limit which is the total number.
You should look at _channel_participant_deposit_limit
Raphael Lullis
@lullis
Yeah, you are right. Bad copy-paste.
So I am guessing that number was ~1000 USD at the time of the contract deployment.
Jacob Stenum Czepluch
@czepluch
Yes
Raphael Lullis
@lullis
Awesome. Thank you.
Raphael Lullis
@lullis
Regarding the previous issue (about keystore and passphrase files being required to start raiden), I managed to circumvent the thing by wrapping the call to raiden with a named temporary file. For docker deployments it should be okay as the files go away when the container is stopped. Still not bullet-proof for non-containerized deployments - if the main app dies for some reason the temp files will be left on the disk.
Raphael Lullis
@lullis

Ok, now an usability question. :)

I joined a token network and I got a channel opened with another participant. I then left the token network (calling DELETE on the token network address). The channel went into closing immediately (expected) and closed after a while (settle timeout?)

What I can not see neither through the API or even the UI is what happened with the tokens that were on the channel. They are not back on my account - balance has not been updated - so I am guessing they are on the UDC? The API does not indicate in any way on what block I should expect to have the funds back.

Also: if they are on the UDC, how can I withdraw to my account? Will the funds be used if I re-join the network?

Jacob Stenum Czepluch
@czepluch
@lullis When you say funds, do you then meant he funds that were locked in the channel or in the UDC? The UDC is only meant for paying services and those funds you'll have to withdraw manually from the UDC or leave theme be if you plan on using the same node in Raiden in the future.
As for the tokens in the channel they should be paid out when settle takes place after the settlement timeout expires, which should be 500 blocks by default.
Raphael Lullis
@lullis

Ah, so this is another thing that was unclear for me. I was under the impression that UDC would hold any token while settlements were open and that services could collect RDN from them. Thanks for clarifying that.

So I guess is just an usability issue? At the moment as an user all I am in the UI is that the channel is marked as "closed" (which now I understand that it means that it hasn't been settled yet), but I am not seeing the funds back and no kind of message indicating when (time or blockwise) they should be back to my account - which can give some sort of anxiety.

Jacob Stenum Czepluch
@czepluch
Yeah. I think the last point is a good point. I think we have an issue for that already, but I cannot find it right now. Otherwise feel free to create on here: https://github.com/raiden-network/webui/issues
Karl Bartel
@karlb
Yes, we have to make it clear that "closed" is not the final state of a channel and the funds are not supposed to be returned, yet. The term "closed" sounds like everything is done if you are new to Raiden.
Raphael Lullis
@lullis
hey guys.... curious issue right now. I am testing with two nodes, both running the same latest release on Görli. Node A is running on my hub20 setup (docker containers), node B is running directly on my machine. Node A has a channel with node B and can send payments, they show up very quickly. If I try to transfer from B to A though payments get pending and never complete.
Raphael Lullis
@lullis
Checking at the logs, seems like node A can not process the received Balance Proofs. I am getting these repeatedly.
raiden_1             | 2020-09-15 09:19:33.280111 [info     ] Received new balance proof, creating message for Monitoring Service. [raiden.services] balance_proof=BalanceProofSignedState< nonce: 13 transferred_amount: 310000000000000000 locked_amount: 120000000000000000 locksroot: 0x700d5bd5a5697965751a2749e0a0a83a0cb1de62abf0a3f3cf76320e1a4bfefc message_hash: 0x2ccb16cc5439e85b51a3b7a97e7787a8a3762975cded3e80a0bb2a067855ae70 signature: 0x5c6787becd98940ccd0b0259db2dd497ba673732bdc3b1e00519c8c1dde11995159e77ca003fc014cb71f708e90c4bb8db5b8940deed77d40870cc52a4c64bed1c sender: 0x9D527BFBF56420ae45f57D79D19060F34957808a canonical_identifier: CanonicalIdentifier(chain_identifier=5, token_network_address=0x812650FB6Acdf9dD47E631cBB5518B32FFD4D129, channel_identifier=67) balance_hash: 0x4f65c2be3f847edb76bd016e4218e741a16d7cba45dddebddc514e135f9bea8b > greenlet_name=GMatrixClient.message_worker user_id:@0xd09a21634b70378a847d9ab61c77d90c43805264:transport.transport04.raiden.network node=0xD09A21634b70378a847d9aB61c77D90C43805264
raiden_1             | 2020-09-15 09:19:36.111005 [info     ] Synchronizing blockchain events [raiden.raiden_service] blocks_per_second=0.06286153873778143 elapsed=15.907978393137455 greenlet_name=AlarmTask._run node:0xD09A21634b70378a847d9aB61c77D90C43805264 remaining_blocks_to_sync=0 to_block=3406203
But no errors on the logs whatsoever of either node
Karl Bartel
@karlb
Getting Synchronizing blockchain events regularly is normal. Do you get the Received new balance proofrepeatedly even without sending new payments to the node? I would expect that message once per received payment.
Raphael Lullis
@lullis
Yes, Received new balance proof is being displayed on the logs of A multiple times for every payment that B sent.
Karl Bartel
@karlb
This is strange. The message indicates the the BP has been processed. But the repeated logging sounds like node B resends the transfer, which would usually happen if it is not processed by node A. Could you please open an issue and attach the logs for both nodes (preferably in JSON format)? I don't think we can give a proper answer on this without taking some time to investigate the logs.
sahar-fehri
@sahar-fehri
Hello everyone, could someone please explain these points for me :
In the case where we are joining an already existing token network, in the docs it says : "By default, Raiden connects automatically to 3 channels to other nodes and splits up 60% of the funds between them. The remaining 40% of tokens will be used to join channels that are automatically opened by other participants."
1 - Saying it splits 60% of the funds between the channels , meaning I DEPOSITED 20% in each channel right? and if that is the case does it mean, if by chance the node i want to make payments to is one of the 3 nodes raiden opened channels with by default, then i no longuer have to open a channel nor deposit funds in the channel ? And if i do then it means that i deposited in that channel
an amount of = 20% of the initial funds + the amount i put to open a channel ?
2- Also, in the case where the node I want to make frequent payments to is not one of the 3 nodes raiden opened channels with by default, then doesn't that somehow means that I lost 60 % of my initial amount on channels that I wont be needing ? I am clearly missing something here so please bare with me
3- i dnt understand "The remaining 40% of tokens will be used to join channels " . Because in API docs there is no API to join a channel , you can join a tokenNetwork , but not a channel.
Could someone clarify these points for me please,
Raphael Lullis
@lullis
@sahar-fehri You wouldn't be "losing" the funds, rather it would happen that transfers would be mediated by the channels you have open.
sahar-fehri
@sahar-fehri
@lullis thnx for your reply, so 60% of the funds will be deposited in channels that will be used by mediated transfers. And the remaining 40 % ? sorry , i still don't get that part
Karl Bartel
@karlb

@sahar-fehri The 60% are deposited in newly created channels. They can be used to pay each of the channel partners, but they can also be used to pay others if the channel partners are online and have other channels themselves. In that case they will act as mediators and forward your payment to the target. This is one of the main points of raiden.

The other 40% are kept in the wallet at first and are used to deposit into channels when other nodes open a channel to you.

sahar-fehri
@sahar-fehri
@karlb thank you so much for the explanation !
tudo1
@tudo1

Hello, apologies in advance if this is not the right space to discuss …

Scenario : Install using Raiden Wizard + Opt to fund Raiden Account using Uniswap = $UNI claimable

Does anyone have any more details for this scenario please?

Thank you!

Karl Bartel
@karlb
@tudo1 Yes, that should lead to an account that can claim UNI. Do you have any specific question?
tudo1
@tudo1

@karlb thank you for your response.

Is there a guide to transfer the $UNI from the Raiden Address back to the original ETH address please?

The closest issue I can find somewhat related : raiden-network/raiden-wizard#131

Thank you!

Manuel Wedler
@manuelwedler
Hey @tudo1, there is no guide but I can tell you.
You need to know your address first. You should be able to get it from the Raiden web interface when you are running Raiden.
Then you need to find the corresponding keyfile from ~/.ethereum/keystoreon Linux or /Library/Ethereum/keystoreon Mac. There is an address property in every keystore file, that you can check. If you have a lot keystore files in the folder you can try finding by writing a little script. If you have problems with this, please let me know.
When you have it the easiest way to get your UNI is to import the file in MetaMask. You should not be running Raiden while you are using the keystore file to make transactions externally.
tudo1
@tudo1

Hi @manuelwedler, thank you so much for your help. Success!

By the way, I’m not a developer :)