User avatar
COO/Community Manager
Posts: 155
Joined: Wed Mar 16, 2016 4:43 am

Technical Meeting - August 13th, 2016

Wed Nov 02, 2016 10:56 am

Outlined is a summary of the technical meeting.

Welcome everyone to the first technical meeting. In this blog post you will find the answers to the questions the community compiled before the meeting. It is published before the actual meeting starts so that the community has some time to read the answers and come up with new questions towards the community meeting. This encourages a community meeting where people can ask us further questions and talk casually with us.

Technical Meeting Questions

Release-Management / Development-Process
What do you plan for future Development-/Release-Management? (cc001)
Oliver: We are planning to develop each new release in 3 week iterations, with release candidates being built for the open testnet in the third week, for at least one week of testing.

The versioning mechanism we are using is: Unfortunately, previous versioning has not strictly adhered to this mechanism, but going forward we hope to improve this for a better understanding of what each release will bring, in terms of any breaking changes.
Short to medium term milestones will be created on our GitHub, and issues will be assigned accordingly. In order to maintain agility, and avoid delaying a particular release cycle unnecessarily, issue assignment is liable to change, and so might get reassigned to a later release, or brought forward if we are ahead of time.

To create a clearer separation between our chosen versioning mechanism, and any indicated milestones, we intend to use canonical milestone names, which don’t mention a particular version number, but instead an alias (e.g. “Community Forging”), which once complete will be assigned a semantic version number according to its changes from the previous release. This will allow us to release hot fixes, without conflicting with any ongoing milestones we are aiming to achieve in the longer term.

We shall publish a blog post outlining our release process further.

What do you think about “Release early, release often”? Is it even possible in crypto? Maybe it could be useful just on the testnet? (couldn’t the 0.3.2 Hot-Fix have been created/published weeks ago…?) (cc001)
Oliver: I think in principle early, frequent releases is something we should strive to achieve. However, I also think in order to to practice this safely, we first need to vastly improve the test-suite we inherited when we forked the project, and furthermore, extend its coverage to a degree where critical components are always functioning perfectly with each release.

Regarding 0.3.2, I think if we were to base a “hot fix” on the broadcasting issue alone, then yes the release should have been made much earlier. Having said that, I really don’t think it would have gone as smoothly as Wednesday’s release. There were a number of interlocking issues that needed to be resolved at once, in order to make the update go without hiccup. This includes a fully passing test-suite, a database migration system, the ability to produce verified snapshots.

Max: Regarding your question, if this is even possible in crypto. I think it’s very important to release often in order to have smaller but more frequent updates. It’s much easier to test them and thus guarantee a working code base. However, you should never release (too) early in crypto for obvious reasons.

What’s the story behind the voting bug which led to the creation of version 0.3.2a? (wannabe_RoteBaron)
Oliver: The story behind the voting bug encountered in the initial build of 0.3.2, is that the first resolution to the “Maximum 101 votes” issue I applied was unfortunately incorrect. In preparation for 0.3.2, I had rewrote all of the voting tests to provide better overall coverage, all of which were passing. However, one of the test examples was unfortunately testing the inverse of what should be expected, and so therefore the edge case was allowed to occur unchecked. Upon discovering this, I proceeded to change the test example involved, and promptly coded the correct solution that was included in 0.3.2a.

Assuming that something like the DAO will be created in the future (max said it might be possible in a few years) is there a plan on how to handle a coding issue similar to the DAO/ETH error that finally led to the “DAO Hack” which in my opinion wasn’t a hack but someone using the code to do something the developer knew of for a long time. If there is something like this how will lisk handle such an issue? I believe that this question is more then important after we saw the rise of ETH Classic over the last days. (gpheheise)
Max: We don’t think a Lisk DAO as a sidechain will become a reality within the next few years. This means we have a lot of time to improve the general concept of a DAO, and its related security issues. After the the DAO fiasco, there has been a lot of research conducted regarding smart contract security, and we intend to utilize it for the benefit of a potential Lisk DAO in the future.

Please note, there is a major difference between Ethereum and Lisk, and that is, sidechains operate autonomously from the parent mainchain, rather than part of a global monolithic machine.

