Bitcoin Forum

Hey folks,

A bit of news from our neck of the woods, tonight in testing we achieved in excess of 2000 transactions per second processing which is generally considered to be "VISA scale" (we achieved 2,400 to be more specific).

Over the past 6 months or so, there have been many developers that have publicly announced that their platforms can scale to handle x thousands of transactions. However, I'm yet to see any evidence of any crypto-platform achieving a few 100 outside of "perfect lab conditions", let alone a few thousand. Some of the platforms attempt to scale vertically to achieve the transaction throughput claimed, but these platforms require things like super-nodes in the network, with the power of a small super-computer (and the bandwidth to match) in order to achieve it.

In my opinion, all of these claims are bogus until evidence can be shown of said platform achieving anything close to VISA scale in the wild. That is the true test, with participants in different locations, with fast, slow and in-between nodes taking part. Super computer nodes do not count!


When I started the eMunie project, VISA scale was one of the many goals I set, and today we are a real step closer to being there. First a little brief on why we can do this (more information on this stuff will be available as soon as I can find some time between coding and testing to write it up).

The eMunie ledger can be partitioned into 1024 partitions, with nodes in the network supporting 1 or more partitions depending on the performance they have available. Fast nodes might support all of the partitions, very slow nodes may only support a few, but between them all partitions are present in the network multiple times providing redundancy.

Partitions contain channels which are owned by wallet holders, and contain the transactions for a particular "channel key". A partition may have millions of channels as the network grows, but most of the time, a large quantity of those channels will be inactive (not receiving or sending transactions), so a single partition of n channels needs only a finite amount of processing power managing it at any one moment in time.

Even the slowest of commodity hardware we have tested can process 100-150 transactions per second with ease, thus that is the baseline sustained performance metric for a partition.


This evening it was decided that we should finally test to see what is the burst limit of a single partition. We have been testing for quite some time with various loads between 50-200 transactions per second, but we've never actually pushed the envelope to see where it maxes out.

After some organization of testers, and the logistics of getting everyone ready to hit the network with a large amount of spam transactions for a short period, we let rip. The network produced over 4000 transactions in under 10 seconds, all directed toward a single partition, with a peak of ~2,400 tx/s....the network size, 12 nodes of varying configuration in various locations around the globe.

With sustained performance of ~150 tx/s per partition easily achieved, burst performance per partition of 2000+ and 1024 partitions, even if cumulative performance of all partitions is not a linear increase, I'd like to think we have enough performance capacity to deal with anything the network has thrown at it.

Here is a short video with a voice over, of that test taking place.

https://www.youtube.com/watch?v=n0YpFfgwudA

You can see the transactions leave from 2 of the 7 designated spamming nodes(in the command consoles), with the monitor displaying the total transactions seen in the network at any moment in time. The monitor updates every 10 seconds and you can clearly see the effect of network latency as all the transactions arrive at that node over the course of a few seconds.

Some of the slower nodes of course struggled a little for 20 seconds or so to catch up, with the faster nodes taking up the slack.  All the transactions presented in the burst were processed by the network, all nodes had them within about 30 seconds (even the slowest) and these funds were available to be re-spent a few seconds later.

As one of the testers I can confirm as well that the claims are valid (as seen from my pc).

It was a beauty to behold:  http://imgur.com/8xOUTvz

Well done eMunie. Looks like we have a real disruptive technology on our hands.

Surprised that this project is still being developed.  I thought development was halted.  Congrats on scaling.  Hope to see it when your network goes up.

Thanks! Project was never halted, we just went under the radar so that we could concentrate without endless noise :)

Vanillacoin can easily do 100+/s currently through ZeroTime and they are respendable in 3-4 seconds each with the TCP/UDP network. Still congrats.

So in other words, Vanillacoin has about 1/20th the processing speed of Visa and 1/24th the processing speed of eMunie. Sounds like something that should be kept quiet rather than promoted.

But what is your coin apart from a coin?
Is there a business-plan so that this supposedly speedy coin will have a purpose, other than being another mining pump/dump coin for the few?
Will it be useful to 'joe-average' and 'auntie-emma' and thereby be valuable outside the crypto exchanges?

Mind you - I'm not asking in order to harass - I'm simply asking because almost none of all the 5-600 cryptos can deliver something that is meant to be useful, other than being sold and bought on crypto exchanges amongst crypto nerds.

Being the fastest altcoin does not give you much benefit. Dogecoin is already quite fast in my opinion and there are many coins which are fast but are nowhere near adoption.

I think to get adoption one would have to be as fast as VISA to make it something worthwhile. Otherwise why would people bother?
Quite fast is 'quite' good.

If you take note of the OP, we stress tested a single partition....there are 1024 partitions in total.

One requirement for this performance is to support the native eMunie debit cards at point of sale terminals.

Agreed. 
Fast is important as well since it works nicely with our native point of sale terminal and smartcard (which we've already successfully tested).  All done without the need for a 3rd party to manage the txns. 

Is it fully decentralized?

It aims to be an overall upgrade to bitcoin: in speed, in decentralization of the revenue stream (mining) and in anonimity. Not finding the question offending, everyone here in the cryptosphere competes for the same objective imho. Else than that the source is cross compatible, we have a native staking wallet that act as full nodes while using almost no (minimal electricity) and the code can be compiled to mine on any smart device if needed (ioT/like what 21 inc aims to do right now, but with built in FPGA chips in smart devices), we have a MinerPP project for that.

But yeah, don't want to be offtopic, came here for Emunie :)

Really asking that question ???  ::)  Of course it is!

There are no "super nodes", no delegates, or anything of the sort.

Even the debit cards are decentralized to the degree where you can make your own, load it with funds, then pop to the store and buy your coffee and cake (assuming the merchants POS terminal has the EMU patch for his existing hardware).  

The debit cards don't run on the VISA/MC network, or need a 3rd party.

Is there a whitepaper available also is open sourced or is everything closed currently?

I'm here because I find different solutions interesting, so congrats for it.

Nice to hear from this project. I had participated in one of the earliest beta tests but then lost interest as it looked a bit like vaporware, sorry.


The crucial factor is not only "being fast", but being able to guarantee a secure network with no bottlenecks when transaction number is high. That means that the currency must provide enough incentive for full nodes to provide storage capacity and bandwidth.

If eMunie does manage this without too much centralization - the "partition system" is interesting - then it's a real progress for cryptocurrencies.

Comparing Dogecoin to emunie is like comparing a clown car to a ferrari.

Unfortunately Im spending much more time in development and testing than actually writing docs....I've got a few half finished that I really need to get to that explain the ledger, balance system, consensus, debit cards and more in detail, I just need the time to get around to it.

I did post a consensus primer a couple of weeks ago you can find at this thread https://bitcointalk.org/index.php?topic=1159624.0

Even that is a little out of date now and there are some things I need to revise within it.

Code is closed source while under development.

indeed - it was great to see that tx spike come through in a live network :)

Fair enough, I get that development has been long, and people lost interest etc...

The purpose of the partitions is to go some way to guarantee those properties.  Ledger data/channels are allocated to partitions as per their ID, which is random, so distribution of channels around partitions should be sufficiently uniform.

The flip side of that is as you rightly state, that incentives must be high enough to encourage those with the hardware to point it at the network.  Nodes are paid for all work they do (not the lottery type deal with BTC), and the fee schedules for various actions in the network top that up further, so this shouldn't be an issue.

There is zero centralization at all in the platform, nor will there be...this is one of the reasons development has been long.  I could have cut corners in the design with super-nodes or whatever, but I didn't want to.

Just throwing this out there..  the OP is misleading, it is not the fastest.

Other than that I love what you guys are doing.
 

How fast is the fastest?  I've not seen evidence of anything significantly faster than 100 tx/s, without some form of semi/centralization.  Pure developer claims don't count.

And thanks :)

Hadn't heard anything about eMunie for about a year. You guys are good at keeping whatever you do out of the radar but this is really worthwhile. You effectively addressed the scalability issue just at the time the bitcoin community is throwing fits about it on a daily basis.

Thanks.  As said in the thread somewhere, it was all getting too noisy and distracting so under the radar to crack on until we had something tangible.

In the past month we've hit 2 of our initial goals, VISA+ scale processing capability, and native debit cards that hook right into the eMunie network at the POS terminal without having to piggyback.

There is more to come in the next month that is being wrapped up now, so we wont be under the radar quite so much now :)

It takes time to build a high quality product.
Quality that can live up to a heavy transaction flow, and future users.

Mintcoin is currently able to support 1600 per second, fully decentralized. I'm not sure what else is faster than that at this point.

Challenge accepted.

Is there a video of the Mintcoin client doing the 1600/sec speed?
Link please so I can watch it... Thanks

The first post clearly states Visa scale processing is 2000 tx/s. eMunie just hit 2400 tx/s. Not sure why people are boasting about Vanillacoin and Mintcoin's processing speeds which are a mere fraction of what eMunie is capable of.

Vanillacoin, Mintcoin, [Insert Name Here Coin] are just copy and pastes of Bitcoin where some "developer" did a search and replace on the code, changed a couple of parameters, changed "Bit" to some food or animal based name and replaced the Bitcoin logo with a GIF they found on Google Images. To think that one of these clown coins is going to be used in mainstream, Visa level financial processing is beyond ridiculous.

You're probably the one and only developer I wouldn't mind proving me wrong :)

If you can show me proof of an existing crypto processing 250 tx/s sustained, I'll be mildly impressed.   If it can be done on 20 or less nodes, I'll be suitably impressed.  If you can show the same doing 500 tx/s+ I'll be very impressed.

Likewise if you can show peaks of 500, 1000 & 2000+ the corresponding impressed level as described above will be in effect :)

You wouldn't state that if you actually researched the source and wouldn't be the average user with sheep mentality here ;)

Some critical points seem to be getting missed by proponents of other cryptos.

1) This was a network of 12 (yes twelve) nodes
2) This was a single partition

Across all partitions (1024), a tentative figure for very high load that the network should be capable of easily processing collectively is around 100k+ tx/s and beyond.

Perhaps I'll post another video when we have enough testers online to actually produce the quantity of transactions needed to surpass 10k+ tx/s :)

I mis-typed. I mean't to say mintcoin's capacity is at 1600 per second. 

Where can I see evidence of this?  Is there a block explorer that shows it happening?

https://chainz.cryptoid.info/mint/

Well it is not currently happening right now this moment, I am just saying what it is supposed to be able to do. I don't know how to test it or I would.

What are requirements for bandwidth, RAM and CPU of a node?

PS: I'm using a hash-based signing algorithm, it's much faster than elliptic curve stuff (even faster than Ed25519), so I may have some advantage right from the start.

The lowest spec node I ran in that test was an Asus i3-3217 laptop, 32bit OS, 256MB of heap allocated to Java and the DB running on its 5400 rpm platter drive.  Its a really crappy machine, the CPU is Quad Core, but it barely manages 2000 passmark points and the HD...well....pen and paper would be faster I swear.  It *just* about kept up acting as a ledger node, so I guess that or lower is your target ;)

Not sure if anyone in the network was running lower grade hardware than that.

Hmmm...Ive found that the major bottlenecks on lower end stuff is actually the IO DB writes/reads and not so much crypto related stuff.  Sure it has a positive effect if you can speed it up, but a good 70%+ of optimizing I do is how to get data over the IO quicker and more efficiently.

What DB system do you use? MySQL? I use http://docs.oracle.com/javase/8/docs/api/java/nio/MappedByteBuffer.html.
I have just recalled that Emunie does much more than just payments, in this case we cannot compare our solutions, because our cryptocurrency works with payments only and doesn't need to do sophisticated stuff like order matching.

That was like word for word what Bytemaster said in this youtube video heh:  http://www.youtube.com/watch?v=bBlAVeVFWFM

Well IO is always a problem bottleneck, thats simple developer 101

MySQL and Derby for development, probably go with Derby or H2 for V1.0.  

The data stores themselves are abstracted though, so any DB solution can sit behind them with minor work so long as they implement the basic interface.

That solution for you (if it fits your purpose) will be very fast, then your IO bottleneck will mainly shift to network I imagine?

Network will become a bottleneck at 12'000 TPS (for 100 Mbps).

Yup, partitions my friend, that problem goes away ;)

Isn't this system going to be extremely difficult for updates in the long run?  Partitioning and having different groups who don't update, etc.

If you get something right the first time you don't have to worry about forking it later due to the inability of it to scale to necessary levels.

The "core" txn system is what is being done right the first time.

All other layers on top of that (e.g. client functionality) are merely utilized expressions of the capabilities for the users.  Those can be updated easily.

Where can I find the specifications?

why not a lean KV approach?
an in-memory/disk hybrid like redis can handle such tiny amounts of data in a blink
with lowest cpu usage compared to bloated rdbms. e.g. one million keys occupies only
100 mb memory. persistence is great via fine granulated shapshots. the api provides
all primitives to layer a query model on top. should be a good choice for this kind of task.

if a full persistent solution is needed something like sophia outperforms many other
disk based storages and is nearly as fast as redis but with a fraction in code size.

Will this approach run on a $600 commodity Notebook computer, which is what I am successfully using as an eMunie beta tester?

How can one be an Emunie beta tester?

Dan has been slowly bringing more in over the past 2 years for the closed beta releases. I've been one for close to a year now. I was pretty frustrated in terms of how long it took to be givent the status. Lately it has been mostly founder beta testing (a much smaller group). From this point you would be better off waiting for the open beta. But to try to get closed beta access, you can try through the eMunie forum.

Ah, no matter.  I'll wait for the open beta.  Thanks.

Should be a few days before the 7 horsemen of the apocalypse approach.

I'll be patient.  ;D

Does the price go up if more people get in =w=

THE fastest crypto-currency is BitShares 2.0 over 100 000 transactions per second scalability (1 second block)
https://bitshares.org/technology/industrial-performance-and-scalability

Will be launched October 13 with 3 seconds block (30 000 transactions per second)

Arguable.  Emunie doesn't have the delegates system you have, but is truly and fully decentralized.

And it will break on October 14th.  Everything BTS does needs emergency patches, forks, magically creates new coins out of thin air, or has to be completely redesigned later.  What is this, like the 9th version of Bitshares?  Reading the blog Dan's answer to a decentralized cryptography value transactions, was to take out all the decentralization and the cryptography.  Nice. 

It's depends from that you mean under fully decentralized, Bitcoin also was designed to be fully decentralized but today you have 3 pools which have more that 50% hashing power.


Today BitShares has 101 block signers (delegates) in 2.0 it's will be configurable without hard fork, so if shareholders will decide to have more decentralization they can vote to 1001 delegate.
Bitcoin has 3+ block signers, Ripple has 7, BitShares has 101, Nxt has 700+, eMunie - potentially unlimited like Bitcoin?

That's inconsequential when a small minority of the shareholders can effectively rig the delegate elections by strategic voting.

I guess fuserleer meant as in fully decentralized, like when Bitcoin was still at the CPU mining stage of its development.  But let's wait for him to drop by and explain.

Correct, there are no super-nodes, delegates or anything of the sort and never will be.  There are no blocks and there is no mining so supply distribution is 100% fair.  Consensus is achieved via a different algorithm which I posted about here a while ago.

Bitshares doesn't count, as its not a fully decentralized transactional system by design, and even if it was I doubt those claims are anywhere near possible in the real world.

In these videos that everyone keeps posting he says "to keep everything in memory".  How much memory do you think you need to keep pace with a days worth of 100,000 transactions per second in there?

He claims that the minimum tx size is something like 120 bytes so thats 120*100000*86400 bytes of transactional data per day, if you are keeping that in memory then it's near as damn it 1TB of RAM.

Now you probably dont need *that* much, but if you are order matching, then you need to have at least a large portion of recent transactions, a couple of hours worth maybe so that you can successfully match old buys/sells that haven't been matched yet to new ones.

What happens if you need to go to disc for a few 100,000 that arent in RAM......dead......that 100,000 tps turns into 1000 tps as soon as you start hitting discs.

In another video he says they made a 1M tx ledger, loaded it to RAM and processed it in 10 secs.  I could load a 1M eMunie ledger to RAM and re-process it in rapid time too.  The problem is constantly getting it into RAM and getting it back out again.

Whats the best write speed on PCI SSDs atm, about a gig per sec? so it takes 1000 seconds to get a days worth of data that might be in RAM to/from disc best case.  If you do it on demand then that 100,000 tps disappears.

What about ACID compliance too, if everything is in RAM what if that machine suddenly crashes, or has a power outage?  What if it was the only machine in the delegate list that had some of the very most recent transactions and hadn't forwarded them yet?

Furthermore I am suspicious that this 100,000 tps only applies to its order matching and not general transactions.  How can 120 bytes store TXID, sender/receiver, signature, value, asset type and the inputs, it doesn't fit.

For the record I'm not well versed in how Bitshares works, nor am I going to spend the precious time to learn its innards, I'm just going on what I've casually read here and common sense.

I found eMunie consensus algorithm description here: https://bitcointalk.org/index.php?topic=1159624.0
Looks interesting, let's see how this will work in test or real network.

You make calculation for BitShares based at your excellent hardware knowledge even without understanding how BitShares exactly works.  :)

But anyway it's will be launched 13 of October and everybody will get chance to try. If someone interesting to try how BitShares 2.0 can handle load in test network, all info can be found here: https://bitsharestalk.org
BitShares 2.0 online wallet (test network): https://graphene.bitshares.org

Where/when eMunie test network will be launched?

Is it possible to invest in this project?

I don't need to know how Bitshares works in detail to apply general computer science theory to the claims made.

Perhaps when its launched everyone should get together on its testnet, and spam it to 100,000 tps and see if it holds up.

The test network is available now if you are a registered beta tester on the eMunie forums, I drop versions there from time to time for beta testers to get to work on.  The latest consensus has had many rounds of testing since it was implemented in Feb.

Not yet, its not launched and there is no public fundraiser scheduled atm.

The statement above is ironic to me because if you consider DPoS not decentralized, that would mean you also consider PoW and PoS not decentralized, meaning Emunie would be the only decentralized system.  Why do I say this?  All you need to do is compare the three systems:  PoW, PoS, and DPoS (Bitshares)

For standard proof of stake, the end game stake scenario results in people having to pool or lease their stake, otherwise there's no point to stake at all.  They're delegating their vote power to determine the longest chain to the pool owner.  The act of doing so results in two things.  First, you've recreated the centralization of PoW pool mining, where most of the blocks are being validated by a handful of people and one out of million being done by some random guy.  Secondly, you've also recreated DPoS, just a less efficient, less decentralized way of doing so.  Most blocks being signed by a few pools vs larger number of block validators in DPoS.

For PoW it's obviously the same thing, delegating your mining power to a pool owner, then like 3 pool guys sign all blocks.  I tend to agree with the following PDF, that actual decentralized currency systems you upload and they run like a virus forever without intervention or attendance aren't possible:

Decentralised Currencies Are Probably Impossible But Let’s At Least Make Them Efficient

http://www.links.org/files/decentralised-currencies.pdf

Due to this, I'm very skeptical of the Fuserleer system functioning without black swan events that just blow it up with no way to recover.  It doesn't seem like you can get rid of the human element, whether that involves switching pools to avoid bad actors, or voting, or whatever.  These acts are fault recovery methods.  What is Emunie's fault recovery method?  Fuserleer changing name and skipping town if it crashes?  The act of software updating a partitioned system also seems sketchy to me.

^ It's all arguable and no one is right or wrong.  And one implementation doesn't necessarily mean it's better than the other one. 

I remember Bytemaster making statement that Bitshares is not decentralized. Has anything changed?

This is true.  I think he mentioned it at Let's Talk Bitcoin or something...

How exactly do you quantify the word "decentralized"?  He refers to Bitshares DPoS as a distributed autonomous company, but if you read my post above and disect the real workings of PoW vs PoS vs DPoS, all three are using delegation.  Lots of people like to claim anything that uses delegation can't be decentralized, but Anonymint and I have made many points to show that's false.  He even went as far as stating he's delegating his transfer of packets to his ISP.  What's next?  Anyone using an ISP isn't decentralized no matter what the coin is?

Delegation is all about economy of scale.  Systems that use it are achieving higher performance or less waste and will outperform systems not using it in the free market.

Fuserleer claims to not be doing this to achieve his performance.  In reality, he's basically created a big video game with lots of arbitrary variables and some rudimentary AI (challenge system) to try and automatically grade the players.  Will it work?  Nobody knows.  Game theory approach vs video game approach, battle of the century.

Even general computer science theory doesn't help if you made wrong assumption what BitShares store in memory.
Thanks for testnet info, I will wait for public beta.

Dan Hughes is a real person with real family, friends, and business associates.  He won't run and hide nor have a reason to do it.  He has poured years into this project...and stands to make a lot of money continuing to help the eMunie ecosystem thrive...by way of honest occupations (e.g., book writing, speaking engagements, movie roles, and further coding).  If, by chance, eMunie does fail, it will be due to some bug/flaw that not one honest code reviewer found.  In a few years, it will possibly become the most reviewed software in the world -- since it could very well become the safest "bank" for individuals to keep control of their wealth.

Just for the record, cross post from https://bitcointalk.org/index.php?topic=1196533.msg12575441#msg12575441

Can't we enjoy both technologies without turning it into a pissing contest?

Ok that clears that up, maybe he should be a bit more clear in future about what exactly "...keep everything in RAM..." means.

It still leaves a lot of questions unanswered regarding that claim though, specifically the IO related ones.

Streaming 11MB from disc doesn't sound like its too hard, but it depends on a number of factors.  Reading one large consecutive 11MB chunk per second is of course childs play, but if you are reading 11MB in many small reads (or worse still if its a mechanical platter drive and is fragmented) then that simple task becomes not so simple.

Also, network IO seems to have some potential issues.  11MB/s down stream isn't too much of a problem, a 100Mbit downstream line will just about suffice, but what about upstream?  I'm assuming (so correct me if Im wrong), that these machines will have numerous connections to other machines, and will have to relay that information to other nodes.  Even if each node only has a few connections (10-20), but has to relay a large portion of those 100,000 tps to each of them, upstream bandwidth requirements for that node quickly approach multiple gigabits in the worst case.

Further more, lets assume that Bitshares is a huge success, is processing just 10,000 tps sustained and that none of these issues exist other than storage.  As Bitshares relies on vertical scaling, and we've already determined that 100,000 tps = ~1TB of data a day, 10,000 tps = 100 GB daily.  Operators of these machines are going to be spending a lot of dollar on fast drive space and have to employ sophisticated storage solutions in order to keep pace.  This becomes quite insane at the 100,000 tps level (365TB per year), perhaps Bitshares has some chain pruning or mechanisms to keep this down?  (I hope so!)

Finally back to RAM requirements, what are the measures or mechanisms in place to prevent someone from creating 1Billion or more empty accounts, and causing RAM requirements to shot upwards as this information is kept in RAM?  A few machines could easily do this over the course of a couple of weeks if there are no other costs associated with it, I assume there is some filtering to only keep accounts with activity in RAM as otherwise this will be a major issue.

Eitherway, this is just another example how vertically scaled systems are not viable, should Bitshares grow to the level where it is processing 100,000s of transactions per second and has even a few 100M accounts, you need a machine with 100s of GB of RAM, 100s of TB of storage, and internet connections in the multiple GB speeds.....not really accessible to the man on the street.

Perhaps the cost of participating at that level just isn't an issue, as Bitshares has always had a semi-centralized element to it anyway, and most supporters of it don't seem to mind it.  For me though, relying on ever increasing hardware performance and sacrificing core principles which brought us all here in the first place is a cop out.

I'd prefer that they do.  It's good that they push the tech forward.

It's nothing about "pissing contest", it's technical discussion which can make both systems better.
PS: I wish eMunie only success

Are there reorgs in BTS ledger? If yes - how fast does it do transactions reprocessing? If no - how does it behave after partitioning?
The same questions about EMUNIE.

Can I just politely ask the audience to use the correct way to write the brand: eMunie

Thank you :)

I wrote "eMunie" but then saw the thead title...

@Come-from-Beyond

Haha you are right - I didn't even notice that in the thread title.. ;)

People get salty when it comes to new released. It seems like bringing development under covers and moving to a dedicated forum worked worked for the team. We'll be able to judge them by the innovation after the release, even better after the source is out after the release.

This is a cool project, and cryptos need to find a way to be as fast as possible for the masses to want to adopt, due to their fast paced life styles, IMO... so when do you think the official release of this coin will be?  Any ideas?

There are no "deadlines" - we will release when its done. No Deadlines allows us to experiment and find new solutions even though we thought we had found it - and test those out.. We probably have disapointed more people stating deadlines than with no deadlines because people won't get all exiting we are gonna launch soon with tech we have much improved only to get their hopes down.

If you're really interested in the project, you can go to our forum and ask to be a beta tester and help test it out after the founder tests (who tests the "alpha" versions). There will soon be a new beta to be tested.

I was just about to post this very same.   "Its ready when its ready" is our mentality.  I made the mistake of setting deadlines in the past, only to find I wasn't happy with components of the platform, or had discovered a better way to do things.  I've probably thrown away more code and smart ideas developing eMunie over 2+ years than most of crypto combined!

IMO a better product, in any way, is always worth sacrificing deadlines for, providing that myself and those with a real vested interest all agree.  So I don't set deadlines anymore.

With that in mind, the core design hasn't changed for 9+ months now, and I don't see any better ways to do the things we want to do in order to achieve the goals we set, most are already achieved.  Take from that what you will :)

Nice, well will you just be opening up another thread asking for more testers for the new up coming beta version? Or will you just be posting that information here? Regardless I'm going to be monitoring this crypto, so I hope the best for what you guys are trying to achieve :)

I'll make a thread on here when the time comes. :D

So as can be evidenced here, while Bitshares did reach 1000 tps (peak!) during their internal tests, it caused stability issues that put the test to a halt. In order to resolve it, they have pegged the throughput to 100 tps max due to network IO issues.

Link to post https://bitsharestalk.org/index.php/topic,18717.msg241280.html#msg241280

Small update on our testing.

We've been running a beta test for a couple of days now and did some sustained and burst performance tests to see how things might go in the real world.

Network was about 30 machines, some of which were very low powered, I think we had a couple of micro-EWS Amazon instances and even an Odroid!

The network was also configured to operate in single partition, multiple partition tests will commence soon (near linear multiplier).

First we did a couple of transaction burst tests, IIRC we hit a peak of 550 tx/s, but the guy making the video didn't catch it.  The next one he did and we managed 400 tx/s spike on this one

https://www.youtube.com/watch?feature=player_embedded&v=L-VBp2lAI5I (https://www.youtube.com/watch?feature=player_embedded&v=L-VBp2lAI5I)

Secondly, we set up a steady sustained spam of about 100-200 tx/s over about 30 mins or so, and then threw multiple bursts on top of that

https://www.youtube.com/watch?feature=player_embedded&v=8jSiUE8VEWc (https://www.youtube.com/watch?feature=player_embedded&v=8jSiUE8VEWc)

Enjoy!

Let's talk software engineering a bit...


Daniel Larimar incorrectly claims in that video (https://youtu.be/bBlAVeVFWFM?t=33) that it is not reliable to validate transactions in parallel multithreaded. Nonsense. Only if the inputs to a transaction fail to validate would one need to potentially check if some other transactions need to be ordered in front of it, or check if it is a double-spend. And he incorrectly implies (https://youtu.be/bBlAVeVFWFM?t=88) that the only way to get high TX/s is to eliminate storing UXTO on disk, because presumably he hasn't conceived of using SSD and/or RAID and/or node partitioning. It is impossible to keep the entire world's UXTO in RAM given 36 bytes of storage for each 256-bit output address+value, given even 1 billion users and several addresses per user. He mentions using indices instead of hashes (https://youtu.be/bBlAVeVFWFM?t=158), but enforcing such determinism over a network makes it extremely brittle (numerous ways such can fail and having addresses assigned by the block chain violates user autonomy and the end-to-end principle) as well even 64-bit hashes are subject to collisions (http://preshing.com/20110504/hash-collision-probabilities/) at billion-scale. Essentially he is making the error of optimizing at the low-level while breaking higher-level semantics, because he apparently hasn't gone about the way to really scale and solve the problem at the high-level semantically.

Edit: Fuseleer applies the term "vertical scaling" to describe Bitshare's optimization strategy.

Both of these methods are horridly inefficient. Cripes disk space is not at a premium. Duh!

Why nonsense, it depends on linearity of the system. For a linear system order doesn't matter, for a non-linear one it does.

PS: We assume that multithreaded execution can't ensure a specific order of events, which is pretty reasonable for current architectures without placing a lot of memory barriers which would degrade the performance significantly.

@TPTB_need_war
yes, agree. datasinks like mysql etc. doesn't provide predictable query performance under real world conditions.
there are reasons ssd optimized stuff liḱe this exists: http://www.aerospike.com/performance/

reagrding threading and trade offs, just a matter of tools. still waiting for the first crypto project written
with an erlang/mnesia combo. spawn a process costs you 1µs and using mnesia as distributed datasink means you
are working within the same memory space as your application, as a result, fetching data objects is a matter of
a few microseconds, all proven and robust due to erlangs memory protection at VM level.

however, curious to see the final storage setup, delivering those tps, doubt it will be mysql or similar rdbms  ;D

I expect that when you do finally issue a white paper, the weakness is going to be the economic model will be gameable such that there is either a loss of Consistency, Availability, or Partition tolerance (CAP theorem). Because without a proof-of-work (or proof-of-share[1]) block chain, there is no objective SPOT (single-point-of-truth), which really becomes onerous once partitioning is added to the design because afaics there is then no way to unify the partitioned perspectives. I believe this to be the analogous underlying flaw of Iota and "block list". Challenge with proving this flaw for Iota et al, is to show a game theory that defeats the assumptions of the developers (white paper), e.g. selfish mining game theory against Satoshi's proof-of-work. However, I have argued in Iota's thread that this onus is on them to prove their design doesn't have such a game theory. Otherwise you all can put these designs into the wild and then we can wait to see if they blow up at scale. Note I haven't had enough time to follow up on Iota lately, and I am waiting for them to get all their final analysis into a final white paper, before I sit down and really try to break it beyond just expressing theoretical concerns/doubts.

[1] In PoS the entropy is bounded and thus in theory it should be possible to game the ordering. In theory, there should be a game theory such that the rich always get richer, paralleling the 25 - 33% share selfish mining attack on Satoshi's proof-of-work. However, it is not yet shown how this is always/often a practical issue. Proof-of-share can't distribute shares of the money supply to those who do not already have some of the money supply. Proof-of-share is thus not a debasement power-law flattening (recycling) distribution compatible scheme, although neither is proof-of-work once it is dominated by ASICs. Without recycling of the power-law distribution, velocity-of-money suffers unless debt-driven booms are employed and then government becomes a political expediency to "redistribute from the rich to the poor" (which is then gamed by the rich and periodic class/world warfare). Proof-of-share suffers from conflating coin ownership with mining, thus if not all coin owners are equally incentivized to participate in mining, then the rich control the mining. A coin owner with a holding that is only worth less than his toenail, isn't going to bother with using his share to mine. Thus proof-of-share is very incompatible with the direction towards micro-transactions and micro-shares. Any attempt to correct this by weighting smaller shares more, can then be gamed by the rich who can split their shares into micro-shares. Ideally debasement should be distributed to an asset that users control but the rich can't profitably obtain.

I believe Availability will always be nine nines for any decentralized cryptocurrency and Consistency will always be eventual, so Partition tolerance is the only toy we all can play with.

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.

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.

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

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.

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.

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.

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.

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

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

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

Congrats on your TPS, very nice!

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

Take a look at BitShares 2.0 pre-alpha testnet (http://blog.smartcoin.pw/2015/10/bitshares-testnet-highlight-1000-tps.html) results :)

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.

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.

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

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

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

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

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

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.

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?

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

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.

Well shit in a bag and punch it!  I didn't even respond and I'm getting personal attacks fired at me!

Ok Mr.Viz, you got my attention, I'm going to engage purely because I'm chomping down on my morning chow before getting to work and I'm in the mood.

I thought initially we'd crossed paths before and I'd perhaps given you reason to be so aggressive, but alas, I can't find anything that would suggest as such.  Let me remedy that by purely and unreservedly pissing you off to high heaven.

First and foremost, lets address the issue of arrogance.  I'd advise you to take a good hard look in the mirror for a picture of it, as during my brief search to see if there was any legitimate reason for your animosity, I constantly came across arrogance emanating from yourself.  A number of times I witnessed things such as "I have 10+ years of coding experience" and other claims stated with some form of perceived authority. You even posted that very fact on our FB page a few times over the past month or so when trying to get my attention, as if it was a justification that I should apply some level of respect towards you.  For what its worth, I've been programming for over 25, yet you don't find me pointing that out to everyone repeatedly.  

There is also the matter of courtesy, or lack of.  You seem to demand that others respect you and listen, yet offer no respect in return, going as far as belittling people that don't share your opinion.  Then you have the damn audacity to complain when those you wish to engage with ignore you.  Your complaint was made despite the fact that I hadn't even posted on here for a number of days!  Please tell me, why on earth would I waste my time getting into a discussion with someone who's obvious agenda is negativity and destructive criticism?  Your guise of "wanting to help" as you posted on Facebook isn't fooling anybody!

Lets look at what is likely the cause of this sudden interest you have with myself and this project.

Back on the 1st Sept Mr.Viz posted this in his Nexus thread...


You can clearly see from the writing of that post that Mr.Viz feels that he has invented something new.  In actual fact a block tree is not new, as many here already know, I was investigating the merits of tree based ledgers up to 2 years ago and implemented the first functional block tree towards the end of 2013.  

The brief description that Mr.Viz provides lead me to believe that the implementation ideas he has, are similar in many ways to the design that I implemented all that time ago. Ultimately the use of block trees was scrapped, as it didn't meet the requirements for the project, and while I didn't publish any papers it's both common knowledge and publicly recorded here and elsewhere that I was the first to investigate it and produce an operational implementation of a block tree based ledger.

It seems to me that Mr.Viz is simply irked off when he learned that he wasn't the first to do so, and so decided to come here and attack rather than just accept it.

Which, seeing as the gloves are off, brings me to this.


I bash heads with plenty of smart people, I just don't do it on a forum, and I certainly don't do it here.  Too many people here only care about sounding smart, rather than being smart.  

Bottom line though, I'm 2 years ahead of you with innovation, so while I certainly am not the most brilliant, I'm more brilliant than yourself.

Merry Christmas

Fuseleer don't engage acrimony. Just say, "the truth will be evident by what is proved in the market" and then proceed on your efforts in proving.

I am reasonably convinced you've done a lot of (afaik mostly private groups) experimentation. Hope you will be able to bring something to market eventually.

You've apparently made such a huge investment over such a long period of time. One question. How do you plan to recoup that investment if you fail to deliver an acceptable outcome with your design? In other words, do you have a plan B?

I am interested in hearing your thoughts on that both because I need to also consider that possibility on my own design and also because I am concerned for you personally at the depression that might result if you fail and don't have a plan B (as I am concerned about myself especially since I am in more dire straits than I assume you are financially and healthwise and have so much riding on the outcome of my work).

Seems is one of us succeeds and the other fails, then it is wise to contribute to the project that is succeeding and recoup all the investment in learning and experience by applying to where the most ROI can be assured.

Yeah, I usually don't but I wanted to spice up my morning :)


Recouping my investment isn't a real priority, not over the short term at least.  Sure, I didn't expect it would cost me as much as it has, but I've enough that should the bottom fall out of the barrel I can "get out alive"...that is, keep my roof over my head, and live comfortable while regrouping and moving forward.  I guess that is my plan B in the event of failure, write it off, move on.

Assuming some level of success (of which I'm confident, you should be too, even when faced with doubt and the odds seem stacked!) there is plenty of revenue stream potential, both internal and external to the system, to recoup that investment over a period of time.  Assuming a moderate success then it may take 3-5 years or more to recover it fully, but I'm in no rush and I don't need it for anything so I'm happy for it to just trickle back in.  Obviously greater success yields a shorter time frame of recovery.

Thinking further ahead, I haven't even considered what I would actually do with regard to crypto should eMunie fail, stick around or admit defeat and move on....I'll cross that one when I come to it I think :)

Much credit to you for a nice post @TPTB_need_war

I will back @Fuserleer with any project he comes up with, for one simple reason (but also many others): he is trustworthy!

Glad I found this thread. Been meaning to check up on the project. Good job fuserleer.

Fuserleer,

So apparently you'll jump at the arrogance remark without answering any of my questions, this speaks quite loudly. I definitely do have issues with my own arrogance, you're correct in stating that to me; though I tend to see it as not many can debase me, so therfore my mind runs unchecked. I would define arrogance as being unwilling to listen or comprehend new information, which I don't have much an issue with as long as the new information carries weight of the proper truth. My block tree concept is not the same as yours, more so, an organic structure that grows scale ability as the network requires it, that allows live networks to be merged into one tree; that's where the concept came from. I'm not really aiming to defeat VISA off the bat, VISA's tx/s is mainly all network packets, it takes a few days for the funds to actually transfer, so 5k requests per second isn't a huge overhead in my opinion.

Personally, I've been watching you for some time Fuserleer. I don't necessarily want to be a part of your project, but was more so looking into finding a means of collaboration, or a meeting in the middle. I don't really care for your choice of name, wouldn't really ever want to own something called "Emunie" (just my opinion, don't get offended), nor that you ran an ICO among many other things.

I hope you can maybe see through emotion and understand my statement "your arrogance will be your downfall" is not hostility, consider it an outside opinion. I really don't have any issues with you, I actually have seen many similarities in our pursuits; hence why I have been attempting to commence contact with you. Not here to spit on your ideas (though you seem to be quite the one upper), I was asking constructive questions to possibly help you think differently. So, would you mind answering some of my questions? If you choose to ignore me again, that's perfectly okay; I'll just consider that a sign that there is no collaboration that could be had between us.

1. If you've been programming for 25+ years, why would you use Java? It over simplifies programming in my opinion, and has slower runtime (even if you argue 96%)
2. Why would you use a SQL database? Curious as to why you chose that route, was it for ease of development or any other performance oriented choices?

3. I'll quote one of my initial questions:

I'll finally repeat my statement about your "arrogance" or my opinion of it, to clarify it is in the context of thinking you are more capable by yourself, rather than collaborating with other people. But you reinforced my initial thought:


This statement seems a bit presumptuous and conceited to me... From what I see, and take this lightly no need to "get aggressive", that you want to prove one person can do it, that you are so super intelligent that you can do it all alone. Yes, this can be true within an infinite time span, so this leads me to my last question:

4. Why do you choose to not collaborate? Isn't the spirit of crypto "working together"?

Trust me, I've been in the same boat, "I need to prove it can be done by one person", had my source closed for quite some time, didn't let anyone help me, until humility kicked in and I realized it's not about being the "next best coin", it's about contributing to the betterment of the industry as a whole, not one particular community. It took me a bit of time and the right people to challenge me for this lesson to penetrate my mind.

I personally believe in Cooperation, not Competition.

Hope you let yourself see it,
Viz.

When you've had every man and his dog make all kinds of unfounded statements over the past who knows how long, it gets a bit old, so yeah if the mood takes me I'm going to speak on it.  It's not arrogance you see in me at all, I just don't take any shit from anyone, period.

I'm not trying to prove one person can do it either, I just don't see any point in having more chefs in the kitchen before the basic recipe is nailed down than is needed.  That just gives cause for everyone to get under everyone elses feet and no one has a clue what the final product should look like.  I have a number of people I converse with everyday, they pitch ideas to me, I pitch ideas to them and between us we take the best course of action.  Some of these individuals are techies, some are what would be regular users, but that allows me to have a broad spectrum of ideas, opinions and suggestions on what direction to take.

To me that is hardly going down the "do it on my own route", and if I was as arrogant as you seem to suggest, I wouldn't even have these people as my council, let alone listen them.  Further than this close circle, I listen to every suggestion that is made to me in our community, no ones opinion is excluded or ignored, you don't have to be in the "counsel group" to get heard.

Some of these aforementioned individuals have been to my house and worked next to me on a number of occasions.  One of which spent an entire week here during which time we covered a large number of technical topics, reviewed the channeled ledger design, possible system pitfalls, potential solutions and more.

Bearing all that in mind I can see why from the outside it may look like that is my goal, but its all for the sake of efficiency and nothing more.  I'm the main developer, purely because its more efficient that way until the ideas are nailed down and there is a recipe for other developers to work off.  The people I've chosen to counsel me are stable individuals whose opinion I can trust and do not let ego get in the way, which again is more efficient.  I'm also the main benefactor to the project (we haven't had an public ICO yet actually, just a small private fundraiser where about 50 or so people took part) and I don't have a never ending supply of resources, thus I have to consider that in everything I too, the less efficient I am, the longer those resources have to last.

Most importantly is time, we all have a finite amount of it and personally I don't like to waste any of mine.  Collaboration in a public environment, such as on a public forum is just a utter waste of such a precious commodity.  Everyone's "right" and their opinion should be the one that is taken into account, no one backs down (sometimes even when they are wrong) and it all ends up being a time soak.  I've seen many threads on here run on for pages and pages of arguments regarding something trivial with no resolution at all.  Frankly I can't be bothered with that, my time is mine to do with what I want, and I'd rather spend it behind a closed door if needed doing something constructive than squabbling on a forum.

Does it still seem like I'm trying to do it all on my own?  Or am I just being smart with my resource management?

Really if you had wanted to connect and get into a discussion, you would of been better served by doing it privately and not in public.  Your choice of language didn't help your cause either, because to me it just looks like you were on the attack and attempting to peacock in front of everyone else.  If that wasn't the intention, well, maybe in future try to connect privately first.  I call a spade a spade, and it looked like a spade to me.

Honestly though, I don't really couldn't care less if everyone see me as an arrogant prick, it serves as a damn good filter to keep all the people that would distract me and take up precious resources well out of my way.

Anyway, I'll answer your questions for the sake of professionalism:

1.  There are a number of benefits, but portability being one of the main reasons.  I considered C and made a careful decision between the two.  In areas where I need ultimate speed I can drop down through JNI to a native lib.  In reality the only time that level of speed is required is when performing lots of BigInt math (signatures and encryption), the rest of the time the CPU is hardly doing anything or is bottle necked by IO.

2.  Purely ease of development.  The DB subsystem is developed so that the DB controller can be swapped out easily and replaced with something else.  Its all abstracted and uses interfaces/adapters heavily.  I did a few experiments to investigate how long it would take to remove the MySQL DB controller and replace it with a Berkeley NoSQL one instead on a few of the modules.  Took a few hours per module.  Infact the plan is to convert all of the SQL to use NoSQL database backends after a period of time.

3.  If you study the link that was posted to the consensus primer, it should be evident how a mass partition event such as that is handled if you apply some thought.  If its not then perhaps wait for the revised consensus doc that will make it a bit clearer and cover that fail-case in a bit more detail.

4.  This takes us back to the start of this post, which I believe I answered there.

I've been programming professionally for a similar length of time (mostly c++) and the answer is trivially obvious to me. c++ is an incredibly unproductive language to use; you spend most of your time doing the job of the compiler (header file dependency management, making sure header only get included once, putting your inlines in the right place to stop compile times being measured in hours, wrangling the linker to achieve a less than 5 minute link time). When you're not doing all that, you spend the rest of it looking at pages of incomprehensible template compile errors, when all you did wrong was something simple.

Higher level languages let you get your job done in half the time, with less stress and they compile so much quicker it isn't funny. Sure, if you're building some low level, performance critical system, then write a c++ module for it, but the majority of code in any project is not performance critical.

I've never looked back.

so ... this is even faster than FST - FASTCOIN?

It depends on your definition of fast.

If you consider the fastest to be the platform with the quickest confirmations, then we average around 5 seconds.  There are cryptos with faster confirm times, but 5 seconds is plenty quick for any use case.  Striving for shorter confirmation times than that is pointless effort IMO with greatly added complexity to prevent double-spends at the edges of the network.  Furthermore eMunie only needs one confirmation and the funds are safe, so apply that as you wish when comparing to others.

If you consider the fastest to be the platform that can handle the most load in transactions per second, then yes, eMunie has the highest proven load capability as of today.  Even in the most limited configuration, eMunie can process at least 2-3x more per second sustained over a long period of time than the next fastest platforms.  Peak burst rates in this limited configuration has touched 2,400 tps as you have likely read in the OP, the best any other platforms have performed is about half of our peak, but in most cases led to stability issues after a while.

We'll be opening the throttle even more over the coming months as development progresses, and expect to see load capabilities exceed 10k transactions per second with ease.

Fuseleer what I was able to solve with my design (that turns PoW on its head so to speak) is transaction verification is as fast as propagating a transaction to a server and it propagating back out its confirmation. So roughly less than 1 second latency (can be faster but just referring roughly general case here).

But in terms of throughput, I believe the limiting factor (but not proven on a testnet yet) will be the rate of processing transactions on the CPU.

But we can talk about none of this without qualifying with detailed analysis of the security tradeoffs.

Thus it is useless to have these discussions and quote these figures until complete specifications and open source are revealed.

Thus I will not participate in any discussion on this until that juncture.

Is there any sort of timeline for your project or paper ?
I really do not mean to offend. I'd just like to get a feel for when we're going to see actual results there.

Wow this enormous speed in data confirmation perhaps would be interesting  to design some fast blockchain usage for bussines, a blockchain bussines model, really nice dev of this project, i hope 2016 bring EMUNIE anly good news

fyi... No idea how long this thread will be allowed to last with the Mods in totalitarian-mode.

https://bitcointalk.org/index.php?topic=1309549.0 (https://bitcointalk.org/index.php?topic=1309549.0)

It's a bitcoin forum. Be happy altcoins are even aloud. Just follow the rules and stop complaining. No one likes a cry baby.

The speed and transaction throughput of eMunie is there because it doesn't use a blockchain.