Topic: [EMUNIE] THE fastest crypto-currency - page 2. (Read 11691 times)

Concensus primer here. Needs some revision, but the overall answer is there to answer your question

https://bitcointalksearch.org/topic/a-world-of-trust-emunie-consensus-primer-1159624

Did you read the web page before challenging the choice of platform for dev?

Dev, how often is emunie block produced? and which is the maximun size of the block, thanks and congrats for so nice project

It's an urban legend that C++ is faster than Java. It's correct only if C++ code was compiled for that very family of the processor, otherwise Java program will run faster after JIT compiler hits (subject to JIT compiler quality).

Probably because the productivity increase of using a modern language far far outweighs the performance advantage of using c++.

If speed is your #1 (I hope not sacrificing security), can I ask why would you write this code in Java?
http://fiehnlab.ucdavis.edu/staff/kind/Collector/Benchmark/JAVA_Benchmark/

I see with high Java optimizations and low C++ optimizations such as 32 bit C++ and 64 bit Java the gap can close to 96%, but at a standard with no preference to Java lovers trying to make it catch up, I see the base span of 71% of C++ performance. At a +29% increase just from runtime execution if numbers stay consistent in proportion even with the cryptographic functions, you could be seeing +580 tx/s based on your 2000 tx/s claim.

Second thing I see here, is that many are concentrating on "confirmed tx/s", but rather banks leave transactions as pending for days until the funds finally reach their destination. The initiation of the transaction is purely just protocol aka memory pool, and the confirmation in reference to digital currencies can be see as "gotten on a block ". You use account channels from what I understand of your implementation, how do you arrive at consensus if lets say I send merchant A coins, and also send myself coins from a node across the world at the exact same timestamp. How will the consensus be reached as to which is the valid transaction? How will the distributed network recover from lets say the trans atlantic cables being out of service cutting europe from the usa for an hour even, which at 2k transactions per second would be 7.2M transactions. And let's say 3.6M happen in US that directly conflict with 3.6M in europe, how will the network reorganize and reach a consensus once again?

Thank You,
Viz.

Thanks for the congrats.

However I do not mean to be rude, but this debate of speed was settled some time ago, and I would suggest you take the advice you offer of being careful about what I say and give it to BitShares instead.

1. They claimed 100,000 tx/s which is simply a claim they can not make.  It was done in a lab, and wasn't even a real world test.
2. Their test net only just managed a peak of 1000 tx/s
3. Their live net is throttled to just 100 tx/s as anything more causes serious issues.

We managed a peak of 2400 tx/s on our test net, achieved peaks over 1500 tx/s many times and ran sustained tx loads of 300+ tx/s for hours at a time with no issue.  Furthermore the last time I checked, 2400 was more than 1000.

Everything else is just wild grandiose claims and until someone presents fact of a something faster, on a public test net, with 3rd parties witnessing the event to back up the claims, eMunie IS the fastest crypto tech right now.

Congrats on your TPS, very nice!

however, be careful with your words (the fastest).

Take a look at BitShares 2.0 pre-alpha testnet results

This seems to be a very interesting Coin-Project. Looking forward to it 

Open betas, crowd sales (or whatever they are called these days) and more is all due to kick off in Jan.  Will post with specifics nearer the time.

I've been a bit quiet as of late I know, hunkered down and working hard

soon.  More info at https://forum.eMunie.com and https://twitter.com/eMunie_Currency.  I'd imagine there will be no date for launch or funding until after all is sewn together and public testing (A.K.A. "OB" or "Open Beta") is looking good.

BTW, I am still willing to do a speed test bake-off if any dev team wants to challenge eMunie's 2000 TPS claim.  PM me if you want to submit an entry (before Dec 26th) per the bake-off thread from two months ago (https://bitcointalksearch.org/topic/m.12670849).

Would love to hear more info about the launch as well.

Any news here Dan. Crowdsale first quarter 2016?
I know, you don’t like to be in a hurry, but in fact the time is running against you…

Thanks.

The following domains can be registered at namecheap.com. I strongly suggest you grab them immediately:

emuni.es
emoni.es

If you had not already claimed that name, then I would strongly consider using those names. But I don't want to steal your ideas.

I think all of us working on block chain scaling are very busy. Good luck to all, and let's see what we all come up with and how it settles.

I personally will put more energy into analyzing Iota once you've guys have settled all the issues and are nearer or at release. Ditto eMunie.

Peace and chillax to all.

We sent them the whitepaper but they seem to be busy with Bitcoin-NG.

That is why I will just wait for the dust to settle, before and if I attempt a more quantitative argument. Or perhaps the guys who found the selfish mining flaw in Bitcoin will endeavor to analyze these new consensus designs once they have been more finalized.

It is an inefficient use of time to chase a moving target where I have the disadvantage of not having first access to the information that is in your head(s). I'll wait for your publishing.

Aye, we stuck because I was too conservative in definitions.

I have already argued to you in your Iota thread that your definition of Availability has no relevant meaning (propagation to across the peer network is not a semantic outcome). Rather a meaningful Availability is the ability to put your transaction into the concensus. In Bitcoin, that availability is limited in several ways:

• Confirmation is only every 10 minutes.
• Inclusion is in a block is dependent on the whims of the node which won the block, and on the maximum block size.
• One who has sufficient hashrate power, has higher availability.
• 51% of the network hashrate power can blacklist your Availability.

It is my stance, that the holistic game theory analysis of Availability in Iota, eMunie, and "block list" is much more muddled thus far. The multifurcated tree of Iota appears to be multiple (potentially inConsistent) Partitions, so Availability to create a new tree branch doesn't appear to be meaningful Availability since there is no confirmation of consensus.

Because (as indicated/implied by my prior post) it is more sane to design your system holistically such that ordering of transactions is an exceptional event, and not a routine one.

Conflation of "order book" with TX/s is a category error. It is not even clear if a decentralized "order book" can or should have a deterministic ordering, because determinism may allow the market to be gamed. In any case, it is not relevant to the issue of rate of processing TX/s for signed transactions. Separation-of-concerns is a fundamental principle of engineering.