One major area where I think Crypti and Lisk both have done an inadequate job in explaining the details is with the functionality of sidechains. Your post this week on “What is Lisk” went a long way to helping newer users understand the Lisk technology in general. Can you do a blog post in the next couple of weeks providing more detail on the sidechain pegging mechanism (i.e. pushing Lisk into a sidechain), as well as explaining how the sidechain nodes or network interact with the main Lisk blockchain? When someone creates and administers a sidechain on the Lisk network, how does that benefit the users of the main Lisk blockchain (assuming they are using a custom token and not direct LSK integration)? (Matt/GreXX)
Oliver: I agree, we should do a better job of explaining the mechanics of Lisk sidechains. We shall begin with a blog post on the subject, covering all of the areas you’ve mentioned.

To briefly answer the question, the main Lisk blockchain does not benefit directly from sidechains using their own custom tokens. Individual sidechains also do not directly interact with the mainchain past the point of registration, but are dependent on the mainchain’s existence and normal operation. This is essentially because sidechains operate as child processes to the mainchain.

Max: To answer your last question, as Oliver already said the mainchain does not benefit directly from sidechains. There is rather a benefit for the network as a whole, every new sidechain will bring in new users, a bigger value, and therefore a growing ecosystem. This bears the potential that Lisk can grow much bigger than any other blockchain-based platform.

Is it correct that the current Lisk version does not support previous simple dapp examples like the guestbook? What version of the Lisk code will support dapps again — 0.3.2, 0.4.0, some future version? What is the estimated time before actual dapp coding can begin, and where will the instructions for doing so be posted? (Mal)
Oliver: The guestbook example does work with the current Lisk version, however other examples still need to be updated in order to reflect changes to the SDK.

In the short-term, there are also a number of issues, bugs outstanding affecting basic blockchain application development, of which we will resolve iteratively over the next few releases. This will enable developers to build applications with much less friction than there is currently today.
Looking longer term, we shall hire a dedicated team to work exclusively on the platform, SDK, documentation, example applications, and surrounding toolset. This should dramatically change the landscape as it currently is seen to be. The current stagnation, is down to a lack of resources, but with the funds Lisk raised, this should not be a problem going forward.

In terms of stability and security, we are aiming towards developing the runtime environment and SDK to a production ready state by early 2017.
In the meantime, we will focus on improving the documentation, examples and supporting tools enough for new developers to come aboard and start building prototypes immediately.

Is the Lisk blockchain currently able to host a project of Steemit size? Stable network is the foundation, if we don’t have it ready then we cannot attract developers and projects. (metropolit)
Oliver: Yes, we believe Lisk can host a project of this size, if not greater. The reason for this are twofold, our choice of database system: PostgreSQL, which has many avenues for scalability, and secondly the fact that each sidechain operates autonomously from the mainchain with the minimum of parental dependency.

Our platform requires a lot more development effort to establish the maturity and security required to operate such a high value sidechain, but the fundamentals are all there.

Can some of you explain the how is implemented the internal process of electing the delegate that forge the block and which factors influence the deviations from the standard 17 min? (wannabe_RoteBaron)
Oliver: How delegate slots are decided:
  • Lisk gets a list of all 101 active delegates sorted by vote
  • Lisk determines an order of delegates based on an initial seed
    • The initial seed is a sha256 hash of the current round, derived from block height.
    • Delegates are then indexed according to currentSeed[x] % 101, with x being an individual byte of said sha256 hash.
    • For every 4th byte of the current seed, a new hash is created based on the previous one.
  • Lisk determines a slot number according to a given timestamp, and selects the delegates key from the previously generated delegates list
  • Lisk checks if the current slot matches any enabled delegates, if there is an exact match on slot time, the delegate generates and signs a new block
The 17 minute round time is extended if one or more delegates miss their slots.

Node running
Any update on the snapshot possibilities (or something like concurrent connections on the rebuild to speed it up greatly)? (MrV)
Oliver: Work is ongoing towards improving the peer selection, and block processing that affects syncing speed and reliability. There has been some major refactoring of the code covering this area, which we hope to include in the next version of Lisk.

What server setup would you recommend (not minimum) for a stable work of an active delegate node? RAM, Cores, SSD, etc. . (polycrypto)
Oliver: We currently recommend having at least 1 GB of RAM, and a minimum of 2 cores. From our experience running 101 delegates on the mainnet, extra cores and a faster SSD are far more important than raw CPU speed or memory capacity.

What is the maximum allowable latency between nodes and how has this been established? (Mal)
Oliver: Based on Lisk’s block time of 10 seconds, I would estimate a latency above 1 second leads to a greater probability forking.

Would it be helpful to add “telemetry” functions so nodes dump information on their interactions with other nodes (perhaps to a central repository) that would assist in understanding fork mechanisms? (Mal)
Oliver: We have practiced this in development, so yes I agree it would be very helpful. Please raise the issue on GitHub, and we can look to schedule its implementation.

Can you enable forging on two or more nodes for the same delegates? if not, why not? as far as i know it’s not recommended, but please give us some more technical infos about it. and: might it be possible in the future? (punkrock)
Oliver: Enabling forging for the same delegate on multiple nodes is possible, but not advisable, as it will eventually lead to the nodes signing the same block multiple times within the same delegate slot, causing a fork. With each slot being identified using the delegate’s public key, there can only be one signing using this key pair on the network, therefore the first to achieve consensus will succeed, leaving the others to fail and end up in a fork.

Will we see some kind of built-in monitoring feature, to get alerts on fork / no forged block for xy minutes / etc.? (punkrock)
Oliver: Built-in, probably not. However, what we can do is allow 3rd party tools to connect to the web socket of a node, and receive broadcasts when a fork occurs, or a node stops receiving blocks. This would utilize the same mechanism used to broadcast changes to the user-interface e.g. when listening for new blocks, transactions and round changes. This way, a simple script could be written to connect to a node and listen for these events, non-intrusively, and react accordingly.

Will we see automatic snapshots in coming versions? (punkrock)
Oliver: The ability to produce verified snapshots was introduced with the release of version 0.3.2. For the moment, this is a manually executed process. So in order to provide constant snapshot updates, we are working on an automated solution for this. We also want to decentralise the storage of any snapshots, initially through trusted mirrors, potentially using IPFS.

Are there some scenarios or technical tests that we as community can make in order to help the testing/validation process of one release? (wannabe_RoteBaron)
Oliver: Yes, I would say a valid scenario for community testing is to conduct rapid and continuous vote swapping between delegates, and monitor the amount of forks which then result. This particular scenario is the one preventing us from safely enabling community forging. The solution to the current instability still needs to be coded, but will be implemented in the near future for the community to test.
Another scenario is to test the maximum transaction volumes per block that individual nodes can support, and also the network as a whole. The currently imposed 25 transaction per block will be raised as we optimize and improve block processing efficiency, therefore these new limits will need to be tested in a less controlled environment than our devnet.

So, in summary, with each new release there will be new areas to test, and old areas to revisit to ensure we are maintaining stability, rather than regressing it. Certain scenarios are very difficult to test within an isolated devnet, therefore we are reliant on community support to make these happen.

Lisk Clients
Are there any plans to make an innate Windows installation instead of having a docker container?
Oliver: Yes, we would like to provide a full native Windows client for running a delegate, or operating sidechains. Due to some reliance on the POSIX architecture used by Linux, OS X and FreeBSD, we will need to conduct a feasibility study before we can commit on a time-frame.
For the time being, the docker container does provide a solution that works.

The weakness of LSK is security, so team have any plans to sign strong security team? (bawga)
Oliver: We have been advised to factor out code security audits to a third party, rather than employ from within. Initially we will request an overall security audit, with follow up audits being performed after significant milestones have been achieved along the roadmap.
We are also planning to employ an in-house cryptographer whose role will be to improve and document the cryptographic elements of Lisk.

Can we get some technical information about the voting bug that led to the creation of 0.3.2a version? (wannabe_RoteBaron)
Oliver: The voting bug was caused by a missing data validation against the Lisk memory tables. Transactions exist within the blockchain in two states, unconfirmed and confirmed. Similarly, any changes to an account on the memory tables are applied according to these two stages.

When we originally forked Lisk, there was no validation implemented at all. A later version introduced a validation at the “confirmed” stage, but neglected to run the same validation at the “unconfirmed” stage. The bug was allowed to exist through a lack of test coverage in the original source, which has now been resolved.

Why the fees are different for different forged blocks? (wannabe_RoteBaron)
Oliver: Depending on the number of, and types of transactions within a block, the fees will vary. The standard transaction fee is 0.1 LSK, but for other types of transactions such as delegate registrations or second signature creations they have different fees, hence the reason for the variability.

Max told at community meeting about roadmap very soon after 0.3.2. When Lisk team will release roadmap? (Calabi–Yau Manifold)
Max: Yes, we are preparing it since the beginning of this week. I had to travel back to Aachen for 3 days for personal reasons so we got interrupted. However, from today on I’m back in Berlin and we can work consistently on our detailed roadmap for 2016. It will be released next week.

Max told at community meeting about asking poloniex to add Lisk on margin trading (after 0.3.2), when he will ask them? (and how? by using some small bribe?) (Calabi–Yau Manifold)
Max: We have established communication channels with the major Lisk exchanges on Skype and can ask the owners directly. I will contact Tristan from Poloniex next week and ask him what he thinks about enabling margin trading for Lisk. We don’t bribe people.

Under what circumstances the Lisk team might consider a hard fork? (bitcoinbox)
Max: We take a very pessimistic view on hard forks and will do everything to not come into a situation where a hard fork is necessary. One thing is for sure; it will always be a decision on a case-by-case basis. The final decision will obviously be made by the delegates and not by the Lisk team, we can only be the neutral instance releasing a compatible client.

In the case of Lisk sidechains (and lost funds on the mainchain due to it) we won’t consider a mainchain hard fork at all, as sidechains are meant to be independent. The decision for sidechain hard forks comes down to the sidechain development team and its delegates.

What is the Lisk team opinion about Ethereum hard fork? (bitcoinbox)
Max: We don’t give a comment on that.

At what level is the advisor (Charles Hoskinson) relation with lisk. Is it discussion about global challenge of running a crypto only? Or more “in-depth” like lisk team send pre-release source code to scorex team (IOHK, Charles Company) to have their insight on the internal mechanics of lisk. (mcdaddy)
Oliver: Charles is advising us as an individual, giving us both technical and legal advice based on his vast wealth of experience. IOHK is a separate entity, which we would need to hire separately under contract for any work to be completed.

@Rise project is Lisk Dapp? (bawga)
Oliver: The Rise project is a fork of Lisk and is completely independent of Lisk. They recently merged all our changes which went into Lisk version 0.3.2. It still remains to be seen what kind of development efforts will be made in the future at Rise, but in essence, we are embracing the spirit of open-source, and wish them all the best.

Megaupload 2.0 will affect on LSK project? (bawga)
Max: No. The Lisk project is a platform which enables the development of applications and services. An application like Megaupload 2.0 is only one use-case of what is possible with Lisk. If Kim’s new project really takes off then it will benefit the whole blockchain space because it brings further adoption into it.

How many LSK still have in @lisk team( Max, Oliver … ) ? (bawga)
Oliver: We both have 4 million LSK each.

Does the lisk team plans to align the log format to a standard like “apache log format(common log format)” or follow there own format? (wannabe_RoteBaron)
Oliver: For the moment, yes we have our own log format, but if there is strong opinion on it from the community we will adapt it to a known standard.

Technical Meeting Transcript

Hello everyone, as always it’s extremely nice that you pay us a visit in order to learn more about the technical sides of Lisk. Today is our first technical community meeting in which we will answer all kinds of technical questions from you. We are following our usual structure, so I will start the meeting and talk about a few things. Afterwards you can ask your follow-up questions, or just chat with us. With us today is @joel, @isabella, and of course @oliver! You can find the answers of the 29 initial questions which were asked prior to the meeting on our blog.
Thank you for submitting so many questions. We have two announcements to make today.

I’m currently sitting with Oliver in our awesome Lisk office in Berlin. It is a serviced one as we intended to do in the beginning.
It’s a 4 people office room at WeWork ( We can scale it up whenever we want, so next month we might already sit in a 6 people office. We decided for WeWork, because it took us literally a weekend to sign the contract and move into the office. Depending on how much we like it here; we either stay here and upscale to bigger offices, or looking for another solution. Until now, we love it. Very soon we will also publish a blog post about the office, with a few images and information.

The second announcement is our roadmap. Oliver and I already sat together on it for many hours. It’s coming along nicely. We had to re-think some internal structures like versioning schemes and milestones, in order to be able to deliver a good roadmap. So you can expect a blog post about these changes as well next week, along with the roadmap. I’m very happy though that Oliver and I are now able to sit in the same room, I can already feel how the efficiency is increasing. So I’m very optimistic about the roadmap.

That’s it already with my introduction into the technical meeting. Now you can ask us any kind of follow-up questions. If they tend to be very complex we might have to delay an immediate answer and provide a well thought out answer in our blog. Thanks for reading, we are looking forward to your answers. Please tag the people you answer directly.

Tharude: Is there any planned coop with Burst or Storj projects?
Oliver: No immediate plans. There is a possibility of ipfs integration however.
Max: IPFS plans to be more like a protocol, but StorJ or Burst are more like startups. We want to stay independent from any third party startups.

Coinz: Can we get some info about what @fixcrypt and @ricardo.ferro are working on?
Oliver: @fixcrypt is working on issues assigned to him according to the current milestone. Lately he has been working on refactoring the block processing and peer selection code.
Max: Ricardo is working on the Lisk nano client. The past two weeks however he was busy because of the Olympics in Rio, as he is also working for an IT company in Brazil. The Lisk nano client is ready to go, we want to do one final round of testing. Then release it.

Techbytes: are you guys closed to nipping the fork in the bud?
Oliver: Closer with every release. Once we have stabilized the votes within memory tables across disparate nodes, I think we will be ready.

Devasive: Can you give any indication of the progress towards fixing the fork cause 3 issue? Have you identified the problem and made any headway on the solution?
Isabella: root cause of fork 3 is related to inconsistency of memory tables compared to other nodes. it received a block with the “incorrect” signature while other nodes validate it as correct. This occurs when there was an issue in processing the slot list and the slot recieved does not match the memory tables on the node

wannabe_RoteBaron: how do you guys plan implement an isolation between the blockchain application the that an application will not able to access the resources/data of other blockchain apps
Oliver: We plan to implement a method of sandboxing the child process from which each sidechain operates from.
Therefore, it is quite likely the current `lisk-node` implementation will be replaced with something more secure.
This is yet to be decided. However, it would be the parts of code which require better optimization or need to be shielded from easy manipulation.

Slasheks: Could you explain, in detail, what is the technical difference between the three block receipt methods:
[inf] 2016–08–13 10:13:11 | Block 17616427187053615948 loaded from x.x.x.x:7000 at — 395782
[inf] 2016–08–13 16:07:50 | Received new block id: 13206140800442002383 height: 397374 round: 3935 slot: 699527 reward: 500000000
[inf] 2016–08–13 16:05:12 | Found common block 13574497443574177009 (at 397362) with peer x.x.x.x:7000

Isabella: #1, block loaded from IP is syncing one or more blocks. #2 received new block is when a block is posted to your node from another node #3 is when the node is searching for a new block because it hasn’t received a new one recently
This is block loaded directly from a peer (pull)
[inf] 2016–08–13 10:13:11 | Block 17616427187053615948 loaded from x.x.x.x:7000 at — 395782
This is a block broadcasted from a peer (push)
[inf] 2016–08–13 16:07:50 | Received new block id: 13206140800442002383 height: 397374 round: 3935 slot: 699527 reward: 500000000
This is the result of a query, initially done find a common peer on the right chain:
[inf] 2016–08–13 16:05:12 | Found common block 13574497443574177009 (at 397362) with peer x.x.x.x:7000

Doweig: Do you have any plans on technical hirings? I mean how many tech people will you need in 6 month or 1 year from now
Max: Definitely! We made the decision to hire local talents in order to increase our efficiency (as we only have so many funds/time, and Lisk is a huge project) to the maximum.
That means starting now, after finally being in Berlin in our office, we can look for further technical employees.
We are definitely looking for 2 core devs and 2 (or more) frontend devs ASAP, but our whole team will grow to about 15 people at the end. With ASAP I mean as soon as possible to help out at urgent construction sides of Lisk.
Following that, we will consistently grow our team. Designer, cryptographer, PR, and so on.

LSK: are you still intending to hire a CTO, or would it be better to build the dev team and then appoint a CTO from the team?
Max: We already have the best CTO for Lisk in the world. Someone who deeply understands the underlying code base, its inherent value, and shares the same vision as the rest of the team. His name is obviously Oliver Beddows!

LSK: how’s your stress level Oliver?
Oliver: Absolutely fine thx, much better now we are making good progress again

Slasheks: Plans on establishing a notification system of upcoming changes that could possibly break compatibility of community tools? ex log file location update
Max: I think this is a very good idea. Previously I was part of the Nxt community and one update changed many different API calls, this was heavily criticised within the Nxt community. That means we will brainstorm about such a notification system with “breaking” changes (API, log file location etc.).
As the first step is our switch to the semver version scheme, which already described if an update “breaks” anything or not.
If you have any ideas please contact us and we can discuss the matter together with you. I think something along the lines of a changelog at the beginning of the testing would be a good start, and depending on the amount of “breaking” changes the testing period should be extended. (Or working with milestones, so that third parties have enough time to update)
Slasheks: Thanks @max ! I think a changelog is a good start. I will look further into this and provide some feedback.

wannabe_RoteBaron: there is possible to scrape out of memory the BIP39 passphrases if you are using programming languages like C/C++.. Do you consider also to use it for authentication?

Oliver: Any major changes to our protocol or the implementation of it, will in the future face a security audit. If there are known weaknesses to be avoided, we will try to avoid them

Qbanow: Canonical milestone names using alias names will be great less confusion and Less FUD about versions #.
Oliver: Thanks, I’m glad you agree. I think it allow us to release more frequently between milestones also.

Gr33nDrag0n: I know @isabella worked a lot on api documentation and there is currently an issue on github for api versioning, I think it should be part of the solution to complete this issue and keep the documentation up to date like Isabella did.
Oliver: I agree. API versioning and possibly automated API documentation should be a priority.

Doweig: How is the white paper going?
Max: Okay!
We waited for this question. Okay, so we heavily discussed this internally and came to a conclusion many might not like. So we know that a whitepaper is extremely important, but we also have to keep in mind that Lisk is extremely new. That means there are so many moving parts. About 2 months ago we prepared (with the help of a community member) an over 20 pages long whitepaper, but this is already outdated in many parts. That doesn’t mean that a whitepaper should be neglected at this point, but it means that with the current small team we have to make the “sacrifice” of not having a whitepaper, but instead concentrate on security issues and the code.

Therefore, we pushed the whitepaper to the first quarter of 2017 in order to get Lisk to a stable state and do the same for our sidechains. This will be something our cryptographer (which we will hire sooner rather than later) will work on full-time in the beginning.

Doweig: Ok, makes sense that way. Can we get more documentation in the short term to compensate? Especially on delegates. Also if you feel like things are changing too fast, you could put your whitepaper on github, kinda like Ethereum did. Easy to edit, versioned and all
Max: Yes, we can provide more documentation short term. Writing the whitepaper in a public way might also be a good idea. I will think about this.

Vega: just yesterday it come up in the chat how I delayed finishing my delegate monitoring tool, as before community delegates can forge on the main net, it’s little use and there is too much can change in the code until then.
My question is: when (if) we can expect such a web socket to be implemented? I’m sure there is no firm plans for it at the moment, but it would be good to know if we can expect it before, around, after or long after the community forging starts, as the answer would influence my (and I’m sure most others) 3rd party tool development
Oliver: We can implement the socket broadcasts quite quickly. We will add an issue to GitHub and assign it to be done asap. It really is a continuation of what is already in place via the lisk-ui.

Slasheks: Has separating /api and /peer functionality made it into the roadmap? From a technical standpoint, what is keeping this from becoming a reality.
Oliver: Separating the `/api`/ from `peer` to different ports, I agree it is a good idea. I think it can also be taken further to move certain components to child processes, as in clustering, to make use of multiple cores. The thing holding us back is that it would require some significant code changes, only that.

Corsaro: can best testnet active delegates be eligible for bounties ?
Max: Yep. Let me think about it! I’m positive about this.

Hoop: any info on how much time till we can see sidechain integration ?
Oliver: We are aiming to stabilize sidechain development and the surrounding toolset by early 2017. I hope between then and now we will make gradual progress, so that the documentation, examples, and tools are significantly better than they are now.
First and foremost, sidechain security needs to be improved before we can take apps into production safely.

Coinz: Any more recent developments with the ghgmb?
Max: Progress is being made. We will publish updates once there is something significant to announce. Let’s wait for the next community meeting.
Levent: steemit style you intend to do a project?
Max: No.

Gr33nDrag0n: @slasheks did you mean separating the web server in http (wallet ui) and the api from port 7000 ?
Oliver: Yes, there is an issue on GitHub for this. I would like to do it for sure. Until now, it’s been a question of different priorities.
Gr33nDrag0n: yes I understand its not a priority but would definitely help for security being able to be done from firewalls

Luiz: hahah…the whole chinese community are all caring about the Whitepaper.
Max: I know. As @doweig mentioned there might be a middle way by writing more frequent blog posts on different parts of Lisk. E.g. one blog posts which explains the Lisk address generation.

Tharude: why don’t you hire a professional blogger part time?
Max: Yes, we will hire a marketing person who will take care of:
  • writing blog posts
  • having a consistent communication channel with news outlets
  • writing PRs
  • getting in contact with conferences
  • managing advertisements
  • coming up with a marketing plan
and so on..

Gr33nDrag0n: those settings are working now ?
“serveHttpAPI”: true,
“serveHttpWallet”: true,

Oliver: Unfortunately not yet. If there is it not an issue for it already, please raise one and we will assign it to a milestone.

Slasheks: Any plans on adopting any type of development methodologies such as scrum/agile, etc? In my experience, it has helped much with ttm and visibility into the process of the team.
Max: Yes. Currently, we are moving to some sort of an agile methodology. (test driven, frequent updates, and so on) However, I also had several talks about scrum already with @joel and also with Richard from BitcoinWednesday (who is a scrum master).
So we are still researching various options, but we probably will adopt some mix and play around with different models.

Thrice.Pi: forging could be enabled as soon as the code is finalized correct? ..we wont have to wait on the white paper in Q1 of 2017 to be completed before delegates can begin to take on the forging process right? just trying to gauge a (possible) time frame @max
Max: Of course not. The whitepaper is just a piece of paper which describes already existing features/processes and features/processes which will be developed in the future.
Oliver could come up with an awesome whitepaper, it would just take him an unbearable long time (as it’s a very time intensive task, I think Ethereum took 6 months), and we don’t have the resources for that right now.

Tharude: Today i had the luck of 8 stalled wallets at once, without any visible reason and no forks (mainnet) Nothing informative in the logs. Should we raise the log report level on mainnet too?
Isabella: was it all the same block? there’s a possibility all of the nodes received the same cause 1 block and took it as consensus. this would lead to no error in the log

Tharude: same block, but all of them resides on different VM’s and different IP’s. It was a bit strange
Oliver: This issue could be related to the issue @isabella just mentioned, or it could be that the forging timeout after no broadcast receipts kicked in. This can be the result of a node being banned after producing what is deemed to be an invalid block.
Lowering the log level to debug might help.

Tharude: Thanks for the tip! It was just a bit strange, that 8 nodes, residing network wise in different countries with different IP glitched in the same time in the same block.
Oliver: Yep, I think longer term we will need to improve the efficiency of block propagation. This would alleviate some of the problems we are seeing.

Qbanow: Could you vote for some delegates that are below 101 delegates in testnet to bring them to forging because there are some delegates with less of 50% of productivity and I think they are not attending the node anymore at this point of development testnet is really as important as mainnet.
Joel: I’ve voted up the new members who’ve asked to test a delegate, those include @bitbanksy @Gigabyted @polycrypto and @liberspirita . There haven’t been any more requests since I voted those up.

Anamix: 0.3.2b is working very well do you have a ETA for start the forging reward process?
Max: No ETAs anymore for things we can’t 100% control. We learned our lessons. It will come when it’s ready, and we are working hard on it.

LSK: will there be a Chrome client?
Max: No. (If you are talking about a chrome plugin as a Lisk client)

Tharude: After some 5–6 years we all be millionaires here. Thanks Lisk team for your hard work!
Max: I would prefer that we entitle ourselves in 5–6 years to be the early adopters of a revolutionary, huge, and life-changing technology.
The money aspect is the positive side effect, but shouldn’t be our motivation. The will to change this world and make an impact should be.
More decentralization for everyone and everything, right?

Slasheks: There are minimum technical requirements that eliminate or make unfeasible to use some of the current arm offerings in the market. Will there optimizations and focus being placed on this aspect of the platform to continue to market LISK as an IoT friendly blockchain or will this be reserved to sidechains?
Max: We are definitely targeting the IoT market as it bears an enormous potential. I think the solution will be that IoT devices will simply connect via APIs to more powerful servers where the IoT app is running on. Such an API interface could be developed extremely lean. That means the IoT device would simply access information, instead of processing it.
This needs more thinking of course and there might be another/better solution, but I don’t see us running on microprocessors anytime soon.

Luiz: is there have some way to tie up the second password with google 2FA?
Oliver: Yes this is possible. Whether it would be desirable or even needed is another question. My instinct says no.

Tharude: It will be nice to make some platform like ODroid “The Lisk chosen (or preferred) platform” thin client/IoT wise.
Max: You mean a “Lisk Computer”? I agree it would be cool to have, on the other hand you could just chose a Raspi, Odroid, BananaPi, C.H.I.P., whatever. Lisk is an open source project which can run everywhere, that means we shouldn’t limit ourselves.
That doesn’t mean that someone outside of the Lisk team can’t develop an awesome, tiny Lisk Computer.

Thrice.Pi: will there be a forging process needed to be maintained by delegates for that IOT app you mentioned (if it can be manifested into reality)
Oliver: The consensus would happen on the network, through the delegate servers. The IOT app would simply interface with the network using an API.

Thrice.Pi: is there any particular BAPPs in the works yet by any chance? or perhaps one you have your mind set on ? @max
Max: There are a few in development, but they are mostly just experimentations and prototypes. I heard of online shops, messengers, “blockchain guns”, and some other stuff. I think before 2017 Q1 (where our sidechains will be stable enough) we won’t see major app projects in public.
Please note that it’s not Bapp, it’s just a Lisk app, blockchain app. Bapp sounds ridiculous.

Slava: What can you say about the project Rise ??
Max: I wish them all the best. I hope they announce credits where credits are due.

Slasheks: Only mentioning because there is still the claim that “It runs on high performance VPS or on inexpensive, low-end ARM” on the main page mentioning the raspberry pi. Which perhaps has been there since the sqlite3 days.
Oliver: I’m running the latest client on a raspberry pi 2 without problem. Yes it forks now and again, but from a performance standpoint it works great.
Slasheks: I am running it on a low-end device for testing as well, but that is only when it is fully synched, that it is good and stable, when a low end device is syncing, that is a whole different conversation. even with mid-range devices. I do acknowledge that there are many issues being worked on that will improve this for lower end devices, like snapshots. Was curious about the focus on IoT since it is a huge untapped market.
Oliver: Yes, agree there are issues to be closed which will improve the situation on these devices vastly. We would therefore still like to maintain support for these devices, mainly because it’s cheap and convenient to operate nodes on them.

Devasive: There have been a couple instances of second passphrases becoming invalid. Is this a documented issue or were these just random occurrences?
Max: Second passphrases never became invalid (wrongly formulated, IMHO). These issues probably were either frontend related (different browsers/OS=different char sets) or wrongly copied/pasted passphrases. We will look more deeply into that.
wannabe_RoteBaron: what are the next features that you are looking to implement on the lisk api
Oliver: the API side we will plan to redesign the structure to be truly ReSTful. With `0.3.2` we added a new endpoint `/api/delegates/search` which is quite useful.
We are also looking at removing insecure endpoints where passphrases are required, using locally signed transactions instead.
wannabe_RoteBaron: ..the documentation for the api needs some help show all the implemented features …can we help in some way
Oliver: Thanks! We will make an effort to better cover the API in our documentation, at least in the short-term. Your help is most welcome if you feel inclined.

Max: Okay guys! I will close the meeting now! Thank you everyone for attending, it was great as always! See you in two weeks at our next regular community meeting. Joel will prepare a blog post in a week to submit new questions.
Joel, Community Manager

Return to “Community Meetings”

Who is online

Users browsing this forum: No registered users and 1 guest