[STRONGLY]

After 5 long years of hard work, failed attempts and lessons learnt, we present the whitepaper explaining Tempo, our ledger and consensus tech that was published this week.

You can get it at our website https://radix.global

It details how our ledger architecture allows high throughput, rapid settlement and offers a true micro-payment and IoT solution, along with the consensus algorithm which we developed to secure it.

Tempo is a completely different way of thinking, and I would STRONGLY suggest you leave anything you know about blockchain, DAG, and other ledger tech at the door, otherwise you will end up with incorrect conclusions.

This paper is the first of a set that will explain all of the Radix core features such as economics, DEX, payment rails and more.

I'll keep this short and let the paper do the talking.

As always, comments, thoughts and feedback welcome.

[don't]

No doubt this will be labelled as "pointless promotion" within the hour and moved to the trash bin, but IMO it's too important not to share.  Regardless of the fact that it's something I've been involved with developing, even if it wasn't I'd still make some noise about it.

A critical goal of eMunie has been the ability to perform payments, independent of the Visa and Mastercard networks, on existing EFTPOS terminals that you find in everyday merchant stores.  We've worked long and hard on this and finally, as of yesterday, it was achieved.

So whats special about this?  There are Bitcoin mobile wallets already that can do that, and Bitcoin debit cards which do the same.  The problems though are many:

1.  Mobile wallets and debit cards on Bitcoin (and others) all involve a "middle man", who take a hefty chunk of fees for the privilege.  Fees for loading the card, fees for spending, fees even if you don't use the service.

2.  Your account with these service providers can be cancelled at any time, and you lose your money.  Or your transactions can be censored and rejected at will.

3.  They all use the VISA/Mastercard/Other networks, which again means the card can be cancelled, or be subjected to transaction censorship.

Our goal was to create a platform, that aside from a plethora of improvements overall, would also support Decentralized Debit Cards on existing hardware (which is critical) and not just virtual cards in a mobile phone, but physical ones too (as mass market consumers overall still don't like, nor trust the idea of money in their phone).

When I say decentralized debit cards, what do I mean?

1.  They interact directly with the eMunie network (which itself is decentralized) and do not transmit transactions over an intermediary network such as Visa.

2.  You are in control of the card, which means no cancellations, no transaction censorship.

3.  Using off the shelf hardware costing around $20, you can create your own debit card!

Point number 3 is probably the most important.  Anyone with $20 of hardware can create a new debit card, load it with funds, then go to the local store and spend it in the same payment terminal they would their regular bank card.....a libertarians dream!

In fact, here is a video link showing exactly that, with some commentary by me all in under 5 minutes:

https://www.youtube.com/watch?v=lqE-7R8liMU

Please excuse the shaky camera work, I wanted to do a video that was uncut and raw, which meant a single cut with no editing.  I wanted to show that it was possible and that there is no trickery involved with fancy editing, what you see is what you get.

[Overview]

Here is an interesting and meaty post for everyone to chew on and provide some food for thought no doubt

Over the past couple of weeks I have been putting the final touches to the eMunie economic model (amongst other things). Despite some stiff arguments presented against it on a number of occasions, I was always confident that it would operate effectively in all but the most extreme of "black swan" events.

A few days ago I got to the point where it was feasible to test it out, the majority of the core economic algorithms and execution models had been implemented culminating in the completion of 3 years of heavy thought, notes, tweaks and sleepless nights

However, I obviously found myself lacking in test data, or the ability to generate it. To generate such data would require completion of the decentralized exchange and other systems, plus a lengthy process to generate such a data set which would allow confidence in the results.

Eager to test out our economics model, I decided to investigate if it would be possible to create a simulator that uses the eMunie economic model as is, using existing Bitcoin trade data to see if it was possible to "stabilize" the price of Bitcoin and review the performance of the economic model as a whole.

If such a volatile (and perhaps even manipulated) currency such as Bitcoin could be stabilized, then it is safe to assume that EMU (and any currency for that matter) could use our economic model to achieve the same goal.

Overview

The white paper which will explain our economic model in detail is not yet finalized and needs to include the most recent changes, which of course will take a little time to do. A basic overview of its operation is presented here which should allow sufficient understanding despite the lack of mathematical representation at this point.

In the following text EMU may be substituted for BTC, LTC or indeed any other digital currency.

The purpose of our economic model is to stabilize the price of EMU over the short term, providing protection against legitimate large movements which may disrupt the price and inadvertently snowball into a panic buy or sell, as well as "pump and dumps", manipulation and similar for-profit activities, whilst allowing long term price trends to proceed unhindered.

The primary components to achieving the above goal are a system buffer and "token" functionality. An additional preferred component is an exchange integrated into the economy which can be "trusted" to provide legitimate trade data.

The economic model is decentralized and bound by a set of rules and consensus and is autonomous.  No party has any control of the economic model, nor the funds available in the various buffers.

In the eMunie platform this exchange is decentralized and built into the platform natively, and all user actions and trades are validated by the network as well as the regular transactions, providing a trustworthy entity by which the economics can operate.

Stability Target

The stability target dictates the maximum desirable price movement of EMU over the duration of a year as a percentage. The economic model will attempt to keep within bounds of this target to the best of its ability.

This target is used at a much granular level most of the time, and it is easy to calculate the corresponding desired maximum movement over any period of time.

For example if the annual target was 10% and one wanted to calculate the daily allowed movement, it is simply 10% / 365 (or 366 for a leap year).

Delta targets are also used extensively, and provide a means to determine what the maximum allowed movement during two points in time may be.

Pressure

Trades on the exchange are converted to buy/sell pressure metrics which the economics model uses to determine both the estimated supply figures for that moment in time, and whether it needs to take action to ensure the price stays within target bounds.

A pressure metric in its simplest form is a percentile delta between the current and last trade for EMU in a particular currency pair (EMU/USD).

For example, if the last trade price was $1 and the next is $1.1 then there is a pressure of +10%. If the prices $1 and $0.90 then there would be a pressure of -10%.

Supply

The economics model can function in both fixed (such as Bitcoin) and elastic supply economies.

eMunie employs an elastic model that responds to "pressure" signals from the decentralized exchange, which are in turn used to calculate the supply/demand estimates at any point in time.  In the case of a supply deficit, a quantity of new supply being created and distributed to the various actors in the system as per a set of defined rules, an excess of supply results in EMU currency being burned by the system.

Tokens

Whether an exchange is decentralized or not, tokens that represent real world currencies are required so that users can "cash out" of EMU. This may be for a period of time as a strategy to maximize their position, or to exit the economy completely by later exchanging those tokens for their real world counterparts.

As eMunie is intended to operate almost completely isolated from existing centralized infrastructure, these tokens that represent fiat currencies are used extensively. Users that wish to cash out entirely would exchange these tokens for the real world counterparts via our TRAID system.

In the case of Bitcoin, these tokens are currently exchanged for fiat by the exchange at which they are held. Should Bitcoin ever advance to using decentralized exchanges and fiat currency on/off ramps, "colored coins" would suffice for use as these tokens.

Buffer

The buffer should receive a portion of all new EMU supply, allowing it sufficient funding to perform its task, and this portion should be significantly higher than any feasible holding by another entity in the system. In the case of the simulated tests, this buffer was set to 10%.

The buffer should receive real time trade information from the exchange, including the buy/sell pressure of that trade and the currencies being traded.

If the pressure percentile of that trade would exceed the allowed delta target, then the buffer is used by the economic model to fill that trade.

As the buffer will be both buying and selling EMU, it not only needs to have a quantity of EMU itself but also be able to hold various "tokens" that represent currencies such as USD which are being traded for EMU.

A critical feature of the buffer is that it is the only party who is allowed to convert digital currency to fiat currency tokens and vice versa, and do so in a frictionless manner without cost. All other parties in the system must trade their USD tokens on the exchange for other currency tokens, assets or EMU.

To maintain balance, should the buffer require some USD tokens, it will convert a quantity of EMU it holds into USD tokens at the current EMU->USD price and record it in a FIFO (first in first out) queue for future use. If later it is required that some USD tokens it holds should be converted back to EMU, it polls the EMU->USD FIFO queue and converts back to EMU using the values stored in those records.

This ensures that the buffer does not profit (or incur loss) from conversions and upset the balance of the system as would be the case if USD was converted back to EMU at the current rate, rather than the rate at which it was made.

Buffer Trades

The buffer only intervenes and fills trades if the pressure of that trade exceeds the target delta since the last trade. In the case that the pressure is beyond bounds the buffer fills the trade at the current maximum allowed ask as per the delta, which then becomes the current price for EMU.

For example assume the current EMU price is $1, the last trade was 1 day ago, and the max daily target delta is 1%. ($0.01) If a trade were now presented to buy at $1.10 per EMU, the buy pressure would be 10%, 9% more than the allowed delta.

The buffer would then sell EMU at $1.01, filling the trade and setting the current price to $1.01, which is the maximum allowed by the delta.

Likewise, if a sell was presented at $0.90 per EMU the sell pressure would be 10% (or the buy pressure -10%) and exceeds the allowed delta of 1%. The buffer would fill that trade by buying the EMU at $0.99 (converting EMU to USD tokens if needed at the current rate of $1.00)

Bitcoin Data

I sourced the Bitcoin trade data from http://api.bitcoincharts.com/v1/csv/ which has data from a number of exchanges and currencies from as far back as 2010. This data is simply formatted as the trade time, the amount of BTC being traded and how much for in a particular currency.

As far as I can determine, this data is every trade that ever happened on the exchange in question. I have been able to find all my past BTC trades that I have made on exchanges within this data set.

To ensure that the economics model can sufficiently handle multiple trade currency types, trade data for USD and CNY was used.

The USD trade data consists of 58M trades made between Sat, 09 Oct 2010 and Tue, 19 Jan 2016 for the major exchanges during that time, namely Bitstamp, Bitfinex, BTCe, Coinbase, Lake, and MtGox.

The CNY trade data consists of 274M trades made between Mon, 13 Jun 2011 and Tue, 19 Jan 2016 for the two major exchanges of OKCoin and BTCChina.

Data Usage

The trade data is fed to our economics model in series, effectively replaying the trades in the order they happened at many multiples of real time.

To counter the phenomenon of varying price across exchanges, and the arbitrage opportunities that come with it, the data was presented in batches from the same exchange for the same timestamp.

Say that Bitstamp had 3 trades at UNIX time 1307942004, and Coinbase has 6. The 3 Bitstamp trades would be applied together, with the 6 Coinbase trades applied after, and so on until all trades for all exchanges and currencies at UNIX time 1307942004 had executed.

Without this batching, the stabilized price of BTC has an small amount of constant "jitter" which was undesirable, with it this "jitter" is eliminated.

A secondary effect due to this phenomenon also needs to be considered when calculating the pressure percentiles. All pressure percentiles should be calculated only from historic data pertaining to the exchange which that trade originated.

In the case of a trade from Bitstamp, if the most previous trade executed occurred on Coinbase, a historic search should be made for the last trade that occurred on Bitstamp and the pressure percentile calculated accordingly.

Emulating Bitcoin

To ensure as close a simulation to Bitcoin as possible, we also simulated Bitcoins supply emission and the rate at which they were generated including halving. 10% of the supply emission was directed to the buffer as already stated, with the remainder going into circulation.

Initial Parameters

The simulation was executed with the first trade occurring on Sat, 09 Oct 2010 02:07:18 GMT which was made at MtGox and was the first purchase of BTC for $0.10.

The quantity of BTC in existence at this moment in time was approximately 4,205,200, 10% of this (420,500) was allocated to the buffer.

A stability target of maximum 10% was specified.

Results

The first test was the processing of USD trades only, and the results were extremely encouraging and interesting to say the least.

After the processing of the 58M trades over the course of almost 6 years, the ending BTC price on the last trade was $0.10085, almost exactly the same as the starting price of $0.10.

Over the course of all the trades, the low and high BTC price was $0.0983 and $0.10321 respectively. Which is obviously extremely stable when considering how volatile BTC has been due to its varying trends and amid large pump and dumps and manipulations.

Also of interest is the fact that at no point was the buffer in danger of expiring its resources, with the minimum and maximum available BTC quantities held by it being 420,500 and 999,126 respectively.  Due to 10% of the BTC issued from block rewards being directed to the buffer, its cumulative purchasing power never actually dropped below the initial value.

The CNY + USD simulation is currently executing, and due to the number of trades (over 320M) it is expected to be completed sometime in the next 12-18 hours. I'll report back with the results of that simulation when it has completed, but as of right now, the results look to be very similar to the USD only simulation.

Some other simulations I would like to run include reducing the buffer allocation and stability targets as low as possible while ensuring stability.

The data sets for these simulations will also be made available for download in MySQL dump format soon, and we will be constructing a basic presentation website where this data can be navigated and queried in a more human form via candle graphs and other charting methods.

Final Thoughts

Application of our stabilizing economic model to Bitcoin unfortunately has some fundamental consequences and I am not suggesting that Bitcoin should do it. The use of its trade data was purely to test our model with intense real world data giving us confidence in the model and the algorithms that power it, and also as a curiosity experiment with regard to Bitcoin.

Perhaps the most critical issue that would prevent any implementation of such a stabilizing model into Bitcoin, is the almost total destruction of the mining economy, which is fuelled by the speculative trading brought about by Bitcoin's fixed rate of supply emission.

In order to supply miners with an incentive should a stabilizing economic model ever be applied, Bitcoin would have to adopt an elastic supply model that, like eMunie, reacts to supply and demand instead of its current fixed emission policy.

Miners then would be rewarded not by an increase in the value of the BTC they hold, but by an increase in the amount of BTC that they hold instead.

Thoughts?

I'm looking for extensive Bitcoin trading data from one or more exchanges, in USD, that lists the trades as they happened.

All I can find so far is "summary" data that provides the high, low, open, close and volume for an interval and that isn't sufficient for my needs.

I'm currently wrapping up the last of the eMunie economic model, and I want to replay BTC trading data to test the stabilization algorithms of the eMunie platform. 

If it's correct, the the volatility should be smothed out significantly over the long term and BTC seems like a perfect test case as its moderately volatile with decent volume.

For this I obviously need data on each trade, mainly the time, the ask/buy price and volume being traded.

Anyone know where I could get it?

I wasnt sure whether to post this in Economics or in here, I feel this is the right place overall as the concerns I'm going to raise are in part relevant to a lot of what goes in in here.  I guess the mods will decide.

For sometime now I've been completely aghast at what seems to be a total lust for partnering up with banks!  Every project and its dog seems to want to be under the wing of banks these days and I've got to the point where I need to speak up on it.

Before anyone jumps to any conclusions, I'm not particularly averse to banks.  They serve a purpose, and they'll continue to be a part of our daily lives.  They've misbehaved sure, and while I feel that there does need to be stricter regulations to control just how misbehaved they can be (and the people at the top who allow this behavior should be held accountable), I don't hold the opinion that many do of "DOWN WITH THE BANKS!"

What does get me irked up, is the hypocrisy, short sightedness and lack of concern that is evident everywhere right now, both here and elsewhere.

Satoshi gave us an opportunity to take a step away from total reliance on the banking sector, and I feel that we as a community and industry are just throwing it away.  The way in which we are going, Bitcoin might as well of never existed and all of us could of saved a lot of time, blood, sweat, tears and money in the meantime.

Everyday I see a new project starting up with plans to cater for the banks, or existing projects partnering up in some manner, followed by a glut of delusional posts stating things like "the banks are afraid", "they want to kill Bitcoin".  

I had meetings with a number of banks over 12 months ago to discuss possible integration and mutual benefit with regard to eMunie.  I left all of these meetings with the same mindset and haven't followed up with any since, perhaps in the future I'll have to if eMunie becomes the success I hope but for now I'm happy to be incommunicado.

Why did I do this?  Let me tell you, because no one else will.  They are not afraid of Bitcoin at all, not in the slightest, or any other similar project either current or on the horizon.  They are interested in this technology because it will make them money, and LOTS of it, and I didn't want eMunie to be a component that makes banks yet more money!

You see it costs the banks quite a lot to send transactions around, as the infrastructure is old, outdated, overly complex and a collection of band-aids upon band-aids.  Each component in this beaten up old infrastructure has a middle man that takes a fee for the processing of that transaction, and these fees add up.  Some transactions can cost upwards of $13 in fees alone (that is why the banks feel justified charging you $30 for a bounced check).

Block chains, DAGs, ledgers or whatever are much more efficient!  All of these middlemen can be cut out, the system is more efficient and the banks can increase their profits MASSIVELY!

Some projects such as R3CEV have probably identified the same thing that I did, and decided that by developing a system that the banks can use, even if they charge a small fee, they will make incredible amounts of money.  The banks are all for it, as in the event of a successful product, they now only have to pay $1 instead of $13 for exactly the same transaction.

Other projects that started off without any intention of joining up to a "Banking Consortium" have also been sucked into this culture which is unfortunate, as these projects could have stood on their own two feet for a long period of time with a little more effort and a little less corner-cutting.  

The banks are forging these relationships purely to hedge, if one project fails, they are partnered with 10 others and only one need succeed.  An added benefit (minor though as they aren't "afraid" at all remember) of course is the fact that if everyone is happy to take partnerships and relationships with banks, no one is working solo, and if no one is working solo, then there is no long term threat from some unknown taking a chunk of the pie.

If you have a good project and you want to partner up with a bank, or you get approached, then make them work for it!  Don't make the mistake of thinking you have been "chosen" or that you are special in someway, you aren't, you're just another means to make money!

In case anyone is interested over here, an interview (the first no less) with me has been published at

http://www.newsbtc.com/2015/10/18/in-conversation-with-emunie-founder-dan-hughes/

In the interview I discuss the trials and tribulations, the tech, the vision, the future  Its quite long, kinda got carried away with the questions but wanted to be thorough.

Thanks to the NewsBTC team for taking the time out to do it and sift through my waffling

[Point of Sale (PoS)]

Hey everyone,

I'm proud to be making this post today and announcing another pioneering tech solution within the eMunie project, but first, a bit of blurb to set the scene....

From the outset, one of our (many) goals was that eMunie would be accessible to the masses and easy to use, a key requirement of meeting that goal being integration into existing merchant infrastructures.
More specifically, we wanted merchants to be able to accept EMU (or other system asset token) payments without needing any additional or new Point of Sale (PoS) hardware as this is not cost effective, nor a good use of valuable counter space.

Additionally, we wanted a convenient primary payment method that non-technical users would already be familiar with, debit cards, yet they should not be reliant on 3rd party payment networks, nor on middlemen services in order to fund and use it. Thus it and had to be a "native" system.

To clarify, native in this context means that users should be able to spend EMU directly from the card, to the merchant, using existing hardware the merchant already possesses which has been updated with a simple software patch, allowing that PoS hardware to push transactions directly to the main eMunie network.....*whew*

Achieving this level of native integration is not possible with current crypto-currency technology, as the architecture of the ledgers (more specifically block chains) do not lend themselves to this kind of operation. There is always a requirement for 3rd party services of some kind, that the merchant and/or users are reliant upon so incurring inconvenience and additional costs (fees).

The eMunie ledger has been designed from the outset with this goal and associated use cases in mind throughout development, and recently we were finally able to perform the first transactions using simulators and hardware that support the same EMV protocols as hardware found in merchant stores.

Presented below is a first look video of this technology in action, I'll then explain in more detail what is going on, as the demonstration has a number of moving parts and it's difficult to represent efficiently in a video.

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

In the demonstration we have 2 machines, 1 in the UK the other in Denmark being viewed over TeamViewer.

The UK machine is acting as the merchant and has a EMV compliant card reader attached to it and is executing a basic PoS terminal device simulator.

The machine in Denmark has the imported card wallet open and the card has been loaded with funds simply by sending EMU to the card wallet address.

Card creation is a simple process and users can either obtain them from an trusted issuer, or if they have access to (or purchase) a cheap EMV compatible card reader and the correct card type, they can install the cardlet application and create their own. Readers can be obtained for between $20-40 depending on any addition features desired and the blank cards themselves costing a few $.

Once created, card wallets can then be imported into the users client/s, and can be loaded/unloaded with funds as they see fit.

In the video there are 2 demonstrations, the first is a payment from the card for 1000 EMU with the card's wallet open in Denmark, and the second is another payment of 1000 EMU with the card's wallet in Denmark closed.

These 2 demonstrations are performed to prevent any confusion that card wallets need to be open somewhere when spending, they do not. Subsequently if the user should open the card's wallet in their client at a later date, the transactions they made with the physical card will be displayed as that client synchronizes.

As you can see in the demonstrations, payments from the card show almost immediately in the user's card wallet (when open), and have cleared and confirmed in the merchant's wallet within around 10 seconds. The system is still in heavy development and unoptimized at present so transaction times are a little longer than optimal.

In the first release candidate post-optimizations and tuning, these durations will be 5 seconds or less, and of course payments will be tightly integrated with the software on the PoS terminal via the update plugin, and will not need the actual eMunie client.

Due to our PoS technology being EMV compliant, contact-less support is also available within future eMunie mobile clients and can use existing merchant contact-less payment terminals in the same manner. A demonstration of contact-less payments will be made and posted in due course.

I hope you enjoyed this short initial demonstration of our native PoS technology. Watch this space for more demonstrations as development progresses, and I welcome any questions or comments.

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.

[Current Solutions]

Today was a significant leap forward in realizing one of eMunie's core goals of enabling crypto-currencies for the masses.

The long awaited 1st native point of sale compatible transaction has been performed, no middle men, no 3rd party processors, no custom merchant hardware....just an EMV compatible debit card, run of the mill hardware and bridging software to connect directly to the eMunie network.

So why is this so important?

Current Solutions

Currently to use your crypto-currency assets in brick and mortar stores, there are 2 solutions.

The first, is that the merchant generally requires some additional hardware along side existing POS terminals in order to accept Bitcoin/LiteCoin/others. Typically this consists of a tablet device with a connection to a 3rd party payment processor, and the customer has access to a similar service on their smartphone.

The process is very "manual", requiring scanning of QR codes/entry of addresses at the least, with entry of spend amount and other inputs sometimes required. It also requires that the customer has an active internet connection on the spending device (not always as reliable as one might assume).

While the process can be swift, on many occasions at crypto-currency events where items can be bought and this is the mechanism for payment, I myself have witnessed the cumbersome nature of this method. Frequent delays in making payment hold up other customers and reduce the turnover of customers to a mere trickle.

The second method involves a VISA or Mastercard debit card, which is provided by a 3rd party that allows the loading of BTC and other currencies to the card with in place conversion to $, £. These cards can be used in existing point of sale terminals, but have the consequence that there are fees attached for many uses of the service, currency conversion charges, loading charges, spending charges, ATM withdrawal charges. These can sometimes be in the order of a 1-2% or more, and with regular use can mount up significantly.

Additionally, if the card is lost, or is deactivated by the card provider for any of a multitude of reasons, funds can be lost and irrecoverable. Worst still your funds are entrusted to a 3rd party, and should that entity decide to close the service, they can easily exit with all customers funds that have not yet been loaded onto a card.

The eMunie Solution

The eMunie implementation is simple, there are no 3rd parties involved, no additional hardware required, and minimal risk, both for customers and merchants.  The owner of the card controls the funds associated with it at all times.

To accept payments via an eMunie debit card, the merchant will simply need to install an update for his existing hardware that connects to the eMunie network and pushes the transactions out to it.

Additional benefits for the merchant are the lack of processing fees, and no requirement to hold a merchant account with a bank. Merchants can simply accept eMunie payments to a wallet they control directly, and cash out via the decentralized on/off ramps available via our TRAID network when convenient for them.

Furthermore, eMunie debit card payments offer increased anonymity over the above methods and of course traditional fiat debit cards. The merchant only has visibility to card address, and information such as your name, DOB, physical addresses or other personal data is not required or transmitted.

Cards can be imported into clients, so even if you loose your card, you can still access the funds and move them to another account or card. Loading funds to a card is a simple case of sending funds to its address from another wallet, be it on a PC, Tablet or Phone, the card never needs to be connected to be able to spend them at a later time.

This technology is unique to eMunie, and is a key requirement to achieving mass market penetration. We know of no other crypto-currency that can enable native point of sale payments in this manner due to the limitations of block chain and similar ledger technologies, nor do we know of any in development that can match it.

Moving Forward

During the course of the next week some video demos will be constructed to show the process in action. Shortly after there will also be a beta with these capabilities enabled, and instructions on how to create a point of sale simulator, along with details of off the shelf hardware, will be provided allowing a first hand test drive of the technology on the test network.

Embracing newer technologies is a small step once the development of the basic features is completed, with the possibility of contactless cards and mobile device contactless payments easily supported.

Information on how this is achieved possible will be covered in 2 articles discussing our ledger technology scheduled for release over the next week or so.

Until then here is a fun mockup of what an eMunie debit card may resemble, with an example of a possible front configuration of data:

[any and all information you think you already know about how eMunie functions should be forgotten immediately!]

Hello everyone,

Before hand I would like to express that any and all information you think you already know about how eMunie functions should be forgotten immediately!  Almost all of that old information is defunct and out of date and no longer relevant in anyway.  Thank you

It is with great pleasure that I publish the first article regarding eMunie technology focusing on our consensus algorithms based around trust.

The first of many upcoming articles covering all areas of the eMunie project, I wanted to start with consensus as it is probably the most important of all.

This first document focuses on the topic in a high level and is meant for a wide audience. There is lots of detail to dig into in future articles, even though it gets quite in depth, but I want to also provide documentation for those not so technically minded which is written in every day language and is easy to understand.

To enable a full and complete understanding of the project, what it offers and how it functions will require many articles and documentation totaling 100s of pages. I'll do my best to make sure that important topics that rely on content within other documents are explained as best I can so that the topics being covered in the material being read can be understood clearly.

I'm happy to answer any questions where I can, but please understand that there may be some items that will be difficult to explain without these yet unfinished additional documents.

The article can be viewed at http://blog.emunie.com

Best Regards to all

- Dan/Fuserleer

PS: I've set self-moderation on this topic as a precaution and will only be removing posts that are blatant attacks and severe trolling.

Thought I would post this here too, as some may be interested.

Today we ran the first real test of the new channeled ledger aka Transaction Forest, and despite most of the code being very untested, incomplete and in need of optimizing, the result was pretty good!

Before I get to exactly how fast, let me first set a few points you should keep in mind:

    The test was ran in a small network of around 10 nodes
    Due to the small network size, only around 20 channels were in use at any one moment
    Live network will support potentially unlimited channels
    Most nodes were also running all other services as well as transaction verification (hatching)

After setting up and performing some ramp up we set about applying load to the network, this is simply done by cross spamming each other with transactions, with each node producing 2-3 transactions per second to the network for processing.

With all nodes participating, there should be between 20-30 total transactions per second being presented to the network, however it is difficult to determine exactly the transaction quantity each node is presenting at any one time, and if all are indeed operating at the expected pace. Therefore it can (and probably does) vary throughout the test by perhaps +/- 5 tx/s at any one moment.

Our peak processing load during the test was 110 tx/s, with many peaks hovering around the 50tx/s mark, see screen shot below:



As you can see from the graph, there are definite regular peaks of transaction load, with a baseline transaction throughput around the 15tx/s mark.

What you can see here is a saturation of available resources, most specifically, bandwidth! Most of the nodes in the test network are behind ADSL connections, and while having good downstream bandwidth, many of which have only 5-10Mb/s upload. As I'm sure many of you know with ADSL, the more of the upload bandwidth you use, the download availability and ping rates suffer dramatically.

All of the nodes in the test were hatching, and connected to a few other nodes, which results in a significant amount of upstream being used for broadcasting verified and countersigned transactions, along with additional upstream bandwidth being used for data delivery for other services, most nodes were hitting upload bandwidth limits.

The graph reflects this almost perfectly, you can see there is a burst of transaction verification activity from all nodes, which quickly saturates most nodes upload bandwidth, preventing them from presenting transactions quite as fast as they would like. The lesser loading after the peaks, are those slower frequency transactions making it out to the network, along with the 2 nodes that were not upload limited as they were sitting on 100Mb/100Mb lines. Shortly after, everyone catches up, upload saturation drops, and we have another burst of transactions around the network. Rinse and repeat.

If we average the graph, we arrive at an average transaction throughput of ~30-35 tx/s, which is as we would expect with 10 nodes performing as explained.

This effect is exaggerated in our test, as all nodes are doing verification, all nodes have a route to all other nodes, and there is low channel utilization. Therefore, all nodes need all new data for all channels immediately, as all nodes are verifying transactions for all channels. In a production environment, where verification is global, and spread over many many more nodes, these nodes will only need a very small portion of all channel data to service the transactions they are processing, thus upload saturation of nodes within any interconnected group will be much reduced.

With that in mind, the global transaction processing capability of the eMunie network will be very high indeed, as 10 nodes can process 30-35 tx/s average, and the scalar as the network grows should prove to be near linear, 1000 nodes could in theory process in excess of 20,000 tx/s globally.

That said, the peaks are real processing happening in the network as the graph is generated by countersigning time and not when the node received the transaction (take 2 graphs, from 2 nodes and they are identical).

So, as to the question, how fast is eMunie, there are 2 valid answers....in a 10 node test, 30-35tx/s if you take the average, 110tx/s if you take the peak. Which you choose is up to you, but I think you'll agree, either of those numbers, on commodity/consumer hardware, is mighty impressive

I don't usually come out on film as my working hours dictate a vampire night shift schedule...

However on this occasion, the photographer was greeted with success, so here we go



In other news:

Final stages of the conversion from the old block-tree transaction ledger to the new (and very nicely named) `Transaction Forest` ledger are about to take place, with about 60% of the conversion done so far and proving VERY successful.

Lots of work is currently underway on the paper (finally I hear you all say) now that all the root tech is nailed down and set in stone.  I'm not working on this alone and have had a eMunie forum member staying with me over the past week who is a technical expert & had plenty of experience writing papers.   There is a lot to cover, its going to be quite large, but we should have this done, proof-read and checked by mid-late Jan.

Finally I made an announcement a few weeks ago on the eMunie forums that there would be an IPO sometime in Q1 along with a corresponding beta.  You can find this post here https://forum.emunie.com/threads/planned-ipo-schedule.2023/

Last but not least, I'm most likely not going to post another thread here for a few weeks as things are busy....so Merry Christmas to you all and a Happy New Year!

Peace!

Peoples,

I'm getting tired of all the scams on here of the so called "developers" of crypto-currencies, duping people into investing with fancy artwork and blurby (but ambiguous) text.  

It gives ALL of the serious developers in this forum a bad rep, yet its a typical case of the few spoiling it for the many.....actually, it probably isn't, there are WAY more scammy developers that couldn't even put a "Hello World" together without a tutorial than real ones...hmmm.....anyway.

Of course, you investors are partly to blame as you seem to let the fear of missing the next big thing warp your logic to make it emotional.  PLEASE do some due diligence into the developers that you are planning to invest into.  Fake developers are easy to spot if you know what to look for, as are real ones.

Before I get to the topic heading subject matter, here are some tips for telling the difference between serious & fake developers:

1)  Any developer that wants to stay anonymous, RUN!  Gone are the days where this was acceptable, because back then, there was no money to be made ripping people off, so anonymous developers were not a threat

2)  Verify the developers credentials, don't just take his word for it.  A passport picture with the signature and numbers blurred out, and a 2nd/3rd or even 4th picture of that same person doing something crypto related should also be provided.  If the developer is willing, other proof should be provided, it doesn't have to be addresses where they live (unless they are willing to go that far), but a Linked-In account that is aged, or Facebook, even Twitter...can all provide credence to that persons identity.

3)  Voice/Video call them over Skype, or a few of you band together and one of you call them.  An honest developer won't mind, a crooked one will, as they wont have the time to think up lies for your questions, and listening to someones voice can give a lot of tell tale signals as to if they are lying.  Video call is even better, as you'll have a visual and audio queue for any tell tale signs of lying.

4)  Check into their background.  Almost any developer that is skilled enough to develop a crypto-currency (even a BTC code clone with new features) will have done something in the past that has been released and they can prove they worked on.  Ask about previous projects, papers, hell even activity on developer related forums will give you some idea if they know what they are on about.

5)  Developers releasing a new currency should be dedicated, as creating and launching one successfully is akin to starting a business, its hard work and requires 100% dedication to the project.  If they are always unavailable, or on holiday, or "ill", then they probably aren't that dedicated to the cause.  Remember though, some of these real devs also have day jobs & families, so many can't be online daily 24/7...but if its weeks between updates, even on their own forums, leave.

6)  Infrastructure.  Any serious developer would have a website, forum, email etc etc setup for the project they are working on.  No real developer, that was proud of what they were doing would run a project from here with a 1000 page thread.  That is insane and shows either lack of commitment, or just pure disorganization.  Real developers will want a home for that project, and will want to have a community..they will NOT run it from Bitcoin talk!  

7)  Finally, and this is my fun call out to our developers here.  Any developer worth his salt, especially developing a P2P distributed system like a crypto currency will have gear, and probably quite a good stack of it.  Someone developing a crypto on an solitary old laptop isn't going to cut it.  Real developers will invest into hardware to get the job done before they even ask for any investment, and most likely will have collected plenty of gear over the years from previous projects they have done in the past.  At the very least, they'll probably have a laptop & a desktop in their arsenal.  If your developer is coding on a single Asus Netbook, I'd probably walk away.

So developers, please post your development setups for all to be awed at and prove your worth in regard to point 7 of my "don't get scammed tips".  If you are so hardcore as to have so much stuff you need multiple pictures, please post it.

Whoever has a setup better than this from Swordfish gets a prize

[NOTE:]

Hey Folks,

This is a call out to all security experts and hackers, inviting you to take part in a pre-launch eMunie network stress and hack test with PRIZES!!

We're getting pretty close to our next OB in a couple of weeks, hopefully followed soon after by our V1.0 launch, thus the time has come to weed out any possible exploits or issues with the system before they can cause loss or harm.

I consider myself a good developer, I try to cover all angles of any scenario as much as possible.  That said I'm not naive, nor have a galaxy sized ego which results in thinking my code is the best, most secure, or can never be exploited....I am human after all, humans miss things and make mistakes.  I expect there to be issues, and the purpose of this test is not to prove there aren't any, but to find any that are and fix them!

So, as we tend to do over here, I would like to set another industry first.

I'm inviting anyone that thinks they have the means, to perform attacks on the network in an attempt to cause disruption in a test environment initially, which will be setup for this task, and also in a future open beta.  The date for these tests to start is not yet planned, but should be within the next 4 weeks (depending on how many applicants and furnishing selected candidates with the needed information to perform thorough attacks).

Disruption is anything from an outright DDOS of the entire network, to message sniffing, double spends and everything in between.  I will provide detailed information regarding the packets and data structures sent around the network, the topology, and various other details to assist in any disruption attempts.  Please do not ask for source code, as stated many times before, eMunie is and will remain closed source for at least 6 months post launch.

There will be limited places available for this task, 2 reasons.

1.  I don't want to manage 1000's of egos
2.  1000's of people cross flooding attacks on the network with only a small number of "honest" nodes will of course cause disruption and make it harder to pinpoint the real exploits.

Those wishing to take part please communicate to me either via PM here, email contest@emunie.com or you can add me to Skype on thengonet   ...   if you are paranoid and would like to communicate via more secure means, please express such in your initial contact, I'm happy to download and install any required software to do so.

A short list of candidates will be constructed, consisting of around 20 or for the initial test environment.  As we plan to do a few of these before launch, these numbers will increase over time and subsequent contests will be held.

Bounties are organized as follows:

• 5 BTC for most serious disruption
• 3 BTC for 2nd most serious disruption
• 1 BTC for 3rd most serious disruption
• 0.25-0.5 for other disruptions classified as threats

To claim a bounty you must provide proof of your successful attack and provide full details on how it was achieved so that we can replicate it.  If the attack can not be replicated, or sufficient details are not provided then the bounty will not be paid for that threat and the subsequent most serious threat will take that bounty.

Decisions on the severity of discovered exploits will be made by forum members both here and at eMunie in a results thread.  No accounts registered on either forum after 1st September 2014 will be allowed to vote, and those votes will be discounted.

NOTE:  If no disruptions are deemed severe enough to warrant the top 3 bounties, those bounties will be spread around any minor disruptions.

Finally, this is a self-moderated thread as it is a serious topic for a serious project.  I do not want it descending into a cock waving contest, about who's hacked what, and how many chicks you were able to lay because of bragging about it  

[REAL]

Hi everyone,

It's been a good while since I posted here.  Earlier in the year after a lot of drama we decided that development of eMunie should continue under the radar, with no distractions until we were getting close to ready.

As we are now getting close to a V1.0 product I thought Id roll by and post an update on whats been going on, progress, screen shots and other interesting info.

Without going into too much detail, over the past few months we've been concentrating on the following:

• Re factorization of prototype code to commercial grade (LOTS of testing)
• Performance optimization
• Development of transaction attachments
• HTML capable secure email with attachments
• Turing complete scripting engine utilizing a Javascript/Java hybrid and GUI integration (Etherium +100)
• Plugin system for native Java plugins
• Initial development of eMuWeb including custom embedded browser (regular and eMuWeb capable)
• A REAL Decentralized Marketplace (DMP) which is also Auction capable
• True high frequency Decentralized exchange (DEX) capable of < 30 second trades
• Economics system and improvements/tweaks
• GUI Overhaul

Most of the above is now in the final stages, with the only major component requiring significant work being the DEX which should bring us to a launch candidate client around the start of Q3 this year.  Additionally we are currently in talks with a number of academic scholars and professors to arrange multiple 3rd party peer reviews of the eMunie protocols, design and code.

We also set a crypto-currency record in our last beta, with the test network processing over 1M transactions in a 24hr period.  To date as far as we are aware no other crypto-currency has achieved this in either test, or production networks; the highest daily transaction count thus far being held by DogeCoin @ ~250,000.    Even more impressive is that this record was achieved on a network of only around 30 nodes, with transaction load varying from 10-50 tx/s at times.  More nodes = more performance, so with a network of only a few 1000 machines, eMunie will be able to process in excess of Visa level transaction quantities.

I'm happy to answer any questions about eMunie providing that they don't require me to divulge any technical information that we wish to keep secret for the time being (ideas get stolen you know!), also before someone asks there is no complete whitepaper at present, just excerpts and crude developer notes, and no it wont be open source for at least 6 months post launch and has already been covered extensively.

So to keep this initial post short, I believe pictures speak 1000 words, so here are some screenies (some are large):

Transactions


Browser
(note the emu:// URL )


Marketplace Search


Marketplace Listing


Marketplace User Area


Marketplace Sell Item

[TO THE THIEF:]

Brothers in Crypto,

I wanted you all to be aware that we have a financial terrorist among us attempting to extort money from myself and likewise further damage the crypto-currency movement, of which we are all passionately involved. This individual’s goal is no doubt targeting all of us in that their actions add further reasons towards preventing our achieving global acceptance.

I am speaking to you as a common member of this movement in the spirit of open and honest communication towards allowing you to understand what has transpired against us.

As many of you may remember, a few months ago our remote servers were under constant attack and resulted in the eMunie website and forum being taken offline on a few occasions. Soon after these attacks the assailants gained access to several online services I control, and most certainly had some form of access to 1 or more machines on my home network and also our remote servers.

Resulting from these coordinated breaches, the assailant made off with over 600 BTC from my own personal BTC wallets and accounts, as well as a sizable amount from of our pre-launch fundraising activities.

Additionally some old backups of the eMunie source code were downloaded and will probably surface on the internet soon after this announcement. This source code is not compatible to any current eMunie code base and is mainly older prototype code, thankfully I had switched backup requirements some time before this attack and thus many of the functions that give eMunie it's edge are still safe.

Extensive time, effort and resources has been expended to understand how these attacks may have been possible, and to track down the offenders whereabouts. Unfortunately at this time, the identity of the thief can not be ascertained with 100% confidence, but I hope in light of recent renewed activity on their part and with help of the community maybe assisting in the search, we can identify the thief and exert some justice.

With regards to the possibility of further attacks, after this event all network infrastructure was changed with revised security methods and a change of service providers where required. These efforts included fortifying my home network and the machines that run within it, including additional internal and external proxy systems between myself and the internet. A second local network that I now use for development and the storage of sensitive information is also in place and connects via an on demand only internet connection when absolutely required.

The methods employed to gain access to remote and local systems are most likely a possibility of 2 which I will detail more in another report, the summary of which, and affected systems is below:

The systems/accounts that were affected were my personal Gmail account (which possibly linked as a backup to my ancient personal Hotmail account) as well as multiple wallets across many reputable online trading services.

Our hosting panel for some remote systems was also breached, as security there is not particularly as great as it should be for a large ISP. I believe this was the primary entry point to gain access to my home systems, with some malicious code planted and a mechanism to transfer upon next login to my home machines. From my home machines it was only a matter of time before access to pretty much everything was possible. At no point did any of the protection on these home machines indicate any virus, trojan or the sort, and considering the complexity of the hack (and how well any evidence of activity was removed) it was certainly an attacker/s of "professional" caliber and likely some custom software made to do that specific job.

No passwords for any of these accounts were kept in any electronic medium so that method was not employed to compromise them. I can only surmise that initially they gained access through the use of "Security Questions" to reset the passwords on less secure accounts, which due to my public profile and online history would not be that difficult to breach.

Based on this revised security implementation the thief is now unable to gain access to any services or accounts, and have noted recent extensive activity since the theft which is clearly such an attempt. As such, he now finds himself having to move towards extortion for further financial rewards by threatening to go public with his prior actions in an attempt to damage our reputation within the crypto-world.

As I stand by my own word and moral character I have personally covered the loss of all eMunie funds so that that the impact to our operations and activities are completely and absolutely unaffected. This was a decision I made personally as I wanted to take the time to ensure there was no loss of momentum for our project development, as well as to allow me time to begin an investigation towards discovering who this person was.

Since the attack and theft, over 300 BTC has been requested in refunds for various reasons to numerous investors, all of which have been returned without incident from my own pocket. I have ensured to keep a steady amount of funds available to be able to purchase BTC as and when required to meet these demands, aside from the occasional delay in purchasing BTC in mass amounts, all refunds have been honored. With that in mind, I would be grateful if perhaps those of you that requested refunds and received them could stand forward and state as such, providing that it does not cause you any ill consequences by doing so.

In light of this news, I am fully aware that many of you will decide to reclaim your investments too, and no ill regard will be taken against you should that be your wish. I am at present in process of repurchasing large amounts of Bitcoin in anticipation, to cover any individuals that might feel they want to be refunded from the project at this time and they can be assured that their initial contributions are still completely valid and secure. I do request, however, that if you wish to leave the project you would have a modest amount of patience for this effort, as acquiring large amounts of Bitcoin, with bank held fiat funding is not a speedy process and can take some time.

Frankly, I am personally disgusted by such a move as I have always strived to maintain a high moral character and reputation with regards to the ideals of the crypto-community. We receive enough mockery from the mainstream press and other communities already for our efforts here and these events only serve to fuel that mockery further. Accordingly, any damage to our collective reputation only serves to weaken our combined efforts to change the face of global financial services.

It is no secret that both myself and the eMunie project have been the target of many attacks over the past year, we have been mocked, laughed at, my personal status and morals have been wrongly brought to question, endless scathing personal insults, and numerous minor disruptions many times, all of which have been overcome and will continue to be so.

I outright refuse to yield to these attempts to halt the vision that is eMunie, and regardless of the outcome from this event, I will not be deterred from completing the goal which I have set. Be it with community support or none at all, eMunie will be a success and I will do whatever it takes to ensure that becomes fact.

TO THE THIEF:

Your original attack was smart, well coordinated and perfectly executed, you obviously took your time and tested for cracks, committing your attack when I was at my most occupied with other matters holding my attention. However, you should have stayed happy with your ill gotten gains, as your recent secondary attacks have not been quite so well played and you have let sheer greed get the better of you.

My trail to you had all but gone cold, and I was in the position of simply having to take the hit and allow spilt milk be just that. Alas, for you, your recent efforts and attempted extortion have done nothing more than to put into motion my forced hand. You called my bluff, I never bluff.....

What awaits you is an existence where you dare not raise your head above water, for the fear of someone, somewhere waiting with a golden axe. I am a calculated man with resources, who can be cunning when needs to be, and I will use all resources that I have to track you down, and I will start with those gold axe's.

I am going to put a bounty on your "head", the 40BTC that you attempted to extort from me. In addition to that, this bounty will increase over time, indefinitely, each week by 1 Bitcoin. This will continue until such a time that reliable information is provided that leads to you, results in your capture and full wrath of the law brought against you, or that the bounty amount is so high, rewards pledged for America's most wanted seem insulting.

By that point I imagine internet bounty hunters finding your whereabouts are the least of your worries.

Checkmate!

You have 2 options:

1. Return the stolen Bitcoins, in full, within 2 weeks. After this period, the bounty will never be lifted and negotiations of any sort are impossible.
2. Run & hide, well, and forever.


If anyone wishes to aid in the search for this financial terrorist then I will be collecting the newest information I have so far and will be publishing these details once the immediate hysteria has calmed, to aid in their eventual identification. I will also be placing the 40BTC bounty into a reputable escrow provider over the next week or so, the timeline of which purely depends on how much BTC I need to purchase to fulfill investment refunds, as that is of course my #1 priority.

Additionally if anyone has suggestions of ways I may not have been aware to attempt to track down this individual, please let me know also.

Finally, to all that have shown me support and faith, I can only offer my sincerest apologies and humbly ask that you do not allow this event to distort your perception of my character and intent. Responsibility of those funds is solely mine and I will carry that responsibility regardless, my vigilance in protecting them was simply not enough and I will pay the cost of that loss without complaint.

- Dan Hughes

For the record, none of the Founders, or any other individual associated with eMunie knew of this event prior to today!

Original Link to Attached PDF containing this text:

https://www.dropbox.com/s/fkhh875u9zokfba/Announcement Of BTC Theft.pdf

A new version of the beta client is available at beta.emunie.com which fixes a large amount of issues discovered with the original OB1 client from last week.

Many people had issues with connecting the client and syncing the block tree after a few days, these problems have now been fixed in 99% of cases and we will continue to work on these problems over the coming week or so.

Chat connectivity is also greatly improved in this verion.

If you would like to try out the update, follow the steps below:

• Make a copy of your current test & hatcher wallet
• Download from beta.emunie.com
• Delete everything in the eMunie dir, PEER/SEED folder, default.config file and everything else
• MYSQL users: As above but you will not have PEER/SEED folders, instead drop the peer/seed databases using a MySQL admin
• Re-install with installer / Unzip & copy jar file depending on your setup
• Copy wallets back to the emunie dir and run client

Any issues feel free to post here, or at the emunie forum.

[Release:]

eMunie Open Beta 1

Download:  Not yet available

Release: 9PM UTC 1st 3rd Feb 2014

Duration: 2 weeks ending 15th 17th Feb 2014

 
An open beta of the current eMunie client will be released to the public, and be freely available for download and general use on the rescheduled dates.  


NOTICE

As many are aware, the release of the OB1 should of been today (1st Feb) at 9PM UTC.  Unfortunately at 2.40PM UTC in the afternoon we had a critical failure of our forum and email servers.  At this point the root cause is undetermined, be it hardware failure, software or DDOS.  

The cause isn't important as it is past, but this disruption this afternoon, especially of email systems which are crucial, required our immediate and extended attention to resolve and as such the preparation of OB1 was affected.  Despite our frustrations, and best efforts to stay on schedule, it was decided at 8PM UTC this evening to postpone so that a calm & collected release could be achieved as per our original intention.

OB1 is currently our #1 priority now that email services have been restored, thus the forum will stay offline until Monday evening as migrations to new hardware and configurations are time consuming, therefore allowing us to prepare OB1 with unhindered focus.  We appreciate this is a little frustrating so we ask for your patience and understanding with regards to the eMunie forum's operation & availability.
 

OB1

The purpose of this open beta is to provide a real world environment test of the eMunie network & systems to allow us to pinpoint any potential issues, and have an opportunity to fix them before V1.0 launch.
 
Additionally, this open beta is to allow parties interested in the upcoming IPO to "test drive" the system so that they can be sure eMunie is the right investment opportunity for them.
 
Note:  All eMu, ENS entries, Assets, Messages, Chat and other data will be DELETED at the end of the OB1 session, and the OB1 beta will cease to function!
 
 
Whats in?
 
At the present time, most of the core eMunie features are in place and have been developed to completion and seen many rounds of beta testing.  Furthermore a large number of the peripheral services such as messaging and chat are developed to a basic level and are also present in OB1.
 
Following is a brief list of the main feature set for the OB1 client:
 
Anonymous, encrypted transactions
Transaction messages
Block-tree record model
Core functional complete assets
Complete ENS (eMunie Name System)
Basic implementation of secure, encrypted messaging
Basic implementation of ERC (eMunie Relay Chat)
Basic implementation of ratings and profiles
Basic economics model for inflation/deflation of supply
API interface for most of the above features
 

Whats not in?
 
A few components of the eMunie system are not present or enabled in OB1.  This is due to them either still being in final development, have remaining issues pending investigation or are in final beta testing, with some scheduled to be enabled for OB2.
 
Following is a list of components not enabled for OB1:
 
Distributed P2P exchange (OB2 scheduled)
Distributed market place (OB2 scheduled)
Final economic model
API calls for the above
Remote admin panel for clients
The above features once completed and tested will complete the feature list for the V1.0 launch client scheduled in March.
 
 
Known Issues
 
There are a number of minor issues we are aware of currently and will likely be present in the OB1 release.  These are mainly GUI issues, some of which are localized to MacOS systems, but do not pose much other than an annoyance to normal operation of the client.
 
Most of these known issues will be resolved for the OB2 release in a few weeks time, plus any issues found & reported during OB1.
 
 
How Can You Help?
 
We are very excited about the OB1 release this week and hopefully, no major issues will be discovered.  However, to expect a perfectly clean and bug free client would be naive, so if you do spot anything that seems wrong or out of the ordinary, please do report it on the forum so that we can investigate and improve the user experience of the client, no matter how small the issue may seem.
 

[Case 1 - Beta IPO]

Now all the chaos from the past few days has calmed down, I thought it would be a good idea to address to the FUD, properly and officially.

I could of course, opt to leave it where it is, the cancellation of the scheduled IPO, and the pending decision on what to do about it seem to have spoken volume enough to those that matter.

However, I did chose to be open about my identity, who I was, and have been called out regarding my integrity.  Now that I've had a chance to reflect and cool off, I've decided to present a rebuttal to the ridiculous claims made against me.

I am of course referring to this thread here - https://bitcointalk.org/index.php?topic=411366.0

Case 1 - Beta IPO
 

   Daniel claims to have 600 BTC ($500K to $600K USD) and there is a $8K investment limit.  That means they needed 75 to 500 people in the beta test to take part in a beta presale.    If you think people would invest into a 'beta', of all things, then I have a bridge in Somalia for sale.
    Fuserleer could counter and said that BTC was raised a long time ago but still no one would invest $60K or $120K into a 'beta' - it's all bollocks.

All I need to do is post this - https://blockchain.info/address/1EMunieVKAs8PC8mXeBkXnnry79toEKust

The sharp eyed among you will notice a deficit in the current balance and amount received, there are 2 reasons for this.

1)  A few early investors requested that I cash out their Bitcoins to lock in their value early, the total was ~60BTC
2)  As I'm sure you are all aware, a couple of weeks ago BTC took a huge dump below $500 due to the China news.  I decided to move the majority of the BTC at that time to various exchanges, so that in the event that the drop continued, I could sell out a chunk of BTC and protect the investments.  Once BTC had stabilized and recovered, I moved those BTC back to the wallet as I had not cashed out.  The total was ~ 220 BTC at the time.
 
Case 2 - Identity
 

http://uk.linkedin.com/pub/dan-hughes/7/b11/2a6
http://www.pof.com/viewprofile.aspx?profile_id=41163580


    We know Daniel is a 34 year old male, with no education, no sure status about his real profession (unless being a scammer counts), et cetera.  Take a note at his age on Plenty of Fish and compare it with his Linkedin profile.  Age 34 means Daniel was born in 1980.

    
    Daniel's first listed job at was a "Senior Developer at Senior Creations" (see Linkedin), in 1996 - meaning he was only 16 years old.  Did Daniel drop out of Highschool to become a senior developer?  Damn - he should had dropped out at age twelve, maybe he would had been made CEO.  Daniel learned so much in his first year and a half that he later made "Director of Technology" at another company.

The claim that my linked in and professional history are fake and manufactured are pretty insane.

If you check my linked in profile, you will see a large amount of individuals from the telecoms industry, mainly T-Mobile, Deutsche Telekom, Nokia, and others.  KDB Technology was my company for many years, and we worked with the companies I have just listed, T-Mobile being our main client.  I invite anyone to message any of my contacts to verify my identity and professional relationship with them.

I'm not sure of the relevance of the POF account, I did not realize that being married to the spawn of the devil, which resulted in my becoming single was a crime.

As for my "claims" of being a Senior developer at Software Creations at the at the age of 17, I refer you to this  http://www.mobygames.com/game/windows/fa-premier-league-stars/credits

I worked as an Assistant Lead developer (which is pretty senior) on the Playstation SKU, if you scroll down the page, you'll see my name.  You can get a copy of this game on eBay, Amazon still if you hunt around, my name is there in the credits listed as "Assistant Lead".

I am self educated in many disciplines, including development, business, mathematics/scientific & economic theory.  Most of brightest minds in the world are self-educated, which means they are not institutionalized and thus can think outside of the box.  Having no official qualifications should be praised, not judged, as those persons are typically more self-motivated and likely to succeed.

Case 2.5 - Scamming

Daniel also had membership on Blackhatworld

http://www.blackhatworld.com/blackhat-seo/members/224492-fuserleer.html

    So we know what Daniel was doing for a living - he was running scams.  Just because he was banned in 2012 does not mean he stopped running his scams, he was likely doing them until March of 2013 (and still could be continuing with them).

    

      There was a post by Fuserleer bragging about scamming $1500 in a single day.

http://www.blackhatworld.com/blackhat-seo/making-money/361170-just-hit-milestone-1000-today.html

    (Fuserleer / Daniel bragging about making $1500)

http://www.blackhatworld.com/blackhat-seo/blackhat-lounge/413499-jr-vip-banned-life-paypal-how.html

Daniel at the time wasn't doing anything for a living, I had sold the IP and assets of KDB and was living a nice, semi-retired lifestyle.  After being so active for so many years, I soon got bored, so I decided to learn some new skills, one that I thought would be useful in the future was internet marketing.

