[ANN] eMunie (EMU) - NOT a BitCoin fork/clone - call for beta testers

[Fuserleer]

The example was regarding the voting of new units, not whether dishonest voting nodes have performed dishonest transaction work.

If a dishonest voter, is doing honest transaction verification, then that's work.

I explained the methods of co-verification which tackle double spending earlier.  Transaction blocking is overcome via a "callback" to the requesting client.  If one isn't received within a set period of time, the transaction is resubmitted to alternate hatchers.

As for the the guy with 51% of Amazon nodes voting endlessly or trying to create additional new coins, it doesn't matter, the honest nodes and hatchers compensate for that with a vote threshold, as previously explained.

[sor.rge]

Honest nodes reject dishonest nodes EMU creation.  
...
EMU's HAVE to be distrubuted according to set of rules, which can be checked against the ledger by ANY node in the system.

So what are those rules exactly? It's easy to imagine a network of two nodes, one honest and another pretending to be a 999 nodes network. Whatever the rules are, from the point of view of the honest node it would seem okay that it gets 0.1% of the EMUs issued, because it thinks that it's one of 1000 nodes network. While in fact it should get 50%.

[Fuserleer]

EMU distribution rules are as follows.

Hatchers receive 80% of new EMU units.  A single hatcher will get a ratio of that depending on the amount of honest transaction verification it has done which is easily calculated from the ledger using transaction volume, and the sum of the EMU units within those transactions.

Non-hatchers, that's clients with wallets, receive the remaining 20%, ratio of which is dependent on how much of an EMU holding that wallet currently contains.

[timeofmind]

EMU distribution rules are as follows.

Hatchers receive 80% of new EMU units.  A single hatcher will get a ratio of that depending on the amount of honest transaction verification it has done which is easily calculated from the ledger using transaction volume, and the sum of the EMU units within those transactions.

Non-hatchers, that's clients with wallets, receive the remaining 20%, ratio of which is dependent on how much of an EMU holding that wallet currently contains.

When you say "depending on the amount of honest transaction verification it has done ", I hope you mean, "transactions it has verified since the last time EMU units were distributed".

[timeofmind]

Honest nodes reject dishonest nodes EMU creation.  
...
EMU's HAVE to be distrubuted according to set of rules, which can be checked against the ledger by ANY node in the system.

So what are those rules exactly? It's easy to imagine a network of two nodes, one honest and another pretending to be a 999 nodes network. Whatever the rules are, from the point of view of the honest node it would seem okay that it gets 0.1% of the EMUs issued, because it thinks that it's one of 1000 nodes network. While in fact it should get 50%.

Distribution is not done evenly between nodes. It is dependent on amount of EMU held at each node and amount of verified transactions done by each hatcher. When a hatcher verifies a transaction, he also signs it, so it can be easily known by whole network who did the work in verifying it.... what I still don't understand is how the network knows he did the work in verifying it. That is what I'm waiting for an explanation on...

[Fuserleer]

Yup, transactional work within the past hour.  Hatcher trust is calculated over the hatcher's entire history since it's first transaction processed.

1 EMU a minute target, collated into hourly unit creation.  So 60 EMU's p/h

This is the problem when throwing together posts on a forum explaining things and working furiously at the other end, tiny details get missed.  

[sor.rge]

Ok. So a hatcher signs transactions and by this his trust value increases. Next questions:
1) Can the transaction author perform the role of the hatcher itself? If so, it can spam transactions and accumulate trust (=money) from nothing. If not, how is this enforced?
2) If the transactions are broadcasted, how to choose the hatcher who will sign it? If they're sent initially only to a specific hatcher, how is double spending prevented?

[timeofmind]

Honest nodes reject dishonest nodes EMU creation.  
...
EMU's HAVE to be distrubuted according to set of rules, which can be checked against the ledger by ANY node in the system.

So what are those rules exactly? It's easy to imagine a network of two nodes, one honest and another pretending to be a 999 nodes network. Whatever the rules are, from the point of view of the honest node it would seem okay that it gets 0.1% of the EMUs issued, because it thinks that it's one of 1000 nodes network. While in fact it should get 50%.

Distribution is not done evenly between nodes. It is dependent on amount of EMU held at each node and amount of verified transactions done by each hatcher. When a hatcher verifies a transaction, he also signs it, so it can be easily known by whole network who did the work in verifying it.... what I still don't understand is how the network knows he did the work in verifying it. That is what I'm waiting for an explanation on...

With Bitcoin, by using hashcash, clients can easily determine that a certain quantity of work was done to reach a certain point in the blockchain. What does this system use to verify that the verifying work was done? I think at a minimum, it must be easy to prove that hatcher nodes are at least doing work, so that the network is not flooded with a bunch of lazy hatcher nodes that are just faking it.

[timeofmind]

Hatcher trust is calculated over the hatcher's entire history since it's first transaction processed.

Aha! Yes. I was thinking something like that would be employed. Basically, we have a whole system that is constantly monitoring each other, the longer hatchers have been trustworthy, the more the network trusts them and if they ever do anything that was verified to be a false transaction, everybody kicks them out, they lose their reputation.

[sor.rge]

Well, I don't see the verification as problematic. In bitcoin, every node does the full verification of every transaction. Anyone with the full chain can check whether a signed transaction is legit.

[Fuserleer]

Honest nodes reject dishonest nodes EMU creation.  
...
EMU's HAVE to be distrubuted according to set of rules, which can be checked against the ledger by ANY node in the system.

So what are those rules exactly? It's easy to imagine a network of two nodes, one honest and another pretending to be a 999 nodes network. Whatever the rules are, from the point of view of the honest node it would seem okay that it gets 0.1% of the EMUs issued, because it thinks that it's one of 1000 nodes network. While in fact it should get 50%.

Distribution is not done evenly between nodes. It is dependent on amount of EMU held at each node and amount of verified transactions done by each hatcher. When a hatcher verifies a transaction, he also signs it, so it can be easily known by whole network who did the work in verifying it.... what I still don't understand is how the network knows he did the work in verifying it. That is what I'm waiting for an explanation on...

To keep the explanation simple, the hatcher generates 2 merkle trees for the transaction, which are the result of the forward and backwards traversal of the transaction chains for that spend.  These should be identical and are then stored with the transaction which the co-verifier can also check upon by doing the same task.

Ok. So a hatcher signs transactions and by this his trust value increases. Next questions:
1) Can the transaction author perform the role of the hatcher itself? If so, it can spam transactions and accumulate trust (=money) from nothing. If not, how is this enforced?
2) If the transactions are broadcasted, how to choose the hatcher who will sign it? If they're sent initially only to a specific hatcher, how is double spending prevented?

1) No, it has to be an external hatcher even if that node is running as a hatcher also.  Of course you could run an external hatcher somewhere and fire transactions back and forth "ping pong" style, but honest hatchers use Stochastic & Markov models to look for this activity so it's quite trivial to detect it.

2) You cant choose the hatcher, it chooses you.  You can request some parameters, such as trust level, min fee, but your broadcast goes system wide.

EDIT:  Your next transaction is sent to a different hatcher, you can not send a transaction to the same hatcher twice in a row, and the network can see this as the hatcher signs the transaction.

[timeofmind]

Well, I don't see the verification as problematic. In bitcoin, every node does the full verification of every transaction. Anyone with the full chain can check whether a signed transaction is legit.

Yes, but if there is a double-spend in the chain of transactions, eventually a hatcher will catch it when they analyze the full transaction chain, and whoever allowed that double spend through, loses his reputation.

[sor.rge]

Distribution is not done evenly between nodes. It is dependent on amount of EMU held at each node and amount of verified transactions done by each hatcher.

EMU-based distribution is pretty straightforward, although I don't see the point since this amounts to (perhaps somewhat randomized) even devaluation of currency.
What is interesting is the trust-based allocation. That key point deserves more clarification and discussion. Well, I guess the source code will give us the final answer.

[Fuserleer]

True, but a 20% portion of new EMU's are distributed in that manner so as to hopefully help stability against dumping, the same idea with the hatchers.

