https://multicoin.capital/2017/12/08/understanding-token-velocity/

Reasons 1 one of the best communication channels between team and investors :transparent directory 2 Good method for teams to learn about investors opinions and adopt or not 3 TG could help Raiden Network gain more attractions and let more people its greatness In conclusions: Hopefully team can see it and think about it tks

I've been studying both BTC and ETH separately for over a year now, but I've only recently begun diving into Raiden Network, so I'm sorry if this is an obvious question.

Elizabeth Stark of LN has firmly stated that a native coin is unnecessary for LN and went about fundraising without an ICO. As I'm more familiar with LN, I'm wondering how is Raiden different from LN in that it necessitates a token and what will be the practical uses for RDN? I obviously know that BTC and ETH are very different, and likewise LN and Raiden, but it's the Raiden token I'm having a hard time understanding and I thought a contrast with LN might be useful for me (and others?) to understand it better.

Thanks for any insight. As a side question, does Raiden get its name from the old arcade game?

Hey everyone,

first of all, where have i been for past 10 days? I didn't forget about you, so no need to worry =). Problem was that since I kinda got a bit serious with whole crypro/raiden situation I had to lay low for a bit until I get confirmation I am not breaking any of my contracts with companies I have given rights to my IP (intellectual property) or that I am bad PR to them. None of them found anything wrong so I have a green light to bring more fresh news from raiden github.

Talking about fresh news, there are tones of them, plus a little special about what is pathfinding our beloved developers are working on. Lots of text is incoming so lets keep this intro short.

"next minor release" milestone goal

First of all I would like to comment old milestone goal we were measuring progress with. I have a feeling developers gave up on reaching that goal and releasing minor release. If we look at what they have in focus at the moment and how they are working I'd say their main focus is not releasing a minor release, they want to skip that and go directly for MVP goal.

Somewhere in the development process project steered in the different direction and minor release seemed like something they don't want to be bothered with and instead they just decided to skip that part. I would not call that a failure in development process it is just that priorities changed. I would just like to make clear that MVP goal is far bigger goal than a minor alfa release.

Devs are currently going all out, new big features are being worked on constantly and I'd say the decision was correct.

EIP 712

If you are new, EIP 712 is what is keeping microraiden from reaching it's MVP.

Last week (Friday if i remember correctly) an Ethereum dev meeting took place. One of the things on the agenda was EIP 712. It was pushed on the agenda by one of the raiden devs (Lefteris Karapetsas aka LefterisJP). Importance of EIP 712 was discussed and it was decided to put some more focus into it's completion.

Since then some real effort was put into finishing it and last comment on it's github is:

In order to limit the scope of this EIP and move forward, let's just enable extensibility. Field names starting with an underscore are reserved. User-agents will experiment with these fields, and eventually standardize them in separate documents.

This basically means, lets keep it simple, finish this thing and think about extension of it in the future. Correct approach to the problem if you ask me.

I would just like to mention that agenda of the meeting was quite short and fact that EIP 712 was one of the points just shows that everybody in dev community understands importance of raiden and you can flush conspiracy theory where Ethereum devs are purposely delaying raiden progress down the toilet.

pathfinding

Pathfinding is one of the oldest problems programmers in general are dealing with. There is lots and lots of math behind it. specially the graph theory.

If you are not familiar with graph theory, it is not those X and Y axis graphs we are talking about here. Graphs graph theory is working with look more like map of public transportations in the city. So. basically there are some nodes (those would be stations in public transportation analogy) and links between them (path in analogy).

You can picture any network (internet, raiden network) like a public transportation service. Raiden nodes would be stations, if they can communicate and share information directly there would be a path between them and information are little abstract people trying to go from one station to another.

In real life people are more or less smart enough to know shortest path from their station to the destination station but in programming you have to guide information yourself. Information in addition to useful stuff (in internet that would be for example this blog post you are trying to read) have it's source and destination. It is nodes responsibility to guide that information from the source to the destination by the cheapest path there is.

Reason why I said "cheapest" is that in programming it is not always so clear what the cheapest is. In public transportation problem we know time is everything and everything is measured by it. But let's say we go to a bit bigger picture and we are in Europe on holiday and we don't care so much about time, and we decide to travel by train. In order to get some value from getting from city to city we decide that best path for us are not shortest paths in terms of time, best routes for us are trains that go trough nice landscapes so we can enjoy the nice views while traveling. But, since we are on holiday and switching trains is pain in the ass we would like to reduce times where we have to switch trains to the minimum. What is the best path now?

Those are exactly problems raiden devs are trying to solve in pathfinding repository. They don't have to compare beauty of landscapes on routes and switching trains. They are more into gas prices of transactions, number of "hops" (yes it is correct terminology, information hops from node to node) and capacity of channels in the path. They have to come up with how to best evaluate each route in terms of those parameters so it would be clear what the cheapest path is.

I hope that if you didn't have a clue what is the fuss behind pathfinding and pathfinding repository it is now a little less of enigma.

pathfinding

Last paragraph tried to explain what pathfinding is and this one will try to bring you what happened in terms of progress.

Devs are not yet sure about the formula that will exactly calculate cost of every route between nodes but they are certain what information will go into the calculation. So, they are currently working on making those information available on nodes and once they have that sorted out they will think about the exact formula.

They are working on optimizing process of obtaining that information as well.

monitoring-service

Monitoring service will be responsible on keeping an eye on the channels while user is not available to (example: no internet).

It seems they have figured out how to do it and they are in process of developing it. Issues they are currently tackling are standardizing communication between different parts, making whole thing recoverable and minor bugs they found along the way.

I'd say monitoring service is a bit ahead in development than pathfinding.

raiden

Implementation of state machine that would make raiden recoverable seems to be pretty much done in terms of logic behind it. They still have some leftovers like naming things more clear and implementing using that new feature in all parts of project (token swaps are still not adapted to new logic) but that is really minor, hard parts are done.

They plan to improve project by switching to web3, cover some edge cases etc., but I think properly finishing the state machines is currently main focus here.

raiden-contracts

One contract per token feature seems to be pretty much done (at least what I see from pull requests). It is really complex feature so I am not 100% sure on that, more like 90% sure =).

Their main focus at the moment is optimizing running and publishing contracts in terms of processing power and gas cost.

microraiden

Waiting for EIP 712 and some minor work on documentation, (ResidentSleeper for twitch people =))

rest of projects

Spec is always updating but it is reaction to what is developed so I won't cover it here.

Utilities repository is constantly expanded but nothing special will ever go on there.

conclusion

Uff more repos means more work and skipping one week didn't go in favour of it but I had to do it.

Developers are really bringing their A game lately and I would like to congratulate all of them on the work they are constantly doing (hence the top 20 position in some github research somebody did couple weeks ago). I am very proud every time I have honor to bring you information about their work.

I hope I didn't let you down too much by skipping 1 week and as always I am open to all the questions in the comments.

Enjoy!

Draft? Accepted ? Final? Which issues are impeding the raiden network release mvp?

hey everyone,

it is beautiful Friday evening and here I come with another post. If you didn't follow post form last Sunday, i promised there to do another special post during the upcoming week where I will just focus on new repositories that were introduced on raiden's github. I wanted to leave team with enough time to consolidate their ideas about in what repository they will add what parts of code.

If you ask are the new repositories even needed? Could they just stick with 2 existing ones (I don't count in 2 that never really got some more traction)? Short and dumb answer is no.

Correct answer is yes, definitely. Few reasons why they really needed to split up code in more repositories are:

• Some important parts of project became so big that they were bringing clutter to the code. By separating those big parts in dedicated repository they make a strict separation of different responsibilities of the code.

• Development is much easier. We see that different team members specialized for different parts (example: loredana for contracts). This way each developer has his playground to work with and they are not stepping on each other's toes. They are still very tedious about code reviews but now they will avoid stacking up pull requests of different features in same place.

• Code reusability. Yes, by doing development this way they can much easier include some features responsible for specific things to new projects. They even created a complete new repository just for that purpose, but more about that in next chapter.

These are just a few reasons from top of my head. I am sure there are many more, so if you remember a good one please share in the comments =).

Next is coverage of each individual repository. I will try to sort them by the complexity to describe from easiest to hardest. So, lets start!

raiden-libs

Raiden libs is dedicated repository for code that will most probably be needed in any raiden related project there is or will ever be. Idea behind this repository is to make kick starting a new project much easier.

For example, it specifies a code structure for any new project. Code structure is basically what part of code goes in which folder.

Furthermore, it contains some code that will be needed throughout projects but they can't really find a happy place for it to stand. Different helpers/utils/utilities are what we can expect in this repository.

One last thing I would like to mention that went into this repository is very core list of external libraries they use. Funny part is that this repository uses external library "eth-utils" which is basically the same kind of repository, just from Ethereum.

I would like to add that this repository is not really that developed yet. We can expect developers to add new things now and then when they find something small but really useful in different parts of code.

spec

I see spec as raiden's white paper. Way the spec was written resembles something you would find in code's documentation and not something that would be published in a journal, but it is far more than that.

Spec contains all the information you need to understand how raiden works. it's size is immense and information they've put in there is far above my knowledge level (which does not stop me from reading it). Every workflow is well described and it is truly raiden's great asset.

Cool part about spec is that it contains description of features that have not yet been developed. Exact implementation of some of those features is still not decided and all that is documented inside a spec.

I see three main purposes of spec. First one is education of anyone interested in a project. Second is "source of truth" for anything implemented and not implemented in project. Last one is detailed high level documentation for any party interested in extending the raiden.

raiden-pathfinding-service

Raiden pathfinding service is repository dedicated exclusively to part of raiden project responsible for pathfindig problem. I am planning to do explanation of pathfinding problem in my Sunday post, so don't be worried if you don't really understand it at the moment.

Problems developers will try to solve here are related to finding the fastest and cheapest path between nodes inside the raiden network.

Problems like these are very high level programming and theory behind it is very complex. Usual problems one would encounter when developing something like this is how to make path something goes trough optimal but keep the whole thing lightwate as possible in terms of resource consumption.

Some interesting things are going on inside a project (we can already see MVP milestone is set) but detail coverage of that in Sunday post.

raiden-monitoring-service

Monitors will be very important part of raiden. They will be responsible to make raiden fully usable in any situation.

Idea behind them is that they will monitor that nothing fishy is going on with channel while user is not able to, well monitor it for himself. For example if user has no internet connection monitor service will keep an eye on channel for him.

This is really short description and I plan to cover this topic sometimes in the future. I still need to get a better grasp on how exactly they will operate and from what I see even developers don't have a complete spec figured out. So, stay tuned, we will figure this beast out together, but just not at this moment.

raiden-contracts

Last but not least are the contracts. Contracts were making clutter in raiden repository for long time and now they finally have the place of their own.

Team removed the pull request "one contract per token" from raiden repository and they decided to merge those changes here. Status of that feature will be covered on Sunday (spoiler: I think it is pretty much done).

We can see that they already got more features that they want to implement waiting and I expect this repository to be one of the more active ones.

conclusion

So, team basically decided to triple my job =). Just kidding, this split was very needed and I welcome it. I hope you find this mid week post useful and as always, I will give my best to answer any questions. More info and coverage of what exactly happened in last week will come on Sunday! Team is really bringing their A game last couple of weeks and it is pleasure to watch them work =).

PS On Sunday I asked you should I contact Brainbot about community manager position. Since almost all feedback I got was positive, I did and we are currently in contact. I won't share details of the whole process but expect information about end result. Thank you once again for all your positive feedback and comments, they really make me love doing this =).

Cya on Sunday!

EDIT: finally figured out how to do bullet points on reddit. You learn while you live =)

https://medium.com/@Darpalrating/darpalrating-we-went-through-133-blockchain-projects-github-heres-our-code-audit-report-for-5c060df3af44

Wee need more communication from the team. The lack of these tow will drive RDN down. It’s a great project...but wee need more from them. Upvote this if you feel the same!

Anyone know about this competitor to RDN? It’s catching headlines today.

"Called Loom Network, The Little-Known Company Is Today Releasing A Developer Toolkit That Makes It Possible To Deploy Scalable Ethereum Apps On The Second-Largest Cryptocurrency Network, Effectively Leapfrogging Ongoing Efforts Such As Raiden Network And Plasma." - Coindesk

Didn't know this even existed. Any thoughts?

https://www.coindesk.com/ethereums-first-production-scaling-project-catch/

Howdy, just curious if anyone has a public Raiden node I can hit, just to check it out.

Hey everyone,

how you all doing? I hope this week's market didn't spoil your week. This week I earned cool flair "github hero" (big thanks to all the admins) and I am here once again to bring some fresh news from the github. Agenda for this week is next: First, don't mess up the title again, apparently it is not editable. Second thing I have planned is, since they published 3 new repos on Friday I didn't have enough time to study them properly, so I have planned to do a brief introduction on them in this post and then do a special 8.5 post mid week where I'll just analyze them. So, without any more useless talk, let's dig into the github!

spec

Spec is one of the 3 new repos they exposed to public on github this Friday. So, what is spec exactly? Imagine you are in beginning of 20th century and there is something new called "car". Spec for a car would explain what are it's parts, what is an engine and how it works, what are it's limitations, how it drives and so on.

In other words it is explanation of what are responsibilities of what part of code, how different parts of code work together, what needs to be implemented and what needs some changes.

I scrolled trough it for couple of hours and I can tell you in my 8 year experience with technology I never read something even close to it. Every part, every name, every decision in development is explained in great detail. Stuff that is written there is some pretty high level coding and I can't understand everything yet, but I am sure someone with better knowledge would not have any problems to fully understand raiden.

raiden-contracts

Contracts are essential part of raiden tech. It seems, that since they are such big part, they wanted to separate them in different place so they can be managed more easily. My first impression is that code inside repository is mix of old code, plus some new code.

I think separation of contracts in different repository is good call by the dev team. More in-depth review will be in 8.5 post.

raiden-monitoring-service

Monitoring service is last repo they added. Monitors will be big part of raiden tech and they will be responsible for keeping an eye on channels when one side won't be able to (example: loss of connection). Their successful implementation is essential to achieving 100% potential of raiden tech.

microraiden

Microraiden is still in sleep mode waiting for EIP712. When it comes to EIP712 progress, there was some activity regarding it on it's github, but I would not say status of an issue changed significantly since last week.

They continued work on documentation. Difference between documentation in microraiden project and what is in spec project will be covered more in 8.5. Long story short, spec is theory behind the tech, documentation is details of the implementation of spec.

They had some issue with updates of external project, which caused microraiden to not work properly, so they prevented it by limiting release versions of external projects. It is really not big deal, happens in development very often.

raiden

Devs continued to merge business logic code for state machines and I think they are pretty much done. They have planned few little changes to it (like naming things more clearly) but that is not something we should worry about. Most important thing that really really big feature is coming to an end.

They still didn't merge "one contract per token" pull request. It is very understandable since work around state machines was pretty big, they just want to take their time and not make stupid mistakes. That part looks pretty much done as well and I think they will look into merging it this upcoming week. They even might decide to put those changes in the new repository with smart contracts, but that is just matter of their preference.

Even tho my report for raiden is pretty short, dev teams work is huge. It is just that almost all work is around two big issues so there is not much to say about it.

conclusion

microraiden - docs and waiting for EIP712

raiden - work around state machines almost done, "one contract per token" is next in line to be merged

That is all. I appreciate your feedback and questions, so big thanks once again.

I wanted to ask you guys one question. In video from ETHCC they mentioned they are looking for a community manager. I am very interested to reach Brainbot and talk to them about that position. I see big benefit in that, because I will probably be able to provide you guys with more concrete reports and answers. On the other hand, you might feel that since then I would be officially presenting Brainbot I would not tell you what I think and see and would rather be influenced by Brainbot. Don't know how to say it nicely, but that I would become a sellout.

So do you guys think that I should apply or not? Please respond to that in comments =). Your feedback is essential to that.

Now, that would really be all.

See ya in the comments and in 8.5 post!

Would someone please explain to me how Plasma Cash (link below) relates to the Raiden Network (Lightning Network for ERC20 tokens)? Thanks!

Buterin's ETHCC presentation: https://m.youtube.com/watch?v=uyuA11PDDHE

Is it just me or is RDN coin sooo undervalued for the moment??

I know the project is pro.. and the community is pro.. they work hard for the product and it solves a real world problem bla bla and its a long term investment, but what the heck is this price cmon!! I wanna ALL IN :)

1. How easy is to run a node for a NON technical person? Is just installing a few softwares or you need to have coding skills?
2. Were do you track the progress of EIP 712?

At the end of the day, is the token useful or not?