[ANN] eMunie (EMU) - NOT a BitCoin fork/clone - call for beta testers

[yoshiyoshi]

I'm in 

[xwebnetwork]

You've peaked my interest. I'd be very happy to test and provide feedback.

[soniq]

I can test

[LimLims]

Please sign me up.

So, say we spawn an arbitrary number of hatchers and clients in order to generate ourselves a disproportionate share of coins. How does the system determine whether our hatchers & clients meet the requirements for being sufficiently "distributed"?

[dacoinminster]

Very interesting proposal. I definitely want to try this. Thanks for innovating!

[dacoinminster]

Also, from what you've described, the best way to game this system is to run lots and lots of nodes. Botnet operators will LOVE this . . . unless you've found a solution to that problem?

[megablue]

i want to be beta tester, sign me in~

[marcetin]

sign me in please

[MyZhre]

Count me in.

[esuncloud]

I am in, and please PM. Thanks.

[Pmalek]

I would like to be a tester  Count me in!

[milly6]

I am very interested in Beta testing this on several different platforms. PM me.

[e777]

I'm in

[timeofmind]

Hatchers" can assign minimum fee's for this service to generate additional income, and any transaction verification request that does not fulfill the minimum set fee is ignored. Of course, transactions can be processed for free as this has additional benefits as explained below.

 If the collective vote is a success a number of EMU units are created and are distributed around the system in the following manner:

• As all hatching nodes have a complete transaction history, they are able to determine the hatching nodes that have done the most work in the system, 80% of the generated units are distributed to all hatching nodes in the system proportional to the amount of work they have done verifying transactions.
• The remaining 20% of generated units are distributed around the system to all clients, the percentage of which will be proportional to the amount of EMU units within that account, this is similar to interest.

I think I'm starting to understand how this could be implemented... I suppose as time goes by, and enough of these transactions are passed around, if half of the hatchers are only pretending to do their work in verifying transactions, and not really doing anything, eventually they will get caught by a hatcher who is... is that correct? And then at that point, the hatchers who screwed up, lose their funds and gets flagged as dishonest? I'm only guessing here since you've not gone into details on how this all works... how the network determines hatchers to be honestly verifying the transactions. I would  reward any hatchers who discover any dishonest hatchers, that would give incentive for hatchers to monitor each other.

[giantdragon]

I would like to try!

[Vorksholk]

Sounds very interesting, I'd love to be involved in the beta.

[Etlase2]

If you DO control the hatcher to always create a coin, you need the signed votes which are verified later, you can only create 60 units at a time, otherwise other hatchers and clients will reject it, and you can only create once every 60 minutes, otherwise other hatchers and clients will reject it.

Creation of a new unit (coinbase in BTC terms) has a record of all the yes voters, with their votes signed.  When that block goes out in to the wild and is re-verified by other hatchers, those voting nodes can be contacted and asked if they indeed voted yes to create that unit, if you control all the voters to that hatcher too, then yes you could falsely create a 60 units.

So you have created 60 units ahead of time, dishonestly, but unless those units are distrubuted as required by the system, those units will again, be rejected by others in the network.

I could continue, but that should give you an clearer idea how its "difficult" to game it unless you are running a lot of the network both in client peers and hatchers.

Who all is behind the programming of this? This does not sound particularly efficient or sybil-resistant. If it is trivial to overload the network with "votes", how will consensus be maintained?

[schnebi]

Also very interested in testing...

[rbdrbd]

I'm interested in testing.

[Luckybit]

eMulah (EMU) Announcement

Production launch: 21st June 2013

Beta (test) launch: ~7th June 2013

Before moving on I would like to make it clear that eMulah is NOT a fork of the BitCoin code, or any alt-coin that has been derived from the BitCoin release by Satoshi.  

eMulah is a decentralized, cryptographic currency, which is planned for launch in June 2013 and includes a number of innovations which will push crypto-currencies to the next stage.  

It is a secure, energy efficient system, which is self regulating and discourages "hoarding" as a whole, the aim of which to enable a more stable, reliable currency and value store.

We have a "closed beta" launch date on our test network due around the 7th of June, and I would like to call upon any interested party that would like to assist us, to get in touch with me.  I'll provide more details on this later in the post.

So whats different

eMulah has similarities to current crypto-currencies by way of a public ledger, blocks and transactions.  These however, are where the similarities end and innovation for a better system comes into action.

The network is composed of clients, seeders and hatchers, the functions of which will be explained in this announcement.  Any node can take task in one, or any combination of these roles dependent on the users wishes.

The network is resiliant to any type of "51%" attack, as the models required to perform such an attack are not present.

Currency generation within the network is a collaborative effort, and created currency is distributed according to a set of requirements.  This distribution should help to ward against hoarding, which can further lead to volatility of the currency.

The network performs extensive verification of itself, more so than the BitCoin algorithms, to ensure that all participants are honest nodes and for additional security overall.

A secure, anonymous peer 2 peer messaging system is built into the network, allowing secure, untraceable communications between 2 or more parties.

How it works

Transactions are similar in nature to BitCoin, each transaction has inputs and outputs which are signed.  Once a transaction is created, a "hatching" node is discovered, a verification request is sent, and if accepted, the transaction is forwarded to that node for verification.  At this point the hatching node, which has an entire, complete copy of all network transactions, performs verification of the submitted transaction (more about this later).  Once verified, the hatching node includes the transaction in the next block created, signs the block and hands that block to an additional hatching node.  This secondary hatching node performs the same verification with the newly created block, and if verified, signs it also, and broadcasts the new block into the network.  

Hatching nodes have a copy of all transactions and all public keys involved in these transactions.  Upon receiving a new transaction, the hatcher performs a full verification of the entire transaction chain backwards to the genesis block, and forward from the genesis block, simulating all the historic transactions and ensuring that 2 true, identical paths are always found.

Hatchers" can assign minimum fee's for this service to generate additional income, and any transaction verification request that does not fulfill the minimum set fee is ignored. Of course, transactions can be processed for free as this has additional benefits as explained below.

The delay time for a transaction to be included within a new, verified block should be nominal.

Currency generation is a collaborative effort between n-client nodes and a hatching node.  Each node in the system will cast a vote to a random hatching node to whether to create a currency unit (EMU).  Creation volume of currency over time is confined to a specified target interval to maintain a steady flow of new EMU's.  As the hatching nodes have the information available of all newly created EMU's, they are able to select the correct vote threshold for the generation of new EMU's.  If the collective vote is a success a number of EMU units are created and are distributed around the system in the following manner:

• As all hatching nodes have a complete transaction history, they are able to determine the hatching nodes that have done the most work in the system, 80% of the generated units are distributed to all hatching nodes in the system proportional to the amount of work they have done verifying transactions.
• The remaining 20% of generated units are distributed around the system to all clients, the percentage of which will be proportional to the amount of EMU units within that account, this is similar to interest.

Generated units are signed collectively by the nodes that voted for its creation, and also by the hatching nodes that co-verified it.  These signatures can then be checked by successive hatching nodes upon receiving the new block to ensure that the EMU unit generation is legitimate.

Benefits

Some benefits of eMulah may be obvious, other may not, so allow me to provide a simple breakdown.

• High security
• Fast transaction times
• Energy efficient
• "Fairer" system, all participants receive reward for work & adoption
• Difficult to crash value through hoarding then dumping
• More stability (we hope)
• Secure messaging[/il]
  

Other thoughts

Currently we are exploring the option of backing eMulah with USD, current proposals are a pre-allocation of 100k EMU units, backed by an as yet undecided amount of USD currency in the region of $50k-100k+   To complement this, we will either produce an exchange where individuals can trade EMU's for USD quickly and easily, or via a partnership with a current exchange.  If any current exchanges would like to discuss this possibility, please do feel free to get in touch with me.

Finally

We are looking for interested parties that would be willing to help us with our closed beta.  This is to enable us to do full stress testing of the system on a test network to ensure that any major lurking issues are caught and resolved before our production launch of 21st June.  Any person that participates will be awarded an allocation of EMU's upon launch, and will be privy to a mention of their choosing (real or pseudonym) on our website when launched and within the default client.

Of course this small post does not answer all questions, nor give all details on the eMulah system.  We are drafting our final paper on our algorithms and implementation currently and this will be released in the near future.

Thanks for reading, hopefully I've covered enough points to provide a complete idea how eMulah will work and I look forward to feedback and questions.

Sign me up.