[EMUNIE] THE fastest crypto-currency

[Come-from-Beyond]

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.

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

[TPTB_need_war]

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.

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

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.

[TPTB_need_war]

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.

[WorldCoiner]

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.

[USB-S]

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.

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

[wingspan]

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://bitcointalk.org/index.php?topic=1203228.msg12670849#msg12670849).

[Fuserleer]

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.

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

[Richard1972x]

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

[favdesu]

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

[Fuserleer]

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.

[Videlicet]

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.

[monsterer]

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/

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

[Come-from-Beyond]

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

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).

[bhokor]

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

[Anima]

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/

Thank You,
Viz.

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

Update 2009 JAVA 1.6 reaches ~95% performance of C++

[Anima]

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.1M happen in US that directly conflict with 3.1M in europe, how will the network reorganize and reach a consensus once again?

Thank You,
Viz.

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

https://bitcointalk.org/index.php?topic=1159624.0

[wingspan]

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

eMunie actually doesn't use blocks anymore.  But confirmations on individual transactions will typically occur in 10 seconds and be spendable again in 20 seconds roughly.  Project is still in development, and docs are being prepared, so I don't have a good link to give you at this time.

I can summarize the history of blocks and eMunie design changes for you, if you were wondering:

• In 2013 eMunie gave up plans to use block chain tech (June 29th). Understandable delay was required to re-code the core using its better block tree design.
• In early 2014, the eMunie main developer suffered $1M theft, intense scam accusations, and resulting delays, but thankfully, he didn't give up the project.
• In late 2014, eMunie chose to move away from blocks entirely (Nov 3rd)! Six more months were required to re-code block tree tech to its better channel design.
• In late 2015, eMunie core code is being wrapped up, with other modules tied in soon.
• In 2016, if no more core design changes or unexpected delays happen, OB (open beta) testing, funding opportunities, and launch of v1.0 is expected.  But no deadlines.

cheers,
- wingspan.

[chennan]

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

eMunie actually doesn't use blocks anymore.  But confirmations on individual transactions will typically occur in 10 seconds and be spendable again in 20 seconds roughly.  Project is still in development, and docs are being prepared, so I don't have a good link to give you at this time.

...

• In 2013 eMunie gave up plans to use block chain tech (June 29th). Understandable delay was required to re-code the core using its better block tree design.

[/b]

...

Wow, I didn't even know that a "block tree" was being developed... that's actually really awesome he's designing something totally different in comparison to the "block chain" architecture.  But could you go more into depth about what that entails and means in regards of being able to confirm tx's faster and remain relatively secure?

[okiefromokc]

Well here is a little more detail:
1. The block-chain currently with BTC is ~7tps, and the eMunie version of the block-chain was running about 30tps per partition and there being 1024 partitions, or about 30,720tps. This was just not fast enough, as the required confirmation per transaction was ~45 seconds.

2. The block-tree version got the eMunie client up to about 100 to 120tps per partition, and still this was not fast enough, as the required confirmation was ~25 seconds.

3. The block-less channel version now gets a sustained for several hours 300+tps per partition. Again, there are 1024 partitions, so 300 * 1024 = 307,200tps. Granted it maybe awhile before this level of speed is required to use the partitions, but the eMunie client will be able to handle increased volumes whenever the need arises.

As you can see, the goal has all along been to meet or exceed the transaction levels of VISA speed.

What with the working Debit card functionality directly into the eMunie client circumventing all banking institutions, this was another goal of the Dev, Fuserleer.  This was the primary reason for the shift away from the block-tree format of the client, as it was determined that it could not handle the debit card required confirmation transaction speed of under 10 seconds.



okie

[Videlicet]

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/

Thank You,
Viz.

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

Update 2009 JAVA 1.6 reaches ~95% performance of C++

Did you read my post? I quoted it my friend, but this is more "java orientated" or in other words, was completely in favor of java, java with full optimizations, C++ with none. So yes I could see 96% being the closing if a C++ programmer does not know what he is doing... Oh well, I'll leave you "Emunites"... So many closed minds here, with none of my questions addressed. Arrogance will be your downfall Fuserleer... you may be intelligent, but you aren't as brilliant as two intelligent people together, or three, or four...

You forget the spirit of Bitcoin:
"vires in numeris"...

Sadly,
Viz.