Pages:
Author

Topic: [EMUNIE] THE fastest crypto-currency (Read 11619 times)

full member
Activity: 147
Merit: 100
April 27, 2016, 02:06:24 PM
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

The speed and transaction throughput of eMunie is there because it doesn't use a blockchain.
sr. member
Activity: 378
Merit: 250
January 01, 2016, 08:07:14 AM
fyi... No idea how long this thread will be allowed to last with the Mods in totalitarian-mode.

https://bitcointalksearch.org/topic/emunie-previously-deleted-post-1309549

It's a bitcoin forum. Be happy altcoins are even aloud. Just follow the rules and stop complaining. No one likes a cry baby.
full member
Activity: 179
Merit: 100
December 30, 2015, 09:03:30 PM
fyi... No idea how long this thread will be allowed to last with the Mods in totalitarian-mode.

https://bitcointalksearch.org/topic/emunie-previously-deleted-post-1309549
legendary
Activity: 966
Merit: 1000
December 20, 2015, 09:03:38 PM
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
hero member
Activity: 980
Merit: 1001
December 20, 2015, 05:07:57 AM
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.
sr. member
Activity: 420
Merit: 257
December 19, 2015, 06:10:40 PM
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.
legendary
Activity: 1050
Merit: 1016
December 17, 2015, 02:58:47 PM
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.
legendary
Activity: 1596
Merit: 1027
December 17, 2015, 01:37:10 PM
so ... this is even faster than FST - FASTCOIN?
legendary
Activity: 1008
Merit: 1002
December 17, 2015, 05:40:12 AM
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%)

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.
legendary
Activity: 1050
Merit: 1016
December 17, 2015, 05:07:58 AM
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 95%)
2. Why would you use a MySQL 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:
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?

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:

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.

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.
legendary
Activity: 868
Merit: 1058
Creator of Nexus http://nexus.io
December 16, 2015, 11:54:27 PM
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:
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?

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:

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.

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.
legendary
Activity: 1148
Merit: 1000
December 16, 2015, 06:35:12 AM
Glad I found this thread. Been meaning to check up on the project. Good job fuserleer.
sr. member
Activity: 420
Merit: 250
"to endure to achieve"
December 16, 2015, 06:29:39 AM
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!
legendary
Activity: 1050
Merit: 1016
December 16, 2015, 06:15:42 AM
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.

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

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.

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 Smiley
sr. member
Activity: 420
Merit: 257
December 16, 2015, 05:58:30 AM
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.
legendary
Activity: 1050
Merit: 1016
December 16, 2015, 05:37:09 AM
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?

Quote from: first line in your own damn link
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.

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

Well instant transactions will happen with levels of security by what I call the Block Tree where transactions can process on their own branches allowing simultaneous processing as each channel forms their trunks, and the limbs to scale the tree based on transaction necessity so in essence the blockchain and production will only scale based on the volume of transactions. The trust network that is becoming formed with trust keys will grow into the core of the network, to allow light nodes to function without needing to sync, so forth.

The block tree will also allow the merging system to take form, so instead of worrying about one chain, we'll see our blockchain grow into a tree as I split the channels, as of right now we are building the solid trunk. Consider it a sophisticated use of side chains, but instead of being a chain on the side, it will be a chain formed from the trunk, to then create the mint upon that branch and causing transactions created from that limb to be processed on that limb, so that as more limbs start to take form, our ability to process transactions simultaneously will increase its capacity.

Thank You,
Viz.

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.

Quote
...you may be intelligent, but you aren't as brilliant as two intelligent people together, or three, or four...

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
legendary
Activity: 868
Merit: 1058
Creator of Nexus http://nexus.io
December 15, 2015, 11:51:40 PM
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?

Quote from: first line in your own damn link
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.
member
Activity: 96
Merit: 10
December 14, 2015, 09:46:09 PM
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
legendary
Activity: 1316
Merit: 1004
December 14, 2015, 07:14:12 PM
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?
newbie
Activity: 54
Merit: 0
December 14, 2015, 04:40:12 PM
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.
Pages:
Jump to: