Arbeitsplan. Apirone.

Thanks to all who submitted questions for Shiv Malik in the GAINS AMA yesterday, it was great to see so much interest in Data Unions! You can read the full transcript here:

Thanks to all who submitted questions for Shiv Malik in the GAINS AMA yesterday, it was great to see so much interest in Data Unions! You can read the full transcript here:

Gains x Streamr AMA Recap

https://preview.redd.it/o74jlxia8im51.png?width=1236&format=png&auto=webp&s=93eb37a3c9ed31dc3bf31c91295c6ee32e1582be
Thanks to everyone in our community who attended the GAINS AMA yesterday with, Shiv Malik. We were excited to see that so many people attended and gladly overwhelmed by the amount of questions we got from you on Twitter and Telegram. We decided to do a little recap of the session for anyone who missed it, and to archive some points we haven’t previously discussed with our community. Happy reading and thanks to Alexandre and Henry for having us on their channel!
What is the project about in a few simple sentences?
At Streamr we are building a real-time network for tomorrow’s data economy. It’s a decentralized, peer-to-peer network which we are hoping will one day replace centralized message brokers like Amazon’s AWS services. On top of that one of the things I’m most excited about are Data Unions. With Data Unions anyone can join the data economy and start monetizing the data they already produce. Streamr’s Data Union framework provides a really easy way for devs to start building their own data unions and can also be easily integrated into any existing apps.
Okay, sounds interesting. Do you have a concrete example you could give us to make it easier to understand?
The best example of a Data Union is the first one that has been built out of our stack. It's called Swash and it's a browser plugin.
You can download it here: http://swashapp.io/
And basically it helps you monetize the data you already generate (day in day out) as you browse the web. It's the sort of data that Google already knows about you. But this way, with Swash, you can actually monetize it yourself. The more people that join the union, the more powerful it becomes and the greater the rewards are for everyone as the data product sells to potential buyers.
Very interesting. What stage is the project/product at? It's live, right?
Yes. It's live. And the Data Union framework is in public beta. The Network is on course to be fully decentralized at some point next year.
How much can a regular person browsing the Internet expect to make for example?
So that's a great question. The answer is no one quite knows yet. We do know that this sort of data (consumer insights) is worth hundreds of millions and really isn't available in high quality. So With a union of a few million people, everyone could be getting 20-50 dollars a year. But it'll take a few years at least to realise that growth. Of course Swash is just one data union amongst many possible others (which are now starting to get built out on our platform!)
With Swash, I believe they now have 3,000 members. They need to get to 50,000 before they become really viable but they are yet to do any marketing. So all that is organic growth.
I assume the data is anonymized btw?
Yes. And there in fact a few privacy protecting tools Swash supplys to its users.
How does Swash compare to Brave?
So Brave really is about consent for people's attention and getting paid for that. They don't sell your data as such.
Swash can of course be a plugin with Brave and therefore you can make passive income browsing the internet. Whilst also then consenting to advertising if you so want to earn BAT.
Of course it's Streamr that is powering Swash. And we're looking at powering other DUs - say for example mobile applications.
The holy grail might be having already existing apps and platforms out there, integrating DU tech into their apps so people can consent (or not) to having their data sold - and then getting a cut of that revenue when it does sell.
The other thing to recognise is that the big tech companies monopolise data on a vast scale - data that we of course produce for them. That is stifling innovation.
Take for example a competitor map app. To effectively compete with Google maps or Waze, they need millions of users feeding real time data into it.
Without that - it's like Google maps used to be - static and a bit useless.
Right, so how do you convince these big tech companies that are producing these big apps to integrate with Streamr? Does it mean they wouldn't be able to monetize data as well on their end if it becomes more available through an aggregation of individuals?
If a map application does manage to scale to that level then inevitably Google buys them out - that's what happened with Waze.
But if you have a data union which bundles together the raw location data of millions of people then any application builder can come along and license that data for their app. This encourages all sorts of innovation and breaks the monopoly.
We're currently having conversations with Mobile Network operators to see if they want to pilot this new approach to data monetization. And that's what even more exciting. Just be explicit with users - do you want to sell your data? Okay, if yes, then which data point do you want to sell.
Then the mobile network operator (like T-mobile for example) then organises the sale of the data of those who consent and everyone gets a cut.
Streamr - in this example provides the backend to port and bundle the data, and also the token and payment rail for the payments.
So for big companies (mobile operators in this case), it's less logistics, handing over the implementation to you, and simply taking a cut?
It's a vision that we'll be able to talk more about more concretely in a few weeks time 😁
Compared to having to make sense of that data themselves (in the past) and selling it themselves
Sort of.
We provide the backened to port the data and the template smart contracts to distribute the payments.
They get to focus on finding buyers for the data and ensuring that the data that is being collected from the app is the kind of data that is valuable and useful to the world.
(Through our sister company TX, we also help build out the applications for them and ensure a smooth integration).
The other thing to add is that the reason why this vision is working, is that the current data economy is under attack. Not just from privacy laws such as GDPR, but also from Google shutting down cookies, bidstream data being investigated by the FTC (for example) and Apple making changes to IoS14 to make third party data sharing more explicit for users.
All this means that the only real places for thousands of multinationals to buy the sort of consumer insights they need to ensure good business decisions will be owned by Google/FB etc, or from SDKs or through this method - from overt, rich, consent from the consumer in return for a cut of the earnings.
A couple of questions to get a better feel about Streamr as a whole now and where it came from. How many people are in the team? For how long have you been working on Streamr?
We are around 35 people with one office in Zug, Switzerland and another one in Helsinki. But there are team members all over the globe, we’ve people in the US, Spain, the UK, Germany, Poland, Australia and Singapore. I joined Streamr back in 2017 during the ICO craze (but not for that reason!)
And did you raise funds so far? If so, how did you handle them? Are you planning to do any future raises?
We did an ICO back in Sept/Oct 2017 in which we raised around 30 Millions CHF. The funds give us enough runway for around five/six years to finalize our roadmap. We’ve also simultaneously opened up a sister company consultancy business, TX which helps enterprise clients implementing the Streamr stack. We've got no more plans to raise more!
What is the token use case? How did you make sure it captures the value of the ecosystem you're building
The token is used for payments on the Marketplace (such as for Data Union products for example) also for the broker nodes in the Network. ( we haven't talked much about the P2P network but it's our project's secret sauce).
The broker nodes will be paid in DATAcoin for providing bandwidth. We are currently working together with Blockscience on our tokeneconomics. We’ve just started the second phase in their consultancy process and will be soon able to share more on the Streamr Network’s tokeneconoimcs.
But if you want to summate the Network in a sentence or two - imagine the Bittorrent network being run by nodes who get paid to do so. Except that instead of passing around static files, it's realtime data streams.
That of course means it's really well suited for the IoT economy.
Well, let's continue with questions from Twitter and this one comes at the perfect time. Can Streamr Network be used to transfer data from IOT devices? Is the network bandwidth sufficient? How is it possible to monetize the received data from a huge number of IOT devices? From u/ EgorCypto
Yes, IoT devices are a perfect use case for the Network. When it comes to the network’s bandwidth and speed - the Streamr team just recently did extensive research to find out how well the network scales.
The result was that it is on par with centralized solutions. We ran experiments with network sizes between 32 to 2048 nodes and in the largest network of 2048 nodes, 99% of deliveries happened within 362 ms globally.
To put these results in context, PubNub, a centralized message brokering service, promises to deliver messages within 250 ms — and that’s a centralized service! So we're super happy with those results.
Here's a link to the paper:
https://medium.com/streamrblog/streamr-network-performance-and-scalability-whitepaper-adb461edd002
While we're on the technical side, second question from Twitter: Can you be sure that valuable data is safe and not shared with service providers? Are you using any encryption methods? From u/ CryptoMatvey
Yes, the messages in the Network are encrypted. Currently all nodes are still run by the Streamr team. This will change in the Brubeck release - our last milestone on the roadmap - when end-to-end encryption is added. This release adds end-to-end encryption and automatic key exchange mechanisms, ensuring that node operators can not access any confidential data.
If BTW - you want to get very technical the encryption algorithms we are using are: AES (AES-256-CTR) for encryption of data payloads, RSA (PKCS #1) for securely exchanging the AES keys and ECDSA (secp256k1) for data signing (same as Bitcoin and Ethereum).
Last question from Twitter, less technical now :) In their AMA ad, they say that Streamr has three unions, Swash, Tracey and MyDiem. Why does Tracey help fisherfolk in the Philippines monetize their catch data? Do they only work with this country or do they plan to expand? From u/ alej_pacedo
So yes, Tracey is one of the first Data Unions on top of the Streamr stack. Currently we are working together with the WWF-Philippines and the UnionBank of the Philippines on doing a first pilot with local fishing communities in the Philippines.
WWF is interested in the catch data to protect wildlife and make sure that no overfishing happens. And at the same time the fisherfolk are incentivized to record their catch data by being able to access micro loans from banks, which in turn helps them make their business more profitable.
So far, we have lots of interest from other places in South East Asia which would like to use Tracey, too. In fact TX have already had explicit interest in building out the use cases in other countries and not just for sea-food tracking, but also for many other agricultural products.
(I think they had a call this week about a use case involving cows 😂)
I recall late last year, that the Streamr Data Union framework was launched into private beta, now public beta was recently released. What are the differences? Any added new features? By u/ Idee02
The main difference will be that the DU 2.0 release will be more reliable and also more transparent since the sidechain we are using for micropayments is also now based on blockchain consensus (PoA).
Are there plans in the pipeline for Streamr to focus on the consumer-facing products themselves or will the emphasis be on the further development of the underlying engine?by u/ Andromedamin
We're all about what's under the hood. We want third party devs to take on the challenge of building the consumer facing apps. We know it would be foolish to try and do it all!
As a project how do you consider the progress of the project to fully developed (in % of progress plz) by u/ Hash2T
We're about 60% through I reckon!
What tools does Streamr offer developers so that they can create their own DApps and monetize data?What is Streamr Architecture? How do the Ethereum blockchain and the Streamr network and Streamr Core applications interact? By u/ CryptoDurden
We'll be releasing the Data UNion framework in a few weeks from now and I think DApp builders will be impressed with what they find.
We all know that Blockchain has many disadvantages as well,
So why did Streamr choose blockchain as a combination for its technology?
What's your plan to merge Blockchain with your technologies to make it safer and more convenient for your users? By u/ noonecanstopme
So we're not a blockchain ourselves - that's important to note. The P2P network only uses BC tech for the payments. Why on earth for example would you want to store every single piece of info on a blockchain. You should only store what you want to store. And that should probably happen off chain.
So we think we got the mix right there.
What were the requirements needed for node setup ? by u/ John097
Good q - we're still working on that but those specs will be out in the next release.
How does the STREAMR team ensure good data is entered into the blockchain by participants? By u/ kartika84
Another great Q there! From the product buying end, this will be done by reputation. But ensuring the quality of the data as it passes through the network - if that is what you also mean - is all about getting the architecture right. In a decentralised network, that's not easy as data points in streams have to arrive in the right order. It's one of the biggest challenges but we think we're solving it in a really decentralised way.
What are the requirements for integrating applications with Data Union? What role does the DATA token play in this case? By u/ JP_Morgan_Chase
There are no specific requirements as such, just that your application needs to generate some kind of real-time data. Data Union members and administrators are both paid in DATA by data buyers coming from the Streamr marketplace.
Regarding security and legality, how does STREAMR guarantee that the data uploaded by a given user belongs to him and he can monetize and capitalize on it? By u/ kherrera22
So that's a sort of million dollar question for anyone involved in a digital industry. Within our system there are ways of ensuring that but in the end the negotiation of data licensing will still, in many ways be done human to human and via legal licenses rather than smart contracts. at least when it comes to sizeable data products. There are more answers to this but it's a long one!
Okay thank you all for all of those!
The AMA took place in the GAINS Telegram group 10/09/20. Answers by Shiv Malik.
submitted by thamilton5 to streamr [link] [comments]

Bottos 2020 Research and Development Scheme

Bottos 2020 Research and Development Scheme

https://preview.redd.it/umh8ivbsua841.png?width=554&format=png&auto=webp&s=5c16d9d9e61503e4c9d44212eecd176eda11550a
As 2020 is now here, Bottos has solemnly released its “2020 Research and development scheme”. On one hand, we adhere to the principle of transparency so that the whole community can comprehend our next step as a whole, but more importantly, it also helps our whole team to think deeply about the future and reach consensus. It is strongly believed that following these consistent follow-ups will help us to in order to achieve the best results.
Based on the efficient development of Bottos, the team’s technical achievements in consensus algorithms and smart contracts are used to deeply implement and optimize the existing technical architecture. At the same time using the community’s technical capabilities, horizontal development, expanding new functional modules and technical directions it stays closely integrated with the whole community.
In the future, we will keep on striving to achieve in-depth thinking, comprehensive planning, and flexible adjustment.


Overview of Technical Routes

https://preview.redd.it/rk9tpg2uua841.png?width=554&format=png&auto=webp&s=77e607b81f31c0d20feaa90eca81f09a23addca4
User feedback within the community is the driving force behind Bottos progress. In the development route of the community and industry we have formulated a roadmap for technical development, pointing out the right path for the team towards the right direction among the massive routes of modern technology.
As part of our 2020 research and development objective we have the following arrangements:
1. Intensifying enormous number of smart contracts and related infrastructures
After many years of development, smart contracts have gradually become the core and standard function in blockchain projects. The strength of smart contracts, ease of use, and stability represent the key capabilities of a blockchain project. As a good start, Bottos has already made great progress in the field of smart contracts. In smart contracts we still need to increase development efforts, making the ease of use and stability of smart contracts the top priority of our future development.
Reducing the barriers for developers and ordinary users to use, shortening the contract development cycle and saving users time is another important task for the team to accomplish. To this end, we have planned an efficient and easy-to-use one-stop contract development, debugging, and deployment tool that will provide multiple access methods and interfaces to the test network to support rapid deployment and rapid debugging.
2. Establishing an excellent client and user portal
The main goal here is to add an entrance point to the creation and deployment of smart contracts in the wallet client. To this end, the wallet needs to be transformed, a local compiler for smart contracts must be added, and an easy-to-use UI interface can be provided for the purpose of creating, deploying, and managing contracts to meet the needs of users with a single mouse click only.
3. Expanding distributed storage
Distributed storage is another focus of our development in the upcoming year. Only by using a distributed architecture can completely solve the issue of performance and scalability of stand-alone storage. Distributed storage suitable for blockchain needs to provide no less than single machine performance, extremely high availability, no single point of failure, easy expansion, and strong consistent transactions. These are the main key points and difficulties of Bottos in field of distributed storage in the upcoming days.
4. Reinforcing multi party secured computing
Privacy in computing is also a very important branch to deal with. In this research direction, Bottos has invested a lot of time and produced many research results on multi-party secured computing, such as technical articles and test cases. In the future, we will continue to give efforts in the direction of multi-party secured computing and apply mature technology achievements into the functions of the chain.

2020 Bottos — Product Development

Support for smart contract deployment in wallets
The built-in smart contract compiler inside the wallet supports compilation of the smart contracts in all languages provided by Bottos and integrates with the functions in the wallet. It also supports one-click deployment of the compiled contract source code in the wallet.
When compiling a contract, one can choose whether to pre-execute the contract code. If pre-execution is selected, it will connect to the remote contract pre-execution service and return the execution result to the wallet.
When deploying a contract, one can choose to deploy to the test network or main network and the corresponding account and private key of the test network or main network should be provided.

2020 Bottos-Technical Research

https://preview.redd.it/x2k65j7xua841.png?width=553&format=png&auto=webp&s=a40eae3c56b664c031b3db96f608923e670ff331
1. Intelligent smart contract development platform (BISDP)
The smart contract development platform BISDP is mainly composed of user-oriented interfaces, as well as back-end compilation and deployment tools, debugging tools, and pre-execution frameworks.
The user-oriented interface provides access methods based on WEB, PC, and mobile apps, allowing developers to quickly and easily compile and deploy contracts and provide contract template management functions. It can also manage the contract remotely by viewing the contract execution status, the consumed resources and other information.
In the compilation and deployment tool a set of smart contract source code editing, running, debugging, and deployment solutions as well as smart contract templates for common tasks are provided, which greatly reduces the threshold for developers to learn and use smart contracts. At the same time, developers and ordinary users are provided with a smart contract pre-execution framework, which can check the logical defects and security risks in smart contracts before actual deployment and promptly remind users a series of problems even before the smart contracts are actually run.
In the debugging tool, there are built-in local debugging and remote debugging tools. Multiple breakpoints can be set in the debugging tool. When the code reaches the breakpoint, one can view the variables and their contents in the current execution stack. One can also make conditional breakpoints based on the value of the variable. The code will not execute until the value reaches a preset value in memory.
In the pre-execution framework, developers can choose to pre-execute contract code in a virtual environment or a test net, checking out problems in some code that cannot be detected during compilation time and perform deeper code inspection. The pre-execution framework can also prompt the user in advance about the time and space resources required for execution.
2. Supporting Python and PHP in BVM virtual machine for writing smart contracts
We have added smart contract writing tools based on Python and PHP languages. These languages can be compiled into the corresponding BVM instruction set for implementation. These two reasons are used as the programming language for smart contracts.
For the Python language, the basic language elements supported by the first phase are:
- Logic control: If, Else, Eli, While, Break, method calls, for x in y
- Arithmetic and relational operators: ADD, SUB, MUL, DIV, ABS, LSHIFT, RSHIFT, AND, OR, XOR, MODULE, INVERT, GT, GTE, LT, LTE, EQ, NOTEQ
-
Data structure:
- Supports creation, addition, deletion, replacement, and calculation of length of list data structure
- Supports creation, append, delete, replace, and calculation of length of dict data structure
Function: Supports function definition and function calls
For the PHP language, the basic language elements supported by the first phase are :
- Logic control: If, Else, Eli, While, Break, method calls
- Arithmetic and relational operators: ADD, SUB, MUL, DIV, ABS, LSHIFT, RSHIFT, AND, OR, XOR, MODULE, INVERT, GT, GTE, LT, LTE, EQ, NOTEQ
Data structure:
- Support for creating, appending, deleting, replacing, and calculating length of associative arrays
Function: Supports the definition and calling of functions
For these two above mentioned languages, the syntax highlighting and code hinting functions are also provided in BISDP, which is very convenient for developers to debug any errors.
3. Continuous exploration of distributed storage solutions
Distributed storage in blockchain technology actually refers to a distributed database. Compared with the traditional DMBS, in addition to the ACID characteristics of the traditional DBMS, the distributed database also provides the high availability and horizontal expansion of the distributed system. The CAP principle of distributed system reveals that for a common distributed system there is an impossible triangle, only two of them can be selected among its three directions, consistency, availability, and partition fault tolerance. Distributed databases in China must require strong consistency. This is due to the characteristics of the blockchain system itself, because it needs to provide reliable distributed transaction capabilities. For these technical issues, before ensuring that the distributed storage solution reaches 100% availability, we will continue to invest more time and technical strength, do more functional and performance testing, and conduct targeted tests for distributed storage systems.
4. Boosting secured multi-party computing research and development
Secured multi-party Computing (MPC) is a cryptographic mechanism that enables multiple entities to share data while protecting the confidentiality of the data without exposing the secret encryption key. Its performance indicators, such as security and reliability are important for the realization of the blockchain. The transparent sharing of the data privacy on the distributed ledger and the privacy protection of the client wallet’s private key are truly essential.
At present, the research and development status of the platform provided by Bottos in terms of privacy-enhanced secured multi-party computing is based on the BIP32 / 44 standard in Bitcoin wallets to implement distributed management of client wallet keys and privacy protection.
Considering the higher level of data security and the distributed blockchain account as the public data of each node, further research and development are being planned on:
(1) Based on RSA, Pailliar, ECDSA and other public key cryptosystems with homomorphic attributes, as well as the GC protocol, OT protocol, and ZKP protocol to generate and verify transaction signatures between two parties;
(2) Introduce the international mainstream public key system with higher security and performance, national secret public key encryption system, and fewer or non-interactive ZKP protocols to achieve secured multi-party computing with more than two parties, allowing more nodes to participate Privacy protection of ledger data.

Summary

After years of exploration, we are now full of confidence in our current research and development direction. We are totally determined to move forward by continuous hard work. In the end, all members of Bottos also want to thank all the friends in the community for their continuous support and outstanding contributions. Your certainty is our greatest comfort and strongest motivation.

Be smart. Be data-driven. Be Bottos.
If you aren’t already in our group, please join now! https://t.me/bottosofficial
Join Our Community and Stay Updated!
Bottos Website | Twitter |Facebook | Telegram | Reddit
submitted by BOTTOS_AI to Bottos [link] [comments]

The History, The Current State And The Future Of NavCoin

The History, The Current State And The Future Of NavCoin

This is it. If you're interested to see what NAV is all about, this is the ultimate guide for you. You will learn about the history of NavCoin and how it evolved. You will learn about the current state and features of NavCoin and you will learn about the exciting new features that are planned and coming up in the (near) future.
So buckle up, this is going to be a long ride!

Table Of Content


Introduction - What is NavCoin?


The History

Introduction
The following chapter will summarize and break down the history of NavCoin in a few sentences. NAV started a long time ago, went through rebrandings and changes of the core team before it became what it is today.

SummerCoin
NavCoin was initially first introduced under the name SummerCoin on April 23 in 2014. SummerCoin was a fork of the Bitcoin blockchain. It used to have a PoW/PoS hybrid algorithm with a block time of 45 seconds.

SummerCoinV2 /NavajoCoin
Soon after the initial launch of SummerCoin, the original developer left and SoopY (soopy452000 on bitcointalk) took over as the main developer and rebranded the project to SummerCoinV2 respectively NavajoCoin and introduced new features.
The name NavajoCoin was chosen in honor of the Navajo Code Talker. The unbreakable Navajo code was used to encrypt highly classified military information and commands and decrypt the same in WW II.
SoopY introduced a technology which allowed sending transactions anonymously and private. This technology was called "Navajo Anonymous Technology". SoopY also released a new wallet and set the Proof of Stake rewards at 10% for the first year, 5% for the second year and 2% for every year after.

NavCoin
On August 12, 2014, Craig (current lead core developer, pakage on bitcointalk) started to get involved with NAV by helping to set up a website [10].
It was officially announced that Craig joined the core team as a "Wallet & Web Developer" on November 06, 2014.
The last tokenswap and restart of the blockchain of NAV happened on May 12, 2016.
Soon later, SoopY stopped showing up and Craig stepped into the role of the lead core developer. Since then, Craig has assembled a strong team with which he built NavCoin into what it is today.
Currently, Craig and the NavCoin Core team is located in New Zealand and they are actively developing many ground-braking features which differentiate NAV from other cryptocurrencies. You will read more about that later in this article.

The Current State

Introduction
The year 2018 has been a thriving year for the NavCoin ecosystem. Despite the USD price of NAV not reflecting it, in 2018 the core team has developed a whole bunch of new features. Also the core content creators published the first official guidelines that function as an orientation guide for community content creators. This chapter will give you an overview of the current team, the features, the prior mentioned guidelines and the community of NavCoin.

Core Team [1]
Last year, the core team has grown alot. It contains of developers, content creators and interns. The core team are employees of Encrypt S, the New Zealand's leading blockchain R&D lab. Encrypt S is developing blockchain solutions since 2014 and values building open-source software highly.

Craig MacGregor - Chief Executive Officer
Craig is the CEO of Encrypt S and the founder of NavCoin. He is one of the world's most experienced blockchain developers. Craig founded NavCoin in 2014 and is developing software for it since then. He has assembled a strong team of like-minded people. Craig also speaks at seminars and conferenced. Some of the companies and conferences he did blockchain education sessions at are Oracle, Xero, Air New Zealand, Blok Tex and trademe. Together with the team, he is also doing a education series on YouTube where he explains upcoming features in-depth for the community.

Alex Vazquez - Chief Technical Officer
Alex is the CTO of Encrypt S and the most active contributor to the NavCoin core Github. He has incredible knowledge of blockchains and proposes and implements solutions for challenges and features. He supports community developers frequently and answers any questions of the community thoroughly. Like Craig, Alex is developing software for the NavCoin ecosystem for a very long time. Alex speaks at universities at times and educates students about the blockchain technology.

Paul Sanderson - Lead Software Engineer
Paul is the Lead Software Engineer at Encrypt S. He has a flair for technology. His technical and management skills are perfectly suited for consultancy and investment advising. He also frequently contributes to the NavCoin core source code.

Rowan Savage - Senior Software Engineer
Rowan is a full stack software engineer with more than a decade experience in developing complex front-end web applications. He joined Encrypt S in February 2018 and has since been involved in the Valence Plattform, the Kauri Wallet and NavCoin Core. You will read more about these feature/projects later.

Carter Xiao - Lead UX/UI Designer
Carter specializes in user-centric design and is also very talented with 3D animation, motion graphics and programming. One of NavCoins core principle is "Simplifying Crypto" and UX/UI is a very important part of that.

Matt Paul - Software Engineer
Like Rowan, Matt is a full stack Software Engineer. He joined the core team in Mai 2017 and has since worked on NavPay, NavPi, the Kauri Wallet and NavCoin Core. Kieren Hyland - Chief Strategy Officer Kieren is one of the employees that are working for Encrypt S for a very long time. He is the CSO and is a digital strategist and growth hacker with a passion for new technology and has a lot of experience in online marketing. Laura Harris - Creative Director Laura has a combination of commercial and creative flair. She manages the social media accounts for NavCoin and ensures, that NavCoins' message is always powerful, relevant and distinctive. John Darby - Content Creator John is an internationally awarded Technology and Financial sector marketing communications specialist. He is one of the Core Content Creators for NavCoin.

Features of NavCoin [2]
The following features are currently available and have been developed in the last months and years. It is sorted from newest to oldest.

Static Block Reward
The soft-fork for the enabling of static block rewards have been accepted and became active recently at 5th January 2019. This means, that the block reward was changed from a percentage based reward to a static reward. This will incentivize the stakers to have their node online 24/7 which increased the security of the network. It also aligns NavCoin with the PoSv3 specification. With this implementation, the yearly inflation will be 3.6% currently and will exponentionally decrease because of the static value of the rewards. Every staked block will now give the staker 2 NAV. Depending on how many people are staking, the yearly percentage varies. With the network weight currently being around 20'000'000 NAV, stakers earn around 10% rewards from staking 24/7.

Cold staking
To provide extra security to participants in the staking process in the NavCoin network, the core team decided to implement cold staking. This allows to store NAV offline and still be able to sign staking inputs. Looking forward, a possible integration into the Ledger Nano S would mean, that one can stake NAV securely from a offline hardware wallet. How cool is that?

OpenAlias
One of the core principle of NAV is to simplify cryptocurrencies. Many non-technical people are deterred from the long, cryptic addresses used in wallets. When sending funds, you have to make sure that every single letter and digit is correct which is nerve-wracking for the average person. NavCoin has implemented OpenAlias, which allows to transform the wallet address into a email-like form. Everyone can register a name like "[[email protected]](mailto:[email protected])". Funds can then be sent to this name, which makes sending crypto much easier and less error-prone.

Community Fund
This is the one big feature I was most excited about. NavCoin core has implemented the first fully decentralized community fund. Acceptance of proposals and release of funds is all approved by the decentralized network. No central authority has access to the fund. The community fund enables everyone to propose their ideas to the NavCoin community and to get paid to implement these ideas. Everyone can propose whatever they like (of course there is a higher rate of success if the proposal contributes to the NavCoin ecosystem ;-)). In fact, this article was sponsored by the NAV-Community by voting "yes" for my proposal. The fund works like this:
For a fee of 50 NAV, everyone can create and present his idea/proposal to the entire NavCoin network. The fee is here to help prevent spam attacks. Proposals can literally be anything - be it development, marketing or anything else you can some up with.
After creating the proposal, everyone contributing to the NavCoin network can then decide if they like the proposal of not. They vote with "Yes" or "No" for the acceptance of the proposal. Voting happens via staking. Every transaction that gets validated by you gives you one vote. This means that the more NAV you are staking, the higher your voting weight is.
The proposal stays in the state "Pending" until it is accepted or rejected. To be accepted, a proposal has to have a participation of at least 50% of all staked blocks and at least 75% of these votes have to be "Yes"-votes. Like-wise to be rejected a proposal need 50% participation of the network and 75% of these votes have to be "No"-votes. Additionally, if a proposal didn't pass after 6 voting cycles (about 6 weeks) it is also rejected.
After a proposal has been accepted, the creator of the proposal can start his work. When the work is finished, or at in the proposal defined checkpoints, the proposal creator can create a payment request for the full or part of the requested funds.
The NavCoin network can then again decide, if the work is what the creator promised to do and vote for the funds or reject the payment request because it was not what he promised. This mechanism ensures, that the funds are only release if the creator of the proposal did what he promised. The NavCoin network decides everything, there is no central authority which makes the community fund 100% decentralized.
The community fund is quite new but there have already been some proposals that were accepted like paying for the development & hosting of NAV block explorer, the creation and distribution of NAV car stickers to the community for free (or paid by the community fund), the funding of interns for NavCoin Core, translation of the website into other languages and YouTube videos. What ideas could you come up with? By the way: this article was also sponsored by the community fund :-)

Proof of Stake
Like said before, NavCoin uses the Proof of Stake algorithm to create and validate blocks. Participants of the NavCoin network can earn rewards by putting their coins to stake and thus validating blocks and securing the network. The reward used to be 4% fixed but recently changed with the implementation of PoSv3. Currently, rewards for stakers that are staking 24/7 is about 10% but it is dependent on how many people are staking. If more nodes come online, this reward will go down. If 90% of all NAVs would be at stake, stakers would still earn 4%.

Tutorials And Guidelines [3]
The NavCoin Core team pushes the community to contribute to the NavCoin ecosystem constantly. They emphasize that NavCoin is an open source project and everyone can contribute. The team tries to make it as easy as possible for the average person to contribute and thus created different tutorials and guidelines.

Tutorials To Contribute To The Website
The whole website is open source. Everyone can contribute to the website. The team created different guides for people to follow [4].

The NavCoin Developer Manifesto
The content creator core team has build a developer manifesto. It defines the values that should be uphold like for example that they will always operate in the best interest of the network. If defines the principles, purposes, scope of involvement and operational requirements [5].

The NavCoin Content Creation Manifesto
Similar to the developer manifesto, there is also a content creation manifesto. Again it defines the principles for creating content, the purpose, the scope of involvement and the operational requirements [6].

NavCoin Brand Guidelines
In addition to the content creation manifesto, there is also a brand guideline booklet. This should help content creators to create images, videos, articles etc. in the same style as the core team. It defines the NAV brand. The brand guidelines contain definitions, the language to use (words to use, words not to use), the tone of voice, what the community aspires to be and what we discourage to be. It also contains the logo pack which can be used in graphics etc. It describes correct logo spacing, logo placement, the colors of NAV and different web assets. It gives tips about gradients and overlays, the typefaces (with a font pack) and many more. Check it out yourself [7].

NavCoin Educational Series
The core team has decided to actively involve the community in the creation of new features. For this reason and to allow users to ask questions, they created the NavCoin Educational Series. The core team schedules an online live meetup which can be joined by everyone. On YouTube they do live-streams and explain upcoming features. Examples of these series are explanations for cold staking, static rewards (PoSv3) and the community fund. The community can ask questions live and the core team will answer them immediately.

Community
During the last year there have been an influx of software developers from the community starting to create features for NAV.

navexplorer.com
An examples is navexplorer.com which is programmed by community developer prodpeak and is a block explorer for NavCoin. Additionally, it functions as a interface to see what is going on in the community fund. It shows pending proposals and payment requests.

NEXT Wallet
The NEXT Wallet is an alternative wallet for NAV and other cryptocurrencies. It has a beautiful user interface and is additionally the easiest interface to interact with the community fund (create proposals, create payment requests and vote for proposals and payment requests). It is programmed by community developer sakdeniz who put hundreds of hours into it during last year.

There were also some marketing activities starting to emerge with the release of the community fund. Some of these were for example free stickers for everyone in the NAV community to stick to their car / shop / window etc. or YouTube videos of CryptoCandor and Cryptomoonie that explained the details of NAV. I am sure, that with the 500'000 NAV available in the community fund per year there will be an influx of gread ideas - development as well as marketing activities - that will be funded.

The Future

Introduction
These features are planned for the future. Many of the following features are part of the 2019 roadmap. Some will not be described in great detail because not much is known about them yet. I've still listed them as they are part of what is yet to come.

Features
Rimu - Improved Privacy Solution
NavCoin used to be a optional privacy coin. That means, that you could choose to send a transaction in private. NavCoin was criticized for the way it handles private payments because it relied on a few servers which didn't make it that decentralized. The technology was called "NavTech" and was a secondary blockchain that obscured the transaction and the amount that was sent. NavCoin Core is currently developing a new improved privacy solution that will make the private payment system completely trustless and districuted and runs at a protocol level. Alex of the NavCoin Core team has published a paper that describes this new privacy solution. It's called Zero Confidential Transactions and can be found here: https://www.researchgate.net/publication/330366788_ZeroCT_Improving_Zerocoin_with_Confidential_Transactions_and_more. What I want to highlight is the collaboration between Alex as the proposer of the solution and the Veil team, a Bitcoin Core developer and Moneros main cryptographer as reviewers. When the best work together, it will be interesting to see what the outcome is!

Valence Plattform [8]
Valence is an applied Blockchain platform that can help businesses realise the tangible benefits of blockchain. You can think of Valence as a platform with which you can build Anonymous Distributed Applications (aDapps) with. But Valence is a different kind of platform that enables developers to create new types of blockchain applications. The problem with current (turing complete) dApp platforms are their complexity and rigid nature. Security holes in smart contracts and scaling issues happen frequently [9].
Valence provides transitional pathways that let businesses migrate only part of their activities to the blockchain without having to restructure their entire business model [9].
Valence will provide a spectrum of blockchain application solutions which sit along the decentralized spectrum, offering businesses simple ways to dip their toes into the blockchain at minimal risk or complexity [9].
Thanks to the proof of stake nature of the Valence blockchain, more of a node's resources can be used for processing and routing application data which makes the platform faster and scalable.
Valence aims to make building blockchain applications as accessible to the general public as WordPress or Squarespace has made building websites.
The developers NavCoin and Valence aim to make Valence extremely easy to work with:
A Valence application could be an open source mobile or web application that submits unencrypted or encrypted data directly to the blockchain. The only configuration necessary for the app developer would be setting up the data structure. Once they've done that they can start writing to the blockchain immediately.
The Valence blockchain interface is language agnostic, meaning developers are free to build applications in whichever language they're familiar with, which greatly reduces the barrier to entry.
As the platform progresses, Valence will introduce more and more smart contract templates in collaboration with the development community. These will be like plugins that users can simply select and configure for their application, without having to reinvent the wheel and risk contract errors or spend countless hours of research to program them.

NavShopper
The following information is taken from the latest weekly news: NavShopper is a new project which will allow people to spend NavCoin on a growing list of retailers and service providers. NavShopper sits between traditional retailers accepting fiat and NavCoin users and purchases products on behalf of the user by managing the crypt-fiat conversion, payment and shipping. This project will unlock many more ways for people to spend NAV on existing websites/marketplaces without requiring each site to individually accept cryptocurrencies. Some of the prototypes we are working on include crediting your Uber account, buying products on Amazon and donating to charities.

Kauri Wallet
The Kauri Wallet aims to be an open-source, multi-currency wallet which functions as a foundation for other features.

Kauri Enhanced
Enhancements to the Kauri Wallet will allow multiple accounts, pin numbers, recurring payments and more.

Kauri DAEx
The Kauri DAEx is a Decentralised Atomic Exchange that utilises the features of the Kauri Wallet and enables users to create safe peer to peer atomic exchanges for any currency supported by the Kauri Wallet. NavDelta NavDelta will be a payment gateway that allows users to spend NAV at any business which accepts currencies supported by the Kauri Wallet. NavMorph NavMorph is a fusion of Rimu and Kauri DAEx and will allow to privately send every cryptocurrency supported by the Kauri Wallet.

Outro

If you have made it this far: Congratulations! You have learned about how NAV evolved, what its current state is and what the future will bring. To sum all up: NavCoin has made incredible progress during last year and released many long awaited features despite the bear market. Many more exciting features are yet to come and it's going to be very interesting to see where we will stand on this day next year.

Giveaway

Unfortunately, the giveaway was not possible in the cryptocurrency-subreddit because of their rules, so I'm doing it here :-) As a surprise, in the next 2 hours I am going to send some NAV to everyone who wants to try out the awesome features and NavPay you read about above.
To get your NAVs, all you have to do is the following:
If you liked the experience, I'd be happy to hear back from you :)

References

[1] https://encrypt-s.com/company/
[2] https://navcoin.org/en/roadmap/
[3] https://navhub.org/get-involved/
[4] https://navhub.org/how-to-guide/
[5] https://navhub.org/assets/NavCoinDeveloperManifesto.pdf
[6] https://navhub.org/assets/NavCoinContentManifesto.pdf
[7] https://navhub.org/assets/NavCoinBrandGuidelines.pdf
[8] https://valenceplatform.org/
[9] https://valenceplatform.org/learn/business-on-the-blockchain-made-easy/
[10] https://bitcointalk.org/index.php?topic=679791.msg8320228#msg8320228
submitted by crypto_sIF to NavCoin [link] [comments]

An extensive list of blockchain courses, resources and articles to help you get a job working with blockchain.

u/Maximus_no and me spent some time at work collecting and analyzing learning material for blockchain development. The list contains resources for developers, as well as business analysts/consultants looking to learn more about blockchain use-cases and solutions.

Certifications and Courses

IIB Council
Link to course: IIB council : Certified Blockchain Professional
C|BP is an In-Depth, Industry Agnostic, Hands-On Training and Certification Course specifically tailored for Industry Professionals and Developers interested in implementing emerging technologies in the Data-Driven Markets and Digitized Economies.
The IIB Council Certified Blockchain Professional (C|BP) Course was developed to help respective aspiring professionals gain excessive knowledge in Blockchain technology and its implication on businesses.
WHO IS IT FOR:

Professionals

C|BP is developed in line with the latest industry trends to help current and aspiring Professionals evolve in their career by implementing the latest knowledge in blockchain technology. This course will help professionals understand the foundation of Blockchain technology and the opportunities this emerging technology is offering.

Developers

If you are a Developer and you are willing to learn blockchain technology this course is for you. You will learn to build and model Blockchain solutions and Blockchain-based applications for enterprises and businesses in multiple Blockchain Technologies.

Certified Blockchain Business Foundations (CBBF)

This exam is designed for non-technical business professionals who require basic knowledge about Blockchain and how it will be executed within an organization. This exam is NOT appropriate for technology professionals seeking to gain deeper understanding of Blockchain technology implementation or programming.

A person who holds this certification demonstrates their knowledge of:

· What is Blockchain? (What exactly is it?)
· Non-Technical Technology Overview (How does it work?)
· Benefits of Blockchain (Why should anyone consider this?)
· Use Cases (Where and for what apps is it appropriate?)
· Adoption (Who is using it and for what?)
· Future of Blockchain (What is the future?)

Certified Blockchain Solution Architect (CBSA)

A person who holds this certification demonstrates their ability to:

· Architect blockchain solutions
· Work effectively with blockchain engineers and technical leaders
· Choose appropriate blockchain systems for various use cases
· Work effectively with both public and permissioned blockchain systems

This exam will prove that a student completely understands:

· The difference between proof of work, proof of stake, and other proof systems and why they exist
· Why cryptocurrency is needed on certain types of blockchains
· The difference between public, private, and permissioned blockchains
· How blocks are written to the blockchain
· Where cryptography fits into blockchain and the most commonly used systems
· Common use cases for public blockchains
· Common use cases for private & permissioned blockchains
· What is needed to launch your own blockchain
· Common problems & considerations in working with public blockchains
· Awareness of the tech behind common blockchains
· When is mining needed and when it is not
· Byzantine Fault Tolerance
· Consensus among blockchains
· What is hashing
· How addresses, public keys, and private keys work
· What is a smart contract
· Security in blockchain
· Brief history of blockchain
· The programming languages of the most common blockchains
· Common testing and deployment practices for blockchains and blockchain-based apps

Certified Blockchain Developer - Ethereum (CBDE)

A person who holds this certification demonstrates their ability to:

· Plan and prepare production ready applications for the Ethereum blockchain
· Write, test, and deploy secure Solidity smart contracts
· Understand and work with Ethereum fees
· Work within the bounds and limitations of the Ethereum blockchain
· Use the essential tooling and systems needed to work with the Ethereum ecosystem

This exam will prove that a student completely understands how to:

· Implement web3.js
· Write and compile Solidity smart contracts
· Create secure smart contracts
· Deploy smart contracts both the live and test Ethereum networks
· Calculate Ethereum gas costs
· Unit test smart contracts
· Run an Ethereum node on development machines

Princeton: Sixty free lectures from Princeton on bitcoin and cryptocurrencies. Avg length ~15 mins

Basic course with focus on Bitcoin. After this course, you’ll know everything you need to be able to separate fact from fiction when reading claims about Bitcoin and other cryptocurrencies. You’ll have the conceptual foundations you need to engineer secure software that interacts with the Bitcoin network. And you’ll be able to integrate ideas from Bitcoin in your own projects.

MIT : BLOCKCHAIN TECHNOLOGIES: BUSINESS INNOVATION AND APPLICATION

· A mid / basic understanding of blockchain technology and its long-term implications for business, coupled with knowledge of its relationship to other emerging technologies such as AI and IoT
· An economic framework for identifying blockchain-based solutions to challenges within your own context, guided by the knowledge of cryptoeconomics expert Christian Catalini
· Recognition of your newfound blockchain knowledge in the form of a certificate of completion from the MIT Sloan School of Management — one of the world’s leading business schools
Orientation Module: Welcome to Your Online Campus
Module 1: An introduction to blockchain technology
Module 2: Bitcoin and the curse of the double-spending problem
Module 3: Costless verification: Blockchain technology and the last mile problem
Module 4: Bootstrapping network effects through blockchain technology and cryptoeconomics
Module 5: Using tokens to design new types of digital platforms
Module 6: The future of blockchain technology, AI, and digital privacy

Oxford Blockchain Strategy Programme

· A mid / basic understanding of what blockchain is and how it works, as well as insights into how it will affect the future of industry and of your organization.
· The ability to make better strategic business decisions by utilizing the Oxford Blockchain Strategic framework, the Oxford Blockchain Regulation framework, the Oxford Blockchain Ecosystem map, and drawing on your knowledge of blockchain and affiliated industries and technologies.
· A certificate of attendance from Oxford Saïd as validation of your newfound blockchain knowledge and skills, as well as access to a global network of like-minded business leaders and innovators.
Module 1: Understanding blockchain
Module 2: The blockchain ecosystem
Module 3: Innovations in value transfer
Module 4: Decentralized apps and smart contracts
Module 5: Transforming enterprise business models
Module 6: Blockchain frontiers

Resources and Articles

Introduction to Distributed Ledger Technologies (DLT) https://www.ibm.com/developerworks/cloud/library/cl-blockchain-basics-intro-bluemix-trs/
Tomas’s Personal Favourite: 150+ Resources for going from web-dev to blockchain engineer https://github.com/benstew/blockchain-for-software-engineers
Hyperledger Frameworks Hyperledger is widely regarded as the most mature open-source framework for building private & permissioned blockchains.
Tutorials: https://www.hyperledger.org/resources/training
R3 Corda Open-source developer frameworks for building private, permissioned blockchains. A little better than Hyperledger on features like privacy and secure channels. Used mostly in financial applications.
Ethereum, Solidity, dApps and Smart-Contracts
Ethereum & Solidity Course (favourite): https://www.udemy.com/ethereum-and-solidity-the-complete-developers-guide/
An Introduction to Ethereum’s Token Standards: https://medium.com/coinmonks/anatomy-of-an-erc-an-exhaustive-survey-8bc1a323b541
How To Create Your First ERC20 Token: https://medium.com/bitfwd/how-to-do-an-ico-on-ethereum-in-less-than-20-minutes-a0062219374
Ethereum Developer Tools [Comprehensive List]: https://github.com/ConsenSys/ethereum-developer-tools-list/blob/masteREADME.md
CryptoZombies – Learn to code dApps through game-development: https://cryptozombies.io/
Intro to Ethereum Development: https://hackernoon.com/ethereum-development-walkthrough-part-1-smart-contracts-b3979e6e573e
Notes from Consensys Academy Participant (free): https://github.com/ScottWorks/ConsenSys-Academy-Notes
AWS Ethereum Templates: https://aws.amazon.com/blogs/aws/get-started-with-blockchain-using-the-new-aws-blockchain-templates/
Create dApps with better user-experience: https://blog.hellobloom.io/how-to-make-a-user-friendly-ethereum-dapp-5a7e5ea6df22
Solidity YouTube Course: https://www.youtube.com/channel/UCaWes1eWQ9TbzA695gl_PtA
[UX &UI] Designing a decentralized profile dApp: https://uxdesign.cc/designing-a-decentralized-profile-dapp-ab12ead4ab56
Scaling Solutions on Ethereum: https://media.consensys.net/the-state-of-scaling-ethereum-b4d095dbafae
Different Platforms for dApps and Smart-Contracts
While Ethereum is the most mature dApp framework with both the best developer tools, resources and community, there are other public blockchain platforms. Third generation blockchains are trying to solve Ethereum’s scaling and performance issues. Here is an overview of dApp platforms that can be worth looking into:
NEO - https://neo.org/ The second most mature dApp platform. NEO has better scalability and performance than Ethereum and has 1’000 TPS to ETH’s 15 by utilizing a dBFT consensus algorithm. While better infrastructure, NEO does not have the maturity of Ethereum’s developer tools, documentation and community.
A writeup on why a company chose to develop on NEO and not Ethereum: https://medium.com/orbismesh/why-we-chose-neo-over-ethereum-37fc9208ffa0
Cardano - https://www.cardano.org/en/home/ While still in alpha with a long and ambitious roadmap ahead of it, Cardano is one of the most anticipated dApp platforms out there. IOHK, the research and engineering company that maintains Cardano, has listed a lot of great resources and scientific papers that is worth looking into.
An Intro to Cardano: https://hackernoon.com/cardano-ethereum-and-neo-killer-or-overhyped-and-overpriced-8fcd5f8abcdf
IOHK Scientific Papers - https://iohk.io/research/papers/
Stellar - https://www.stellar.org/ If moving value fast from one party to another by using smart-contracts is the goal, Stellar Lumens is your platform. Initially as an open-source fork from Ripple, Stellar has become one of the mature frameworks for financial applications. Stellar’s focus lies in interoperability with legacy financial systems and cheap/fast value transfer. It’s smart-contract capability is rather limited in comparison to Ethereum and HyperLedger, so take that in consideration.
Ripplewww.ripple.com Ripple and its close cousin, Stellar, is two of the most well-known cryptocurrencies and DLT frameworks meant for the financial sector. Ripple enables instant settlement between banks for international transactions.

Consensus Algorithms

[Proof of Work] - very short, cuz it's well-known.
[1] Bitcoin - to generate a new block miner must generate hash of the new block header that is in line with given requirements.
Others: Ethereum, Litecoin etc.
[Hybrid of PoW and PoS]
[2] Decred - hybrid of “proof of work” and “proof of stake”. Blocks are created about every 5 minutes. Nodes in the network looking for a solution with a known difficulty to create a block (PoW). Once the solution is found it is broadcast to the network. The network then verifies the solution. Stakeholders who have locked some DCR in return for a ticket* now have the chance to vote on the block (PoS). 5 tickets are chosen pseudo-randomly from the ticket pool and if at least 3 of 5 vote ‘yes’ the block is permanently added to the blockchain. Both miners and voters are compensated with DCR : PoS - 30% and PoW - 60% of about 30 new Decred issued with a block. * 1 ticket = ability to cast 1 vote. Stakeholders must wait an average of 28 days (8,192 blocks) to vote their tickets.
[Proof of Stake]
[3] Nxt - The more tokens are held by account, the greater chance that account will earn the right to generate a block. The total reward received as a result of block generation is the sum of the transaction fees located within the block. Three values are key to determining which account is eligible to generate a block, which account earns the right to generate a block, and which block is taken to be the authoritative one in times of conflict: base target value, target value and cumulative difficulty. Each block on the chain has a generation signature parameter. To participate in the block's forging process, an active account digitally signs the generation signature of the previous block with its own public key. This creates a 64-byte signature, which is then hashed using SHA256. The first 8 bytes of the resulting hash are converted to a number, referred to as the account hit. The hit is compared to the current target value(active balance). If the computed hit is lower than the target, then the next block can be generated.
[4] Peercoin (chain-based proof of stake) - coin age parameter. Hybrid PoW and PoS algorithm. The longer your Peercoins have been stationary in your account (to a maximum of 90 days), the more power (coin age) they have to mint a block. The act of minting a block requires the consumption of coin age value, and the network determines consensus by selecting the chain with the largest total consumed coin age. Reward - minting + 1% yearly.
[5] Reddcoin (Proof of stake Velocity) - quite similar to Peercoin, difference: not linear coin-aging function (new coins gain weight quickly, and old coins gain weight increasingly slowly) to encourage Nodes Activity. Node with most coin age weight have a bigger chance to create block. To create block Node should calculate right hash. Block reward - interest on the weighted age of coins/ 5% annual interest in PoSV phase.
[6] Ethereum (Casper) - uses modified BFT consensus. Blocks will be created using PoW. In the Casper Phase 1 implementation for Ethereum, the “proposal mechanism" is the existing proof of work chain, modified to have a greatly reduced block reward. Blocks will be validated by set of Validators. Block is finalised when 2/3 of validators voted for it (not the number of validators is counted, but their deposit size). Block creator rewarded with Block Reward + Transaction FEES.
[7] Lisk (Delegated Proof-of-stake) - Lisk stakeholders vote with vote transaction (the weight of the vote depends on the amount of Lisk the stakeholder possess) and choose 101 Delegates, who create all blocks in the blockchain. One delegate creates 1 block within 1 round (1 round contains 101 blocks) -> At the beginning of each round, each delegate is assigned a slot indicating their position in the block generation process -> Delegate includes up to 25 transactions into the block, signs it and broadcasts it to the network -> As >51% of available peers agreed that this block is acceptable to be created (Broadhash consensus), a new block is added to the blockchain. *Any account may become a delegate, but only accounts with the required stake (no info how much) are allowed to generate blocks. Block reward - minted Lisks and transaction fees (fees for all 101 blocks are collected firstly and then are divided between delegates). Blocks appears every 10 sec.
[8] Cardano (Ouroboros Proof of Stake) - Blocks(slots) are created by Slot Leaders. Slot Leaders for N Epoch are chosen during n-1 Epoch. Slot Leaders are elected from the group of ADA stakeholders who have enough stake. Election process consist of 3 phases: Commitment phase: each elector generates a random value (secret), signs it and commit as message to network (other electors) saved in to block. -> Reveal phase: Each elector sends special value to open a commitment, all this values (opening) are put into the block. -> Recovery phase: each elector verifies that commitments and openings match and extracts the secrets and forms a SEED (randomly generated bytes string based on secrets). All electors get the same SEED. -> Follow the Satoshi algorithm : Elector who have coin which corresponded to SEED become a SLOT LEADER and get a right to create a block. Slot Leader is rewarded with minted ADA and transactions Fee.
[9] Tezos (Proof Of Stake) - generic and self-amending crypto-ledger. At the beginning of each cycle (2048 blocks), a random seed is derived from numbers that block miners chose and committed to in the penultimate cycle, and revealed in the last. -> Using this random seed, a follow the coin strategy (similar to Follow The Satoshi) is used to allocate mining rights and signing rights to stakeholders for the next cycle*. -> Blocks are mined by a random stakeholder (the miner) and includes multiple signatures of the previous block provided by random stakeholders (the signers). Mining and signing both offer a small reward but also require making a one cycle safety deposit to be forfeited in the event of a double mining or double signing.
· the more coins (rolls) you have - the more your chance to be a minesigner.
[10] Tendermint (Byzantine Fault Tolerance) - A proposal is signed and published by the designated proposer at each round. The proposer is chosen by a deterministic and non-choking round robin selection algorithm that selects proposers in proportion to their voting power. The proposer create the block, that should be validated by >2/3 of Validators, as follow: Propose -> Prevote -> Precommit -> Commit. Proposer rewarded with Transaction FEES.
[11] Tron (Byzantine Fault Tolerance) - This blockhain is still on development stage. Consensus algorithm = PoS + BFT (similar to Tendermint): PoS algorithm chooses a node as Proposer, this node has the power to generate a block. -> Proposer broadcasts a block that it want to release. -> Block enters the Prevote stage. It takes >2/3 of nodes' confirmations to enter the next stage. -> As the block is prevoted, it enters Precommit stage and needs >2/3 of node's confirmation to go further. -> As >2/3 of nodes have precommited the block it's commited to the blockchain with height +1. New blocks appears every 15 sec.
[12] NEO (Delegated Byzantine Fault Tolerance) - Consensus nodes* are elected by NEO holders -> The Speaker is identified (based on algorithm) -> He broadcasts proposal to create block -> Each Delegate (other consensus nodes) validates proposal -> Each Delegate sends response to other Delegates -> Delegate reaches consensus after receiving 2/3 positive responses -> Each Delegate signs the block and publishes it-> Each Delegate receives a full block. Block reward 6 GAS distributed proportionally in accordance with the NEO holding ratio among NEO holders. Speaker rewarded with transaction fees (mostly 0). * Stake 1000 GAS to nominate yourself for Bookkeeping(Consensus Node)
[13] EOS (Delegated Proof of Stake) - those who hold tokens on a blockchain adopting the EOS.IO software may select* block producers through a continuous approval voting system and anyone may choose to participate in block production and will be given an opportunity to produce blocks proportional to the total votes they have received relative to all other producers. At the start of each round 21 unique block producers are chosen. The top 20 by total approval are automatically chosen every round and the last producer is chosen proportional to their number of votes relative to other producers. Block should be confirmed by 2/3 or more of elected Block producers. Block Producer rewarded with Block rewards. *the more EOS tokens a stakeholder owns, the greater their voting power
[The XRP Ledger Consensus Process]
[14] Ripple - Each node receives transaction from external applications -> Each Node forms public list of all valid (not included into last ledger (=block)) transactions aka (Candidate Set) -> Nodes merge its candidate set with UNLs(Unique Node List) candidate sets and vote on the veracity of all transactions (1st round of consensus) -> all transactions that received at least 50% votes are passed on the next round (many rounds may take place) -> final round of consensus requires that min 80% of Nodes UNL agreeing on transactions. It means that at least 80% of Validating nodes should have same Candidate SET of transactions -> after that each Validating node computes a new ledger (=block) with all transactions (with 80% UNL agreement) and calculate ledger hash, signs and broadcasts -> All Validating nodes compare their ledgers hash -> Nodes of the network recognize a ledger instance as validated when a 80% of the peers have signed and broadcast the same validation hash. -> Process repeats. Ledger creation process lasts 5 sec(?). Each transaction includes transaction fee (min 0,00001 XRP) which is destroyed. No block rewards.
[The Stellar consensus protocol]
[15] Stellar (Federated Byzantine Agreement) - quite similar to Ripple. Key difference - quorum slice.
[Proof of Burn]
[16] Slimcoin - to get the right to write blocks Node should “burn” amount of coins. The more coins Node “burns” more chances it has to create blocks (for long period) -> Nodes address gets a score called Effective Burnt Coins that determines chance to find blocks. Block creator rewarded with block rewards.
[Proof of Importance]
[17] NEM - Only accounts that have min 10k vested coins are eligible to harvest (create a block). Accounts with higher importance scores have higher probabilities of harvesting a block. The higher amount of vested coins, the higher the account’s Importance score. And the higher amount of transactions that satisfy following conditions: - transactions sum min 1k coins, - transactions made within last 30 days, - recipient have 10k vested coins too, - the higher account’s Important score. Harvester is rewarded with fees for the transactions in the block. A new block is created approx. every 65 sec.
[Proof of Devotion]
[18] Nebulas (Proof of Devotion + BFT) - quite similar to POI, the PoD selects the accounts with high influence. All accounts are ranked according to their liquidity and propagation (Nebulas Rank) -> Top-ranked accounts are selected -> Chosen accounts pay deposit and are qualified as the blocks Validators* -> Algorithm pseudo-randomly chooses block Proposer -> After a new block is proposed, Validators Set (each Validator is charged a deposit) participate in a round of BFT-Style voting to verify block (1. Prepare stage -> 2. Commit Stage. Validators should have > 2/3 of total deposits to validate Block) -> Block is added. Block rewards : each Validator rewarded with 1 NAS. *Validators Set is dynamic, changes in Set may occur after Epoch change.
[IOTA Algorithm]
[19] IOTA - uses DAG (Directed Acyclic Graph) instead of blockchain (TANGLE equal to Ledger). Graph consist of transactions (not blocks). To issue a new transaction Node must approve 2 random other Transactions (not confirmed). Each transaction should be validate n(?) times. By validating PAST(2) transactions whole Network achieves Consensus. in Order to issue transaction Node: 1. Sign transaction with private key 2. choose two other Transactions to validate based on MCMC(Markov chain Monte Carlo) algorithm, check if 2 transactions are valid (node will never approve conflicting transactions) 3. make some PoW(similar to HashCash). -> New Transaction broadcasted to Network. Node don’t receive reward or fee.
[PBFT + PoW]
[20] Yobicash - uses PBFT and also PoW. Nodes reach consensus on transactions by querying other nodes. A node asks its peers about the state of a transaction: if it is known or not, and if it is a doublespending transaction or not. As follow : Node receives new transaction -> Checks if valid -> queries all known nodes for missing transactions (check if already in DAG ) -> queries 2/3 nodes for doublepsending and possibility -> if everything is ok add to DAG. Reward - nodes receive transaction fees + minting coins.
[Proof of Space/Proof of Capacity]
[21] Filecoin (Power Fault Tolerance) - the probability that the network elects a miner(Leader) to create a new block (it is referred to as the voting power of the miner) is proportional to storage currently in use in relation to the rest of the network. Each node has Power - storage in use verified with Proof of Spacetime by nodes. Leaders extend the chain by creating a block and propagating it to the network. There can be an empty block (when no leader). A block is committed if the majority of the participants add their weight on the chain where the block belongs to, by extending the chain or by signing blocks. Block creator rewarded with Block reward + transaction fees.
[Proof of Elapsed Time (POET)]
[22] Hyperledger Sawtooth - Goal - to solve BFT Validating Nodes limitation. Works only with intel’s SGX. PoET uses a random leader election model or a lottery based election model based on SGX, where the protocol randomly selects the next leader to finalize the block. Every validator requests a wait time from an enclave (a trusted function). -> The validator with the shortest wait time for a particular transaction block is elected the leader. -> The BlockPublisher is responsible for creating candidate blocks to extend the current chain. He takes direction from the consensus algorithm for when to create a block and when to publish a block. He creates, Finalizes, Signs Block and broadcast it -> Block Validators check block -> Block is created on top of blockchain.
[23] Byteball (Delegated Byzantine Fault Tolerance) - only verified nodes are allowed to be Validation nodes (list of requirements https://github.com/byteball/byteball-witness). Users choose in transaction set of 12 Validating nodes. Validating nodes(Witnesses) receive transaction fees.
[24] Nano - uses DAG, PoW (HashCash). Nano uses a block-lattice structure. Each account has its own blockchain (account-chain) equivalent to the account’s transaction/balance history. To add transaction user should make some HashCash PoW -> When user creates transaction Send Block appears on his blockchain and Receive block appears on Recipients blockchain. -> Peers in View receive Block -> Peers verify block (Double spending and check if already in the ledger) -> Peers achieve consensus and add block. In case of Fork (when 2 or more signed blocks reference the same previous block): Nano network resolves forks via a balance-weighted voting system where representative nodes vote for the block they observe, as >50% of weighted votes received, consensus achieved and block is retained in the Node’s ledger (block that lose the vote is discarded).
[25] Holochain - uses distributed hash table (DHT). Instead of trying to manage global consensus for every change to a huge blockchain ledger, every participant has their own signed hash chain. In case of multi-party transaction, it is signed to each party's chain. Each party signs the exact same transaction with links to each of their previous chain entries. After data is signed to local chains, it is shared to a DHT where every neighbor node validate it. Any consensus algorithms can be built on top of Holochain.
[26] Komodo ('Delegated' Delayed Proof of Work (dPoW)) - end-to-end blockchain solutions. DPoW consensus mechanism does not recognize The Longest Chain Rule to resolve a conflict in the network, instead the dPoW looks to backups it inserted previously into the chosen PoW blockchain. The process of inserting backups of Komodo transactions into a secure PoW is “notarization.” Notarisation is performed by the elected Notary nodes. Roughly every ten minutes, the Notary nodes perform a special block hash mined on the Komodo blockchain and take note of the overall Komodo blockchain “height”. The notary nodes process this specifc block so that their signatures are cryptographically included within the content of the notarized data. There are sixty-four “Notary nodes” elected by a stake-weighted vote, where ownership of KMD represents stake in the election. They are a special type of blockchain miner, having certain features in their underlying code that enable them to maintain an effective and cost-efcient blockchain and they periodically receives the privilege to mine a block on “easy difculty.”
Source: https://www.reddit.com/CryptoTechnology/comments/7znnq8/my_brief_observation_of_most_common_consensus/
Whitepapers Worth Looking Into:
IOTA -http://iotatoken.com/IOTA_Whitepaper.pdf
NANO -https://nano.org/en/whitepaper
Bitcoin -https://bitcoin.org/bitcoin.pdf
Ethereum: https://github.com/ethereum/wiki/wiki/White-Paper
Ethereum Plasma (Omise-GO) -https://plasma.io/plasma.pdf
Cardano - https://eprint.iacr.org/2016/889.pdf
submitted by heart_mind_body to CryptoCurrency [link] [comments]

Transcript of the community Q&A with Steve Shadders and Daniel Connolly of the Bitcoin SV development team. We talk about the path to big blocks, new opcodes, selfish mining, malleability, and why November will lead to a divergence in consensus rules. (Cont in comments)

We've gone through the painstaking process of transcribing the linked interview with Steve Shadders and Daniell Connolly of the Bitcoin SV team. There is an amazing amount of information in this interview that we feel is important for businesses and miners to hear, so we believe it was important to get this is a written form. To avoid any bias, the transcript is taken almost word for word from the video, with just a few changes made for easier reading. If you see any corrections that need to be made, please let us know.
Each question is in bold, and each question and response is timestamped accordingly. You can follow along with the video here:
https://youtu.be/tPImTXFb_U8

BEGIN TRANSCRIPT:

Connor: 02:19.68,0:02:45.10
Alright so thank You Daniel and Steve for joining us. We're joined by Steve Shadders and Daniel Connolly from nChain and also the lead developers of the Satoshi’s Vision client. So Daniel and Steve do you guys just want to introduce yourselves before we kind of get started here - who are you guys and how did you get started?
Steve: 0,0:02:38.83,0:03:30.61
So I'm Steve Shadders and at nChain I am the director of solutions in engineering and specifically for Bitcoin SV I am the technical director of the project which means that I'm a bit less hands-on than Daniel but I handle a lot of the liaison with the miners - that's the conditional project.
Daniel:
Hi I’m Daniel I’m the lead developer for Bitcoin SV. As the team's grown that means that I do less actual coding myself but more organizing the team and organizing what we’re working on.
Connor 03:23.07,0:04:15.98
Great so we took some questions - we asked on Reddit to have people come and post their questions. We tried to take as many of those as we could and eliminate some of the duplicates, so we're gonna kind of go through each question one by one. We added some questions of our own in and we'll try and get through most of these if we can. So I think we just wanted to start out and ask, you know, Bitcoin Cash is a little bit over a year old now. Bitcoin itself is ten years old but in the past a little over a year now what has the process been like for you guys working with the multiple development teams and, you know, why is it important that the Satoshi’s vision client exists today?
Steve: 0:04:17.66,0:06:03.46
I mean yes well we’ve been in touch with the developer teams for quite some time - I think a bi-weekly meeting of Bitcoin Cash developers across all implementations started around November last year. I myself joined those in January or February of this year and Daniel a few months later. So we communicate with all of those teams and I think, you know, it's not been without its challenges. It's well known that there's a lot of disagreements around it, but some what I do look forward to in the near future is a day when the consensus issues themselves are all rather settled, and if we get to that point then there's not going to be much reason for the different developer teams to disagree on stuff. They might disagree on non-consensus related stuff but that's not the end of the world because, you know, Bitcoin Unlimited is free to go and implement whatever they want in the back end of a Bitcoin Unlimited and Bitcoin SV is free to do whatever they want in the backend, and if they interoperate on a non-consensus level great. If they don't not such a big problem there will obviously be bridges between the two, so, yeah I think going forward the complications of having so many personalities with wildly different ideas are going to get less and less.
Cory: 0:06:00.59,0:06:19.59
I guess moving forward now another question about the testnet - a lot of people on Reddit have been asking what the testing process for Bitcoin SV has been like, and if you guys plan on releasing any of those results from the testing?
Daniel: 0:06:19.59,0:07:55.55
Sure yeah so our release will be concentrated on the stability, right, with the first release of Bitcoin SV and that involved doing a large amount of additional testing particularly not so much at the unit test level but at the more system test so setting up test networks, performing tests, and making sure that the software behaved as we expected, right. Confirming the changes we made, making sure that there aren’t any other side effects. Because of, you know, it was quite a rush to release the first version so we've got our test results documented, but not in a way that we can really release them. We're thinking about doing that but we’re not there yet.
Steve: 0:07:50.25,0:09:50.87
Just to tidy that up - we've spent a lot of our time developing really robust test processes and the reporting is something that we can read on our internal systems easily, but we need to tidy that up to give it out for public release. The priority for us was making sure that the software was safe to use. We've established a test framework that involves a progression of code changes through multiple test environments - I think it's five different test environments before it gets the QA stamp of approval - and as for the question about the testnet, yeah, we've got four of them. We've got Testnet One and Testnet Two. A slightly different numbering scheme to the testnet three that everyone's probably used to – that’s just how we reference them internally. They're [1 and 2] both forks of Testnet Three. [Testnet] One we used for activation testing, so we would test things before and after activation - that one’s set to reset every couple of days. The other one [Testnet Two] was set to post activation so that we can test all of the consensus changes. The third one was a performance test network which I think most people have probably have heard us refer to before as Gigablock Testnet. I get my tongue tied every time I try to say that word so I've started calling it the Performance test network and I think we're planning on having two of those: one that we can just do our own stuff with and experiment without having to worry about external unknown factors going on and having other people joining it and doing stuff that we don't know about that affects our ability to baseline performance tests, but the other one (which I think might still be a work in progress so Daniel might be able to answer that one) is one of them where basically everyone will be able to join and they can try and mess stuff up as bad as they want.
Daniel: 0:09:45.02,0:10:20.93
Yeah, so we so we recently shared the details of Testnet One and Two with the with the other BCH developer groups. The Gigablock test network we've shared up with one group so far but yeah we're building it as Steve pointed out to be publicly accessible.
Connor: 0:10:18.88,0:10:44.00
I think that was my next question I saw that you posted on Twitter about the revived Gigablock testnet initiative and so it looked like blocks bigger than 32 megabytes were being mined and propagated there, but maybe the block explorers themselves were coming down - what does that revived Gigablock test initiative look like?
Daniel: 0:10:41.62,0:11:58.34
That's what did the Gigablock test network is. So the Gigablock test network was first set up by Bitcoin Unlimited with nChain’s help and they did some great work on that, and we wanted to revive it. So we wanted to bring it back and do some large-scale testing on it. It's a flexible network - at one point we had we had eight different large nodes spread across the globe, sort of mirroring the old one. Right now we scaled back because we're not using it at the moment so they'll notice I think three. We have produced some large blocks there and it's helped us a lot in our research and into the scaling capabilities of Bitcoin SV, so it's guided the work that the team’s been doing for the last month or two on the improvements that we need for scalability.
Steve: 0:11:56.48,0:13:34.25
I think that's actually a good point to kind of frame where our priorities have been in kind of two separate stages. I think, as Daniel mentioned before, because of the time constraints we kept the change set for the October 15 release as minimal as possible - it was just the consensus changes. We didn't do any work on performance at all and we put all our focus and energy into establishing the QA process and making sure that that change was safe and that was a good process for us to go through. It highlighted what we were missing in our team – we got our recruiters very busy recruiting of a Test Manager and more QA people. The second stage after that is performance related work which, as Daniel mentioned, the results of our performance testing fed into what tasks we were gonna start working on for the performance related stuff. Now that work is still in progress - some of the items that we identified the code is done and that's going through the QA process but it’s not quite there yet. That's basically the two-stage process that we've been through so far. We have a roadmap that goes further into the future that outlines more stuff, but primarily it’s been QA first, performance second. The performance enhancements are close and on the horizon but some of that work should be ongoing for quite some time.
Daniel: 0:13:37.49,0:14:35.14
Some of the changes we need for the performance are really quite large and really get down into the base level view of the software. There's kind of two groups of them mainly. One that are internal to the software – to Bitcoin SV itself - improving the way it works inside. And then there's other ones that interface it with the outside world. One of those in particular we're working closely with another group to make a compatible change - it's not consensus changing or anything like that - but having the same interface on multiple different implementations will be very helpful right, so we're working closely with them to make improvements for scalability.
Connor: 0:14:32.60,0:15:26.45
Obviously for Bitcoin SV one of the main things that you guys wanted to do that that some of the other developer groups weren't willing to do right now is to increase the maximum default block size to 128 megabytes. I kind of wanted to pick your brains a little bit about - a lot of the objection to either removing the box size entirely or increasing it on a larger scale is this idea of like the infinite block attack right and that kind of came through in a lot of the questions. What are your thoughts on the “infinite block attack” and is it is it something that that really exists, is it something that miners themselves should be more proactive on preventing, or I guess what are your thoughts on that attack that everyone says will happen if you uncap the block size?
Steve: 0:15:23.45,0:18:28.56
I'm often quoted on Twitter and Reddit - I've said before the infinite block attack is bullshit. Now, that's a statement that I suppose is easy to take out of context, but I think the 128 MB limit is something where there’s probably two schools of thought about. There are some people who think that you shouldn't increase the limit to 128 MB until the software can handle it, and there are others who think that it's fine to do it now so that the limit is increased when the software can handle it and you don’t run into the limit when this when the software improves and can handle it. Obviously we’re from the latter school of thought. As I said before we've got a bunch of performance increases, performance enhancements, in the pipeline. If we wait till May to increase the block size limit to 128 MB then those performance enhancements will go in, but we won't be able to actually demonstrate it on mainnet. As for the infinitive block attack itself, I mean there are a number of mitigations that you can put in place. I mean firstly, you know, going down to a bit of the tech detail - when you send a block message or send any peer to peer message there's a header which has the size of the message. If someone says they're sending you a 30MB message and you're receiving it and it gets to 33MB then obviously you know something's wrong so you can drop the connection. If someone sends you a message that's 129 MB and you know the block size limit is 128 you know it’s kind of pointless to download that message. So I mean these are just some of the mitigations that you can put in place. When I say the attack is bullshit, I mean I mean it is bullshit from the sense that it's really quite trivial to prevent it from happening. I think there is a bit of a school of thought in the Bitcoin world that if it's not in the software right now then it kind of doesn't exist. I disagree with that, because there are small changes that can be made to work around problems like this. One other aspect of the infinite block attack, and let’s not call it the infinite block attack, let's just call it the large block attack - it takes a lot of time to validate that we gotten around by having parallel pipelines for blocks to come in, so you've got a block that's coming in it's got a unknown stuck on it for two hours or whatever downloading and validating it. At some point another block is going to get mined b someone else and as long as those two blocks aren't stuck in a serial pipeline then you know the problem kind of goes away.
Cory: 0:18:26.55,0:18:48.27
Are there any concerns with the propagation of those larger blocks? Because there's a lot of questions around you know what the practical size of scaling right now Bitcoin SV could do and the concerns around propagating those blocks across the whole network.
Steve 0:18:45.84,0:21:37.73
Yes, there have been concerns raised about it. I think what people forget is that compact blocks and xThin exist, so if a 32MB block is not send 32MB of data in most cases, almost all cases. The concern here that I think I do find legitimate is the Great Firewall of China. Very early on in Bitcoin SV we started talking with miners on the other side of the firewall and that was one of their primary concerns. We had anecdotal reports of people who were having trouble getting a stable connection any faster than 200 kilobits per second and even with compact blocks you still need to get the transactions across the firewall. So we've done a lot of research into that - we tested our own links across the firewall, rather CoinGeeks links across the firewall as they’ve given us access to some of their servers so that we can play around, and we were able to get sustained rates of 50 to 90 megabits per second which pushes that problem quite a long way down the road into the future. I don't know the maths off the top of my head, but the size of the blocks that can sustain is pretty large. So we're looking at a couple of options - it may well be the chattiness of the peer-to-peer protocol causes some of these issues with the Great Firewall, so we have someone building a bridge concept/tool where you basically just have one kind of TX vacuum on either side of the firewall that collects them all up and sends them off every one or two seconds as a single big chunk to eliminate some of that chattiness. The other is we're looking at building a multiplexer that will sit and send stuff up to the peer-to-peer network on one side and send it over splitters, to send it over multiple links, reassemble it on the other side so we can sort of transition the great Firewall without too much trouble, but I mean getting back to the core of your question - yes there is a theoretical limit to block size propagation time and that's kind of where Moore's Law comes in. Putting faster links and you kick that can further down the road and you just keep on putting in faster links. I don't think 128 main blocks are going to be an issue though with the speed of the internet that we have nowadays.
Connor: 0:21:34.99,0:22:17.84
One of the other changes that you guys are introducing is increasing the max script size so I think right now it’s going from 201 to 500 [opcodes]. So I guess a few of the questions we got was I guess #1 like why not uncap it entirely - I think you guys said you ran into some concerns while testing that - and then #2 also specifically we had a question about how certain are you that there are no remaining n squared bugs or vulnerabilities left in script execution?
Steve: 0:22:15.50,0:25:36.79
It's interesting the decision - we were initially planning on removing that cap altogether and the next cap that comes into play after that (next effective cap is a 10,000 byte limit on the size of the script). We took a more conservative route and decided to wind that back to 500 - it's interesting that we got some criticism for that when the primary criticism I think that was leveled against us was it’s dangerous to increase that limit to unlimited. We did that because we’re being conservative. We did some research into these log n squared bugs, sorry – attacks, that people have referred to. We identified a few of them and we had a hard think about it and thought - look if we can find this many in a short time we can fix them all (the whack-a-mole approach) but it does suggest that there may well be more unknown ones. So we thought about putting, you know, taking the whack-a-mole approach, but that doesn't really give us any certainty. We will fix all of those individually but a more global approach is to make sure that if anyone does discover one of these scripts it doesn't bring the node to a screaming halt, so the problem here is because the Bitcoin node is essentially single-threaded, if you get one of these scripts that locks up the script engine for a long time everything that's behind it in the queue has to stop and wait. So what we wanted to do, and this is something we've got an engineer actively working on right now, is once that script validation goad path is properly paralyzed (parts of it already are), then we’ll basically assign a few threads for well-known transaction templates, and a few threads for any any type of script. So if you get a few scripts that are nasty and lock up a thread for a while that's not going to stop the node from working because you've got these other kind of lanes of the highway that are exclusively reserved for well-known script templates and they'll just keep on passing through. Once you've got that in place, and I think we're in a much better position to get rid of that limit entirely because the worst that's going to happen is your non-standard script pipelines get clogged up but everything else will keep keep ticking along - there are other mitigations for this as well I mean I know you could always put a time limit on script execution if they wanted to, and that would be something that would be up to individual miners. Bitcoin SV's job I think is to provide the tools for the miners and the miners can then choose, you know, how to make use of them - if they want to set time limits on script execution then that's a choice for them.
Daniel: 0:25:34.82,0:26:15.85
Yeah, I'd like to point out that a node here, when it receives a transaction through the peer to peer network, it doesn't have to accept that transaction, you can reject it. If it looks suspicious to the node it can just say you know we're not going to deal with that, or if it takes more than five minutes to execute, or more than a minute even, it can just abort and discard that transaction, right. The only time we can’t do that is when it's in a block already, but then it could decide to reject the block as well. It's all possibilities there could be in the software.
Steve: 0:26:13.08,0:26:20.64
Yeah, and if it's in a block already it means someone else was able to validate it so…
Cory: 0,0:26:21.21,0:26:43.60
There’s a lot of discussions about the re-enabled opcodes coming – OP_MUL, OP_INVERT, OP_LSHIFT, and OP_RSHIFT up invert op l shift and op r shift you maybe explain the significance of those op codes being re-enabled?
Steve: 0:26:42.01,0:28:17.01
Well I mean one of one of the most significant things is other than two, which are minor variants of DUP and MUL, they represent almost the complete set of original op codes. I think that's not necessarily a technical issue, but it's an important milestone. MUL is one that's that I've heard some interesting comments about. People ask me why are you putting OP_MUL back in if you're planning on changing them to big number operations instead of the 32-bit limit that they're currently imposed upon. The simple answer to that question is that we currently have all of the other arithmetic operations except for OP_MUL. We’ve got add divide, subtract, modulo – it’s odd to have a script system that's got all the mathematical primitives except for multiplication. The other answer to that question is that they're useful - we've talked about a Rabin signature solution that basically replicates the function of DATASIGVERIFY. That's just one example of a use case for this - most cryptographic primitive operations require mathematical operations and bit shifts are useful for a whole ton of things. So it's really just about completing that work and completing the script engine, or rather not completing it, but putting it back the way that it was it was meant to be.
Connor 0:28:20.42,0:29:22.62
Big Num vs 32 Bit. I've seen Daniel - I think I saw you answer this on Reddit a little while ago, but the new op codes using logical shifts and Satoshi’s version use arithmetic shifts - the general question that I think a lot of people keep bringing up is, maybe in a rhetorical way but they say why not restore it back to the way Satoshi had it exactly - what are the benefits of changing it now to operate a little bit differently?
Daniel: 0:29:18.75,0:31:12.15
Yeah there's two parts there - the big number one and the L shift being a logical shift instead of arithmetic. so when we re-enabled these opcodes we've looked at them carefully and have adjusted them slightly as we did in the past with OP_SPLIT. So the new LSHIFT and RSHIFT are bitwise operators. They can be used to implement arithmetic based shifts - I think I've posted a short script that did that, but we can't do it the other way around, right. You couldn't use an arithmetic shift operator to implement a bitwise one. It's because of the ordering of the bytes in the arithmetic values, so the values that represent numbers. The little endian which means they're swapped around to what many other systems - what I've considered normal - or big-endian. And if you start shifting that properly as a number then then shifting sequence in the bytes is a bit strange, so it couldn't go the other way around - you couldn't implement bitwise shift with arithmetic, so we chose to make them bitwise operators - that's what we proposed.
Steve: 0:31:10.57,0:31:51.51
That was essentially a decision that was actually made in May, or rather a consequence of decisions that were made in May. So in May we reintroduced OP_AND, OP_OR, and OP_XOR, and that was also another decision to replace three different string operators with OP_SPLIT was also made. So that was not a decision that we've made unilaterally, it was a decision that was made collectively with all of the BCH developers - well not all of them were actually in all of the meetings, but they were all invited.
Daniel: 0:31:48.24,0:32:23.13
Another example of that is that we originally proposed OP_2DIV and OP_2MUL was it, I think, and this is a single operator that multiplies the value by two, right, but it was pointed out that that can very easily be achieved by just doing multiply by two instead of having a separate operator for it, so we scrapped those, we took them back out, because we wanted to keep the number of operators minimum yeah.
Steve: 0:32:17.59,0:33:47.20
There was an appetite around for keeping the operators minimal. I mean the decision about the idea to replace OP_SUBSTR, OP_LEFT, OP_RIGHT with OP_SPLIT operator actually came from Gavin Andresen. He made a brief appearance in the Telegram workgroups while we were working out what to do with May opcodes and obviously Gavin's word kind of carries a lot of weight and we listen to him. But because we had chosen to implement the May opcodes (the bitwise opcodes) and treat the data as big-endian data streams (well, sorry big-endian not really applicable just plain data strings) it would have been completely inconsistent to implement LSHIFT and RSHIFT as integer operators because then you would have had a set of bitwise operators that operated on two different kinds of data, which would have just been nonsensical and very difficult for anyone to work with, so yeah. I mean it's a bit like P2SH - it wasn't a part of the original Satoshi protocol that once some things are done they're done and you know if you want to want to make forward progress you've got to work within that that framework that exists.
Daniel: 0:33:45.85,0:34:48.97
When we get to the big number ones then it gets really complicated, you know, number implementations because then you can't change the behavior of the existing opcodes, and I don't mean OP_MUL, I mean the other ones that have been there for a while. You can't suddenly make them big number ones without seriously looking at what scripts there might be out there and the impact of that change on those existing scripts, right. The other the other point is you don't know what scripts are out there because of P2SH - there could be scripts that you don't know the content of and you don't know what effect changing the behavior of these operators would mean. The big number thing is tricky, so another option might be, yeah, I don't know what the options for though it needs some serious thought.
Steve: 0:34:43.27,0:35:24.23
That’s something we've reached out to the other implementation teams about - actually really would like their input on the best ways to go about restoring big number operations. It has to be done extremely carefully and I don't know if we'll get there by May next year, or when, but we’re certainly willing to put a lot of resources into it and we're more than happy to work with BU or XT or whoever wants to work with us on getting that done and getting it done safely.
Connor: 0:35:19.30,0:35:57.49
Kind of along this similar vein, you know, Bitcoin Core introduced this concept of standard scripts, right - standard and non-standard scripts. I had pretty interesting conversation with Clemens Ley about use cases for “non-standard scripts” as they're called. I know at least one developer on Bitcoin ABC is very hesitant, or kind of pushed back on him about doing that and so what are your thoughts about non-standard scripts and the entirety of like an IsStandard check?
Steve: 0:35:58.31,0:37:35.73
I’d actually like to repurpose the concept. I think I mentioned before multi-threaded script validation and having some dedicated well-known script templates - when you say the word well-known script template there’s already a check in Bitcoin that kind of tells you if it's well-known or not and that's IsStandard. I'm generally in favor of getting rid of the notion of standard transactions, but it's actually a decision for miners, and it's really more of a behavioral change than it is a technical change. There's a whole bunch of configuration options that miners can set that affect what they do what they consider to be standard and not standard, but the reality is not too many miners are using those configuration options. So I mean standard transactions as a concept is meaningful to an arbitrary degree I suppose, but yeah I would like to make it easier for people to get non-standard scripts into Bitcoin so that they can experiment, and from discussions of I’ve had with CoinGeek they’re quite keen on making their miners accept, you know, at least initially a wider variety of transactions eventually.
Daniel: 0:37:32.85,0:38:07.95
So I think IsStandard will remain important within the implementation itself for efficiency purposes, right - you want to streamline base use case of cash payments through them and prioritizing. That's where it will remain important but on the interfaces from the node to the rest of the network, yeah I could easily see it being removed.
Cory: 0,0:38:06.24,0:38:35.46
*Connor mentioned that there's some people that disagree with Bitcoin SV and what they're doing - a lot of questions around, you know, why November? Why implement these changes in November - they think that maybe the six-month delay might not cause a split. Well, first off what do you think about the ideas of a potential split and I guess what is the urgency for November?
Steve: 0:38:33.30,0:40:42.42
Well in November there's going to be a divergence of consensus rules regardless of whether we implement these new op codes or not. Bitcoin ABC released their spec for the November Hard fork change I think on August 16th or 17th something like that and their client as well and it included CTOR and it included DSV. Now for the miners that commissioned the SV project, CTOR and DSV are controversial changes and once they're in they're in. They can't be reversed - I mean CTOR maybe you could reverse it at a later date, but DSV once someone's put a P2SH transaction into the project or even a non P2SH transaction in the blockchain using that opcode it's irreversible. So it's interesting that some people refer to the Bitcoin SV project as causing a split - we're not proposing to do anything that anyone disagrees with - there might be some contention about changing the opcode limit but what we're doing, I mean Bitcoin ABC already published their spec for May and it is our spec for the new opcodes, so in terms of urgency - should we wait? Well the fact is that we can't - come November you know it's bit like Segwit - once Segwit was in, yes you arguably could get it out by spending everyone's anyone can spend transactions but in reality it's never going to be that easy and it's going to cause a lot of economic disruption, so yeah that's it. We're putting out changes in because it's not gonna make a difference either way in terms of whether there's going to be a divergence of consensus rules - there's going to be a divergence whether whatever our changes are. Our changes are not controversial at all.
Daniel: 0:40:39.79,0:41:03.08
If we didn't include these changes in the November upgrade we'd be pushing ahead with a no-change, right, but the November upgrade is there so we should use it while we can. Adding these non-controversial changes to it.
Connor: 0:41:01.55,0:41:35.61
Can you talk about DATASIGVERIFY? What are your concerns with it? The general concept that's been kind of floated around because of Ryan Charles is the idea that it's a subsidy, right - that it takes a whole megabyte and kind of crunches that down and the computation time stays the same but maybe the cost is lesser - do you kind of share his view on that or what are your concerns with it?
Daniel: 0:41:34.01,0:43:38.41
Can I say one or two things about this – there’s different ways to look at that, right. I'm an engineer - my specialization is software, so the economics of it I hear different opinions. I trust some more than others but I am NOT an economist. I kind of agree with the ones with my limited expertise on that it's a subsidy it looks very much like it to me, but yeah that's not my area. What I can talk about is the software - so adding DSV adds really quite a lot of complexity to the code right, and it's a big change to add that. And what are we going to do - every time someone comes up with an idea we’re going to add a new opcode? How many opcodes are we going to add? I saw reports that Jihan was talking about hundreds of opcodes or something like that and it's like how big is this client going to become - how big is this node - is it going to have to handle every kind of weird opcode that that's out there? The software is just going to get unmanageable and DSV - that was my main consideration at the beginning was the, you know, if you can implement it in script you should do it, because that way it keeps the node software simple, it keeps it stable, and you know it's easier to test that it works properly and correctly. It's almost like adding (?) code from a microprocessor you know why would you do that if you can if you can implement it already in the script that is there.
Steve: 0:43:36.16,0:46:09.71
It’s actually an interesting inconsistency because when we were talking about adding the opcodes in May, the philosophy that seemed to drive the decisions that we were able to form a consensus around was to simplify and keep the opcodes as minimal as possible (ie where you could replicate a function by using a couple of primitive opcodes in combination, that was preferable to adding a new opcode that replaced) OP_SUBSTR is an interesting example - it's a combination of SPLIT, and SWAP and DROP opcodes to achieve it. So at really primitive script level we've got this philosophy of let's keep it minimal and at this sort of (?) philosophy it’s all let's just add a new opcode for every primitive function and Daniel's right - it's a question of opening the floodgates. Where does it end? If we're just going to go down this road, it almost opens up the argument why have a scripting language at all? Why not just add a hard code all of these functions in one at a time? You know, pay to public key hash is a well-known construct (?) and not bother executing a script at all but once we've done that we take away with all of the flexibility for people to innovate, so it's a philosophical difference, I think, but I think it's one where the position of keeping it simple does make sense. All of the primitives are there to do what people need to do. The things that people don't feel like they can't do are because of the limits that exist. If we had no opcode limit at all, if you could make a gigabyte transaction so a gigabyte script, then you can do any kind of crypto that you wanted even with 32-bit integer operations, Once you get rid of the 32-bit limit of course, a lot of those a lot of those scripts come up a lot smaller, so a Rabin signature script shrinks from 100MB to a couple hundred bytes.
Daniel: 0:46:06.77,0:47:36.65
I lost a good six months of my life diving into script, right. Once you start getting into the language and what it can do, it is really pretty impressive how much you can achieve within script. Bitcoin was designed, was released originally, with script. I mean it didn't have to be – it could just be instead of having a transaction with script you could have accounts and you could say trust, you know, so many BTC from this public key to this one - but that's not the way it was done. It was done using script, and script provides so many capabilities if you start exploring it properly. If you start really digging into what it can do, yeah, it's really amazing what you can do with script. I'm really looking forward to seeing some some very interesting applications from that. I mean it was Awemany his zero-conf script was really interesting, right. I mean it relies on DSV which is a problem (and some other things that I don't like about it), but him diving in and using script to solve this problem was really cool, it was really good to see that.
Steve: 0:47:32.78,0:48:16.44
I asked a question to a couple of people in our research team that have been working on the Rabin signature stuff this morning actually and I wasn't sure where they are up to with this, but they're actually working on a proof of concept (which I believe is pretty close to done) which is a Rabin signature script - it will use smaller signatures so that it can fit within the current limits, but it will be, you know, effectively the same algorithm (as DSV) so I can't give you an exact date on when that will happen, but it looks like we'll have a Rabin signature in the blockchain soon (a mini-Rabin signature).
Cory: 0:48:13.61,0:48:57.63
Based on your responses I think I kinda already know the answer to this question, but there's a lot of questions about ending experimentation on Bitcoin. I was gonna kind of turn that into – with the plan that Bitcoin SV is on do you guys see like a potential one final release, you know that there's gonna be no new opcodes ever released (like maybe five years down the road we just solidify the base protocol and move forward with that) or are you guys more on the idea of being open-ended with appropriate testing that we can introduce new opcodes under appropriate testing.
Steve: 0:48:55.80,0:49:47.43
I think you've got a factor in what I said before about the philosophical differences. I think new functionality can be introduced just fine. Having said that - yes there is a place for new opcodes but it's probably a limited place and in my opinion the cryptographic primitive functions for example CHECKSIG uses ECDSA with a specific elliptic curve, hash 256 uses SHA256 - at some point in the future those are going to no longer be as secure as we would like them to be and we'll replace them with different hash functions, verification functions, at some point, but I think that's a long way down the track.
Daniel: 0:49:42.47,0:50:30.3
I'd like to see more data too. I'd like to see evidence that these things are needed, and the way I could imagine that happening is that, you know, that with the full scripting language some solution is implemented and we discover that this is really useful, and over a period of, like, you know measured in years not days, we find a lot of transactions are using this feature, then maybe, you know, maybe we should look at introducing an opcode to optimize it, but optimizing before we even know if it's going to be useful, yeah, that's the wrong approach.
Steve: 0:50:28.19,0:51:45.29
I think that optimization is actually going to become an economic decision for the miners. From the miner’s point of view is if it'll make more sense for them to be able to optimize a particular process - does it reduce costs for them such that they can offer a better service to everyone else? Yeah, so ultimately these decisions are going to be miner’s main decisions, not developer decisions. Developers of course can offer their input - I wouldn't expect every miner to be an expert on script, but as we're already seeing miners are actually starting to employ their own developers. I’m not just talking about us - there are other miners in China that I know have got some really bright people on their staff that question and challenge all of the changes - study them and produce their own reports. We've been lucky with actually being able to talk to some of those people and have some really fascinating technical discussions with them.
submitted by The_BCH_Boys to btc [link] [comments]

The History, The Current State And The Future Of NavCoin

The History, The Current State And The Future Of NavCoin

This is it. If you're interested to see what NAV is all about, this is the ultimate guide for you. You will learn about the history of NavCoin and how it evolved. You will learn about the current state and features of NavCoin and you will learn about the exciting new features that are planned and coming up in the (near) future.
So buckle up, this is going to be a long ride!

Table Of Content


Introduction - What is NavCoin?


The History

Introduction
The following chapter will summarize and break down the history of NavCoin in a few sentences. NAV started a long time ago, went through rebrandings and changes of the core team before it became what it is today.

SummerCoin
NavCoin was initially first introduced under the name SummerCoin on April 23 in 2014. SummerCoin was a fork of the Bitcoin blockchain. It used to have a PoW/PoS hybrid algorithm with a block time of 45 seconds.

SummerCoinV2 /NavajoCoin
Soon after the initial launch of SummerCoin, the original developer left and SoopY (soopy452000 on bitcointalk) took over as the main developer and rebranded the project to SummerCoinV2 respectively NavajoCoin and introduced new features.
The name NavajoCoin was chosen in honor of the Navajo Code Talker. The unbreakable Navajo code was used to encrypt highly classified military information and commands and decrypt the same in WW II.
SoopY introduced a technology which allowed sending transactions anonymously and private. This technology was called "Navajo Anonymous Technology". SoopY also released a new wallet and set the Proof of Stake rewards at 10% for the first year, 5% for the second year and 2% for every year after.

NavCoin
On August 12, 2014, Craig (current lead core developer, pakage on bitcointalk) started to get involved with NAV by helping to set up a website [10].
It was officially announced that Craig joined the core team as a "Wallet & Web Developer" on November 06, 2014.
The last tokenswap and restart of the blockchain of NAV happened on May 12, 2016.
Soon later, SoopY stopped showing up and Craig stepped into the role of the lead core developer. Since then, Craig has assembled a strong team with which he built NavCoin into what it is today.
Currently, Craig and the NavCoin Core team is located in New Zealand and they are actively developing many ground-braking features which differentiate NAV from other cryptocurrencies. You will read more about that later in this article.

The Current State

Introduction
The year 2018 has been a thriving year for the NavCoin ecosystem. Despite the USD price of NAV not reflecting it, in 2018 the core team has developed a whole bunch of new features. Also the core content creators published the first official guidelines that function as an orientation guide for community content creators. This chapter will give you an overview of the current team, the features, the prior mentioned guidelines and the community of NavCoin.

Core Team [1]
Last year, the core team has grown alot. It contains of developers, content creators and interns. The core team are employees of Encrypt S, the New Zealand's leading blockchain R&D lab. Encrypt S is developing blockchain solutions since 2014 and values building open-source software highly.

Craig MacGregor - Chief Executive Officer
Craig is the CEO of Encrypt S and the founder of NavCoin. He is one of the world's most experienced blockchain developers. Craig founded NavCoin in 2014 and is developing software for it since then. He has assembled a strong team of like-minded people. Craig also speaks at seminars and conferenced. Some of the companies and conferences he did blockchain education sessions at are Oracle, Xero, Air New Zealand, Blok Tex and trademe. Together with the team, he is also doing a education series on YouTube where he explains upcoming features in-depth for the community.

Alex Vazquez - Chief Technical Officer
Alex is the CTO of Encrypt S and the most active contributor to the NavCoin core Github. He has incredible knowledge of blockchains and proposes and implements solutions for challenges and features. He supports community developers frequently and answers any questions of the community thoroughly. Like Craig, Alex is developing software for the NavCoin ecosystem for a very long time. Alex speaks at universities at times and educates students about the blockchain technology.

Paul Sanderson - Lead Software Engineer
Paul is the Lead Software Engineer at Encrypt S. He has a flair for technology. His technical and management skills are perfectly suited for consultancy and investment advising. He also frequently contributes to the NavCoin core source code.

Rowan Savage - Senior Software Engineer
Rowan is a full stack software engineer with more than a decade experience in developing complex front-end web applications. He joined Encrypt S in February 2018 and has since been involved in the Valence Plattform, the Kauri Wallet and NavCoin Core. You will read more about these feature/projects later.

Carter Xiao - Lead UX/UI Designer
Carter specializes in user-centric design and is also very talented with 3D animation, motion graphics and programming. One of NavCoins core principle is "Simplifying Crypto" and UX/UI is a very important part of that.

Matt Paul - Software Engineer
Like Rowan, Matt is a full stack Software Engineer. He joined the core team in Mai 2017 and has since worked on NavPay, NavPi, the Kauri Wallet and NavCoin Core. Kieren Hyland - Chief Strategy Officer Kieren is one of the employees that are working for Encrypt S for a very long time. He is the CSO and is a digital strategist and growth hacker with a passion for new technology and has a lot of experience in online marketing. Laura Harris - Creative Director Laura has a combination of commercial and creative flair. She manages the social media accounts for NavCoin and ensures, that NavCoins' message is always powerful, relevant and distinctive. John Darby - Content Creator John is an internationally awarded Technology and Financial sector marketing communications specialist. He is one of the Core Content Creators for NavCoin.

Features of NavCoin [2]
The following features are currently available and have been developed in the last months and years. It is sorted from newest to oldest.

Static Block Reward
The soft-fork for the enabling of static block rewards have been accepted and became active recently at 5th January 2019. This means, that the block reward was changed from a percentage based reward to a static reward. This will incentivize the stakers to have their node online 24/7 which increased the security of the network. It also aligns NavCoin with the PoSv3 specification. With this implementation, the yearly inflation will be 3.6% currently and will exponentionally decrease because of the static value of the rewards. Every staked block will now give the staker 2 NAV. Depending on how many people are staking, the yearly percentage varies. With the network weight currently being around 20'000'000 NAV, stakers earn around 10% rewards from staking 24/7.

Cold staking
To provide extra security to participants in the staking process in the NavCoin network, the core team decided to implement cold staking. This allows to store NAV offline and still be able to sign staking inputs. Looking forward, a possible integration into the Ledger Nano S would mean, that one can stake NAV securely from a offline hardware wallet. How cool is that?

OpenAlias
One of the core principle of NAV is to simplify cryptocurrencies. Many non-technical people are deterred from the long, cryptic addresses used in wallets. When sending funds, you have to make sure that every single letter and digit is correct which is nerve-wracking for the average person. NavCoin has implemented OpenAlias, which allows to transform the wallet address into a email-like form. Everyone can register a name like "[[email protected]](mailto:[email protected])". Funds can then be sent to this name, which makes sending crypto much easier and less error-prone.

Community Fund
This is the one big feature I was most excited about. NavCoin core has implemented the first fully decentralized community fund. Acceptance of proposals and release of funds is all approved by the decentralized network. No central authority has access to the fund. The community fund enables everyone to propose their ideas to the NavCoin community and to get paid to implement these ideas. Everyone can propose whatever they like (of course there is a higher rate of success if the proposal contributes to the NavCoin ecosystem ;-)). In fact, this article was sponsored by the NAV-Community by voting "yes" for my proposal. The fund works like this:
For a fee of 50 NAV, everyone can create and present his idea/proposal to the entire NavCoin network. The fee is here to help prevent spam attacks. Proposals can literally be anything - be it development, marketing or anything else you can some up with.
After creating the proposal, everyone contributing to the NavCoin network can then decide if they like the proposal of not. They vote with "Yes" or "No" for the acceptance of the proposal. Voting happens via staking. Every transaction that gets validated by you gives you one vote. This means that the more NAV you are staking, the higher your voting weight is.
The proposal stays in the state "Pending" until it is accepted or rejected. To be accepted, a proposal has to have a participation of at least 50% of all staked blocks and at least 75% of these votes have to be "Yes"-votes. Like-wise to be rejected a proposal need 50% participation of the network and 75% of these votes have to be "No"-votes. Additionally, if a proposal didn't pass after 6 voting cycles (about 6 weeks) it is also rejected.
After a proposal has been accepted, the creator of the proposal can start his work. When the work is finished, or at in the proposal defined checkpoints, the proposal creator can create a payment request for the full or part of the requested funds.
The NavCoin network can then again decide, if the work is what the creator promised to do and vote for the funds or reject the payment request because it was not what he promised. This mechanism ensures, that the funds are only release if the creator of the proposal did what he promised. The NavCoin network decides everything, there is no central authority which makes the community fund 100% decentralized.
The community fund is quite new but there have already been some proposals that were accepted like paying for the development & hosting of NAV block explorer, the creation and distribution of NAV car stickers to the community for free (or paid by the community fund), the funding of interns for NavCoin Core, translation of the website into other languages and YouTube videos. What ideas could you come up with? By the way: this article was also sponsored by the community fund :-)

Proof of Stake
Like said before, NavCoin uses the Proof of Stake algorithm to create and validate blocks. Participants of the NavCoin network can earn rewards by putting their coins to stake and thus validating blocks and securing the network. The reward used to be 4% fixed but recently changed with the implementation of PoSv3. Currently, rewards for stakers that are staking 24/7 is about 10% but it is dependent on how many people are staking. If more nodes come online, this reward will go down. If 90% of all NAVs would be at stake, stakers would still earn 4%.

Tutorials And Guidelines [3]
The NavCoin Core team pushes the community to contribute to the NavCoin ecosystem constantly. They emphasize that NavCoin is an open source project and everyone can contribute. The team tries to make it as easy as possible for the average person to contribute and thus created different tutorials and guidelines.

Tutorials To Contribute To The Website
The whole website is open source. Everyone can contribute to the website. The team created different guides for people to follow [4].

The NavCoin Developer Manifesto
The content creator core team has build a developer manifesto. It defines the values that should be uphold like for example that they will always operate in the best interest of the network. If defines the principles, purposes, scope of involvement and operational requirements [5].

The NavCoin Content Creation Manifesto
Similar to the developer manifesto, there is also a content creation manifesto. Again it defines the principles for creating content, the purpose, the scope of involvement and the operational requirements [6].

NavCoin Brand Guidelines
In addition to the content creation manifesto, there is also a brand guideline booklet. This should help content creators to create images, videos, articles etc. in the same style as the core team. It defines the NAV brand. The brand guidelines contain definitions, the language to use (words to use, words not to use), the tone of voice, what the community aspires to be and what we discourage to be. It also contains the logo pack which can be used in graphics etc. It describes correct logo spacing, logo placement, the colors of NAV and different web assets. It gives tips about gradients and overlays, the typefaces (with a font pack) and many more. Check it out yourself [7].

NavCoin Educational Series
The core team has decided to actively involve the community in the creation of new features. For this reason and to allow users to ask questions, they created the NavCoin Educational Series. The core team schedules an online live meetup which can be joined by everyone. On YouTube they do live-streams and explain upcoming features. Examples of these series are explanations for cold staking, static rewards (PoSv3) and the community fund. The community can ask questions live and the core team will answer them immediately.

Community
During the last year there have been an influx of software developers from the community starting to create features for NAV.

navexplorer.com
An examples is navexplorer.com which is programmed by community developer prodpeak and is a block explorer for NavCoin. Additionally, it functions as a interface to see what is going on in the community fund. It shows pending proposals and payment requests.

NEXT Wallet
The NEXT Wallet is an alternative wallet for NAV and other cryptocurrencies. It has a beautiful user interface and is additionally the easiest interface to interact with the community fund (create proposals, create payment requests and vote for proposals and payment requests). It is programmed by community developer sakdeniz who put hundreds of hours into it during last year.

There were also some marketing activities starting to emerge with the release of the community fund. Some of these were for example free stickers for everyone in the NAV community to stick to their car / shop / window etc. or YouTube videos of CryptoCandor and Cryptomoonie that explained the details of NAV. I am sure, that with the 500'000 NAV available in the community fund per year there will be an influx of gread ideas - development as well as marketing activities - that will be funded.

The Future

Introduction
These features are planned for the future. Many of the following features are part of the 2019 roadmap. Some will not be described in great detail because not much is known about them yet. I've still listed them as they are part of what is yet to come.

Features
Rimu - Improved Privacy Solution
NavCoin used to be a optional privacy coin. That means, that you could choose to send a transaction in private. NavCoin was criticized for the way it handles private payments because it relied on a few servers which didn't make it that decentralized. The technology was called "NavTech" and was a secondary blockchain that obscured the transaction and the amount that was sent. NavCoin Core is currently developing a new improved privacy solution that will make the private payment system completely trustless and districuted and runs at a protocol level. Alex of the NavCoin Core team has published a paper that describes this new privacy solution. It's called Zero Confidential Transactions and can be found here: https://www.researchgate.net/publication/330366788_ZeroCT_Improving_Zerocoin_with_Confidential_Transactions_and_more. What I want to highlight is the collaboration between Alex as the proposer of the solution and the Veil team, a Bitcoin Core developer and Moneros main cryptographer as reviewers. When the best work together, it will be interesting to see what the outcome is!

Valence Plattform [8]
Valence is an applied Blockchain platform that can help businesses realise the tangible benefits of blockchain. You can think of Valence as a platform with which you can build Anonymous Distributed Applications (aDapps) with. But Valence is a different kind of platform that enables developers to create new types of blockchain applications. The problem with current (turing complete) dApp platforms are their complexity and rigid nature. Security holes in smart contracts and scaling issues happen frequently [9].
Valence provides transitional pathways that let businesses migrate only part of their activities to the blockchain without having to restructure their entire business model [9].
Valence will provide a spectrum of blockchain application solutions which sit along the decentralized spectrum, offering businesses simple ways to dip their toes into the blockchain at minimal risk or complexity [9].
Thanks to the proof of stake nature of the Valence blockchain, more of a node's resources can be used for processing and routing application data which makes the platform faster and scalable.
Valence aims to make building blockchain applications as accessible to the general public as WordPress or Squarespace has made building websites.
The developers NavCoin and Valence aim to make Valence extremely easy to work with:
A Valence application could be an open source mobile or web application that submits unencrypted or encrypted data directly to the blockchain. The only configuration necessary for the app developer would be setting up the data structure. Once they've done that they can start writing to the blockchain immediately.
The Valence blockchain interface is language agnostic, meaning developers are free to build applications in whichever language they're familiar with, which greatly reduces the barrier to entry.
As the platform progresses, Valence will introduce more and more smart contract templates in collaboration with the development community. These will be like plugins that users can simply select and configure for their application, without having to reinvent the wheel and risk contract errors or spend countless hours of research to program them.

NavShopper
The following information is taken from the latest weekly news: NavShopper is a new project which will allow people to spend NavCoin on a growing list of retailers and service providers. NavShopper sits between traditional retailers accepting fiat and NavCoin users and purchases products on behalf of the user by managing the crypt-fiat conversion, payment and shipping. This project will unlock many more ways for people to spend NAV on existing websites/marketplaces without requiring each site to individually accept cryptocurrencies. Some of the prototypes we are working on include crediting your Uber account, buying products on Amazon and donating to charities.

Kauri Wallet
The Kauri Wallet aims to be an open-source, multi-currency wallet which functions as a foundation for other features.

Kauri Enhanced
Enhancements to the Kauri Wallet will allow multiple accounts, pin numbers, recurring payments and more.

Kauri DAEx
The Kauri DAEx is a Decentralised Atomic Exchange that utilises the features of the Kauri Wallet and enables users to create safe peer to peer atomic exchanges for any currency supported by the Kauri Wallet. NavDelta NavDelta will be a payment gateway that allows users to spend NAV at any business which accepts currencies supported by the Kauri Wallet. NavMorph NavMorph is a fusion of Rimu and Kauri DAEx and will allow to privately send every cryptocurrency supported by the Kauri Wallet.

Outro

If you have made it this far: Congratulations! You have learned about how NAV evolved, what its current state is and what the future will bring. To sum all up: NavCoin has made incredible progress during last year and released many long awaited features despite the bear market. Many more exciting features are yet to come and it's going to be very interesting to see where we will stand on this day next year.

Giveaway

Unfortunately, the giveaway was not possible in the cryptocurrency-subreddit because of their rules, so I'm doing it here :-) As a surprise, in the next few hours I am going to send some NAV to everyone who wants to try out the awesome features you have read about above.
To get your NAVs, all you have to do is the following:
If you liked the experience, I'd be happy to hear back from you :)

References

[1] https://encrypt-s.com/company/
[2] https://navcoin.org/en/roadmap/
[3] https://navhub.org/get-involved/
[4] https://navhub.org/how-to-guide/
[5] https://navhub.org/assets/NavCoinDeveloperManifesto.pdf
[6] https://navhub.org/assets/NavCoinContentManifesto.pdf
[7] https://navhub.org/assets/NavCoinBrandGuidelines.pdf
[8] https://valenceplatform.org/
[9] https://valenceplatform.org/learn/business-on-the-blockchain-made-easy/
[10] https://bitcointalk.org/index.php?topic=679791.msg8320228#msg8320228
submitted by crypto_sIF to CryptoCurrency [link] [comments]

Bitcoin Cash Roadmap, Eth2.0, and Handshake Protocol With Mark Tyneway From handshake.org How To Buy Bitcoin Cash [Quick And Easy Guide] Schnorr Signatures Might Be Bitcoin’s Next Step Forward ... DigiByte (DGB) - New Road Map Will Revitalize #DGB - What is SegWit? - DGBAT Bitcoin Tech Update with Andrew Poelstra

Bitcoin Cash brings the sound of money to the world, fulfilling the original promise of Bitcoin as “Peer-to-Peer Electronic Cash”. Merchants and users are empowered with low fees and reliable confirmations. The future shines brightly with unrestricted growth, global adoption, permissionless innovation, and decentralized development. Bitcoin ₿) is a ... Reasons for this decline include high transaction fees due to bitcoin's scalability issues and long transaction times. Bloomberg reported that the largest 17 crypto merchant-processing services handled $69 million in June 2018, down from $411 million in September 2017. Bitcoin is "not actually usable" for retail transactions because of high costs and the inability to ... During Blockchain Week in Shanghai, tech giant Microsoft revealed its roadmap for the Bletchley Blockchain Project. The announcement was introduced by Marley Gray, the program manager of Azure’s blockchain engineering team. Also read: Microsoft & IBM Declare Blockchain Open for BusinessSponsored Links Microsoft’s Bletchley and Cryptlet Roadmap Project Bletchley wants to start harnessing ... Apirone was born from the initiative of crypto-enthusiasts, programmers and designers, who dream of enhancing bitcoin and seek simplicity so as to encourage widespread use. The road is long, sometimes winding and full of obstacles, but we are moving at a steady pace in the right direction. Here is our roadmap, welcome on board! During Blockchain Week in Shanghai , the technology giant Microsoft revealed its roadmap for the Bletchley Blockchain Project. The announcement was introduc

[index] [10058] [32587] [25328] [6470] [15481] [7125] [7358] [34844] [214] [2023]

Bitcoin Cash Roadmap, Eth2.0, and Handshake Protocol With Mark Tyneway From handshake.org

RSK (Rootstock) Smart Bitcoin and Scalability - Duration: 34:30. TokenMarket 514 views. 34:30. Eliud Kipchoge - 15x1000m before @berlinmarathon - Duration: 5:02. RUN'IX Recommended for you. 5:02 ... On Chain Scalability - Bitcoin Cash follows the Nakamoto roadmap of global adoption with on-chain scaling. As a first step, the blocksize limit has been made adjustable, with an increased default ... The Schnorr signatures algorithm promises to help to address one of the most pressing problems affecting Bitcoin today: scalability. Additionally, Schnorr si... How important are privacy improvements to Bitcoin in the roadmap? How will second layers and atomic swaps help with this? When will Schnorr signatures / signature aggregation be added to Bitcoin? In today's video, CryptoCurrently covers #Digibyte #DGB latest roadmap, and why it could revitalize the #cryptocurrency and send it to new heights. While DigiByte came from little beginnings in ...

#