Welcome to The Understory Series — a series dedicated to projects that we believe show innovation and quality level far surpassing known crypto standards. This article is a recap of a discussion panel conducted in the Jungle Discord where the team answered questions from the community throughout a several day period.
Chase S: Just want to say welcome to @nyzo — our latest Understory project!
To get things started off, could you please do a very short introduction to what NYZO is and what‘s your USP (Unique selling proposition)?
Nyzo: Hi!
Nyzo is a blockchain/cryptocurrency that runs on a system we call “proof of diversity.”
We don’t feel that we’ve met these goals fully, but we have one major technical USP and one major non-technical USP.
On the technical side, we think that Nyzo can be the first blockchain that scales to meet whatever demand anyone throws at it without sacrificing security or decentralization. On the non-technical side, we think that the fee structure will allow Nyzo to be indefinitely sustainable in a way that works for both the verifiers and the users.
For positioning, we hope that Nyzo becomes a truly native digital currency, providing opportunities and solutions that aren’t possible with conventional systems or other cryptocurrencies.
Chase S: Can you dive a bit deeper into what proof of diversity is and how it differs from traditional POW/POS coins?
Nyzo: The idea comes from a few different directions, and understanding where it comes from helps in understanding what it is.
First, we felt that PoW was wasteful, and we also felt that it wasn’t really that secure.
The wasteful part doesn’t need explanation, but the “not really secure” part probably does. If you look at pure PoW, anyone can take control of any blockchain at any time with enough computing power. That’s a problem. Maybe not for Bitcoin right now, but for a lot of the smaller coins. And you have to worry when block rewards get reduced and mining becomes less profitable. The expense to take over the Bitcoin blockchain would be huge, but the potential reward would be huge, also. So, we wanted something more secure than PoW, not only for the biggest PoD blockchain in the world, but also for all the smaller ones.
And then there’s PoS. Lots of different implementations fall under the PoS umbrella, and I would even accept PoD being described as a form of PoS. Where the “stake” is the investment you made to join the cycle — running a verifier, or many verifiers, trying to get into the cycle. And once you are in the cycle, you have to maintain your verifier and contribute to the system to stay in the cycle. So it’s a continuous investment.
But going back to the “few different directions,” we looked at different proof systems, but we also looked at the huge disparity between how easy/cheap it is to secure accounts and transactions vs. how difficult/expensive it is to secure the blockchain. And we wanted to move the blockchain to the transaction model. If you hold the key for an account, then you control the account. In PoD, if you hold the key for an in-cycle verifier, you share in control of the direction of the blockchain.
So that led to the idea of the cycle, and the proof-of-diversity rules are basically just ground rules for allowing natural evolution of the democracy established by the cycle. The entry process is still ugly. It’s far, far better than it used to be, but it’s a part of the system that we’re still not really happy with.
Once you are in the cycle, the rules are easy and clean and efficient. But the entry pool/queue, because it deals with the real world outside the clean rules of the system, is still very wasteful and subject to manipulation. Right now, we have close to 8000 verifiers doing nothing useful, earning nothing. That’s not good for a system that aspires to eliminate wastefulness. And we have the DDoS issues with new verifiers trying to enter. The next sentinel release will provide a rather robust solution to that particular issue, but it’s definitely a problem right now.
Ropo: Can you consider to make a new website redesign soon ? It would be great to have something with a better UX and more attractive.
Nyzo: We plan on replacing the website with a copy of the client and having a separate tech site that is a kind of hierarchical version of our release notes. The Javascript animations need to die, and the space on the sides is a waste. But I’d argue that the overall UX is quite good. The website gives you the information it needs to give you, and it’s easy to understand. I know I’m not the only one who leaves the mesh page open 24 hours a day.
jimtalksdata: What are your views on proof of work and the need for a robust fee market? and do you have ideas for on-chain scripting, and what that would look like on Nyzo, or do you see off-chain solutions as more viable?
Nyzo: I personally think that proof-of-work is a non-solution to the blockchain problem. I’ve been studying digital money systems — reading the latest research, playing with implementations — since the late 90s. When I first saw Bitcoin, I thought that it was almost a viable system. But proof-of-work seemed like a bit of a joke for actually securing the chain, and I figured people would realize that soon enough and it would never really gain traction. I was very, very wrong about Bitcoin’s ability to gain traction, but I still feel that PoW is not quite a real solution to securing a blockchain.
Regarding proof-of-work, I don’t mean to be dismissive of Bitcoin or anything that came before us. I find inflammatory statements (like the one I made above) to be counterproductive and rude. A better way to position that statement would be to say that I wouldn’t want to have to engineer the problems associated with proof of work. And this isn’t me trying to be politically correct — I genuinely respect and appreciate the work that so many have done in the cryptocurrency space.
And to revisit the UX stuff with the website: I know it’s not beautiful by modern, conventional standards, but we’ve made a conscious decision to avoid spending too much time on the details of user interfaces, instead choosing to focus on the big UX issues of presenting the state of the cycle and mesh and the technical issues associated with the blockchain.
I think Nyzo has been around long enough now that everyone following the project can see the general work capacity of the Nyzo team. We have no plans to drastically change the rate at which we contribute to the project, and every little thing that we focus on means some other little thing that we can’t focus on. We have to pick our battles, and we’re a long way from caring which sans-serif font we use or using hero images on the website.
Regarding fees, we are very happy with the current state of the fee structure, with a few exceptions.
What we’re happy with: the 0.25% fee is really low by conventional payment standards, and it doesn’t inhibit real commerce in a substantial way. If someone pays you $0.02 for an article you have published online, do you really care that you are losing $0.00005 of that to processing fees? I think most people will be appreciative that they have a new opportunity for monetization that doesn’t involve adding crappy Javascript and serving annoying ads.
Where we are not happy with fees: cold storage for users and exchanges. This is responsible behavior that we want to encourage, and we are currently discouraging that with the fee structure we have in place. We’d like to work on that.
The whole set-your-own-fee idea seems terribly dysfunctional to me. Seriously, how does this seem like a good idea to anyone? (Again, I should avoid inflammatory comments) But we think that’s just a distraction. We set a fee that’s so low that it shouldn’t matter for ordinary commerce, but it should be enough to support verifiers indefinitely if the system really catches on.
Finally, we have no plans for on-chain scripting, for several reasons.
First, back to the general work capacity of the Nyzo team, we want to have a functioning monetary system that is scalable to whatever levels people want to use it, while remaining decentralized, democratic, and secure, and on-chain scripting is just too much to handle. But there’s a lot more to it.
I can see the value in a Turing-complete scripting option, but I also see the value in a more limited scripting option that offers more assurances of security and robustness in exchange for less flexibility
sidenote: I love that more people are starting to understand Turing completeness I remember with great fondness the first time a professor talking about a Turing machine, and in my notes for the class, I spelled it as “touring machine”
So, I can see the justification for two very different scripting languages, and do we want to implement both on chain? The modularity afforded by off-chain solutions is attractive in this case.
There’s also an advantage to the modularity of brokenness. Scripting is difficult. Languages are difficult. Secure scripting is almost impossible. If you have broken on-chain scripting, you have an emergency that needs to be fixed to continue using the blockchain. If you have broken off-chain scripting, you simply stop using that scriping until it is fixed.
Chase S: What mechanisms are in place to keep people paying attention to their verifiers? Specifically as it relates to the upcoming cycle fund and how those funds get spent — what happens if not enough people are paying attention to current events for 75% to vote for payments that need to be made (for bounties, etc)
Nyzo: The verifier scoring and removal vote mechanism is the primary mechanism for encouraging people to properly maintain their verifiers.
The upcoming cycle fund is interesting. The 75% threshold is a high threshold, but seeing community involvement during problems with the cycle, it seems that 75% is an attainable level.
Really, though, we need to make verifiers much more profitable than they are now.
Chase S: So will scores be impacted (significantly) by failure to vote on payments when the time comes? Also, have you considered any kind of mechanism for casting votes via proxy for those who will be away from their verifiers for extended periods?
Nyzo: That’s one of the cool things about proof-of-diversity. If the system really takes off, then verifiers will become much more profitable, and everyone in the cycle will have much more incentive to maintain their verifiers. The scores, as they are currently calculated, will not be impacted at all by a failure to vote.
But that could be added to the system, and we’d be open to implementing something like that if it is necessary.
Ultimately, the removal process is an entirely democratic process. We haven’t built a mechanism into the code for it, but it would be trivial to add a manual override for removal votes, just like the manual override for entry votes.
Set Animals: Since the dev fund is now gradually released over time based on organic transaction volume, how is the team looking to start developing that side of Nyzo? Are there plans/products/integrations in the works? Is it something where you are hoping the community or outside interests/companies start to create new ways to use/integrate Nyzo?
Nyzo: We have a lot of ideas for this. The big focus now is getting the blockchain v0 to v1 change implemented. We also need to get the sentinel change implemented for the sentinel to help new verifiers join the cycle.
But Micropay is the first big step for this. We’re going to get back to Micropay after the other changes are in place, and we already have ideas to make the Micropay server more efficient and more reliable.
Also, the Nyzo codebase is going to start acting as an API server. This will be run-mode dependent, just like the various web server functions that are available now.
So that should make integrations much easier — you can run the Nyzo codebase as a local trusted API server, and it can interact with the mesh on one side and whatever it needs to interact with on the other side. If no one else implements it, we’ll eventually do a Micropay WordPress plugin. Basically, we want Nyzo to become the native currency of the Internet. We’re always going to prioritize core blockchain functionality: security, stability, and scalability. But any extra cycles that we have beyond that will go into trying to increase usefulness of the system to work toward the goal of long-term sustainability.
Also, the cycle fund should help with that. Right now, seed transactions dominate what verifiers earn. But what if they were only a small fraction of what verifiers earn? Not because of a decrease in seed transactions, but because organic transactions increase significantly. The cycle should be motivated to spend the cycle funds in a way that will increase organic transactions, because that will increase verifier earnings. It’s a win for everyone.
And to provide a concrete, simple example: if someone develops an amazing, easy-to-use Micropay WordPress plugin, I think the cycle should vote for a payment to the developer of that plugin.
And I know this sounds a bit like a non-plan and a lot of hand waving, and it is to some extent. But just think of the potential of an actually usable micropayment system for the Internet. Print articles, audio streaming, video streaming. Cut out all the crappy ads, cut out all the middlemen, cut out all the ridiculous freemium subscription models where a few users pay a hefty subscription fee to support the system while most users pay nothing. Everyone pays a reasonable amount for the content they consume, and 99.75% of that amount goes directly to the provider of that content. To me, that sounds like something that could make the internet a much better place for everyone. And there’s so much potential for growth there that I don’t think we need to worry too much how it’s going to happen. If we just keep pushing forward, improving the core system, and exploring ideas, we’re going to find ourselves in a very good place very quickly.
Teodor: I found myself painful to run and to add the “verifiers” on the network and I gave up. Has the team any plans to make an easier way to deploy verifiers, maybe few clicks solution for those that are not very technical?
The team has stated they will deactivate the official nyzo verifiers. Aren’t these verifiers used for debugging in circumstances where the chain experiences issues (like what happened recently when a lot of verifiers dropped from cycle)?
Nyzo: We will continue to work to make everything about deploying and managing verifiers easier. But we could put the entire system in a bad spot if we made the initial deployment too easy with the current overall maturity of the system.
There are a lot of things that should not happen but still do happen consistently.
- Verifiers should not crash due to excess traffic.
- Verifiers should not fall behind when they have intermittent network issues.
- Verifiers should not be unable to catch back up when they do fall behind.
Right now, the difficulty of the initial setup is in line with the overall difficulty of managing a verifier. We’d like to lower the overall difficulty of everything in the system, but lowering the initial difficulty before improving the long-term stability and manageability would not be good for the overall health of the system.
The team controls 10 other in-cycle verifiers: Argo 746, Argo 752, Killr, and seven others that we have not made public. When we shut down the 10 official verifiers, those 10 will be used for all the purposes for which we are currently using the official verifiers.
Having an in-cycle verifier you control is incredibly useful, especially for debugging. But we want to highlight what we’ve said all along: the “official” verifiers are nothing special. As anyone who has seen Nyzo’s problems over the last 11 months can attest, we actually have very little control over the system, and it’s been highly decentralized in practice from the day of launch.
Chase S: Would you ever consider doing any kind of KYC for people starting verifiers?
How concerned are you (if at all) about cryptocurrency regulations? Is that part of the reason the team has remained anonymous (outside of encouraging decentralization)?
Nyzo: I think that it would be really cool for people to people operating verifiers to disclose who they are, and I’d even love to see some in-cycle verifiers run by exchanges or other companies involved in the crypto space. While Nyzo is very transparent to both in-cycle and out-of-cycle users, you do get a special insight into the operation of the cycle when you are in it: receiving all blocks immediately, being able to request unfrozen blocks, and receiving all votes.
At some point, if the cycle chooses to do so, there could be a KYC requirement if you want to enter the lottery. That would actually be a really good way to eliminate waste. Each person goes through some kind of verification process, and then they get one spot in the lottery. Of course, there are a lot of details that would need to be worked out, and I’ve put very little time into thinking about this answer, so don’t read this as a proposal. But, superficially, it seems like a good idea.
I hope that Nyzo influences the discussion about cryptocurrency regulations in a positive way. In a few years, I’d could totally see Nyzo’s Micropay system being discussed by legislators as they are debating regulation. We’re still at a very early stage, but if it really works out how we want it to work out, then it will be providing real economic opportunities to content creators that simply did not exist before. That’s a really good thing, and I think regulators will appreciate the positive impact that Nyzo is having on the economy.
Our choice to remain anonymous is for three reasons, and there’s a bit of overlap among them:
(1) decentralization
(2) personal privacy/security, and
(3) a general distaste for the hype/grandstanding that seems so prevalent in crypto
Starting with #3 — think of some big names in crypto
haha… I won’t even mention any names — I don’t want to get sued — but a lot of the big names in crypto are real characters, and that’s just not us
I think #2 is self-explanatory.
And, for #1, I’d like to see Nyzo move beyond the BDFL stage to something that is truly owned by the community with no single team controlling it.
Chase S: Can you give a summary of what a micropayment system is/does for those who may not be familiar with the term?
Nyzo:
And that provides a little more detail on where we’d like to go with decentralization of development.
Micropay is a lightweight way of using Nyzo that shifts as much burden as possible to the person receiving the payment to make it as easy as possible for someone to send small payments.
We have a simple proof-of-concept system running here:
As the site explains, 100% of the site code is available in the main Nyzo repo, and 100% of the site content is available in the micropayExample repo.
Right now, in order to make Micropay payments, you have to have a local version of the Micropay client running. There’s still a lot we need to do to make this easier. But, eventually — and this is just simple engineering that needs to be worked out, not any big problems that need to be figured out — regular users will be able to confidently and securely pay for content on the internet with a single click with Nyzo.
The basic process is this:
(1) the receiver sends a suggested transaction to the person wanting to access content,
(2) the person wanting to access content reviews and approves the transaction, sending the signed transaction to the receiver,
(3) the receiver reviews the transaction, provides access to the content, and then forwards the transaction to the verifier that’s in the correct cycle position to make the block that will incorporate the transaction.
Chase S: Have you (or the team) worked on any other crypto projects in the past?
What do you say to the people who claim nyzo is centralized because some people got many verifiers in when the cycle was still small?
How hard is it for new exchanges to integrate nyzo and how important do you think additional exchanges are in the growth of nyzo?
Nyzo: No one on the team has worked on a crypto project in the past. We’ve worked on some other interesting projects in our respective fields, but no cryptocurrencies.
I agree that the early growth of the cycle did lead to some centralization. But I still think it’s more decentralized than most cryptocurrencies. And it’s naturally going to become more decentralized over time. That’s the really important point.
I think that Nyzo is an especially difficult coin to integrate for several reasons. It has an odd/novel design, so a lot of assumptions about other blockchains don’t apply, and there’s a lot of learning that needs to take place to work effectively with Nyzo. The home-grown messaging system makes it more difficult, too.
I think that more exchanges would help Nyzo grow, but we’re not especially concerned about growth. As I’ve said many times, we want to focus on the technical aspects. We want to make the system more secure, more robust, more decentralized, more usable. We want to make the system intrinsically more valuable. If you do all that, the growth will happen, and it will be growth that will be less likely to burn people along the way.
Slow, steady growth. Less hype, more substance.
Petar: Nyzo critics often say that Nyzo is not as decentralized as it appears on the first look as most verifiers are hosted on a few (2–3) cloud providers. Since Nyzo is heavily dependant on uptime and nodes can not join and leave at will as is the case with Bitcoin, what would be the best ways to improve things in this aspect? Are average-household-hosted verifiers possible given current conditions?
Nyzo: I’d like to see a breakdown of how many verifiers are hosted on each cloud provider. I do think we need to improve on that, and visualizing problems is a good first step to addressing them.
The ownership of keys is the real decentralization, and the sentinel provides a mechanism to buffer the uptime requirements. If an entire cloud provider or region goes down, then your sentinel can cover for you until you get your private keys running on another provider.
I don’t want to misrepresent the current state of the system, though. A lot of what I’m saying now is not the current reality of the system, or at least it wasn’t when the chain last stalled. The last stall was a nice reminder at how fragile the system can still be. Though we’ve addressed most of the issues that caused the stall and caused many verifiers to be dropped from the cycle, we can’t pretend that the system is more robust than it is. We still have a lot of work to do.
One point worth noting, though: even when this system is in a much better state than it is now, you will always need to have at least one sentinel running in a physically different place than your verifiers.
I think from a physical centralization standpoint, we need to consider both security of private keys and the possibility that Nyzo will be banned from cloud providers.
For security of private keys, we need to have a key-switch option available: a temporary key is stored on the verifier, and the key is swapped in at runtime from a remote location. So, while you would have the actual verifier key in RAM, it would not be persisted on the verifier.
To avoid being banned, I think we just want to be good citizens. Keep CPU usage as low as possible, keep network usage as low as possible, and ensure that we make the system as profitable as we can for verifiers so that verifiers will gladly spend the money necessary to pay for proper infrastructure.
So often, “banning” is just due to people wanting to do really intensive workloads on discount providers (constantly maxing out a CPU on a cheap provider for mining, for example).
I do think that a good home internet connection might be sufficient for maintaining a verifier now, but I don’t think it will continue to be sufficient as our transaction volume increases. Either cloud providers, cohosting, or paying for a legit business internet connection will likely be required. I also think that a home connection will remain perpetually viable for sentinels.
Petar: Nice, you just answered the two follow up questions I wanted to ask in one go :) Let’s expand on the private key security so that our readers can understand it better. Each verifier stores its private key in a plain text file currently, and sentinels do the same thing for all verifier private keys they manage. This is a potentially big security risk that can be exploited by both hackers and cloud providers as they can leverage their access and steal private keys. Basically, not your hardware, not your keys apply. Does private key need to remain in RAM at all times, or can it be encrypted? And are there any additional security practices that can be implemented other than the remote key loading you mentioned? What about sentinels that are private key honey pots at the moment?
Nyzo: The private key does need to remain in RAM at all times, as it is used to sign all messages. Ultimately, no amount of engineering (that I can imagine right now) can robustly solve this issue. However, use of surrogate keys could solve the issue: the “master” key for each verifier would periodically delegate a “surrogate” key that would be used in normal operation. The master key could be kept in a secure location, as it would only need to send a single message infrequently to designate a new surrogate key. If the surrogate key was compromised, then the master key would designate a new surrogate key to regain control of the verifier.
Johntradez: I saw in the Nyzo Discord that the devs mentioned if they could go back they would distribute each block reward over every verifier in the cycle instead of only 10 verifiers as it is now. Is this something that you are considering changing?
Nyzo: I do like the idea of making the whole-cycle fee change. It seems fairer, especially if a whale transaction comes through. All in-cycle verifiers are working all the time to move the blockchain forward, so it makes sense that all in-cycle verifiers should share equally in rewards, and it eliminates some possibility for manipulation of the system through strategically placed transactions.
The block-4,500,000 change will be our first blockchain change, and it should provide a basis for making future changes easier.
Perhaps this change could be incorporated with the cold-storage fee changes we have been discussing over in the Nyzo general channel.
Maloris: You mentioned in “Building a sustainable blockchain“ announcement that you find mined cryptocurrency with more than a 5% premine or any sort of ICO as unjustifiable. At the same time, you allocated 47% of Nyzo total supply to the Nyzo team that is gradually released depending on transactional volume. Can you explain your thought process, and how is it different and justified in Nyzo case?
Nyzo: It’s explained rather clearly in that statement:
Chase S: So you’re saying it’s not the percentage itself that’s unjustifiable, but rather the impact a percentage that level or higher would have on the security of the chain? (just to make sure I’m clear what you’re saying)
Nyzo: I’m saying that we want a strong blockchain. In a mined cryptocurrency, a premine weakens the blockchain. In Nyzo, a seed account is a necessary placeholder while we’re working to increase organic transaction volume, but the seed account is nothing more than a necessary evil. The real thing that we must work toward is organic transaction fees. And we have designed a system that, if it is successful, will reward all verifiers more and more over time, not less and less like a mined system with reward dropoffs.
To look at it another way: let’s say we allocate that 47% to a seed account. We stop working on the project, because we have no incentive to work on it anymore. And the verifiers get all those coins, and then the coins dry up and Nyzo likely dies a slow death.
I’m not sure. Maybe not: maybe someone else picks up the development, and Nyzo prospers. That would be cool.
But if we only cash out coins relative to what’s earned in organic transactions, it’s essentially equivalent to us putting 100% of those coins into a seed account. With the added bonus that, unlike a seed account, the organic transactions that are built up, and all the things that are implemented to encourage organic transactions (and all the value that Nyzo contributes to the world) doesn’t just go away at some point. Those things will build and grow, and they should be able to perpetually sustain, like any healthy economy.
I really do think the statement explains it well. Even consider, like the statement says, that we have enough organic transactions to generate 47 million Nyzos in transaction fees in the first year after this change is implemented. That means that the cycle earns 47 million Nyzos in that first year. I’m not suggesting anything remotely close to that is going to happen. But, my point is: this is a situation where, regardless of the outcome, we will only be able to recover our expenses and/or profit if the system remains strong and the verifiers are rewarded. The outcome cannot possibly be a win or a break-even for us unless it’s a huge win for everyone else involved. Try to find another cryptocurrency that can make that claim without laughing.
Chase S: In your opinion, what is the biggest weakness nyzo has right now? Is it just how young the project is?
Nyzo: The youth of the project is definitely the biggest weakness. It takes time to find all the flaws of a system, and you can’t just force a system to mature. Every little (or huge) issue that we encounter is an opportunity to learn, to make the system more robust.
Chase S: What are the biggest things that aren’t being worked on right now that you think nyzo will one day be capable of?
Nyzo: The biggest thing we aren’t working on right now is transaction throughput. This is the right choice. Stability and security are more important. We have had a total of 75 organic transactions in the last 48 hours of blocks. But as we get more people to use the system, we will need to make sure that we can handle the increased volume.
Chase S: Once the official verifiers are shut down, will you continue to interact with the community on discord or will your only contribution be committing code after that point (i.e. will you “put it in the hands of the community” at that point)?
Nyzo: Shutting down of the Nyzo verifiers will be of little consequence. I’ll still be on Discord. We’ll keep operating as we are right now. Initially, we wanted to drop out at the year-1 mark, but it quickly became clear that wasn’t going to work out well. That’s why we amended the white paper with this:
With the cycle fund, we still hope that competing implementations arise. Personally, I don’t feel that Nyzo will be appropriately decentralized until there is a totally different implementation that verifiers can choose to run instead of the implementation we release. Then, if someone doesn’t like how we implement things, or if they don’t agree with features or rule changes that we implement, then they don’t have to use our implementation. Until that point comes, we still have too much power over this project, and we still have too much power over the blockchain.
Chase S: A lot of people new to NYZO think it sounds an awful lot like NANO in it’s intended use/purpose. Can you talk about the main separators between the two projects?
Nyzo: I’d prefer not to compare and contrast Nyzo and Nano in detail, because I don’t have enough knowledge of Nano to give it a fair assessment. However, I will point out that in our early discussions of developing Nyzo, we made the decision to stick with a true blockchain structure. No sharding, no sidechains. Just a blockchain. The strength of using an actual blockchain versus other structures should not be ignored. It’s well-researched and well-understood. Just reading Nano’s superficial marketing copy, I can see that it is not a blockchain. But that’s as far as I’ll comment on it. It looks like a really cool project, and I wish them success.
Chase S: (Hypothetically) once the cycle fund is implemented, what will be the mechanism for making the cycle aware of things like bounties that need to be paid out? Will you offer any kind of “recommendation” on amounts to be paid for the bounties?
Also with the 75% requirement for approval; what happens if there aren’t enough people voting yes for this type of payment due to not paying attention? Could the cycle vote to change the requirement to 67%? Have you considered making it mandatory to have a 3:1 ratio of yes vs no votes as long as at least 75% of the cycle votes (to help account for possible apathetic verifiers)?
In theory I would think the more decentralized nyzo becomes, the harder it would be to get such a large majority on the same page, especially with time differences, language barriers, etc. Do you agree with that?
Nyzo: Right now, we only plan to make the basic mechanism available. And, of course, we plan to fund the wallet. If someone provides information that I think is worthy of a bounty, I will mention that information on Discord. I also think that it would be appropriate for me to provide some suggestions on bounty amounts based on the quality of information provided, the severity of the issue, etc. — all the same considerations that currently go into the team’s process for deciding bounties.
The cycle could change the requirement to any value they want to change it to. I recommend keeping it at 75%, but it could be anything.
The mechanism in the initial implementation will be this, and some of the implementation is already released. Each in-cycle verifier will be allowed to create cycle transactions. All verifiers will store no more than one cycle transaction from each in-cycle verifier at a time, to prevent spamming. These transactions will be timestamped, as all transactions must, so they have a natural expiration. If 75% of the cycle chooses to sign a cycle transaction by its scheduled block, then it can be added to that block. The ratio of yes vs. no does not matter, and I’d recommend against incorporating any sort of yes vs. no votes, because that would open a new avenue of potential manipulation.
You cannot fake “yes” votes, but you can easily discard “no” votes.
I think that getting cycle transactions approved will get much easier with time. I think that any additional difficulty due to increased decentralization will be offset and more by increased user experience with the system, improvements to the system, increased interest in Nyzo, etc.
Petar: What are your thoughts regarding privacy, and do you think it might be important in the future for Nyzo use-cases? Is privacy layer something that could be easily added on top of Nyzo?
Chase S: If someone wanted to do a nyzo-style blockchain for non-currency purposes (I.e. smart contracts or decentralized social media, etc) how hard would that be to do?
Nyzo: Both privacy and non-currency purposes would be easy to build on top of Nyzo (or any other good blockchain). From a software design standpoint, the real value of the blockchain is the data layer. While the current Nyzo blockchain integrates some currency-specific features into the blockchain, those would be easy to strip away. Other features would be easy to add, either on-chain or off-chain.
Also, Nyzo’s proof system allows both the small and large blockchains to be secure, unlike PoW blockchains. And you don’t have to play games with the hashing algorithm to provide transient security. Nyzo could provide a solid foundation for a lot of different use cases with very little modification.
Bebop: What do you feel is the biggest disadvantage or weakness of NYZO in it’s current form?
Nyzo: That’s a great question on which to finish. The biggest weakness of Nyzo is its openness, and it will continue to be its biggest weakness. I cannot foresee a time in the future where we say, “We’re good on that; there’s no more work to do.” But we do feel it is a manageable weakness, or we wouldn’t have bothered moving forward with this project at all. Our goals for this project were to create a usable, decentralized, efficient, democratic, secure blockchain. We knew that the openness would be a huge engineering problem. A typical first reaction when some sees Nyzo is, “What about denial-of-service attacks?” Yep, we’re really concerned about those, and we will continue to be. But each time we have to deal with one, we’ll learn, and we’ll get better. I’m sure, as Nyzo’s popularity grows, the attacks will be increasingly more sophisticated. And Nyzo will have to become more sophisticated to deal with them.
CryptOrangutang: This is a great answer to an even better panel. I want to thank you @nyzo and everyone who participated, it was a pleasure getting to know more about Nyzo. Now it’s our turn to this into the article to spread a good word around the community
Petar: I’d also like to thank @nyzo for a great interview, it was a great pleasure like always.
Jungle’s take on NYZO:
Thanks for reading our article. If you want to find more of our work follow CryptoJungle on Twitter and Telegram where we share the work done in our Discord. Cheers!
