Topic: Decrits: The 99%+ attack-proof coin - page 3. (Read 45356 times)

https://bitcointalksearch.org/topic/m.2846240

I want also to see Decrits get out of paper and into Beta .

hopefully you can market it correctly , and try to achieve the lofty goal of peers review and open source.

It is awesome when very smart people learn and grow. Cool!  

Yeah, by accident BTC is three-letter too,
but i meant NSA, FBI etc
Sad, but AM won't read this, cuz we are both on his ignore list ((

I love to see innovating ideas. Interested

This is a lot to take in but it looks promising.  Looking forward to further updates.

AnonyMint, my love !
Please, don't "bow out", we all be feeling orphaned w/o you !

Oh, i forgot, you are trapped here, because
 you'll be fired by your three-letter bosses,
if you will stop spewing your everyday BS...

Assuming, of course, that on aggregate the hatchers are honest. When dishonesty can lead to profitability, this is very unlikely to remain true.


I'm going to straight up call bullshit on this until someone from emunie shows how this is possible. It doesn't even make sense.


If the "graph" algorithm is open source, it can be gamed. As I mentioned to brenzi, the bitcoin theft was only obvious because the perpetrator was unaware of how his transactions could be analyzed. Under emunie, a dishonest person will know exactly what behavior the network is looking for, thus making it trivial to avoid detection.


It doesn't matter because then google can change the parameters to something else without the spammers being able to stay ahead. This is not possible in an open system.


No, it can't, unless you throw any notion of scalability out the window. It is easy to say something is possible, but when it comes down to implementation, this is not going to be a protocol that will be useful on any sort of reasonable scale if you have to keep track of kilobytes of data for every little gameable metric multiplied by millions or billions of transactions, or to check hundreds of thousands of prior transactions to determine how each divisible unit of a transaction has arrived to where it is today.


"Yes, emunie intends to be a centralized protocol." This a monumental failure in design. You may as well drop all these shenanigans and have a central server--it would certainly be far simpler.

If fuserleer thinks your ideas bear any consideration, combined with his poor understanding of the double spending problem, I do not foresee emunie being a viable currency. But the details are so scarce at this point I could be convinced the code is nothing more than a hamster running on a wheel.

There are more than one hatcher, so on aggregate, the big picture will give you clear patterns of honest profiles.

It's not possible for the cheater to choose which hatcher to handle it's transaction. Plus even if they do manage to cheat through Ip and Mac adress as you described, there will be lots more signals they can't game, such as EMU age, graph, and so on (each EMU unit can have a stamp separate from the wallet it belongs too to identify it's mint date, for example.).

Re google centralization: sure keeping the info private does help, but that doesn't mean they are not known to spammers. Quality rating guidelines of Google leak out to the web every now and then. But that doesn't matter.

As long as you make the system a "pain in the ass" to manipulate, then there will be no incentive for ppl to do so, because it will be more profitable to just cooperate with the system and do what you are supposed to do, like an honest user.

The key is not whether it is centralized or decentralized, it's about giving more incentives for people to cooperate.

While this is nice, it is not what I was referring to. Those exchanges still have the power to determine what is "validly transacted" or whatever you want to term it. It is still not decentralized just because you put the bids and asks over the protocol--it is actually somewhat silly since it is just a waste of bandwidth, but presumably you are using this as some kind of metric for determining legitimate network activity. Rather unscalable, and still centralized because it is the exchanges that make this determination.

Also note the complete sidestepping of the issue as to what a mediator is.


An obvious fail attempt is assuming that a MAC address is in any way definitive. Assuming it was (which it absolutely is not), who is validating the MAC addresses? If I'm a hatcher and I say these 10 million MAC addresses are connected to me, how do you prove that I'm lying? This is also under the incorrect assumption that a MAC address means anything more than one hop away.


Not only is google's system proprietary and closed, it is also centralized. If it were open, it would never work because everyone would know what google thinks and how to manipulate it. If it were decentralized, no one would ever agree on how it's supposed to work. And whenever the emunie developers want to tweak this system, how do you get the hatchers, or whoever controls the network order of events, to agree? Only via a centralized mechanic. In effect, the emunie developers, or whatever few that are in control of this system, are in control of the money supply.

The exchange will be decentralized as it will be integrated right into the wallet client. The role of third party services will then only serve as payment processors, as bid/ask orders matching are already handled by the network itself.

There is a plan to release API for the exchange.

Doing things like checking IP, eMugraph, etc. each on its own is gameable and not foolproof, but when combined together, it will make it nearly impossible to manipulate the signals.
Example: you can make tons of different IPs, but if they all come from the same Mac Ip, it's an obvious fail attempt. This example is perfectly illustrated by Google and the way they fight web spam.

As a veteran SEO guy, I know Google has over 500 signals it uses to rank sites, and if we simply consider the merit of each of those 500 signals on their own, (example: number of backlinks) they cannot work and will be easily gamed.

But Google doesn't just combine those 500 signals in a linear fashion, it mixes them together through artificial learning to establish common patterns of natural vs. fake website profiles (example: backlinks with variety of link anchor text; backlinks in different forms: text/image/hotlinking; etc.) - that is what makes it harder and harder to game Google rankings these days.

Back to eMunie - we can follow Google's and Facebook's suit by increasing signals variety and scale it with artificial intelligence.

https://bitcointalksearch.org/topic/emunie-latest-update-lots-of-new-features-and-improvements-246463

"eMu can not be spent from a hatcher account, it can only be transferred to either an exchange account, or a regular eMu wallet via a mediator. This mediator records the movement of supply eMu into the system and is included in future supply calculations.  Hatcher owners are then free to do with the eMu as they so wish, hopefully, trading some or all of it out into the system."

I don't know if exactly what a "mediator" is is explained anywhere, but the exchange accounts are definitely centralized from what I briefly read on their forum. Basically "people we select to prove you aren't gaming the system", because they have apparently realized that doing things like checking IPs and whatnot cannot work. Can a mediator deny a hatcher's transaction? :lol: I'm sure visin will come in and say "lol of course they can't"--great explanation.

While the bitcoin theft graph is nice, it is because someone expected only a cursory glance at their activities. When the model behind any behavior algorithm is known, it can and will be defeated. So unless eMunie remains closed source, it will not be effective. Their solution (now) seems to be a centralized mechanism.

I don't see how any supply adjustment algorithm comes into play here. Probably because one hasn't been given, as if this is some kind of trade secret. More probably, there isn't any concrete design.

The options I still see for creating money are:

1) Centralized control of the monetary system - where eMunie seems to be headed
2) Proof of work
3) A broken system that can be gamed

And the developers still have not addressed in *any* significant way how hatchers can't be gamed. Sure I have been dodgy too in parts of this thread, but I also don't have a working implementation.

I'd rather graph the transactions on basis of their account addresses like they did in that paper. No need for IP or MAC addr. (of course this wouldn't be a brilliant idea). This way you can guess how much money is actually changing hands (i think they call it egocentric networks in the graph)
Scaling might become an issue but as money supply doesn't need to be optimized every few seconds but rather within days, I guess the computation should be feasible and indeed scalable. But that's only gut feeling.

It is probably unscalable. Requiring the history of transactions for any significant amount of time results in runaway storage issues for a network of any significant size. Any system that relies on the difficulty of obtaining IP addresses or MAC addresses is also setting itself up for failure. Are they aware that IPv6 has 3.4x10^38 addresses? Where is this information being stored? Are more complicated models involved in determining who might be spoofing (MAC addresses? Really?)? I believe further in that thread Fuserleer talks about centralizing exchange nodes that will actually be the source of this information. Maybe it was a different thread.

Decrits does not rely on the number of transactions, but the amount transacted and charged a percentage fee. It also requires proof of work to prove demand--the transaction activity only sets a few (important) variables. We are back to energy wasting proof of work again, but as eMunie scales to more hatcher nodes, the energy required to run all of these models of behavior may well be very significant, and may result in there being few hatcher nodes. It is difficult to say with what little information has been provided, but there always seems to be a trade-off between centralization and energy usage. At least Decrits requires the bare minimum amount of energy in a network that is not producing new currency, and only fractions when it is.

Additionally, there are several very simple things that can be done to prevent maliciously changing the important minting variables if someone does choose to donate a bunch of money to the network via tx fees--such as only considering money that has aged for awhile and dropping outlying periods of excessively high transaction activity. This does not require any complex behavioral models.

I'd be interested in your thoughts on the eMunie money supply discussion (2nd post)

I'm especially convinced by the idea to analyze the transaction graph (Ecoinimist calls it eMuGraph). This could be a good way to estimate the amount of real transactions (meaning money changing hands). Much more robust than relying on the number of transactions. As shown for THE bitcoin theft, such graphs are not easy to trick.

Solution for Proof-of-Work:

https://bitcointalksearch.org/topic/m.2575106

Would you please use English words correctly as defined in an English dictionary. You've been playing semantic shell games for far too long. And no one has called you on it.

Trust means believing the system is reliable, based on analysis or accepting what has been claimed. Trust is always required. No one uses something they don't trust (unless they have no other choice).

If your system requires a reputation for peers to distinguish from dishonest peers, that has nothing to do with trust in the system, rather is the way you achieve security. Security is probably a requirement in order to earn the users' trust, but security not trust is what reputation is designed to solve.

Proof-of-Work achieves security not with reputation, but with the inability to preimage the input entropy.

I speak in definite technical terms, not in semantic vagueness.

Very little trust, if that's what we'll call it, is required for decrits. On the other hand, proof-of-work requires faith.

Trust is orthogonal to reputation and centralization. I can trust Proof-of-Work, which is decentralized trust without reputation. Reputation isn't needed in Proof-of-Work, because the input entropy is fresh (can't be preimaged) on every new TB.

Sure someone can make a political money. We have it already, it is called legal tender. They can make a new one, and if it goes big, it will take on (some of) the traits of legal tender.

The key for me is that centralization means we lose the ability to signup and be a peer instantly without any centralized approvals. I would prefer a system where I turn on my peer and am instantly mining currency so I can subvert anti-money laundering laws. Which will be critical as the G20 goes into full blown confiscation mode in 2 - 3 years.

I see a near-term market need, to covertly (and decentrally) move capital from a financial system that will self-destruct into one that can survive and cross the chasm. That is why I said greater than 6 months implementation time is too great for me.

You all can carry on without on me. Good luck.

P.S. I discovered a great domain name.

Ah Anonymint , with all, due respect that's why it's called "trust", trust doesn't have multiple primary meanings.

It only has the one meaning if trust that was built  over time was  actually not trust, but something else ,  if reality kept splitting every five minutes and humans could perceive that , then yes it's a trade-off,.

but seeing that a human observers plain of reality normally stays vector ,

I think they will be fine with a trust system , that is built over time.