Topic: [eMunie] eMunie Tech & General Q&A Thread - Get Involved - page 5. (Read 15671 times)

+1 on this, would like to know some kind of estimate on #'s for the launch.

id be interested to know, initially, how may coins will be released beyond those that invested at the beginning?  they dont want to call it a premine, ok, so tell us how many extras will be released?

why do i keep finding my self agreeing with "Internet celebrity" Hazard ?

but yeah + 1

maybe we come form the same place ?


i'd even go further and say - if someone did try to clone it , they will guaranteed fuck it up in some way and it will be obvious that its a clone , but on the other side of that i guess , is well, the other side.

The whitepaper, to be useful, should contain enough information about the protocol that a third party could build a functional node from scratch.  And someone will probably try.

If it contains that level of detail, then it should also be possible for third parties to analyze the security / cryptography of the system, even without source code.

I believe most of these sentiments were shared by Satoshi (or I could be talking out of my ass).

I think you strongly overestimate the desire of the community to launch a clone. Ripple, for example, has yet to be cloned, and it's been open source for a while now.

You might be shooting yourself in the foot by going this route.

eMunie tells me to un learn Bitcoin and basically that Im stupid. I don't need anyone to tell me Im stupid I do a great job proving that to myself everyday. Thanks eMunie Im going to go masterbate with my tears.

Why open source is important :
- It provide scrutiny from the community and thus security of the code.
- It provide trust (no I won't run a pre-compiled binaries that could contain any malaware, coin stealer, backdoor, or security critical bug)
- It help the common good buy providing solution to every one.
- Community will make the code better by correcting bugs, or adding new functionality.
- it provide a larger community

Why it doesn't matter if someone copy cat it :
- Community will stay behind the original
- If you are confident that your thing is the best then why would you fear a pale copy.
- For a copy to even grab attention, it would need a clever new functionality, so it will take time to develop.
- What would be the incentive to make a copy :
1)make a scam and profit : then it would be easily debunked.
2)make a better coin : if it is really better then it's a good thing, but it would be easier to add it directly to the original.

Sly

If people took the time to read just the 1st page, they wouldn't ask all the dumb ignorant questions that most due, which clearly shows they haven't even wasted 5 minutes researching the topic, yet they are all experts on the matter.

Good Work Fuserleer, awesome coin. 

I have a question about the demand based supply, as I'm sure other potential investors do too. If the point of the demand based supply is supposed to keep the price stable and avoid minimal fluctuations (correct?) what do I stand to gain from taking a big risk and investing my money by buying the currency? If the price is designed to remain stable how do I justify the lack of big potential payoff for the risk of investing?

As we all know in the early stages for a crypto currency actual usage for products and services is extremely limited and adopters are mostly drawn in by the investment potential. Once enough investors have been drawn in the coin gains critical mass and then there's enough people holding the coin to make it worthwhile for services to accept payment for it etc. This is what happened with Bitcoin and is happening with Litecoin.

Interested to hear your thoughts on this. My take on it is that you should not introduce a system to stabilise the price until after the coin has been very well distributed amongst adopters... Or perhaps incrementally increase the strength of the stablisation process... so the effect doubles in strength every interval.

Have you seen all of the ALT-Coins in this sub-forum?

Sorry, but some of them are smart enough to take existing code and paste it into their own alt-coin and then announce "We have a new Feature!!!".  Most programmers can copy/paste code and then tweak it to fit their application as necessary, and presto the coin now has a new feature. 

But to actually create the code would take them 6 months to a year, if they are even capable of coding it.  The P2P light and fast network is an example, how many white papers have been written on this functionality? And these P2P white papers have usually been written by a group effort, not a single coder.  Well Fuserleer has taken it a step further and actually created the P2P network.  That particular code module is worth millions of USD, EURO or whatever currency you want to use. Yet, Fuserleer has stated earlier in this thread that he is going to release it to the public domain in less that a year after eMunie launches.

The features look very promising and superior to bitcoin but make that open source.

We need to know if decentralization, security and privacy are respected. Don't worry, the scammers here won't be able to clone your coin without guide...

Launch will be some time in January, hopefully the beginning, certainly before the end.

Quality of the client and system are THE most important thing to me, and I've delayed launch 3 or so times now because I wanted it right.

Everything is in place now, technical workings are finalized, and there will be no more new features between now and launch, so I won't be slipping again much if at all.

Good question and I'll finally be able to clear up all this "insta-mine" talk

Due to eMunie's unique supply & demand model, an initial system balance (or float) is required to ensure fairness of the system initially from speculators and individuals whose only goal is generate large profits.

Additional to the above, eMunie will feature the worlds first true Peer 2 Peer distributed exchange & marketplace. This exchange & marketplace also requires an initial system balance be present to ensure that the stability of an eMu's value can be ensured, even when large buy or sell activity is present at any particular time, whilst still allowing individual unit value to appreciate steadily and predictably over time.

The supply model and exchange are closely integrated as both systems use information from the other to determine what action they should be doing at any one time. 

An example:

Assume there are only 100 eMu in existence, and I own them all.  You wish to obtain some eMu so you place a buy order on the exchange for 100 eMu at whatever the current rate is (doesn't matter for this example).  I am not selling my eMu, so there is no eMu available for you to buy, the exchange system recognizes this, so creates a demand signal and passes that to the supply system.  Save for the technical details, the supply system will create that 100 eMu over time and distribute it to stake holders, which is me in this example, and Hatchers.

In this example, there are no transactions happening so the Hatcher's would not receive any of the new 100 eMu supply as earnings bonus, so all 100 eMu would end up with me.  I have just made 100% profit, or more accurately, 100% interest, and supply overall is at 100% inflation.

If I do not sell those eMu on the exchange, eventually I will receive another 100 eMu again and again providing that your 100 eMu buy order is still there.

---

By having an initial quantity of eMu at launch, it dampens this effect for the short term, and over time, the natural spread of eMu around the system would ensure that all is fair and balanced.

It would be possible to create this initial system balance and allocate it entirely to an account in eMunie's control and we then sell those eMu on the exchange, perform giveaways and whatnot; however by doing so this would levy control of a large portion of the total eMu supply to a single entity for an unknown period of time.

One of eMunie's main goals is that it should be a decentralized currency, thus adopting the above approach would call that goal into question as eMunie/I would be able to abuse and drive the market price to where ever we wished it to be.

As the system needs this initial base of currency to "kickstart" it we have decided that this initial system balance should be distributed around as many accounts as possible, with the fairest way to achieve this being by way of a pre-launch purchase of eMu.  This will serve as both the system start point, and will allow us to raise additional funding to my own to push development and adoption over the coming 12 months.

Upon launch eMunie (us) would have zero eMu balance, I myself will allocate a small percentage of the total amount in the system at launch for my efforts over the past year and to use as a form of recouping my expenditures, with the view point of what I have spent on eMunie in those 12 months in my pre-launch buy in.  Of course if interest is low, then I wont end up with very much at all

I can't really give any solid estimates on what the start supply will be, as we haven't performed the pre-launch sale yet.  We will be announcing this officially soon, but until then it is a question I can not really answer as I have no indicators to determine what it may or may not be.

Growth over the first of course depends totally on demand for eMunie...if there is little demand, then low volume of eMu will be created and vice-versa.  The system tries to manage & regulate inflation along with market value as best as it can so that both growth and value are predictable over time.   I will be purchasing eMu from the exchange for the system to work with to help meet these goals post-launch.

I hope that answers your question

Presently its mainly myself and another developer, I use 3rd party freelancers as and when I need to, but the majority of the design and development of the system is done by myself.

I do this full time and have done for the past year, admittedly I'm a bit of a workaholic when I am passionate about something I am involved with (much to the real bosses frustration at times) so I'm regularly sitting here for 18+ per day.  Probably not good for me, but I'd much rather do this than lay on the couch watching reality TV

As we roll out and grow, I will certainly be bringing more developers on board as well as other individuals with notable skill set for promotion, general admin etc.

The system is designed to be very lightweight and should easily be able to run on a modern smartphone, one of our Beta testers is currently playing around with running the full client on a 256MB Pi.

Our roadmap for mobile devices also includes legacy J2ME devices, I am well versed with the capabilities of these older J2ME devices as my previously owned company worked very closely with Nokia, Sony, Motorola and other OEM creating various JVM & JSR implementations and software for these devices.

The 3rd world market is full of these legacy devices and eMunie should be able to run on a large percentage of them as a raw client (no Hatching functionality) which opens up huge possibilities for global adoption past us mere crypto nerds

Could OP answer this?

Nice, when eMunie will be launched?

HDD space should be very minimal also for regular nodes thanks to the DFS (distributed file system), self pruning and compact block tree.   Hatchers and Seeders will need the whole tree short term, but we plan to roll out the DFS version for Hatchers and Seeders later on to cut down on HDD requirements for them also. 

DFS based block tree's on these nodes is more complicated than regular nodes due to some required additions to communications protocol.  This won't really be required until some network growth has occurred so for now we decided to go with a regular full block tree implementation.  The tree will still be pruned and compact and wont take up much space as a BitCoin equivalent over time would.

As an example for regular clients, assuming that the total pruned and compact tree of all current unspents and their current required dependencies is 1GB, each regular client on average will require ~1024th of the total size which is about 1MB.   1GB of block tree with an average dependency requirement of 3 previous transactions is ~500k current unspent transactions, with each regular client in the network requiring around 500 minimum (depending on total network size) of these unspent records to satisfy the DFS requirements.