The thinking behind it is that even with only a small number of hatchers doing all the work, one of those hatchers will not be able to hold a majority stake of the total EMU's and so can not "dump" the market quite so drastically.

[timeofmind]

Distribution is not done evenly between nodes. It is dependent on amount of EMU held at each node and amount of verified transactions done by each hatcher.

EMU-based distribution is pretty straightforward, although I don't see the point since this amounts to (perhaps somewhat randomized) even devaluation of currency.
What is interesting is the trust-based allocation. That key point deserves more clarification and discussion. Well, I guess the source code will give us the final answer.

Ya, this trust stuff, is sort of like proof-of-stake; except, is proof-of-done-lots-to-keep-this-system-going

[Fuserleer]

proof-of-done-lots-to-keep-this-system-going + so-I-wouldnt-be-a-fool-and-trash-my-rep

[sor.rge]

1) No, it has to be an external hatcher even if that node is running as a hatcher also.  Of course you could run an external hatcher somewhere and fire transactions back and forth "ping pong" style, but honest hatchers use Stochastic & Markov models to look for this activity so it's quite trivial to detect it.

Cool, now we're getting closer to the point If only you would explain more.

2) You cant choose the hatcher, it chooses you.  You can request some parameters, such as trust level, min fee, but your broadcast goes system wide.

How is it chosen? Based on public keys, something like "a transaction must be assigned to the hatcher with closest public key"? That can be subverted by a chosen-key hatcher. The algorithm to choose the hatcher is rather critical IMHO, since everyone wants to be the hatcher.

EDIT:  Your next transaction is sent to a different hatcher, you can not send a transaction to the same hatcher twice in a row, and the network can see this as the hatcher signs the transaction.

Again, one could create new hatchers on demand.

[arij]

I'm interested in testing

[Seth Otterstad]

Hatcher trust is calculated over the hatcher's entire history since it's first transaction processed.

Aha! Yes. I was thinking something like that would be employed. Basically, we have a whole system that is constantly monitoring each other, the longer hatchers have been trustworthy, the more the network trusts them and if they ever do anything that was verified to be a false transaction, everybody kicks them out, they lose their reputation.

The currency is assigned in greater proportion to anyone spawning infinite nodes on amazon servers to validate transactions.  Validating transactions is a trivial task.  That's why bitcoin does not hand out currency to anyone running a bitcoin node verifying transactions.  Now there appears to be some kind of reputation/trust model built into it.  What could possibly go wrong?  Pirate had a super high level of trust on OTC until he defaulted on 5 million.  It looks like they turned the proof of work into "who can spawn more nodes."  I am kind of suprised that serious development work would go into something this obviously bad.   Anyone with 51% of the horde of amazon hatchers can build up a reputation and then double spend.  Non-hatchers cannot tell that the honest hatchers from the dishonest ones or see the double spend.  The dishonest 51% has a higher chance of choosing the clients and telling them the double spend is valid.

[Fuserleer]

I will explain why lots of honest hatchers is irrelevant.  Dishonest hatchers will get caught and this has been explained already, so I'll leave those out of it.

Remember, there is only a finite amount of work in the system that needs doing at any one time.  No one can create work that adds a share of the EMU pie to them, "ping ponging" is detectable and sending millions of tiny transactions will not help because the EMU distribution is volume & sum of value based.

Lets say A & B are hatchers

They both have the same work load capacity, and over time, they both do an equal share of the work.   D rolls in with 1 million amazon instances, which combined are 1 million times more powerful A & B.

The work load in the system is the same, so the power is no advantage at all.  That's exactly the same as D rolling in with a supercomputer that runs just 1 node, doesn't matter, the work isn't there.

But gosh, all them nodes!!!  Doesn't really matter either:

1) It wont massage the trust value of your collective nodes, you do a transaction you get some trust, sure the distribution of trust is spread thinner, but no one gets a trust advantage.

2) Real world cost, if some guy, wants to rent 1 million Amazon nodes and perform 99% of all the transaction work in the network, that's up to them.  It's still work.  Some miners have HUGE hashrates, and rake in a lot of BTC, but they have had a real world cost, so why shouldn't they get the reward for that?  No one seems to have a problem with that model so why should it be different here?