Topic: [eMunie] Latest update, lots of new features and improvements. - page 4. (Read 10005 times)
Where does the demand information come from?
Correct on all counts. Although in your example, that inflation rate would be 200% 
So in traditional currency your % share of the money supply decreases, along with its value.
Here while your overall share of the money supply decreases, its worth remains as it is topped up by more valuable (in the work sense) eMu's.
Demand will typically come with an increase in the real value (that's the market) of eMu.
When demand is up you gain in 2 areas, eMu holding, say 5% p/a + whatever the current % of rise in real value is that has created that demand in the first place.
If an eMu is worth a $, you have 100 of them, if the demand creates an inflation of 4%, then at the end of that year you have 105$ (4%+1% for equilibrium for arguments sake). The demand will also of pushed up the real value too, lets say 3% over that year.
Thus, your original $100 could now be worth as high as $108.15
So in traditional currency your % share of the money supply decreases, along with its value.
Here while your overall share of the money supply decreases, its worth remains as it is topped up by more valuable (in the work sense) eMu's.
Demand will typically come with an increase in the real value (that's the market) of eMu.
When demand is up you gain in 2 areas, eMu holding, say 5% p/a + whatever the current % of rise in real value is that has created that demand in the first place.
If an eMu is worth a $, you have 100 of them, if the demand creates an inflation of 4%, then at the end of that year you have 105$ (4%+1% for equilibrium for arguments sake). The demand will also of pushed up the real value too, lets say 3% over that year.
Thus, your original $100 could now be worth as high as $108.15
UPDATE: This infographic illustrates how eMunie Block Tree (not chain, unlike Bitcoin) Transaction model is resistant to 51% attack:
So lets say originally the network has 1 Million eMus, and demand indicates it needs to issue another 1M eMu, based on explanation, the system has to bloat 3 times in total eMu, not 2 times, is that correct?
So while there is huge advantage for early EMU holders (very high interest rate when networks grows fast), their share of total EMU in the network will be diluted over-time. But providing the price of each EMU remains stable or keeps increasing steady, there is still huge investment gain purely from high dynamic interest rate, correct?
So lets say originally the network has 1 Million eMus, and demand indicates it needs to issue another 1M eMu, based on explanation, the system has to bloat 3 times in total eMu, not 2 times, is that correct?
- 1M existing eMu
- 1M hatcher's earning to meet new demand
- 1M+1% interest rate distributed to existing 1M eMu above
So while there is huge advantage for early EMU holders (very high interest rate when networks grows fast), their share of total EMU in the network will be diluted over-time. But providing the price of each EMU remains stable or keeps increasing steady, there is still huge investment gain purely from high dynamic interest rate, correct?
Some great new features especially the interest. Hopefully you can pull it off. Will be watching this thread.
[reserved]
Work Value & Real Value
Above I mentioned a few times about the "value" of an eMu. There are 2 value classification for a single eMu, "work value" and "real value".
Work value is the classification I talk about above, it is the work value of that eMu within the system and has no bearing or relevance at all to the eMu's real value. The work value is an abstract that is used to correctly govern the supply of new eMu's thus to ensure that the current collective work value of all existing eMu's is not compromised.
Real value is the value placed upon eMu by you, me, and anyone else that chooses to use them, and that is a different kettle of fish entirely.
The work value of an eMu can be going up, while the real value is going down, or vice versa. The real value is isolated from the work value, and is determined by the market, not the system.
That said, the real value of an eMu will most certainly have an effect on the supply and demand model within, as generally, it can be assumed that if the real value is dropping, so is demand, and vice versa.
The real value is what you "trade OF value" to acquire an eMu, whether that be a $, a £, a service, work, or a sheep.
With that in mind, if the demand of eMu is high, then the real value of an eMu will typically rise. If the demand of eMu is low, or none, the real value may drop, but the work value will hold until demand resumes. Due to the work value of an eMu being topped up via interest, your overall holding of eMu increases in proportion to the work value, and thus the real world value should rise at a steady and predictable manner. The result is a reliable, predictable real world value increase, which when rising ultimately results in ... profit for you the stake holder.
In closing
Finally I would like to end with a breakdown of some innovative and unique features within the eMunie eco system, as aside from the above strong points, there are others too as listed below:
Above I mentioned a few times about the "value" of an eMu. There are 2 value classification for a single eMu, "work value" and "real value".
Work value is the classification I talk about above, it is the work value of that eMu within the system and has no bearing or relevance at all to the eMu's real value. The work value is an abstract that is used to correctly govern the supply of new eMu's thus to ensure that the current collective work value of all existing eMu's is not compromised.
Real value is the value placed upon eMu by you, me, and anyone else that chooses to use them, and that is a different kettle of fish entirely.
The work value of an eMu can be going up, while the real value is going down, or vice versa. The real value is isolated from the work value, and is determined by the market, not the system.
That said, the real value of an eMu will most certainly have an effect on the supply and demand model within, as generally, it can be assumed that if the real value is dropping, so is demand, and vice versa.
The real value is what you "trade OF value" to acquire an eMu, whether that be a $, a £, a service, work, or a sheep.
With that in mind, if the demand of eMu is high, then the real value of an eMu will typically rise. If the demand of eMu is low, or none, the real value may drop, but the work value will hold until demand resumes. Due to the work value of an eMu being topped up via interest, your overall holding of eMu increases in proportion to the work value, and thus the real world value should rise at a steady and predictable manner. The result is a reliable, predictable real world value increase, which when rising ultimately results in ... profit for you the stake holder.
In closing
Finally I would like to end with a breakdown of some innovative and unique features within the eMunie eco system, as aside from the above strong points, there are others too as listed below:
- Transaction message attachments
- Secure P2P messaging system
- Multiple accounts within a single wallet
- Higher wallet security
- Easy wallet retrieval if lost
- Built in system escrow system
- Transaction schedules (transactions sent now but clear on a certain date)
- Decentralized P2P exchange
- ..much much more..
Supply, Demand & eMu Generation
Currencies, or money supply, work with reliance to supply and demand, the more demand the more supply, the problem is of course, that in the fiat world, this is manipulated by the central banks to their own agenda, and dilutes the fiat supply... or inflation.
A stable currency needs a stable value, and a stable value can only be achieved with a solid supply and demand model that doesn't dilute the already in circulation money supply. If it does, new money steals the value from your current money supply and thus is devalued, as it has not "earned" its own value yet.
With eMunie we have looked at these issues in great detail, and believe we have a solution, that will ensure a fair, stable, honest currency value that does not dilute the holding of any single person in the system anywhere.
Save for the details of the mathematics (which will be in the white paper), demand is simply a call for new eMu, whether that be new accounts with new people coming on board, or regular users of eMunie wanting to have more of a holding.
Demand in the system is always closely chased, via an trailing elastic supply model, so there is just enough eMu in circulation to almost meet to the current demand trends....unless demand comes to a halt or is exceeded by supply. When this happens, no more eMu is created until the current excess supply available is used by demand. This recognition of excess supply happens quickly, so the excess will always be a very small percentage of the entire money supply, thus the effect of this supply will be nominal at best.
Where does the supply come from you ask? It comes from the hatchers. Hatchers perform work while clearing transactions, the amount of work any single hatcher in the system does, is easily calculated from the block tree, and thus, a % portion of the work done by that hatcher in a specific time period can be determined. A hatcher will then receive that % portion, of the systems calculated supply of new eMu required from the current demand.
eMu can not be spent from a hatcher account, it can only be transferred to either an exchange account, or a regular eMu wallet via a mediator. This mediator records the movement of supply eMu into the system and is included in future supply calculations. Hatcher owners are then free to do with the eMu as they so wish, hopefully, trading some or all of it out into the system.
These generated eMu's will have "value" as the hatchers have performed real world work to acquire them, however, a caveat of this, is that as the system load increases, and more work is done by more hatchers, these eMu's increase in deemed value, thus devaluing the already present eMu's in the system....and thus acts like traditional INFLATION.
Interest
To combat this inflation due to the effect of the increasing work in the system, a portion of the supply eMu's are passed to the accounts already holding eMu as "interest". Interest is calculated as the current annual % increase in eMu supply, as per demand, plus a % increase to ensure equilibrium. This ensures that while the new supply of eMu entering into the system may have higher "value" due to more work done to achieve them, all other eMu's in the system, while worth less, are topped up with new, more valuable eMu to guarantee that stake holder of current eMu does not loose out.
Interest is ALWAYS higher than new supply %, even if just marginally, except in the event, that demand ceases to exist, or is 0. Interest is then also 0 to ensure the equilibrium and solidify the value of all eMu in the system.
.... NEXT Value ....
Currencies, or money supply, work with reliance to supply and demand, the more demand the more supply, the problem is of course, that in the fiat world, this is manipulated by the central banks to their own agenda, and dilutes the fiat supply... or inflation.
A stable currency needs a stable value, and a stable value can only be achieved with a solid supply and demand model that doesn't dilute the already in circulation money supply. If it does, new money steals the value from your current money supply and thus is devalued, as it has not "earned" its own value yet.
With eMunie we have looked at these issues in great detail, and believe we have a solution, that will ensure a fair, stable, honest currency value that does not dilute the holding of any single person in the system anywhere.
Save for the details of the mathematics (which will be in the white paper), demand is simply a call for new eMu, whether that be new accounts with new people coming on board, or regular users of eMunie wanting to have more of a holding.
Demand in the system is always closely chased, via an trailing elastic supply model, so there is just enough eMu in circulation to almost meet to the current demand trends....unless demand comes to a halt or is exceeded by supply. When this happens, no more eMu is created until the current excess supply available is used by demand. This recognition of excess supply happens quickly, so the excess will always be a very small percentage of the entire money supply, thus the effect of this supply will be nominal at best.
Where does the supply come from you ask? It comes from the hatchers. Hatchers perform work while clearing transactions, the amount of work any single hatcher in the system does, is easily calculated from the block tree, and thus, a % portion of the work done by that hatcher in a specific time period can be determined. A hatcher will then receive that % portion, of the systems calculated supply of new eMu required from the current demand.
eMu can not be spent from a hatcher account, it can only be transferred to either an exchange account, or a regular eMu wallet via a mediator. This mediator records the movement of supply eMu into the system and is included in future supply calculations. Hatcher owners are then free to do with the eMu as they so wish, hopefully, trading some or all of it out into the system.
These generated eMu's will have "value" as the hatchers have performed real world work to acquire them, however, a caveat of this, is that as the system load increases, and more work is done by more hatchers, these eMu's increase in deemed value, thus devaluing the already present eMu's in the system....and thus acts like traditional INFLATION.
Interest
To combat this inflation due to the effect of the increasing work in the system, a portion of the supply eMu's are passed to the accounts already holding eMu as "interest". Interest is calculated as the current annual % increase in eMu supply, as per demand, plus a % increase to ensure equilibrium. This ensures that while the new supply of eMu entering into the system may have higher "value" due to more work done to achieve them, all other eMu's in the system, while worth less, are topped up with new, more valuable eMu to guarantee that stake holder of current eMu does not loose out.
Interest is ALWAYS higher than new supply %, even if just marginally, except in the event, that demand ceases to exist, or is 0. Interest is then also 0 to ensure the equilibrium and solidify the value of all eMu in the system.
.... NEXT Value ....
This thread was bumped today (4th Nov 2013) by a BTT member, the information within is out of date.
Up to date information and announcements will be posted on BTT shortly
Hey BitcoinTalkers
Been a while since I posted the original eMunie thread, and I stated that I would only post here in the future with any major developments. Well, I have a ton to share, as things have been pretty busy over here.
Due to these changes/improvements/additions the launch date has slipped by quite a lot, it was originally penciled for ~21st June, but even when posting the original thread, there were policies and philosophies in the design that I wasn't sure would stay, or might change. Which is why I didn't spend the time completing the whitepaper, as I felt that information might become outdated. Currently there is a tentative launch date set sometime around the end of July.
In this post I'll be addressing some technical elements, new features, the new and improved eMu generation model and how that will work. Plus some information on features that we are planning/building in to the system. Some of it I will keep out, as the features are innovative, but could easily be implemented by others, and I'm not a fan of my idea's being stolen before I've executed them.
All of what I post technically will be brief, and more detail will be included in the published whitepaper when methods are finalized.
Transactional Model
Originally the eMunie transaction model shared a lot in common with the Bitcoin design, single chain, in and out transactions cross signed using ECDSA scripts and other similarities. From day one, this did not "feel" correct, it is limiting, it is susceptible to 51% attacks via forking and while its design is acceptable to a minor currency implementation, moving forward, it does not scale well enough to be considered a "fiat" challenger.
We decided to redesign 70% of our transaction model and refactor our code.
So how does it work now?
Confirming transactions continues to operate in much the same manner, a forward and back search of the block chain is performed, verifying that the current transaction dependencies are legitimate and continuing in a recursive fashion until either the transaction worth is fulfilled by the transactions it depends on (ie you don't need to do a full tree scan), an eMu generation block is encountered, or the genesis. Coupled with our efficient POW algorithm (although slightly revised which I'll get into later on) this original method is still the basis of our transaction confirmation functionality and processing.
The main changes are in the "block chain" itself, and the way that transactions are recorded and stored.
eMunie now uses multiple chains, think of the ledger as more of a block tree, than a block chain. There may be many 1000's of small, interconnected chains, all holding valid transactions, and all able to validate transactions across other chain sections. "Forks", or new chains in eMunie are good, they strengthen the system and make a 51% attack impractical if not nigh on impossible, as there are so many chains, taking them all over is rather difficult. Transactions are verified in multiple blocks, with many "hatchers" (or miners as is the lingo here) in the system verifying the same transaction over and over and including a reference to that transaction in many blocks, within many chains.
Double spends are also EXTREMELY difficult with eMunie, as the system now favors a rolling balance over a "transaction in/out" method such as Bitcoin. As soon as you create a transaction, that transaction is distributed to the network as an intention, and it is logged. All nodes now know about this intended transaction and will include it in any subsequent balance calculation should they need it.
Upon the transaction clearing, that transaction is included in 1 or many blocks, and your rolling balance will calculate to the same as when performed using the transaction intention.
Transaction intentions take huge priority over other system messages, so to perform that double spend would require you to be very targeted in where it is sent to, know all about the current network position (its very dynamic) and sent immediately after the original transaction. Should you successfully achieve a double spend, soon after your rolling balance when calculated by nodes in the system will enter a negative balance, that peer and wallet address will then be immediately blacklisted forever.
.... NEXT eMu Generation ....
Up to date information and announcements will be posted on BTT shortly
Hey BitcoinTalkers
Been a while since I posted the original eMunie thread, and I stated that I would only post here in the future with any major developments. Well, I have a ton to share, as things have been pretty busy over here.
Due to these changes/improvements/additions the launch date has slipped by quite a lot, it was originally penciled for ~21st June, but even when posting the original thread, there were policies and philosophies in the design that I wasn't sure would stay, or might change. Which is why I didn't spend the time completing the whitepaper, as I felt that information might become outdated. Currently there is a tentative launch date set sometime around the end of July.
In this post I'll be addressing some technical elements, new features, the new and improved eMu generation model and how that will work. Plus some information on features that we are planning/building in to the system. Some of it I will keep out, as the features are innovative, but could easily be implemented by others, and I'm not a fan of my idea's being stolen before I've executed them.
All of what I post technically will be brief, and more detail will be included in the published whitepaper when methods are finalized.
Transactional Model
Originally the eMunie transaction model shared a lot in common with the Bitcoin design, single chain, in and out transactions cross signed using ECDSA scripts and other similarities. From day one, this did not "feel" correct, it is limiting, it is susceptible to 51% attacks via forking and while its design is acceptable to a minor currency implementation, moving forward, it does not scale well enough to be considered a "fiat" challenger.
We decided to redesign 70% of our transaction model and refactor our code.
So how does it work now?
Confirming transactions continues to operate in much the same manner, a forward and back search of the block chain is performed, verifying that the current transaction dependencies are legitimate and continuing in a recursive fashion until either the transaction worth is fulfilled by the transactions it depends on (ie you don't need to do a full tree scan), an eMu generation block is encountered, or the genesis. Coupled with our efficient POW algorithm (although slightly revised which I'll get into later on) this original method is still the basis of our transaction confirmation functionality and processing.
The main changes are in the "block chain" itself, and the way that transactions are recorded and stored.
eMunie now uses multiple chains, think of the ledger as more of a block tree, than a block chain. There may be many 1000's of small, interconnected chains, all holding valid transactions, and all able to validate transactions across other chain sections. "Forks", or new chains in eMunie are good, they strengthen the system and make a 51% attack impractical if not nigh on impossible, as there are so many chains, taking them all over is rather difficult. Transactions are verified in multiple blocks, with many "hatchers" (or miners as is the lingo here) in the system verifying the same transaction over and over and including a reference to that transaction in many blocks, within many chains.
Double spends are also EXTREMELY difficult with eMunie, as the system now favors a rolling balance over a "transaction in/out" method such as Bitcoin. As soon as you create a transaction, that transaction is distributed to the network as an intention, and it is logged. All nodes now know about this intended transaction and will include it in any subsequent balance calculation should they need it.
Upon the transaction clearing, that transaction is included in 1 or many blocks, and your rolling balance will calculate to the same as when performed using the transaction intention.
Transaction intentions take huge priority over other system messages, so to perform that double spend would require you to be very targeted in where it is sent to, know all about the current network position (its very dynamic) and sent immediately after the original transaction. Should you successfully achieve a double spend, soon after your rolling balance when calculated by nodes in the system will enter a negative balance, that peer and wallet address will then be immediately blacklisted forever.
.... NEXT eMu Generation ....
Jump to: