Lisk Community Meeting Summary — August 27th

Welcome everyone to the fourth community meeting. In this blog post you will find the answers to the questions the community compiled before the meeting. It is published about half an hour 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.
We kept the questions quite general and created a new kind of community meeting for all technical questions. The technical community meeting will happen in two weeks and we will answer all outstanding questions there.
Refer to this blog post in order to view the Q&A from our last community meeting, conducted on July 30th, 2016.

Communication

1. Are there any thoughts about a weekly newsletter/blog status update post for Lisk? Ideally you could sign up for email notifications when the weekly update is posted to the blog. (MrV)
   A weekly summary newsletter is already happening, the retrospect. Since the 19th August we are also sending out newsletters for every important blog post we publish. However, I assume you mean a more general blog post which includes various updates about the past week; like development, community efforts, legal progress, and so on. We can definitely do that. Let me speak with Joel and we will think about a way to do this.

Question back to you: What kind of information do you want to see within these status update posts?

Delegated Proof of Stake / Algorithm

1. Will dev funds (8mil) that Max & Oliver control be used for voting or promoting individuals into top 101 delegates? If yes, wouldn’t that mean Lisk being centralized and subject to manipulations? The only scenario I can imagine them getting involved to vote is to counter an attack from one person having a lot of voting power to control network. (distro)
   Yes, we will vote with our fundings. If it turns out that we have too much power, we will think about possible countermeasures (e.g. we only vote with a smaller amount). However, looking at the broader picture we “only” have 8% of all tokens and it’s continually becoming smaller once the forging rewards are activated. I assume once there is something to earn, many people will start voting as well.
   On another note which is not set in stone yet; we definitely want a decentralised community delegate take-over. That means even though the forging rewards are activated we won’t remove any vote from the genesis delegates for one week. We will see if this works, the potential earnings would obviously go into a fund.

2. I heard talk of increasing the number of Lisk delegates. (thrice.pi)
   i. Is this a guarantee? If so when?

What is a guarantee nowadays. :) However, I would really like to see that as it’s making the whole network more decentralised and robust, splits the forging rewards between more individuals, more Lisk projects could be funded, and we would have more servers for the upcoming lite clients to connect to. It’s a win-win situation, so it’s clear I want to do it. However, I can’t give any timeline for that.
ii. Also (approximately) by how much will it be increased?
It has to happen step by step because we need to have the necessary delegates at hand and the code has to be more optimised to support a bigger number of delegates. I would say increasing it by 20 delegates with every update is a good number. The best-case end-goal is around 1000, but I’m not sure what kind of code or network optimisations we would have to do for that. We will know it later on.
iii. Can this be done with the current code or what changes to the code might be needed to make this a reality?
Currently, the 101 delegates are deeply entwined within the codebase. It’s not so easy to increase the number of delegates and such a change needs to be heavily tested. I’m not only talking about code changes here, also about network latency and behaviour which might change with a larger amount of delegates. Even game theory is an area we would have to think about.
The Lisk code is becoming more modular over time and at one point I assume it will be a simple variable edit. That’s the best-case at least.
iv. What causes and effects might be expected with such a change?
There will definitely be a latency increase, i.e. the time every delegate needs to receives the current block. That means we have to optimise the codebase to a point where we can support more delegates without any problem. This optimisation will be done in the Resilience phase with the complete re-write to TypeScript and by adhering to ECMAScript standards.
Forging rewards / GenesisDelegate-Replacement

1. So, my question is not provocative, but very important! I think when you say that forging will delay until 6 month, you was understanding that you can’t enable this in 1–2 month. Now I see that we(team and community) must do all that enable forging as soon as possible! This make ecosystem more active! You can see started activity after Lisk team activity! What time do you need to enable forging? (grumlin)
   I’m not sure I understand the first part of your question. However, I estimate we need around 3–5 more updates to activate forging rewards.
2. When mainnet forging is released to delegates will the rewards start at 5 lisk per block for a year starting at that point or will they only be 5 lisk a block until Block 3,060,480 then they go to 4 lisk per block? (cryptostorms)
   That is a very good question! I’d have to discuss it with Oliver. At the current valuation of around $26M and 2,000,000 more blocks to go I think it’s the best to just keep the numbers the same. Even at 4 LSK per block the delegates would have plenty of new LSK to support and fund new projects.
   Testnet
3. What do you think about the proposal for testnet bounties? If we want to pay such bounties, how exactly? how much and to whom? (cc001)
   I think it’s much more straightforward to release a bug bounty programme than paying people for their performance on the testnet. There are only 101 delegate spots after all and at one point it would be unfair for those who can’t become an active delegate. Additionally, there are too many moving factors for the performance that it isn’t a good measure.
   I know that keeping the testnet running is cost intensive and therefore we will hurry up with the bug bounty programme. Once, we have mainnet forging rewards the delegates can split 0.3%-1% of their income to pay for a testnet delegate. We might also just contribute a few LSK to the testnet delegates directly, to cover the VPS costs. I will talk to Oliver about that next week.
4. Can the dev team please ask all delegates to unvote the dead nodes on the testnet so we can establish a healthy testnet in which to perform tests on with 101 updated nodes please? (cryptostorms)
   Yes! This should already have happened.
   Roadmap
5. Maybe it would make sense to publish the Roadmap (great work!, btw) on a separate page, like for example in https://lisk.io/documentation and keep it up-to-date? (cc001)
   I agree. We will have dedicated sub pages on our re-branded website for every phase. These will be kept up-to-date and there will be even more information provided for some milestones.
   Until then the first stage is pretty fixed anyways, so the blog post should be good enough for now. Actually, there won’t be many changes to the milestones. If something changes then probably it’s either an addition or move of a milestone. Everything we listed in the roadmap is a must-have and will come.
   By the way, we will probably also add the milestones of the current phase to GitHub where everyone can take a more dynamic look at them.
   ICO / Funding
