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

Technical Meeting - September 10th, 2016

Wed Nov 16, 2016 12:22 pm

Outlined is a summary of the technical meeting.

Welcome everyone to the second 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

Is the plan now to have releases go to the testnet first and then the mainnet or will the next release (0.3.4) be pushed directly to the mainnet? If it’s going to the mainnet, when might the plan be to start using the testnet for testing new releases? (I know 0.3.3 was a special situation with the hot fix :) ) (MrV)

Oliver: Yes, the plan is to release first onto the testnet. However, in the case of where a hot fix needs to applied, we will sometimes release immediately to the mainnet, but only under special circumstances.
Max: I don’t have much knowledge about the test network, however I believe we are already following the test network first approach since a few versions (beside the hot fixes). Last week I have started planning our bug bounty programme and a large part of it will involve the test network.

How will users get protected of malicious blockchain apps running on Sidechains or mainchain? The same goes for delegates securing sidechains. Will their nodes be protected somehow from getting compromised? (distro)

Max: First of all, blockchain applications will never run on the mainchain, only on sidechains. In the future we will implement a sandboxing mechanism in order to secure nodes, delegates, and users from running blockchain applications. That means every blockchain application will run in its own encapsulated environment and can’t get outside of that, i.e. causing harm to the system or stealing data.

Adding a sandbox will be one of the major efforts to make the Lisk App SDK ready for blockchain application development. More information about sandboxing can be found here
Node running
How important are nodes >101? Are they helping to stabilize the network in any way, when they are >101? What exactly are they doing? (punkrock)

Oliver: The nodes in operation other than the active 101 delegates, keep the same decentralized ledger of accounts, transactions and blocks. They help relay new unconfirmed transactions, and process new blocks like the delegates themselves. The key difference being they don’t sign any blocks themselves, but instead, verify the integrity of the chain only. Therefore they still serve an important role in decentralizing the data on the chain.

Follow-up: If nodes >101 aren’t useful, is it best to not have too many since all they are doing is adding another node where everything has to propagate to? (I thought I had read that they just add extra work for the network) (MrV)

Oliver: It is important to have as many nodes as possible, as they help to distribute the dataset that makes up the blockchain. In a scenario where the entire 101 active delegates are under attack, then maybe block generation would either slow down or come to a halt, but access to the blockchain by new or existing nodes would still remain intact. There is an issue with blockchain propagation efficiency as the network scales, but there are always ways we can improve this efficiency.

How and when is the order of the forging delegates determined? Randomly at the beginning of every new round? How is the node determined that replaces a node that misses his block? This replacing node can forge two blocks in this round. Is it possible that this process is not completely random but some forging nodes get more “additional blocks” than others? (cc001)

Oliver: Lisk gets a list of all 101 delegates sorted by vote (remember, vote changes are applied at the end of a round). Lisk then determines an order of delegates based on an initial seed, a sha256 hash of the current round. Lisk determines a slot number according to the current block time, and selects the delegate public key from the previously generated delegates list. Therefore, although it appears that it is done randomly, the list is generated in a way which can be determined by all nodes in unison, providing their memory tables are in consensus.

If a delegate misses a block, then the assigned slot is skipped, which will delay block generation until the next available delegate reaches their slot.

Is there any danger to rebuild a node from a database that has been dumped some minutes ago on the same node (without verifying it)? If yes, what is the nature of the danger? And who/what is at risk, the node? The network? Other? (liberspirita)

Oliver: Yes there is the danger of using corrupt memory tables, which can lead to a break in consensus on votes specifically. There is an issue on GitHub due to be closed in the next release cycles, which will finally resolve this problem, by wrapping the transaction application logic within an atomic database transaction. This should make it a lot safer, but a full blockchain verify will still be the best practice.

Would it be possible and do you think it would be a nice feature to add “hierarchical deterministic wallet structures, bip 32” to Lisk. Meaning, to have the possibility to have unlimited addresses linked to a root key pair and not only one address per account (seanpaul/Tectract/cc001)

Max: I agree that on a technical and security aspect HD wallets have big advantages for users. However, to implement HD wallets into Lisk would be a major effort because the whole system is not laid out for that as Lisk is using a single passphrase system. That means currently our focus is not on that but rather implementing other, more important, features.

On another note; if we are going to implement HD wallets in the future then it would be a feature only for advanced users. We want to keep the system and the clients extremely easy in order to attract mainstream users in 2017. I know that there are HD wallets out there who are already quite simple, but we want to become far more simple than anything currently out there.

The quotation is taken from the official blog of Dan Larimer. His thoughts about Smart Contract Scripting Languages. Can you comment it? (vi1son)
From what I can tell about Lisk and it’s reliance on Javascript, it is not suitable for running untrusted code on a public blockchain in the same way Ethereum is. Lisk is targeting a different market. When I first heard of lisk I was excited because I thought they found a deterministic Javascript interpreter with sandboxing and computation metering; I was wrong.

Max: Dan thought that Lisk is a smart contract platform, which it isn’t. I agree with him that JavaScript is not suitable for smart contracts (what he means with “running untrusted code on a public blockchain”) out of the box. He just misunderstood the Lisk vision, didn’t know what Lisk is, while using his blog post (which contained many valid criticisms about Lisk!) in order to use the Lisk hype for his own, new cryptocurrency STEEM.

If you check out our roadmap you will see that we are going to implement our own smart contract system during Expansion. We might continue the work being done by Mark Miller (and others) and check if it’s possible to implement JavaScript smart contracts. If at that time Solidity became the omnipotent standard within the smart contract industry we might just port over the EVM to Lisk. As we don’t want that developers need to study yet another language (or special rules) for smart contracts.

Technical Meeting Transcript

Hello @all to the second technical community meeting! With us today is @joel, @isabella, and @oliver . Thank you everyone for submitting questions and for participating in the meeting now. I see we currently have over 60 people here. More will definitely come during the meeting. This time we received fewer questions than the last time, I suspect everyone is waiting for the next update and activation of community forging; maybe also because of our constant communication many questions are already answered. :)

In terms of development Oliver worked extremely hard in the past weeks for our next release. As you can read in our first weekly summary he did major changes to the underlying structure of the code.


The latest changes towards the structure were being done due to criticism on various social media channels. Even though it was planned (already before the criticism) for a later release (1–2 updates further down the road), we decided to implement them for the next update already. I’m mainly speaking about ES5 standardisation, refactoring, and static code analysis. This delayed the test network release for a week, because there was also a need to fix the address collision to be fixed. However, the next update will come within the next few days to the test network. So that everyone can start tinkering around with it. In that regard I want to remind everyone about our latest change of our versioning scheme. We will release a blog post about that next week which explains it in more detail. You can read all about it here: In principle it means, that we are no longer limiting ourselves to fixed versions for new updates. We are using a proper scheme which is connected to back end changes; i.e. if they are backwards compatible, incompatible, add new functionalities, and so on.

This way we can remain agile and flexible, if there is a need for a hot fix.

I’m repeating that (we explained it in the past technical meeting) because the next test network release will be named 0.4.0. In the past we explained that community forging will be activated with that version. However, due to the semantic versioning we have to name the next update like that due to added functionalities in the back end.

To keep an eye on community forging, we have the milestone on GitHub.

Additionally, I want to say that we are now seeking help with a reputable recruitment agency in order to find developers more quickly. While this might cost more in the beginning, it will allow us to move on faster with hiring (finally).

We will announce more about that once we can do so.

Okay, that’s it already from my side! Now you can ask any technical question. If you already asked one above, please copy/paste it again here, so that we can add it to the transcript.

Thank you! :)

Carolina: I believe the question about smart contract like features in Lisk is interesting and essentially important, and as much the article linked. I hope this can be more elaborated in the near future.
Oliver: Smart contract support is slated for the Expansion phase. So yes this part will be elaborated on more later.

Staticinstance: es6?
Oliver: Yes absolutely. But first, we needed to normalise the existing code base. We are also going to continue the practice of test driven development, so that when we make major changes we have an excellent test suite to go against.

Staticinstance: makes sense, what testing framework is being used / considered?
Oliver: Mocha, Chai is being used.

Hmachado: Max, i was on vacation so maybe this was already discussed, but are you now planning to support IPV6? It should be supported if we are pointing to the IoT market.
Max: Since you are directing the question to me I will answer. (Please note that there are more intelligent people present here than me, looking to @isabella and @oliver).

I think IPv6 is a necessity for the future. So we will definitely add support for it at one point. With more and more connected devices in the world, especially with the upcoming IoT revolution IPv4 addresses will hit their limits, as probably everyone here in this channel knows.

Tharude: IPv6 is a must for the future! IoT requires it!

Oliver: I agree IPv6 is must, we will support it. Not sure when yet though.

Max: Btw. @hmachado we gonna go to the websummit, let’s meet.

Hmachado: Great @max ! Is anyone else also attending or you coming alone?
Oliver: I will be also attending websummit.

Max: Oliver will definitely come along. Still need to talk with Joel/Isabella about it, because of the visa. Because it’s such a huge event, everyone from the team can come with us. Would be cool.

Ntelo: @hmachado: @max please tell me i will join you i would love to know you

Max: We just did. If you want to meet there, contact me here on Lisk Chat.

LSK: why not have a #jobs channel on here?
Max: In the chat? We have it on our forums and I think it’s more suitable there. Looking for employees or offering one’s own skill-sets is an ongoing process. So a dynamic platform like a chat is not the best for that.

wannabe_RoteBaron: how do you plan to fix the
Oliver: There is some work towards this issue in the upcoming testnet release, therefore we might close this issue, pending further tests. However, there are certainly more things we can do to prevent the single nodejs process from being over-consumed with work, once example would be to clusterize the application into several child processes.

