Topic: A World of Trust – eMunie Consensus Primer - page 7. (Read 7372 times)
For the sybil attack to be unprofitable, the amount of funds spent to acquire the needed trust to pull it off must be <= the amount you can potentially double spend with such an attack. Is this the case?
Before hand I would like to express that any and all information you think you already know about how eMunie functions should be forgotten immediately!
What has made you abandon the idea of block-trees?
Thanks for taking the time to read.
Firstly, I should of made it clear in the OP to dis-regard anything you may have read about eMunie in the past, as all of it is out of date and likely incorrect by now. Ive modified to the OP to state that.
Regarding balances, the decision to use them was based on an lot of research into which of the two method could achieve the core goals that we wanted. Lots of time and effort was put into applying different scenarios, use and edge cases which were evaluated against the strengths and weaknesses of both approaches. In the end, balances won out due to the long term efficiency and flexibility they can provide as will be clear soon.
They are more complicated to implement than input/output, but the declarations that it does not work are simply wrong, it can work, and it does work. Its just a hard task to achieve in an efficient and reliable manner.
I really didn't want to get into economics within the article, as the eMunie ecosystem is very fluid, dynamic and diverse. It will likely require quite a few detailed documents to cover all aspects of it, and I didn't want to "brain dump" too much unrelated information, distract from the main topic of the article and risk sending readers into a confusion induced coma.
The details following really should be left for the associated economic documentation to explain them fully, but your question about incentive is an important one so I'll briefly cover some of it.
Revenue for the work performed by the nodes in the network can quickly become quite significant when you apply all factors of the economics. Not only that, the distribution of this revenue is very broad, due to work being recorded at a much granular level all over the network, instead of it being a huge "race condition" such as with Bitcoin. Nodes that perform even the smallest amount of work get rewarded for doing so, and the execution of that work is much more efficient than simply testing billions of hashes per second in what might as well be a lottery.
In terms of income there are multiple streams:
Firstly, fees that are generated by transactional and peripheral content actions are allocated to the relevant service providers, and this income is periodically distributed between them as per the amount of work they have done. We've performed a number of calculations with regard to income and even in the most frugal of cases, the cost required to operate the services providers is much less than the fees recouped, even if that node only performs a couple of tasks per day.
Bitcoin is perhaps the lowest income provider of any currency in relation to the amount of work done. Megawatts of electricity is currently burned just to enable miners to make a few cents of profit over that cost, not to mention hardware replacement costs, maintenance, disposal of old hardware, pollution from both the creation and disposal of said hardware and the additional pollution of generating all that electricity. Most of that is a hidden cost, but at some point it has to be paid for in some manner.
With eMunie the efficiency of performing work is many magnitudes more efficient than Bitcoin. For example a Pi could be used to provide some of the lighter network services, consuming just a handful of watts per day yet seeing an income of a few dollars or more per month from minimal workload. When there is no work for it to do, it can sit idle and power consumption is literally 1-2 watts.
Secondly, eMunie's new currency supply is dynamic and the total amount of currency can increase or decrease depending on the demand. Assuming that eMunie is successful and sees even moderate success compared to Bitcoin, then the network will nearly always be in growth, and an increase in supply will consistently be required. Of course, at some point in time there comes a plateau but I'm digging too much into economics already, so I'm going to skip that.
New supply is distributed in 2 ways, the first being in the same manner as fees. Nodes that have done work are also eligible for a slice of the new supply proportionate to the amount of work they have done since the last distribution. The second mechanism is via interest on assets that are held in balances within the network, with holders of balance receiving a slice of new supply proportional to the amount of EMU they hold v's total supply, and how long that EMU has been sitting in that balance.
For service nodes that are active, not only do they receive a portion of fees for that service and a portion of new supply for doing work, if they were to hold those earned EMU and not move them, they would also receive a 2nd portion of new supply as interest.
The question isn't should I run a service node, the question should be why on earth aren't I?
Firstly, I should of made it clear in the OP to dis-regard anything you may have read about eMunie in the past, as all of it is out of date and likely incorrect by now. Ive modified to the OP to state that.
Regarding balances, the decision to use them was based on an lot of research into which of the two method could achieve the core goals that we wanted. Lots of time and effort was put into applying different scenarios, use and edge cases which were evaluated against the strengths and weaknesses of both approaches. In the end, balances won out due to the long term efficiency and flexibility they can provide as will be clear soon.
They are more complicated to implement than input/output, but the declarations that it does not work are simply wrong, it can work, and it does work. Its just a hard task to achieve in an efficient and reliable manner.
I really didn't want to get into economics within the article, as the eMunie ecosystem is very fluid, dynamic and diverse. It will likely require quite a few detailed documents to cover all aspects of it, and I didn't want to "brain dump" too much unrelated information, distract from the main topic of the article and risk sending readers into a confusion induced coma.
The details following really should be left for the associated economic documentation to explain them fully, but your question about incentive is an important one so I'll briefly cover some of it.
Revenue for the work performed by the nodes in the network can quickly become quite significant when you apply all factors of the economics. Not only that, the distribution of this revenue is very broad, due to work being recorded at a much granular level all over the network, instead of it being a huge "race condition" such as with Bitcoin. Nodes that perform even the smallest amount of work get rewarded for doing so, and the execution of that work is much more efficient than simply testing billions of hashes per second in what might as well be a lottery.
In terms of income there are multiple streams:
Firstly, fees that are generated by transactional and peripheral content actions are allocated to the relevant service providers, and this income is periodically distributed between them as per the amount of work they have done. We've performed a number of calculations with regard to income and even in the most frugal of cases, the cost required to operate the services providers is much less than the fees recouped, even if that node only performs a couple of tasks per day.
Bitcoin is perhaps the lowest income provider of any currency in relation to the amount of work done. Megawatts of electricity is currently burned just to enable miners to make a few cents of profit over that cost, not to mention hardware replacement costs, maintenance, disposal of old hardware, pollution from both the creation and disposal of said hardware and the additional pollution of generating all that electricity. Most of that is a hidden cost, but at some point it has to be paid for in some manner.
With eMunie the efficiency of performing work is many magnitudes more efficient than Bitcoin. For example a Pi could be used to provide some of the lighter network services, consuming just a handful of watts per day yet seeing an income of a few dollars or more per month from minimal workload. When there is no work for it to do, it can sit idle and power consumption is literally 1-2 watts.
Secondly, eMunie's new currency supply is dynamic and the total amount of currency can increase or decrease depending on the demand. Assuming that eMunie is successful and sees even moderate success compared to Bitcoin, then the network will nearly always be in growth, and an increase in supply will consistently be required. Of course, at some point in time there comes a plateau but I'm digging too much into economics already, so I'm going to skip that.
New supply is distributed in 2 ways, the first being in the same manner as fees. Nodes that have done work are also eligible for a slice of the new supply proportionate to the amount of work they have done since the last distribution. The second mechanism is via interest on assets that are held in balances within the network, with holders of balance receiving a slice of new supply proportional to the amount of EMU they hold v's total supply, and how long that EMU has been sitting in that balance.
For service nodes that are active, not only do they receive a portion of fees for that service and a portion of new supply for doing work, if they were to hold those earned EMU and not move them, they would also receive a 2nd portion of new supply as interest.
The question isn't should I run a service node, the question should be why on earth aren't I?
Well, whether this turns out to be the best or worst distributed ledger, once you factor in the consensus mechanism + economics system (if it's still the same one as before), it will probably win the award for most complicated one. I was surprised that I couldn't find any Satoshi post regarding inputs/outputs vs balance sheet, only a Gavin post saying basically it won't work, and a Theymos post saying headers first and merkle root solves the same problem. It does solve space constraints, creating SPV clients, but does nothing to address the issue of lower number of consensus nodes in general from exponentially increasing overhead in the input/output blockchain model.
I tried to speed read through this post and didn't really see what motivation existed for creating a large number of unique, non-sybil nodes. I'm not sure if incentives were adequately addressed or not. Overhead is the main variable. If the overhead is low, then you have a larger number of sybil nodes, and possibly a small number of real nodes since who wants to be one out of a billion transaction processors making one cent a month? If the overhead is high, then you have a lower amount of every type of node, until the moment someone decides to attack it, since it's almost impossible to guard against people who willingly operate at a loss. You have a no win situation in that regard in terms of trying to design overhead into the system. Quite a paradox...
This is related to the Satoshi "no free lunch" principle and general game theory, where in order to trust output from an entity, somebody somewhere has to be making a revenue stream, where them substituting false information is going to end that revenue stream.
I tried to speed read through this post and didn't really see what motivation existed for creating a large number of unique, non-sybil nodes. I'm not sure if incentives were adequately addressed or not. Overhead is the main variable. If the overhead is low, then you have a larger number of sybil nodes, and possibly a small number of real nodes since who wants to be one out of a billion transaction processors making one cent a month? If the overhead is high, then you have a lower amount of every type of node, until the moment someone decides to attack it, since it's almost impossible to guard against people who willingly operate at a loss. You have a no win situation in that regard in terms of trying to design overhead into the system. Quite a paradox...
This is related to the Satoshi "no free lunch" principle and general game theory, where in order to trust output from an entity, somebody somewhere has to be making a revenue stream, where them substituting false information is going to end that revenue stream.
Hello everyone,
Before hand I would like to express that any and all information you think you already know about how eMunie functions should be forgotten immediately! Almost all of that old information is defunct and out of date and no longer relevant in anyway. Thank you
It is with great pleasure that I publish the first article regarding eMunie technology focusing on our consensus algorithms based around trust.
The first of many upcoming articles covering all areas of the eMunie project, I wanted to start with consensus as it is probably the most important of all.
This first document focuses on the topic in a high level and is meant for a wide audience. There is lots of detail to dig into in future articles, even though it gets quite in depth, but I want to also provide documentation for those not so technically minded which is written in every day language and is easy to understand.
To enable a full and complete understanding of the project, what it offers and how it functions will require many articles and documentation totaling 100s of pages. I'll do my best to make sure that important topics that rely on content within other documents are explained as best I can so that the topics being covered in the material being read can be understood clearly.
I'm happy to answer any questions where I can, but please understand that there may be some items that will be difficult to explain without these yet unfinished additional documents.
The article can be viewed at http://blog.emunie.com
Best Regards to all
- Dan/Fuserleer
PS: I've set self-moderation on this topic as a precaution and will only be removing posts that are blatant attacks and severe trolling.
Before hand I would like to express that any and all information you think you already know about how eMunie functions should be forgotten immediately! Almost all of that old information is defunct and out of date and no longer relevant in anyway. Thank you
It is with great pleasure that I publish the first article regarding eMunie technology focusing on our consensus algorithms based around trust.
The first of many upcoming articles covering all areas of the eMunie project, I wanted to start with consensus as it is probably the most important of all.
This first document focuses on the topic in a high level and is meant for a wide audience. There is lots of detail to dig into in future articles, even though it gets quite in depth, but I want to also provide documentation for those not so technically minded which is written in every day language and is easy to understand.
To enable a full and complete understanding of the project, what it offers and how it functions will require many articles and documentation totaling 100s of pages. I'll do my best to make sure that important topics that rely on content within other documents are explained as best I can so that the topics being covered in the material being read can be understood clearly.
I'm happy to answer any questions where I can, but please understand that there may be some items that will be difficult to explain without these yet unfinished additional documents.
The article can be viewed at http://blog.emunie.com
Best Regards to all
- Dan/Fuserleer
PS: I've set self-moderation on this topic as a precaution and will only be removing posts that are blatant attacks and severe trolling.
Jump to: