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
Johannes
@jo-tud
I couldn't find any info on what ports need to be open. Can anyone here tell me?
Jacob Stenum Czepluch
@czepluch
I think your node works fine.
Johannes
@jo-tud
well of course - because I opened all ports :)
I'd just like to know the minimal config
Ulrich Petri
@ulope
@jo-tud Hi, no ports need to be open. Raiden uses Matrix as it's transport protocol which is based on HTTP (which is one of the major reasons we chose it). As long as you can open outgoing HTTPS connections to the matrix servers (which normally should work through even the most convoluted router / NAT / firewall setups) you don't need to do anything else. You can see which server is used in the Raiden log (not sure how you'd get at that in dappnode though).
Jacob Stenum Czepluch
@czepluch
Dappnode offers a view of the logs of Raiden
Temation
@Temation
the new awesome-raiden, has a few small issues, Rapps link doesnt work on the intial list, and there is a miss spelling of submissions under RApps:
hackathon submussions (SP)
hughlang
@hughlang
Hi everyone. I am running the Wizard and added some test eth to my account. And I'm trying to figure out how to use it with the light client SDK.
I am also running the light client dapp and I don't see how to get the goerli address from the Wizard into Metamask for the dapp. How does that work?
André Vitor de Lima Matos
@andrevmatos
Hi, @hughlang . Sorry, I don't get your question. the Wizard is for the main Raiden Client (python), the full-node reference implementation. The light-client is a JS/TS lib/sdk/web-dApp implementation of a subset of the protocol, which connects to a full-node transparently as another Raiden Client for the protocol and perform payments "independently" on the Raiden Network by simply forwarding these payments to this connected full-node (called hub), as a full-node would do with one of its neighbors if it didn't have a direct channel with the payment target
So, one thing is to follow the wizard and get a full-node set up and running. A completely independent thing is using the light dApp to connect another account to the Raiden Network, which may happen to be with this full-node you also set up, but could be with any client in the network. This second part isn't related to the wizard at all
hughlang
@hughlang
Ok thanks for that.
Franziska Heintel
@_franzihei_twitter
@Temation Thanks for the heads up, I fixed it! :)
Isaacryptotrade
@isacisa123_twitter
hi
why ithaca milestone had changed to Alderaan
hughlang
@hughlang
Is there a way to reduce the calls made to Infura from the Wizard Raiden node?
Or can I change the target to a local Goerli node?
Mattias Nystrom
@mat7ias
the explorer is showing some incorrect values, I'm guessing since the backend update last week. it's not showing any previously closed channels as closed/settled
Franziska Heintel
@_franzihei_twitter
@hughlang yes, you should be able to enter a local Goerli node as a target by pasting in the the URL that your local Görli node uses where you would usually put the Infura Project ID. We haven't tested this much, hence we're not officially listing it as an option, but it should theoretically work.
xiaofo09
@xiaofo09
Hi. I have a question. When making a payment on the payment network, let L be the length of the hop, X be the payment amount, and T be the time at which the transaction is registered on the blockchain. If so, is the worst "in unit of money × time" equal to "LX x (L+T)"? It looks similar to the Sprites protocol because the receiver puts the secret on the contract.
Yoichi Hirai
@pirapira
@xiaofo09 In Raiden, not every payment has to be registered onchain. If peers cooperate and send transfers in both directions, they never need to go onchain (until the total transfers reach 2^256). In those cases, T doesn't appear in the equation. Also, the amount of time and the amount of payments are not related. The number of hops matter though.
hughlang
@hughlang
Thanks @_franzihei_twitter
xiaofo09
@xiaofo09
Yes. I know it. What I asked is the case which mediator does not cooperate. so secret must be placed onto the blockchain. In this case, is collateral cost "LX x (L+T)" ?
Mattias Nystrom
@mat7ias
was looking at this lnd routing improvement lightningnetwork/lnd#3143
could something similar be used to benefit raiden multi-hop latency?
Yoichi Hirai
@pirapira
@xiaofo09 in the non-happy case, the time factor is roughly the settlement period.
Augusto Hack
@hackaugusto
@xiaofo09 Raiden uses the same approach introduced by sprites, you can find the secret registry here
@pirapira was talking about the on-chain collateral, if you are interested on the collateral off-chain, then the time portion of the formula is just the lock timeout, currently defined as 2 * reveal_timeout
xiaofo09
@xiaofo09
@hackaugusto Thanks a lot. bb
Susil Kumar Mohanty
@susilmohanty11_twitter
There is an error with the pathfinding service with address https://pfs-goerli-with-fee.services-dev.raiden.network. Raiden will shut down.
How to fix the above error?
Paul Lange
@palango
@susilmohanty11_twitter I restarted the PFS, so it should work again for now. I'm also working on a fix for the problem you run into. It's tracked at raiden-network/raiden-services#520
George Moxeve
@moxeve_twitter
Hey guys! will Raiden be at devcon 5?
Can’t wait to see you
Gaspar Medina Burgardt
@gasparmedina

Hello everyone, I am trying to understand how unlocking pending transactions between two nodes works. And for that I did a test between two nodes.
The test I did was the following, to better describe the test, I will call these two nodes A and B. Node A creates a channel with node B and deposits 10 tokens, A makes a payment of 1 token to B.
When A starts the payment to B between the nodes, an exchange of messages begins, within this exchange of messages when B receives the secret of A, A is no longer online. So B never receives the balance proof to complete the payment flow, but if he received the secret issued by A. In this way B never receives a balance proof of A, therefore B decides to register the secret in the chain of blocks
After B decides to close the channel, the channel closes successfully, B waits for 500 blocks and sends a message to the block chain to settle the channel. The settle is carried out successfully and a ChannelSettled event is emitted by the blockchain, B receives it and processes it leaving the channel in its liquidated state machine, (it does not delete the channel data because, it verifies that A has a pending transaction.) In the end B has not yet received the token that A had tried to send him.
On the other hand, A is back online after the channel was settled by B. When A is turned on, it begins to receive the events that the blockchain emitted, in these events there are the SecretReveal, ChannelClosed and ChannelSettled events. If we stop at the ChannelSettled event, it is here that A decides to unlock the pending transaction that had been left unpaid for the blockchain. And at that moment from the smart contract a transfer of 1 token is made to B that no had not been able to transfer outside the chain.

The doubts are: Why B after registering the secret could not claim the value of the transfer if he knew the secret?
In the event of a protocol failure outside the chain, does the sender of the payment always unlock the pending transactions and send the payments to the final recipient as a transaction within the blockchain?

Gaspar Medina Burgardt
@gasparmedina
In addition to the previous question, I have another question related to the exchange of messages when a transfer is made between 2 nodes.
Although in its documentation it is clear the process of exchanging messages between N nodes, being N> 2. ¿Why when there is a transfer between two nodes, when one reveals his secret the other also has to return the same secret to obtain a proof of balance and thus complete the payment outside the blockchain?
Is the node that begins the payment considered as the initiator and mediator of a payment at the same time? It makes sense when it is a payment between more than two nodes, but when it is made between two I do not see the reason that the node that receives the payment has to return the secret to the node that issued the payment.
François-Julien Alcaraz
@hefgi
hey guys, anyone from raiden is at ethberlin hackathon ?
Dominik1999
@Dominik1999
hey, I am at the hackathon together with Jacob
Jacob Stenum Czepluch
@czepluch
@hefgi we're sitting on the second floor in the community kitchen
Augusto Hack
@hackaugusto

@gasparmedina first of all, that is a very accurate descriptio, kudos :thumbsup: .

Why B after registering the secret could not claim the value of the transfer if he knew the secret?

B can, I believe you're referring to the behavior of the Red Eyes release. At that point we just had a policy that each participant would unlock its own side of a channel. That behavior was changed, and now the node will unlock when it has a financial gain. Here are the relevant lines of code

Augusto Hack
@hackaugusto

Why when there is a transfer between two nodes, when one reveals his secret the other also has to return the same secret

If you have a transfer without mediators, this is not strictly necessary, the initiator could send the unlock right away; This is just an optimization and currently there is no need for it.

If a transfer has mediators, than the secret has to flow backwards, this makes sure that the mediator will pay before receiving tokens. Otherwise a malicious mediator could just not pay and steal tokens

Gaspar Medina Burgardt
@gasparmedina
@hackaugusto Thank you very much! Actually the tests I have described were done in the release v0.100.3 - Rosemary. In this release, node A was the one who claimed the token blocked token and transferred it to B. I thought that B after registering the secret onchain was going to be able to claim it directly. You say this behavior is right for you?

Why when there is a transfer between two nodes, when one reveals his secret the other also has to return the same secret

If you have a transfer without mediators, this is not strictly necessary, the initiator could send the unlock right away; This is just an optimization and currently there is no need for it.

If a transfer has mediators, than the secret has to flow backwards, this makes sure that the mediator will pay before receiving tokens. Otherwise a malicious mediator could just not pay and steal tokens

@hackaugusto Ok is what we thought, which was not necessary, although it is implemented like this. It only makes sense when there are mediators, in a payment between more than two nodes.

Gaspar Medina Burgardt
@gasparmedina

@gasparmedina first of all, that is a very accurate descriptio, kudos :thumbsup: .

Why B after registering the secret could not claim the value of the transfer if he knew the secret?

B can, I believe you're referring to the behavior of the Red Eyes release. At that point we just had a policy that each participant would unlock its own side of a channel. That behavior was changed, and now the node will unlock when it has a financial gain. Here are the relevant lines of code

According to the code that you emphasize, I see that it is always about unlocking when a node has pending transactions, that is, it has a pending transaction in its merkle tree. In the example I described above, the one with a pending transaction is always A who sends a token to B and that is why A invokes the unlcok method in the blockchain.

Augusto Hack
@hackaugusto

I see that it is always about unlocking when a node has pending transactions, that is, it has a pending transaction in its merkle tree.

Actually it is in either one of the two trees, the one from the node itself, or the one from the partner. The idea here is that the state machine is saying "there is something pending to unlock". After that, during the handling of that event, we look up the correct values from the blockchain an decide if an unlock is beneficial or not.

BOR4
@BOR4
I had trouble running raiden wizard so I deleted my infura project. Now whenever I start wizard and go to localhost:8888 I see it is trying to use old project without prompting me to input project-id. As I deleted old one now it really has no chance to work.
Where is it reading from old projectId so I can delete it and try fresh?
BOR4
@BOR4
.local/share/raiden
if you get stuck go there and rm -rf raiden
you will be able to start fresh
Raphael Lullis
@lullis

@BOR4 That will be one way to do it. Just be careful that this folder will store any configuration files as well as the passphrases used to unlock your account for raiden. When we get to have a mainnet release you will have to be more careful with these files.

A cleaner way to deal with changes in your infura project id is to open the config file (formatted like config-<account>-<network>.toml) and find the eth-rpc-endpoint entry. There you should find the URL to connect to infura. You can just change the project id part (if you are still using infura, but a different project id) or you can even put the URL of any RPC node you have access to.

BOR4
@BOR4
thanks @lullis that makes sense. I just never had anything working so there was nothing to lose. I hope you don't mind me opening issues on github with my findings while testing wizard.
Michael Bissinger
@Michael-Bissinger
i can't use the light-client on goerli-testnet right now. Is it offline on purpose?
https://lightclient.raiden.network/
Jacob Stenum Czepluch
@czepluch
@Michael-Bissinger works fine for me. What problem do you experience?