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

[timeofmind]

The network is composed of clients, seeders and hatchers, the functions of which will be explained in this announcement.  Any node can take task in one, or any combination of these roles dependent on the users wishes.

This was the only one time that you mentioned seeders in your presentation. You did not explain what they are or what benefits there are for being a seeder.

[1715314612]

1715314612

[1715314612]

1715314612

[1715314612]

1715314612

[1715314612]

1715314612

[1715314612]

1715314612

[1715314612]

1715314612

[Fuserleer]

Ahh yes, slipped my mind when composing the OP.

Hatchers are also generally seeders, but a node can run as a seeder only, or a client & seeder.

Seeders keep a record of all the most recently connected nodes, and upon connection to the network, your client or hatcher will connect to a seeder to fill its peer pool and announce its connection to the network.  There will be some preconfigured seeders with the clients, and also the ability to add your own that you know of within a config file.

Seeders also assist in the selection of hatcher nodes for both the transaction verification that you send verify requests to, and also provide you with a hatcher to send the currency creation votes to.

On a side note, we had a meeting and brainstorm and decided upon a new name, after looking at the suggestions/advice I received, we decided upon eMunie...buying up the domains (including a .com believe it or not!) as I type.

[Remember remember the 5th of November]

Ahh yes, slipped my mind when composing the OP.

Hatchers are also generally seeders, but a node can run as a seeder only, or a client & seeder.

Seeders keep a record of all the most recently connected nodes, and upon connection to the network, your client or hatcher will connect to a seeder to fill its peer pool and announce its connection to the network.  There will be some preconfigured seeders with the clients, and also the ability to add your own that you know of within a config file.

Seeders also assist in the selection of hatcher nodes for both the transaction verification that you send verify requests to, and also provide you with a hatcher to send the currency creation votes to.

On a side note, we had a meeting and brainstorm and decided upon a new name, after looking at the suggestions/advice I received, we decided upon eMunie...buying up the domains (including a .com believe it or not!) as I type.

SSL is a must!

[ohhaithere]

Unsure how I feel about the technology here, but I'd be interested in premining... erm I mean testing it.

[imbecileee]

I'm in!

[LimLims]

FWIW I think eMunie is worse than eMulah. At least Mulah was a corruption of a slang word; Munie just sounds childish and unprofessional. Ecurrencies need some sort of superficial legitimacy to succeed, and a big part of that is the choice of name.

[iamrickrock]

FWIW I think eMunie is worse than eMulah. At least Mulah was a corruption of a slang word; Munie just sounds childish and unprofessional. Ecurrencies need some sort of superficial legitimacy to succeed, and a big part of that is the choice of name.

I have to agree, eMulah was much better.

[Seth Otterstad]

How do you prevent Sybil attacks-- somebody creating a gazillion n-client and/or hatching nodes, and voting themselves lots and lots of new currency?

And how does a node choose a "random" node-- does every node know about every other node?  If yes, then how do you avoid getting O(N^2) communication as the number of nodes (N) rises and every existing node must be told about every new node?

I'm composing an amendment to the OP regarding Sybil like attacks and the prevention of them as a few members have raised this point both public and private, I'll be appending it shortly after I've finished up some other tasks.  Hopefully that will then give an idea how we handle it.

Selecting a random hatching node doesn't require the peer to know about all of them, or about any other client peers in the system.  A voting peer can either select a hatcher from its currently connected peer pool (if there is one or more present) or send a request to a seeder node which has a collective store of all the most recent nodes within the system (as its seeding it is able to do this easily), including plain client peers, hatchers and other seeders.  As peers and hatcher connections come in and out of this peer pool, that further massages the entropy of the hatcher selection.

With the voting system it is possible to have many hatchers, all obtaining votes from the client peers independent of each other, and deciding, independently also, whether to create a new currency unit or not.  Currency regulation is determined by using the public ledger, so providing that all the hatchers collecting votes are close to being up to date, they will all be working to the same vote threshold.

As the system grows hatchers will be working with a subset of the total voting power in the system, but the required target volume can still be met and held.

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.

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.

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.

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

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.

A proof-of-work or proof-of-stake system are the only known ways to stop someone from running a lot of client peers or hatchers in a decentralized system in order to block transactions or double-spend.  I do not see any new solution to the Byzantine Generals problem in your answers.

[timeofmind]

A proof-of-work or proof-of-stake system are the only known ways to stop someone from running a lot of client peers or hatchers in a decentralized system in order to block transactions or double-spend.  I do not see any new solution to the Byzantine Generals problem in your answers.

Or a system of "elitist" "miners" who have to share the work cooperatively, like I proposed here:

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

But nobody seems too pleased with that idea... :-(

[digit]

count me in

[Visin]

looks like a solid bet to me

[feeleep]

I am in

[timeofmind]

A proof-of-work or proof-of-stake system are the only known ways to stop someone from running a lot of client peers or hatchers in a decentralized system in order to block transactions or double-spend.  I do not see any new solution to the Byzantine Generals problem in your answers.

proof-of-work = all the rich people control the damn currency!
proof-of-stake = all the rich people control the damn currency!

damn it, there has to be a way to guarantee an even distribution of control over transaction processing! But the only other way I can think of is if you could verify that every node involved in the verification of blocks is in fact a separate individual!

[Visin]

A proof-of-work or proof-of-stake system are the only known ways to stop someone from running a lot of client peers or hatchers in a decentralized system in order to block transactions or double-spend.  I do not see any new solution to the Byzantine Generals problem in your answers.

proof-of-work = all the rich people control the damn currency!
proof-of-stake = all the rich people control the damn currency!

damn it, there has to be a way to guarantee an even distribution of control over transaction processing! But the only other way I can think of is if you could verify that every node involved in the verification of blocks is in fact a separate individual!

Should we be thumb printing individuals now? haha.

[pinger]

What do I have to do? What do you mean by energy eficient?

I'm IN if you want. Send private for OS and hardware specifications.


Greetings.

[Seth Otterstad]

A proof-of-work or proof-of-stake system are the only known ways to stop someone from running a lot of client peers or hatchers in a decentralized system in order to block transactions or double-spend.  I do not see any new solution to the Byzantine Generals problem in your answers.

proof-of-work = all the rich people control the damn currency!
proof-of-stake = all the rich people control the damn currency!

damn it, there has to be a way to guarantee an even distribution of control over transaction processing! But the only other way I can think of is if you could verify that every node involved in the verification of blocks is in fact a separate individual!

When the dozen or so startups who are working on a reputation economy find a way to uniquely identify everyone on the planet over the internet, it will enable a bitcoin competitor to make a decentralized initial distribution of the currency evenly to everyone, which would be VASTLY superior to bitcoin's system of mining as an initial distribution. Unfortunately, by the time this capability exists in one or two decades, bitcoin will have huge special interest groups who will attempt to destroy such a competing system before it gets started.

Mining sucks, but it is the best solution Satoshi had available.

[GSnak]

find a way to uniquely identify everyone on the planet over the internet

Yeah that's what everyone wants.

[r3wt]

I could understand
e-coin
e-cash
e-dollar
e-note
e-funds
e-currency
e-tokens

but

e-munie? dafuq are you high on?

my personal vote would be

e-tokens

[Visin]

A proof-of-work or proof-of-stake system are the only known ways to stop someone from running a lot of client peers or hatchers in a decentralized system in order to block transactions or double-spend.  I do not see any new solution to the Byzantine Generals problem in your answers.

proof-of-work = all the rich people control the damn currency!
proof-of-stake = all the rich people control the damn currency!

damn it, there has to be a way to guarantee an even distribution of control over transaction processing! But the only other way I can think of is if you could verify that every node involved in the verification of blocks is in fact a separate individual!

When the dozen or so startups who are working on a reputation economy find a way to uniquely identify everyone on the planet over the internet, it will enable a bitcoin competitor to make a decentralized initial distribution of the currency evenly to everyone, which would be VASTLY superior to bitcoin's system of mining as an initial distribution. Unfortunately, by the time this capability exists in one or two decades, bitcoin will have huge special interest groups who will attempt to destroy such a competing system before it gets started.

Mining sucks, but it is the best solution Satoshi had available.

From working in the advertising end of the internet world, I can tell you one thing, you will never have a true link to a human being with a way to distinguish if thats the said user or not. Many firms have tried doing this online and its far from possible due to the way the entire tech world was built around, which was not being connected IRL.

Even if you go as far as biometrics, which I do not think most will go that far, it will still be possible to fraud the system with a torn out eye / chopped hand

[YaCoinYeah]

Someone make a name suggestion thread, we can all brainstorm and promote the new upcoming coin at the same time.