Say what you will about BHW, but it has some of the smartest white hat internet marketers on the planet residing there (its a shame management aren't quite as smart) and I decided to participate there, and other websites, to learn about IM.

If you actually spend some time to check out BHW, you will notice that many many people there post the results of their internet marketing milestones.  My posting about the first day I made $1500 was nothing out of the ordinary, and they generally help to motivate and encourage the people spending many hours learning and honing their IM skills.

Also in that thread there is a quote from me "...even though I'm on BHW its all pretty much white hat techniques and a little grey in for good measure..." Scammers don't use white or grey hat marketing, they use 100% black with a bit of blood colored red in for good measure.

Aside from my internet marketing, I was playing around with an retail online store, I had concentrated solely on telecoms for almost 10 years, and wanted to learn about everything.  Let me tell you, operating that retail site was TOUGH work and very long hours and I wouldn't recommend it to anyone.  Delivery companies couldn't give 2 craps about your customers, or the goods you are sending out, and as result there were a lot of logistical problems, negative reviews, and I soon decided that it wasn't for me.

Paypal however decided it would be a great idea to freeze the account due to 1 rather hard to please customer while it had in excess of £30k in it, and they were going to hold it for 180 days.

Needless to say I was not best pleased, as aside from some of that being profit, a large portion of it was to cover my expenses incurred re-sending out replacement items for those that had been lost.  I decided not to wait to the 180 days for Paypal get around to releasing it and hit them head on.

Adpulse was a venture into CPA and other affiliate marketing methods and it started off extremely well.  I even have an award trophy sitting on my desk for "Best CPA Network 2012" that I am very proud of (and can post a picture of, including the day it arrived in the box).

As we are seeing here though, with good work come foul souls, and it wasn't long before we were seeing a lot of fraud in the network and our advertisers were refusing to pay for those leads.  All affiliate networks that are driven by lead generation take the same stance "If we don't get paid for your fraud leads, then you don't get paid for them either" and that is the stance we took.  Some fraudsters weren't happy, but overall things were moving well.

Then we get to the BHW incident which I have explained in other places already so I will simply re-post my response
 

Because some guy on there attempted to scam me out of $2k even though he had been paid.  It wasn't even anything to do with BHW, yet he posted a thread.  I kicked up a fuss about it, stating it was nothing to do with BHW, it wasn't for a service or product listed on there as it was personal business and refused to yield to his threats.

    For some reason the BHW mods decided to poke their noses in even though it was nothing to do with them, by this point I was trying to keep my good name yet they sided with him even though I had proof I'd paid him.  The BHW mods are as crooked as the members quite frankly and I wouldn't visit that place again if I was paid to.

    Hopefully that is a sufficient explanation regarding a crooked websites actions.

Case 3 & 4 - eMunie

Anyone that's ever spent any time interacting with the members on the eMunie forum will immediately notice that it is different from many other forums by way of it FEELS like a real community with everyone pushing in the same direction with the same goal.

The reason for that is the way I run my own house there, its fair, everyone gets a say, I don't victimize anyone for any opinion they have, even if it goes against my own, and I listen.  I encourage everyone to follow those same principles, and they do, because they feel part of something.

Some of the guys there have spent months now, working with me on a daily basis, honing and perfecting the eMunie system, and they rightly feel its as much their project as it is mine.

The client is not vaporware, and the delays are due to my own strive for perfection, if its not 100% right, I'm not happy, and if I'm not happy I feel like I have failed myself.  I could of released eMunie many times over, but as we have seen with other projects, releasing too soon can do more damage than good and I'm sure if I was to launch early and someone lost their life savings due to a bug, the pitchforks would be out and rightly so.

eMunie is a complicated piece of software, much more so than BitCoin and it's clones, thus it requires rigorous testing to ensure its stability, and should be THE highest priority of all because ultimately it is ME that will be held accountable for any losses.

In Closing

I'm going to wrap this rebuttal up at this point, I could continue and provide more solid evidence to counter the ridiculous claims made against me but I feel I have provided enough to vindicate any doubt regarding my ability, integrity and morality.

Of course, your opinion is your own and you are entitled to it, and should you choose to believe or not believe the claims or my responses that is up to you.  

Finally, I would ask and appreciate any future personal attacks are kept just that, personal to yourselves.  Critique of the project I welcome, some of it in the past has resulted in me looking at parts of the system and redoing them, usually at the cost of great effort and have provided a better implementation than before, just to be sure.

Yours

Dan Hughes / Fuserleer

[Known Scams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

People of Crypto,

Following on the cancellation/delay of the official eMunie IPO, it has come to my attention that some scammers have decided to take it upon themselves to pose as me and promote fake ones.

These eMunie IPO's are NOT official, I have made NO decision as yet what action to take regarding the eMunie IPO, so PLEASE DO NOT INVEST IN ANY OF THESE!  You will lose your investment/BitCoins and receive nothing in return.

I have signed this message with my GPG key, and will sign any posts in future regarding eMunie investment, IPO, scams, and anything related with that GPG key also.

I will keep this post updated with information of these scams as and when we find out about them.  If any here could post this on any forums you see fit please do so, I do not want any person to lose money to these low lifes.

Known Scams

BTC Address: 19Y36Yjxtu3cz1xXHZkDFoRctjRCVUNCmL

It is obvious that EMU has plunged charging with a deception by FUD. I myself regard them as being perfectly ridiculous, i feel no need at all to justify the accusation. therefore, i have to cancelled the Pre-launch public sale temporarily in order to protect the project which i have devoted great deal of enthusiasm to.I recognized this issue deeply through the hard time.ONE of the most essential points is that Unless we plan ahead, our team even EMU are going to be in a mess.


I'm so appreciate for what you and your group have done as you mentioned in the mail. I know that a developing and competitive market in china. however, I never expected that the EMU in CN would be of such great interest to so many people (just like you and your group). Things goes even better than we planed previously.Thus,i decide to give your a discount price for small scale Public sale which is being to 0.07 usd p.p.. the approximate date of the pre-sale is in early Feb. there are some notes:

Im going to give you(your group) a BTC address of your own,pls write down the "username\amount of emunie\email" into the public note after the each sending. Pls do not use the mail box in QQ, and no one is allowed to buy more than 500,000 emunie at once.(MT GOX Avg:$)

the IPO WOULD BE DIRECTED ONLY TOWARD YOUR GROUP AND ONLY FOR ONCE the starting date is on 17th Jan to 25th Jan.(Second days after public sale and send EMU by EMU client)
you have the response to fix the final list up and then send it to me. I will confirm each transaction with yours.

as you know, it is not only a tough decision but i totally made by myself. All the reasons for those are coming from the fullest confidence in yours' faith, so notice that lead it to a downplay way which mean no more disclosing of the information or tend it into publicity.

please shown due respect for me and eMunie.

if you have any further queries, please do not feel hesitate to contact me. eMunie will be a success, and I will not quit until it is!

Bitcoin Address:19Y36Yjxtu3cz1xXHZkDFoRctjRCVUNCmL

kind regards

Dan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJS18KsAAoJENkDeop2N8+T06sIALAh1HmxnVS2youcspEKHenj
eBL+bxlxqIepUwqxqUt03/abHhJDpjUC61M0Ul0P+a6qAB46h8Ah92T3kSX3sOdg
scRrvQ91GN14m5X828pykYjFzQJtkNnBQZmpMxbGRP8bXIwA9bo+3N2zJO/IEt9n
X5KPLOhdFlWDbmS8RATZZzcz+M3FbIaIddPu2k7IXoW1dN+oFoQH2Db13OSR/CHy
uvS5DqYGfrgBPX8dAfdsNbboGlWGHoXaDrqT0jouufzovqCAQlHmomjSF5J9NFo2
hqmyrpJPkNXKlVsvQygv5LGjJBY3yqYDMwtDTVDwX5I6YCv9GUM3wQ+80o1xJ4w=
=vHAb
-----END PGP SIGNATURE-----