Topic: [ANN] eMunie (EMU) - NOT a BitCoin fork/clone - call for beta testers - page 18. (Read 78405 times)

Thanks!

Ok, thanks for your answer 

Ok, why not if it's temporary

To start yes, with native clients later on for efficiency.

It'll be open source anyway, so a Java implementation allows cross platform quickly and decompilation of code isn't an issue.

Did I read Java?

Didn't forget anyone, just crazy hectic over here atm that's all.  Ive got everyone's details saved.

I was in the first page of this thread, still got nothing, but i registered on the website too. I think we will get some news soon and i hope i will not be forgotten 

I sent a pm one day after my post on the thread, never had answer. I think everything will happen on the website (when I registered, I didn't receive a confirmation on my mailbox, I hope it's normal).

We're still plugging away over here wrapping up some final bits and pieces, I'll be in touch with those shown support as soon as we are ready to go.



As for your other points I'm not going to re-discuss them over again and spend 8 hours going around in circles.  The source code and paper will address the issues you have when the time comes.

Does anybody received "invitation" to be a beta-tester?
since OP silent on my pms

eMunie incorporates trust, causing some of the same vulnerabilities as ripple.  Also the proof-of-"work" that eMunie uses is so absurd that it will cause all the coins to get distributed to a handful of people, much like ripple.

Ripple
Closed Source
Premined 100 billion ripple, gave 80 billion of them to opencoin
Gives coins to some forum members, people on mailing lists, and other for profit companies like PIA

EMU
Open source
New way to distribute coins instead of proof of work (different than bitcoin)


I'm confused as to how you are tying the two together. Care to share any more thoughts than the diarrhea that came out in your last post?

another ripple.

I would love to be a beta tester.

This is yet another: 'Interested to test' post.

This is the bit that gets me confused.

I run a client on my local network - it can only connect to my own hatchers.  What stops them from hatching its transactions - noone else is going to see them to get the chance?  Or do nodes only ever approve transactions that they saw before they were processed (meaning immediate fork as soon you connect if any transactions were already being processed)?

Is there something that stops hatchers below a certain trust-level from processing transactions?  Do they have to back-date the time-stamp so it looks like they waited to give more trusted ones a chance to process them first?

And what's with the claim that honest nodes can detect ping-pongs (not quoted above)?  Is there some penalty for sending funds back and forth?  Do hatchers need to analyse all transactions to make sure they won't be penalised if they process them?  If I send money to someone then they send it back will it be taken away or something?  A general statement that something can be detected doesn't explain anything without detail of what happens when it IS detected.

If generating key pairs is fairly trivial then there'd be no need for anyone doing transaction padding to use same address twice anyway.  You just have X blocks of cash that you keep moving to new addresses.  Or one big block if its weighted by transaction size.

Seems interesting. I'll give it a try.

i'd like to be beta tester and make some attack analysis on experiment on the code base.

I have some idea on how someone with 50 clients sending to each other money can help market share of 4-5 hatchers. one would be to scrap other hatchers rep. yes sometimes he best way to get the best rep is to scrap other rep. this is especially true in computer computed rep. making.


I have some concern about the rep and the monopol of transaction to 4-5 high rep hatchers. As this will make it in the hand of 4-5 persons getting 80% of the currency and 10% as interest on their pile of currency while selling few to market to make a profit as only 10% could be in fact really circulating the price will be high or the currency not used.


the interest part seems a good  distribution method when a lot of coin are hold by different person, but can be exploited to get a lot of interest if someone get a big part of the currency available and sit on it. especially when coins are still not very disperse at begin.(note this can be exploited by the entity that would back it for 100K )



But the idea is very interesting. I would love to try to break it in beta(to make sure it is bullet proof) before someone break it for real and get someone scam in the process

yeah the algo's for it all seem pretty solid and I think this kind of system is what the community needs as a whole, why just stick with BTC clones when there is atleast another trying something new? my humble opinion.

Soo...for this or some other coin, on the topic of CPU-based PoW:

I saw his post with the breakdown of algorithms over at https://bitcointalksearch.org/topic/m.786472 in that thread.

I am still a newb to the math involved with bitcoin. Would the radix sort/tree sort be thrown in there as an addition to the hashing work done, or to replace it? Hashing seems to be the glue that keeps the entire blockchain concept in place to me. In either case, what data would you be sorting/searching? Is this data stored in the blockchain to allow some kind of verification by other nodes? And if you're searching/sorting a lot of data and you are storing it, how do you prevent the blockchain/whatever from growing out of control?

I guess I am trying to figure out what the mechanics of how either of these algorithms would enable the brute force initial pass and easy verification system that bitcoin PoW currently uses, while keeping the blockchain size (or whatever transaction logging system would be used) size down.

I do agree that the absence of PoW with this coin raises a lot of questions and new ways to "game" the system. PoW can be very energy intensive, but it works very well to distribute coin circulation to participants (esp early on when it's crucial to get coins in as many hands as possible), while rewarding folks that take the most risk (i.e. dedicate the most computing resources to it) and preventing manipulation by unethical players that would undermine the basis of any currency (trust).

It sounds like at this point the issue with this system is how to prevent someone from just creating 1000 amazon instances, with 1000 node instances on each. I DO think this matters because besides the obvious unequal and unfair coin distribution in this case (where, unlike PoW there isn't a significant cost/risk increase on the "hatcher"'s part to justify it), I also see network speed and stability issues. If your coin distribution is controlled primarily by how many "trusted" hatching nodes/clients you have up, the P2P network could grow to immense proportions and complexity, especially if the coin starts to gain traction and "hatchers" try to out-game eachother. At that point, your propagation speed across the network could become an issue (or at least would be greatly affected). Machines do have hard limits on the number of open file descriptors/ports, for instance. With bitcoin, this is a non-issue because node participation is not a rewarding factor in and of itself, and thus is naturally optimized in the system.

Any solution to the above in a PoW-less implementation would most likely need to solve the issue of accurate node identification... for instance, if, in the protocol, they tie hatcher identity to IP (or something that factors network node identity in, such as MAC address), you can possibly use tor/proxy meshes, MAC spoofing, IP aliasing, etc to overcome this. I highly doubt there is a form of zero-trust node identification that can not be gamed. With PoW this doesn't really matter, since the work itself is both the limiting and identifying factor (i.e. payment address), and can be easily verified by other nodes.

I guess we will see what direction this all takes when/if the source/whitepaper is released.