Perhaps the jump to vest should look something like:
[(Total XEM)/(avg PoI for new node period)]/(XEM Marketcap)
I'd have to crunch some numbers, but this seems like it would give everyone a more 'fair' entry, again rewarding those who indulge the PoI model the most.
— Edit that equation is waaaay off, but I think the idea of incorporating those variables is sound.
I have re-thought this as I have been reading up on NEM today. From a philosophical standpoint we're facing a problem similar to what is having on the bitcoin dev team ATM.
How do you appease all the currently interested, currently vested and future interested and vested participants?
The only way to do this productively is to ensure their is a 'free market' approach. The tech simply needs to function as a proper architecture to scale efficiently when asked/needed and be secure from a technical standpoint. When the tech begins making decisions for the market we get all sorts of problems (like the large debate currently).
Some Thought Experiments:
The current proposal requires 3mil XEM+ and the reward program banks on the network fee's - if adoption fails to live up to the idea then there exists a possibility for stagnation in the network which is a big gamble. This also has a strong centralization effect on the network and seems to re-introduce a problem that PoI addressed, which is a entity controlling too many nodes, especially nodes that now have extra importance. Now you will never escape manipulation its inherent with any market, but can we eliminate or reduce the impact of said manipulation? Lowering the XEM amount, like the paper says, invites the opportunity for a node spam attack and incorporating any 'hard' limits always gets met with contention somewhere down the line. .
I believe the time a node has existed must come into play, but also a quality score as the purpose is to effectually make a strong backbone for the network. It seems the idea to constantly ping nodes to asses their quality is already there so why not display that quality score to the node operator? Its already there with PoI and the importance score to the network, the parameters that create that score and how that affects rewards would need some tweaking.
For New Nodes:
Importance score = (age of node)*(PoI score)/(total # of new nodes) = x% of the allotted reward pool for each individual node.
So a new node, very enthusiastic about XEM and very active would be the ideal new node operator and this would reward them as such. The thought process being that enthusiasm and higher tx rate would carry over into more real world 'touches', exposing more people to the coin.
For Vested Nodes:
Importance score = (age of vested node)*(PoI Score)*(Quality score)/(total # of vested nodes) = y% of the remaining reward pool given per node.
The reward pool distribution could follow something similar to what is proposed, this still leaves us with a problem when the reward pool runs out if tx fee's fail to be enough sustenance, however if you eliminate the large centralizing buy-in of 3m, which seems almost counter intuitive to PoI as it locks down funds, and instead we played with the numbers and figured out a way that after a new node had reached its vesting period its became a relatively small step financial step to become a vested node beyond a minimum quality score. This should most likely be a function that relates to XEM at its current value and market cap (still thinking on this) - However if they can't obtain the quality or don't want to run a 24/7 node then a 3rd option should exist that removes them from and incentive pools and places their node in another pool that instead of the age of the node being the measure its the active time of the node so something like:
(active node time past 24h)*(PoI Score)/(total # of random nodes)
This re-enforces the incentive to become a pillar in the community, but doesn't alienate the less fortunate and speculators and instead gives them a carrot to remain in the NEM community.
I haven't found a blockchain that has total XEM stats? I hope this at least a bit more clear and thought out!
That is a very complicated solution to a simple problem. If you want to make centralization via botnets a non issue, you make it expensive to centralize the network with a botnet. It is tricky to reward someone for making botnets while discouraging their use. A high quality, near 100% uptime public node costs money and/or time to opporate so make the value of the reward less than the opporating cost. Making payouts directly in XEM caused a problem because if the price on XEM goes up, then the cost of botnet goes down. Instead, make a lottery type asset that pays out large amounts of XEM go the winner. The DAO will also sell tickets to anyone for a fixed price. This way, when XEM goes up, so does the cost of the ticket. Public nodes can either use their tickets or sell them to other users for less than the DAO's price for some quick XEM. To a node operator, they see reduced costs in node operation thanks to the tickets they are selling but it is a speculative market so their tickets may be worth more later... Or less. By hanging onto tickets, they could win big.
That is a very complicated solution to a simple problem. If you want to make centralization via botnets a non issue, you make it expensive to centralize the network with a botnet. It is tricky to reward someone for making botnets while discouraging their use. A high quality, near 100% uptime public node costs money and/or time to opporate so make the value of the reward less than the opporating cost. Making payouts directly in XEM caused a problem because if the price on XEM goes up, then the cost of botnet goes down. Instead, make a lottery type asset that pays out large amounts of XEM go the winner. The DAO will also sell tickets to anyone for a fixed price. This way, when XEM goes up, so does the cost of the ticket. Public nodes can either use their tickets or sell them to other users for less than the DAO's price for some quick XEM. To a node operator, they see reduced costs in node operation thanks to the tickets they are selling but it is a speculative market so their tickets may be worth more later... Or less. By hanging onto tickets, they could win big.
I don't believe trivializing future growth and scalability as 'simple' is in any way correct, these problems, while not truely having much weight on the here and now, are about securing a future not today. This has nothing to do with botnets - they were mentioned as an attack vector because the original proposal mentioned as much. The whole purpose of basing the price on XEM is that XEM fluctuates which means that at any given point in the cost of entry, the cost of startup, and potential return are all variable. So instead of having this variate according to the market you would rather 'freezing' 3 million XEM per node (which is still subject to all of above but now adds a whole new variable as well).
Tickets do not solve the problem whatsoever? The offer no solution for scalability while maintaining decentralization, unless I am missing something?
Adam made a block explorer with the rich list. It gives you a really good idea just how many accounts can run nodes. Or how many nodes a single account could get going by itself.
[url=http://blockexplore.in/search/richlist/]http://blockexplore.in/search/richlist/
remember to that many people are in control of more that one account, so the rich list is actually more concentrated than this appears.
The top 15 account are more or less funds or exchanges.
There is easily enough XEM just being tucked away by top accounts to fund 500 nodes and still have lots left over for a hot wallet.
Its a really hard balance trying to find a way for people to participate, that just want to help and and deserve a tip, verses if we had a low deposit a big player could kick start 50 nodes.
The funny thing is too, NEM has an amazing distribution in that we don't really have very many big players at all. We have a huge middle class and a some (but not many rich accounts) and some (but not many) poor accounts. Once the economy really gets going, it'll be very interesting to see how this shifts and which way.
Adam made a block explorer with the rich list. It gives you a really good idea just how many accounts can run nodes. Or how many nodes a single account could get going by itself.
[url=http://blockexplore.in/search/richlist/]http://blockexplore.in/search/richlist/
remember to that many people are in control of more that one account, so the rich list is actually more concentrated than this appears.
The top 15 account are more or less funds or exchanges.
There is easily enough XEM just being tucked away by top accounts to fund 500 nodes and still have lots left over for a hot wallet.
Its a really hard balance trying to find a way for people to participate, that just want to help and and deserve a tip, verses if we had a low deposit a big player could kick start 50 nodes.
The funny thing is too, NEM has an amazing distribution in that we don't really have very many big players at all. We have a huge middle class and a some (but not many rich accounts) and some (but not many) poor accounts. Once the economy really gets going, it'll be very interesting to see how this shifts and which way.
Thanks for the link! Indeed it is hard to find a balance, but I believe the task almost becomes improbable when you add hard levels to it. By creating a hard level of 3million you have alienated a large % of the population, mostly consumers, but also future adopters with lower capital as by all accounts the price of XEM will increase making it a proportionally greater expense to become a node and eventually cornering off the node market to those with deeper pockets.
Is this ideal? That is when NEM runs the risk of being controlled by the few. While yes my solution is more complex it also scales better over time and creates an inviting economy not a good ol' boys club.
Unless that of course is what everyone wants?
Which is fine too I have my stake *shrug* , however it just doesn't feel like it 'fits' in a PoI model...
That is a very complicated solution to a simple problem. If you want to make centralization via botnets a non issue, you make it expensive to centralize the network with a botnet. It is tricky to reward someone for making botnets while discouraging their use. A high quality, near 100% uptime public node costs money and/or time to opporate so make the value of the reward less than the opporating cost. Making payouts directly in XEM caused a problem because if the price on XEM goes up, then the cost of botnet goes down. Instead, make a lottery type asset that pays out large amounts of XEM go the winner. The DAO will also sell tickets to anyone for a fixed price. This way, when XEM goes up, so does the cost of the ticket. Public nodes can either use their tickets or sell them to other users for less than the DAO's price for some quick XEM. To a node operator, they see reduced costs in node operation thanks to the tickets they are selling but it is a speculative market so their tickets may be worth more later... Or less. By hanging onto tickets, they could win big.
I don't believe trivializing future growth and scalability as 'simple' is in any way correct, these problems, while not truely having much weight on the here and now, are about securing a future not today. This has nothing to do with botnets - they were mentioned as an attack vector because the original proposal mentioned as much. The whole purpose of basing the price on XEM is that XEM fluctuates which means that at any given point in the cost of entry, the cost of startup, and potential return are all variable. So instead of having this variate according to the market you would rather 'freezing' 3 million XEM per node (which is still subject to all of above but now adds a whole new variable as well).
Tickets do not solve the problem whatsoever? The offer no solution for scalability while maintaining decentralization, unless I am missing something?
I am lost... Decentralization is maintained by making a consensus attack so costly to perform that no one could do it. Proof of Work does this through the cost of computing power (51% of all computing power in the network is EXPENSIVE). PoS does this through the cost of the coin itself (to gain 51% of all coins staking requires buying a LOT of coins). PoI also does this through the cost of the coin itself, though less directly (The more coins you send out, the more importance you get; sending out enough coins to get 51% of importance is also expensive).
Someone controlling 51% of all public nodes can also lead to a consensus attack in certain networks. This is true in the case of NEM, especially because of delegated harvesting. Assuming that most people will use delegated harvesting because it is easier, then someone controlling 51% of nodes also controls approximately 51% of importance as about 51% of users will have delegated harvesting active on their nodes. This is why botnets are so bad for NEM.
If botnets aren't the problem you are referring to, than I am unsure what is.
my computer is 4 gigs of RAM and I have super fast internet, at least for my country, so I think my local node I am running 24/7 at home will be okay.
Don't get me wrong... I'm with you!!! ;D
Question:
Do the node health tests allow for unavoidable downtime (reboots, client updates, etc.) or is it almost guaranteed to get hit with the 2880 block penalty if caught during such cases?
I think the document says somebody has a week to update their version before it starts failing tests. And having somebody reboot there node or restart their machine won't affect their scores. But if the turn of a node and leave if off for a while then it will affect them. Or leave it running with an old version after a week then that will hurt too.
Someone controlling 51% of all public nodes can also lead to a consensus attack in certain networks. This is true in the case of NEM, especially because of delegated harvesting. Assuming that most people will use delegated harvesting because it is easier, then someone controlling 51% of nodes also controls approximately 51% of importance as about 51% of users will have delegated harvesting active on their nodes. This is why botnets are so bad for NEM.
That's only true if 51% of importance are harvesting on those nodes. If I have 100 nodes and only a small percentage of importance is actually harvesting on them then it doesn't matter that i have such a butload of nodes.
That's why people should only harvest on their own nodes or on nodes from people they know they can trust to some extent. Noone should ever pick a random node and start harvesting on it. If everyone does that it could lead to some serious issues down the road.
Should we limit the total sum of harvesting power (importance score) for a node?
Should we limit the total sum of harvesting power (importance score) for a node?
Not sure that's possible.
Also it wouldn't be very effective. Someone with evil intent could always collect all the harvesting power from serveral nodes he controlls.
Oh yeah, you're right of course.
Just came back to check on what's the status on Node Rewards. Looks like it's still not active yet. Is it?
right. we need somebody to build it.
main devs are very busy working on core NIS features right now that need to be done quickly.
My 2 XEMs for this discussion is that people can deploy a lot of nodes quickly using AWS 1-year free trial. But for that to work properly, the rewards program has to be adjusted to the performance that those vpses can provide and they probably need to be configured to work with slightly worse-than-ideal bandwidth limits.
Maybe a lot of these nodes could compensate for a few very good ones?
Actually, lots of nodes (especially slow ones) will actually slow down and hurt the performance of the network.
Point taken.
How is the idea of reducing the entry point for people already hosting nodes standing at the moment?
when is this planed to start?
We are testing internally right now. Next phase will be public testing. Should start soon.
3 Likes
Any updates on expected hardware and network requirements ?
I guess you’ve performed some tests already so it would be nice to get an idea of what is required.
1 Like
I use a 5 year old MacBook Air. I chose that because it had a good amount of RAM (4 gigs) and an SSD and uses almost no electricity so even though it was five years old It seemed like a good choice. I always have a good internet option at my house but I am pretty geographically separated from any other nodes as I live in Korea. Any information I have coming in or out is crossing fiber on the ocean floor.
My node does really well in all the tests except bandwidth. I usually pass every test but when I fail it’s almost always bandwidth. I think that’s because I get caught in a bottle neck somewhere else as the data comes and goes out of the country.
I’m not sure but I think when we have more nodes up and going that won’t be as big of a deal.
Running the node on the MacBook Air is nice. I have it set up so I turn the node on and then close the lid. The processor is usually over 95% free so I know it’s barely sipping any electricity on a computer that was already very light on electricity. So I’m basically running a node for free with some old hardware and my house wifi.
I realize a lot of people won’t have old MacBook Airs but I’m curious to see how many people maybe have an old notebook computer or something like what I did instead of going the cloud server direction which especially a lot of people to do.
1 Like