Topic: [ANN] eMunie (EMU) - NOT a BitCoin fork/clone - call for beta testers - page 28. (Read 78405 times)

sign me in please

i want to be beta tester, sign me in~

Also, from what you've described, the best way to game this system is to run lots and lots of nodes. Botnet operators will LOVE this . . . unless you've found a solution to that problem?

Very interesting proposal. I definitely want to try this. Thanks for innovating!

Please sign me up.

So, say we spawn an arbitrary number of hatchers and clients in order to generate ourselves a disproportionate share of coins. How does the system determine whether our hatchers & clients meet the requirements for being sufficiently "distributed"?

I can test

You've peaked my interest. I'd be very happy to test and provide feedback.

I'm in 

Pmd interested in testing

want to test

let me test. thANKS

Please count me in.

I'll explain further, as no "magical" algorithm is needed to prevent runaway creation volume of units, and to overcome nature of how it works to benefit, you would need to own, or control the entire network.  That's all client peers, all seeders, all hatchers, to ensure that the fruits of your attack were beneficial, then its no longer decentralized anyway, so then it would die.

Anyway, lets say that current vote threshold is 50%, that is, 50% of the votes in need to be yes to create a new unit.  To force a hatcher to create a new unit, you would need to have more than 50% of the vote power to that hatcher (disregarding any others in the system).

Assume that you have managed to pin down a few hatchers, and you flood them with votes from many clients to push the vote 50%+ so new units are created.  That will likely move the created unit volume up past the required target the network, so hatchers in the system (including the ones you have pinned down assuming you don't own them) will adjust up from 50%+ yes vote, to say 75%.

You perform the attack again and again until the vote threshold is 90%+, that essentially cuts of the creation of the units, because the volume is ahead of where it should be, so no new units will be created until time catches up.

If you DO control the hatcher to always create a coin, you need the signed votes which are verified later, you can only create 60 units at a time, otherwise other hatchers and clients will reject it, and you can only create once every 60 minutes, otherwise other hatchers and clients will reject it.

Creation of a new unit (coinbase in BTC terms) has a record of all the yes voters, with their votes signed.  When that block goes out in to the wild and is re-verified by other hatchers, those voting nodes can be contacted and asked if they indeed voted yes to create that unit, if you control all the voters to that hatcher too, then yes you could falsely create a 60 units.

So you have created 60 units ahead of time, dishonestly, but unless those units are distrubuted as required by the system, those units will again, be rejected by others in the network.

I could continue, but that should give you an clearer idea how its "difficult" to game it unless you are running a lot of the network both in client peers and hatchers.

OK, count me in. 

That's meaningless from a security mindset. If it's open source, people can change the client software, heck, even if it's closed source, people can change the client software with enough effort.

So now we're back to "what magical algorithm are you using to stop Sybil attacks?"

I would love to be part of this

I'd could be a tester as well if possible.

The hatcher that is selected and the vote (yes or no) are handled by the client software.  The actual wallet holder has no control over this at all.

If you were to grab the source and modify it to always vote yes, then even if there were only 100 other voters in the system, you vote can only skew the vote by 1%, which isn't enough to cause damage and will only push up the vote threshold over time.

The hatchers don't vote, the client peers do.  The hatchers count the votes and decide if there is enough to create a new EMU.  

These units are then co-verified by other hatchers in the system a bit like how the miners within BitCoin verify other miners actions.

How do you force people to choose their hatchery randomly? Is there anything to be gained from choosing a hatchery on purpose instead of randomly?