Tharude: Is the Lisk code ready to accept the newly announced sidechain adopters?
Max: Which newly announced sidechain adopters?
Tharude: Those from ETH as example @max Shift

Wobit: is there any plans for a Lisk mixer?
Max: Not from our side as mixer’s are in a gray area. Personally, I hope that someone will implement it in a sidechain as the deposit/withdrawal process to/from sidechains is perfect for that!

Cc001: more generally, are there plans to implement optional privacy/anonymity features?
Max: No, we want to build a public platform. The mainchain just acts as a transmission layer towards the sidechains. With integrated privacy features we would
1. complicate many processes going on internally and on the front end
2. we would become an “anon-coin” which comes with side effects (see Dash and Apple’s App Store)
3. make everything more complicated for users, or at least less clear
This doesn’t exclude privacy sidechains at all though.

Staticinstance: What is the timeline for releasing a contribution guide for developers?
Oliver: We will look to do it as soon as possible. A contribution guide would certainly help a lot to encourage more external input from other developers.

wannabe_RoteBaron: do you have also plans to make lisk aware of distributed nodejs clusters?
Oliver: Please elaborate what you mean by distributed nodejs cluster?

Slasheks: To which extent will there be intervention from the team on side chains if say for example, one is created as a torrent tracker?
Isabella: we would not have any control over the side chains activity.
Max: Because we are somewhat responsible for the UI and client, we might hide blockchain applications from the app directory. However, they will remain fully operational and functional. However, this would only be a temporary solution. Long-term we are integrating various governance tools and I think it’s right to say that delegates should be the ones who are controlling which apps are allowed and which aren’t.

LSK: when do you expect the first independent applications to be running live on the network?
Max: Q1 2017, but it’s just an estimate.

wannabe_RoteBaron: any plans to run the bug-hunting program in the future?
Max: Yes, definitely. I’m already working on it sporadically over the past 10 days. And it will be announced in the upcoming week.

Slasheks: To expand on @wannabe_RoteBaron ‘s question. Will the rewards, if available, be hosted and accept donations from the community?
Max: Do you mean if community members can contribute to the bug hunting bounties?

Slasheks: Yes @max I think if there is a bug bounty fund it should accept donations from anyone in addition to whatever is collected. This in addition to independent research/funds.
Max: Yes, there will be a bug bounty fund and anyone can send LSK to it. No problem at all, if people want to financially help they get the opportunity to do so. Independent research and funds, should be managed independently. Not by our team else it’s not independent anymore. I hope we will see some efforts in that regard in the future.

Slasheks: So if there is hosting of less than reputable content, nothing will be done? Like blocking of access to the main chain for example? Or even something as simple as publicly denouncing the behavior?
1. hide very bad apps from the app store in a temporary, centralised way (short-term only!)
2. possibly hide apps in a completely decentralised way long-term (decided by delegates)
3. Publicly denouncing is definitely something we will do if it becomes necessary.

Redsn0w: What about the testnet ‘bounties’ ?
Grumlin: What about cc001 initiative?(about testnet rewards)

Joel: A lot of thought has been given on how to appropiately reward loyal and committed testnet participants. We’re still ironing out the details, and have yet to finalize any testnet bounties.

LSK: who decides what is and is not reputable? however, what if illegal?
Max: In the very beginning, we do. But not what is reputable. Only what is broken and what is illegal world-wide. (e.g. child porn). This is not a perfect solution of course, but later we will do it much better in a decentralised way.

Tharude: Is there a plan for QA for the sidechain apps before they hit the sidechain? (Apple style)
Max: We want to stay open and public. An on-boarding process might be implemented (if we see in the future it is necessary) in a decentralised way, where people get rewarded for controlling apps. But generally, I’m against that, as it creates uncertainty for app developers.

LSK: is the jurisdiction for a Lisk sidechain Germany, or the country of the sidechain’s author?
Max: Probably: sidechain author + all sidechain delegates. This is no legal advice, I’m not a lawyer.

Tharude: How would you filter the child porn?
Max: With updates and a blacklist, but again only as a temporary solution.

LSK: i just want to make sure that these issues are being thought through and that Lisk does not expose itself to legal difficulties.
Joel: It’s something to think about, yeah. But most importantly is having the platform ready, so that it can actually support such applications.
Joel: There are various ways one can look at this, such as creating a community focused group to approve or disprove unreputable applications.
Joel: I’m sure there are other options, but it’s something to think about once sidechains are here.
Max: Okay, as you see I didn’t get involved into this discussion as we can only speculate. Once further along the stage we will do the necessary legal research.
Max: We will put more effort and thought into that, once we are further in the stage.

I think that’s it for today! Thank you everyone for participating in today’s meeting. I hope that some topics became more clear. We will update the blog post as soon as possible.
Joel, Community Manager

Return to “Community Meetings”

Who is online

Users browsing this forum: No registered users and 1 guest