6. You mentioned “Lisk Fund” in the Roadmap to secure funding of Lisk after the ICO funds are spent. I think this is a great way how delegates can use some parts of their income to support Lisk. Do you already have an idea how and when this Lisk Fund will come to life? (cc001)
   Yes, I have it pretty much in my mind. I just need to write the blog post and create the Lisk account. It will definitely come before the forging rewards are starting.
   Basically, it’s simple. The Lisk Fund will accept any donation and contribution from any individual, i.e. normal users, developers, or delegates. There are a few more factors which play into that, but that’s it already. The Lisk Fund will then be used once the decentralised voting/proposal system is implemented in the last phase.
7. Has Lisk formed an agreement with a third party investor in return for capital investment? (LSK)
   No.
8. Have the founders agreed to the future sale of their tokens, in part or in total, at an agreed future price? (LSK)
   No. We are not even thinking about the possibility of selling right now.
   Team/Developers/Advisors
9. How is the process of acquiring new devs/team-members going? Any updates/progress? (cc001)
   We receive several applications every week. I have begun sorting them out and contacting individuals. Everyone who sent an application will receive an email from me. Oliver and I made the decision to carefully hire developers, else it means even more work for us. We also have to check several things in regard to hiring; legal, accounting, medical insurance, etc.
10. When will you hire the first new team member? (grumlin)
    Within 1–2 months, can’t give a certain date.
    Node running
11. If also nodes >101 help to support/stabilize the network somehow, are there plans to incentive users to run nodes even if they don’t want to be delegates? A similar question is asked in the bitcoin community, how to encourage users to run “full nodes”? (cc001)
    Currently, we don’t have any plans to incentivise users to run a full node without being a delegate. I estimate that with the mainnet delegates and all those sidechain delegates which are all also full nodes on the main network, we have a good chance to get far more full nodes than any other cryptocurrency long-term.
    Legal
12. How is the formation of the gGmbH going? Any updates/progress? (cc001)
    According to our lawyer the finance office (“Finanzamt”) needs to accept our gGmbH application by now. We had to make many revisions to our charter during the past weeks, and we may still need to do one or two. Once they and we are entirely happy, we will officially register it. Next week however, we will get a part of the funds (around $100,000) so that we can start to hire more people, a new PR agency, rent a second office room, and so on. The funds will be sufficient for 2–3 months easily.
13. Do the delegates have any legal obligation? Particularly meaning if they are connected to the apps they fund. If not, this should be clarified in the formation papers of the gGmbH. (liskyjet)
    A delegate definitely has a legal obligation. You can’t fund a single-purpose terrorism-tailored blockchain application and not come out of it without any responsibilities. However, I strongly think that mainnet delegates won’t have any legal obligation because of all the different apps which are registered on the Lisk network. Securing single sidechains is another story, those sidechain delegates who are securing apps which are illegal in their country might need to face legal prosecution.
    However, this whole area is so new that there is most probably not a case on this yet. Additionally, I’m not a lawyer so don’t take this as legal advice.
    Other
14. Will you start and support a faucet on mainnet for new users? If yes, when will it start? (grumli)
    Our faucet was gamed badly before launch and an individual withdrew a lot of testnet LSK from it. That means we will likely not put a faucet online anymore. We might introduce a tool in the future to “validate” your Lisk account, so that it gets a public key.
15. What will you do with 4m lisk bounties in near time? (grumlin)
    We are already using the bounty fund for several smaller bounties which were promised during the ICO. Short-term, we will launch a bug bounty programme which gets the LSK from the bounty fund. However, the bounty fund is mainly intended for blockchain applications, that’s why it will be utilised much more once the App SDK is ready.
    We will soon publish the excel sheet with all the outgoing bounties. Please note, that the bounty fund follows a long-term plan and we don’t intend to empty it within a year.
16. Will applications for Lisks non profit and documentation be made public so other projects can use it? (mike)
    Are you talking about applications by possible employees and internal documentation? If yes, applications will definitely not be made public. Internal documentation will be made public to a certain extend. For example; we are going to publish transparency reports every month and at the end of the financial year we will then publish the internal papers for that.
17. Any further comments about the address collision and how to fix/prevent it? (cc001)
    In this case I make an exception and will answer the technical question.
    Oliver is working extremely hard in order to get the code base to a higher standard, you can see how much he changed this week alone. He added static code analysis and corrected thousands of smaller things to make the code lint-free. Two days ago, he refactored large parts of the code, separating many different logic parts into single, individual files. He also constantly improved and expanded the test coverage so that we will have a full test suite in place in the future. These efforts will help us dramatically to find bugs, add new features, and maintain the code.
    We will fix the address collision problem in two steps. To explain the problem; Lisk addresses are 8 byte big, while a Lisk public key is 32 byte big. That means there naturally are far more public keys in existence than addresses, that’s why it can happen that different public keys point to the same address. Theoretically that can also happen in Bitcoin, because AFAIK Bitcoin addresses are 24 byte. However, I think that this never happened before. At Nxt it already happened and is not a huge deal.
    The first step involves the following; once someone initiates a transaction from the address, the public key is permanently being added to it. That means no one else, even with the same address (but different public/private key) can send funds from it. Cold wallets will not be entirely secure anymore in this case, even though an address collision is extremely rare.
    The second step is a special transaction type, which will send LSK with a public key. This way someone can create a cold wallet and initialise it from the outside with a public key to make it entirely secure.
    I will add all follow-up questions here.
    That’s it! These were seriously a lot of question again!
    Thank you very much!
    Kind regards,
    Max Kordek