Bitcoin Forum

PLEASE SEE REV4: https://bitcointalk.org/index.php?topic=49683.0

Since this version is completely revised and much more professional (except for section 12) and it has incorporated much of the discussion from the previous thread, I have created a new thread so that the discussion focuses on the new proposal and does not get lost in the mix.

The primary goals of EnCoin are as follows:

•   To maintain a relatively stable cost point where 1 ENC requires about 10kWh of electricity to produce.
•   To maintain a relatively stable exchange point where the effects of price inflation or deflation are smoothed out by economic and monetary policy.
•   To provide a stable currency that merchants can rely on in both value and security.
•   To use smaller, decentralized hubs that support themselves rather than relying on large pools of computational resources.
•   To make use of a reputation system so that the EnCoin Network is not vulnerable to a 51% computational attack or network subversion attack.

Document: http://www.mediafire.com/file/ghmb81e79msy63a/EnCoin%20Proposal%203.0.1.rtf
Pastebin: http://pastebin.ca/2085821   (lol the real pastebin took down my submission, they must work for bitcoin)
google docs: https://docs.google.com/document/pub?id=1voi9j2kNgwdh0Y56r-9zSC5Bv6tOWwJ4X1OiBvFUAw4

I highly recommend downloading the document so that the formatting is preserved.

IRC: irc.freenode.net #encoin

The previous thread can be found here: https://bitcointalk.org/index.php?topic=44682.0

I haven't read the new version yet, but I plan to. I really want to continue our discussion, but if I don't clear one thing up my head will explode.

You seem to be using the word "security" in ambiguous ways that are driving me crazy. On many occasions it seems you are using the word "security" to mean "continuity". Occasionally, you seem to use it to mean "dependability".

Security: the state of being free from danger or threat.
Continuity: the unbroken and consistent existence or operation of something over a period of time.
Dependability: trustworthiness and reliability.

I tend to interpret EnCoin security to mean, nobody can steal my coins.
EnCoin dependability means, it's always there and works when I need it.
EnCoin continuity means, the network as a whole goes on forever. It will never disappear taking all my coins with it.

Before I start reading, please tell me we are using the same language.

---

OK, I'm reading now. I'd like to make inline suggestion about the parts I find confusing, but think I now understand. I don't really want to clutter up this thread with those. Would that horribly offend you?

se·cu·ri·tyNoun/siˈkyo͝oritē/
1. The state of being free from danger or threat.

I think that covers all three. And yes, it means all three. Stealing coins is a threat and reliability is an even bigger threat because if the network stops your coins are worthless (same as stealing).


Not at all.

*Needlessly Ranting* Hoping you will change your ways

If you are Chinese and started learning English just yesterday maybe you would think so. But in reality, it just makes people think you are clueless about the subject matter. And it explains why you can't understand a fucking thing I'm saying.

It's like saying, "The federal reserve has been providing security since 1914."
When you mean "The federal reserve has been operating continuously since 1914."

Or like saying, "I have security guy that always goes when I head out to party."
When you mean,"I have a dependable friend who always goes when I head out to party."

Rationalize them all you want, but they don't have the same connotations. I would forgive you if your native language was Thai. (I can't even attempt to speak that.) But your native language seems to be English.

I won't forgive you being deliberately obtuse just to waste my time.

I've sent you comments on the first three pages. Before you ask me to read it again, ask someone who doesn't already understand your idea to read it. Then assume every question they ask you is one I'll have.

I didn't mean to needlessly repeat myself or use the exact definition you used--I seem to be doing like 16 things at once these days and my attention was divided. Sorry for that.

You have to take in a few factors:

1) I am coming from a Bitcoin mindset where the only word used is security. I am trying to separate myself from that, but it is not easy. Dependability and continuity are not aspects that are often discussed about Bitcoin.
2) I am not writing a white paper, I am writing ideas down on electric ink and this is only the 3rd revision. Comments are obviously expressly welcome, but I did not realize that there were like 8 different posts between us on this issue because of a clash of interpretation on the word security.
3) I wrote this 24 page proposal in a matter of two days. So please, cut me some slack. ;)

I'll be reading through your comments in a few. I've uploaded a new version that seriously tones down the bitcoin hate as it was pretty unprofessional, though I thought it was funny. It also adds a new Q&A and fixes a few minor errors.

I am really striving to understand your concept. I understand your goals. First a little background so you can reinterpret my previous posts as well as interpret the ones which will follow.

I have great respect for all of the detailed thought that went into bitcoin. I analyzed the bitcoin white paper, read the code tried to poke holes in everything. When I saw potential exploits I pointed them out to satoshi. We worked through his existing defenses, generally he proved correct. But hashing out the logic increased our trust in both the algorithms and implementation.

Note, I was probably the first to clarify bitcoin's lack of anonymity. Not because of IP addresses recording, in bitcoin's case. But because every transaction since the beginning of time is stored in a directed acyclic graph. That makes it almost trivially easy to coordinate "accounts" owned by the same human. Someone published a paper investigating the recent bitcoin thefts using exactly the mechanisms I posted about a year ago.

Notice I say accounts in quotes above. That is because bitcoin's block chain doesn't contain an entity called "account". It only has transaction in-points and out-points. Each out-point is associated either with either a public key, or the hash of a public key. This public key hash is what is commonly called a bitcoin account. Bitcoin's block list does not sum or track account balances in any way.

You propose to change that. You, in each primary block, propose to record account balances rather than transactions. That decision has many consequences that need to be analyzed. However, the "balance sheets" concept was proposed over a year ago on this site. That thread should be reviewed. In a very important sense balance sheets improves anonymity. I really like that. You however claimed EnCoin cares little about anonymity. I'm still searching for the necessity of this.

There are interesting advantages to the way bitcoin's DAG works. One of the most important being, it makes it trivial to identify maliciously attempted double spends. Out-points don't keep a running balance. They are single use. All coins must be used in one and only one subsequent in-point. No other party can attempt to forge a transaction. The "account" owner must deliberately create two transactions which cannot simultaneously be valid under ANY circumstances. It cannot be done accidentally. This is called "fraud". This is different from banking where you might be acceptably or unacceptably "overdrawn".

This fraud was what I proposed detecting when I shouted STUPID and IRRESPONSIBLE. I was referencing the fact that bitcoin detects fraud attempts, but it *silently* prevents them. It doesn't notify anyone of the instance of a fraud attempted, nor of its perpetrator. This is a stupid and irresponsible policy decision. That mistake should not be repeated.

On security:

In bitcoin, theft through forgery, is prevented by cryptography, not any form of plurality.
In bitcoin, fraud via double spending of out-points, is prevented by DAG validation rules and procedures, not any form of plurality.
In bitcoin, there is one, and only one, transaction DAG. For a transaction to be "confirmed" there must be an absolutely immutable 100% consensus our shared history. If the transaction doesn't validate in the DAG it never happened. In bitcoin, the DAG is encapsulated inside the block chain.
In bitcoin, this 100% consensus is not created by any form of plurality. It is created, and mandated, by random chance. This random selection is implemented by the proof-of-work procedure. (Who solves the proof is stochastic. But existence of a valid proof makes acceptance mandatory.) Many, much more efficient, procedures for mandating consensus could have been implemented.
In bitcoin, theft via history modification, is prevented by protecting the block chain using a "hash chain". This is a common technique used to protect shared histories like digital notarization records. This protection does not require a proof-of-work.

In bitcoin, theft via history substitution, is prevented by careful monitoring of  the working end of the hash chain. Originally, this task was trusted to a mathematical function. In cases where two equally valid block chains exist, either by accident or by deliberate subversion, this function mandated which chain must be accepted as our shared 100% consensus on history. No form of plurality agreement was involved.

This function takes the combined proof-of-work effort and chain length as parameters. It then decides which chain required the most effort to construct. This function is well known, but its dynamics are often misunderstood. It is also important to know that,

THIS FUNCTION PROVED INSUFFICIENT FOR PERMANENT PROTECTION.

Bitcoin programmers, by programmer consensus, began adding "block locks" into each client's block chain validation procedures. This programmer consensus overrides the above function in any case where the function might attempt to switch to a non-programmer-blessed history. This has been commonly accepted as "a good thing". I concur.

Notice that none of the proof-of-work effort prior to the most recent programmer block lock, provides any protection from a history modification attack. The hash chain alone provides perfect protection. That means all of historical POW effort and electrical consumption was made moot, by a single line of code, created by a plurality of *trusted* programmers.

That should serve as our definition of "Trust". Someone is trusted if they get to participate in locking down our shared history. Trusted peers guarantee that confirmed transactions stay confirmed.

In a sense, all of the words I used above—theft, forgery, fraud, history modification, history substitution—are all "security". But using the same name for all of them conflates multiple distinct topics and makes specific targeted discussion baffling.

---

I have tried to discuss each of these specific areas in previous posts. In variably, every reply became miners/peers/trustnets/freenets have to keep actively mining in order to provide security.

I understand the conflated sense of why you keep saying this. But I think you are wrong for very specific reasons. I can't convey these reasons unless we accept a more specific vocabulary.

In bitcoin's case, the proof-of-work-summation-function provides most of its actual utility for about an hour. If history more than a hour old changes, something catastrophic most likely happened. Humans SHOULD be alerted prior to accepting the results.

---

That means all of bitcoin's electrical consumption does two things:

1) It makes about six history substitution decisions each hour to resolve minor network splits.
2) It serves as a weighted random number generator, for periodic bitcoin awards.

The periodic bitcoin awards serve to provide incentive for non-transacting people to keep clients running. Thus your argument that mining provides incentivizes network continuity. I agree with that. But mining clearly does not provide any additional protection from theft, forgery, fraud, or history modification.

It also begs the question of whether other have enough incentive to provide network continuity absent mining rewards. I would argue they do. The primary examples of this are the bitcoin exchanges. Their whole business depends on bitcoin continuity and security. If there were no more mining awards, they would continue to provide bitcoin network continuity.

In effect the exchanges represent the dreaded "center" of the bitcoin network. It makes zero sense for them to transact on two branches of a single chain. it also makes zero sense for different exchanges to trade on different branches of a single chain. They must cooperate to stay on the same fork. Everyone else will follow them out of necessity.

So in summation, if someone mounts a history substitution attack via 51% (or even 99%) of the CPU power, that attack only succeeds if the exchanges consent to the history substitution. Note that, only exchanges get a vote, and they must come to 100% consensus out of self-interest. Everyone else must follow. So, by my definition above, bitcoin exchanges are the only "trusted" peers in the bitcoin network.

If you analyze it completely you will see the same relationship will hold true for EnCoin. No matter what your total reputation count, if the exchanges dont agree, you lose. If you attempt to continue the other branch, you have created a NewCoin a currency already pre-distributed to prior EnCoin owners. If an exchange starts, the EnCoin humans will simply cash out their free NewCoins taking every dollar needed to incentivize NewCoin miners.

I always meant anonymity in IP->wallet terms. In Bitcoin, it is very difficult to tell if a transaction originated from the peer that just sent it to you or somewhere else, because all peers spread all data. A huge waste of network resources and terribly unscalable. Since, in the design proposal for EnCoin, peers (as opposed to freenet peers) do not need all data, peers only need to send transactions or request data that matter to themselves. It later occurred to me that "the cloud" in concept (sec. 9-2) could be used so that it is much less trivial to associate a wallet with an IP address without putting an additional, unnecessary load on freenet peers. Still working on whether or not that association is impossible or is at least at the same level as bitcoin's.


The scenario I talked about was if a freenet peer tries doing it by subverting reputation. What if a regular peer tries doing it? At this point, encoin basically silently prevents it as well. However, the potential fraud victim will never even know, which is a benefit over bitcoin. I'm not sure how the bitcoin client handles receiving a second transaction using the same coins after it has already put up a "0/confirmations". Does it just ignore it? Probably. With Encoin, no fraud could ever be committed because the receiver will never get any knowledge (unless they are in a freenet) until the transaction is irreversible. This "fraud" could happen accidentally if the peer tried sending money from another computer (or phone or whatever) before requesting a balance update.


I don't know if you want me to respond to any of this or if you're just rehashing what bitcoin does for my/everyone's benefit. What EnCoin does, in essence, is "block locks" once per day.


Ok, that's fine, but if you want to discuss one of those specific issues, why not bring up those specific issues instead of calling me out on encompassing them all into one terrible term? What productive use does it serve? It is not an important issue at this point. This proposal is not written for the masses, it is written for the people that understand how bitcoin works. It says so in the first page.


Bring up an issue, argue why or why it isn't good and how it benefits or may harm the network. It's that simple. Arguing that minting coins doesn't "secure" the network, it "keeps the network running" is starting to get incredibly pedantic.


No, the honest peers who run the network do. (at least in encoin) And there is no better way to provide a reputation system that is implemented by computer and consensus that is EASY TO PROVE and DIFFICULT and TIME-CONSUMING and COSTS REAL MONEY. Why not use the system that already exists and charge the users of the network a tiny fee to ensure that these peers have incentive to keep doing it?


Ok, what? Are the exchanges going to agree or not? What in god's green earth are you trying to say, because it sure as hell isn't making sense to me. Someone makes a fork, therefore it forks the chain? Are you saying that there is a danger of someone forking and making the currency useless? Because I can make arguments against that point. I can't make arguments against paragraphs of words bandied about that may or may not mean anything--but it assures me it does if I analyze it completely.


.......................................

The bitcoin checkpoints only lock history for history that is many thousands of blocks in the past. Preventing "double spending" is impossible in bitcoin, at least with its current design. Exchanges will take it just like everyone else because that is the way bitcoin is designed. Exchanges won't agree to a history modification because they should have the newest "block lock."

It sounds like what you're saying is that the only way to have a cohesive network is to have a central authority (whether that's trusted programmers or exchanges depends on which paragraph I read). I don't know if you're saying this from the point of view of bitcoin or encoin or both because I can't apparently analyze too well. But since encoin actually has no "block chain" per se, and it "block locks" once per day without requiring programmer intervention nor a central authority to agree on that block lock, there is no parallel to draw here between the two networks.

If you would like to bring up a SPECIFIC SCENARIO, I will be happy to tell you why it won't work, or I will be happy to agree that it's possible and I will think of a way to fix it and will thank you for pointing out a flaw in my design.

Otherwise, I am getting tired of this runaround with a whole lot of words but very little actual discussion.

By the way Red, I am reconsidering a lot of what you talked about as far as the transaction fee/reputation goes. I think I may have overcompensated for some of bitcoin's faults. And more of what you said is starting to make sense in light of that fact. I've been worried about the value tanking if the network drops in activity, but realistically this is very unlikely. Once people are invested, they are invested (for however much they are invested for). During the bootstrap process, the coins may not be worth much actual value, but once there are enough people it should hit some kind of "end of bootstrap" point where demand is strong enough to bring a value of 10kWh to the coins. The process would probably take longer than bitcoin's, but then again, I'm not so sure as I think bitcoin may have intentionally been kept out of the limelight, and in any case encoin would be able to abuse its popularity.

Other questions I'm thinking on... how many clients could one peer support? easily 100 to 1, perhaps 100 to 2 or 3 so that each node can double or triple check. If everyone averaged a transaction or two a day, at a ratio of 100/1, the transaction fee would not need to be much at all, maybe 5 encents or even less. I was too worried about inflation that really shouldn't happen with a stable value. But if people take part in the network without minting, then you have a lot more data to try to reach consensus. And you have the cost issue far reduced, so it will be easier to attack the network with useless data, or prevent valid data from being confirmed. So I don't think the reputation system can be eliminated. And another question is, if the economy is stable and no new coins are produced, how do you determine the difficulty of making coins when someone decides to make coins? That's a very big question that needs a rock-solid answer.

This discussion is feeling much more productive now. You were correct. I didn't want to you to respond to lots of that. I just wanted to provide a frame of reverence and define some terms. That way, when I ask questions about a how you propose to do X when you removed bitcoins X mechanism, we'll both be on the same terms.

I'm going to reply to your long post in sections. Otherwise I don't think I'll be able to keep up with so many threads when you respond again. Nothing in this post attempts to be critical of any of your ideas. I'm still trying to confirm I understand the logic behind them. (Which bitcoin issues were you attempting to fix)

OK, so you are not opposed to anonymity. And I think I understand what you are saying. Please correct me If I'm wrong.

Defining EnCoin "client" as a human who wants to transact in ENC but does not run a continuous node. As such this client cannot (and does not want to) maintain a running tally of every EnCoin account balance in the system.

You are saying if a client wants to transact in ENC he must submit his transactions to some "Peer" who will have the ability to associate his IP address with the accounts listed in his submitted transaction. Fair enough.

This does not compromise any of the anonymity I care about. I (as a client) *have to* trust the processing peer to tell me the truth about my transaction and other transactions I cannot verify. If I trust the peer this much, trusting him with my IP address seems of little consequence. As long as that peer does not include my IP address with my transaction *and* broadcast that information to everyone. You don't seem to be claiming that is necessary, so that makes me happy!

I like this feature for anonymity reasons.

I suggested as such in one of my first posts to this site. We are in agreement.

I understand your attempt to minimize the span of broadcasts as:
1) Defining the role of "client". Computers operating in this role, do not need to be part of any broadcast. They can either poll for information, or register call-backs for events they care about.
2) You expect there to be orders of magnitude more clients than the number of participating peers. Hence, the peer-to-peer broadcasts span becomes drastically narrower.
3) You are batching transactions into blocks by FreeNet. This narrows the network wide broadcast span to FN-to-FN. It does likely require defining a second kind broadcast. An intra-FreeNet broadcast restricted to only peers of a given FreeNet.

I accept these concepts. I suspect that you could leave out the (3) optimization and still create a system that scales well enough. I do recognize you are using these intra-FN broadcasts for other purposes as well. As such, I'm not lobbying against (3) just making a mental note for reasons that come later in this post.

Additional topology choices such as small-world vs spanning-tree or other optimization seem inappropriate at this time. Saying broadcast is good enough for me. I don't care how it is implemented at the moment.


I'm not disagreeing with this section but I am confused about the terminology. I'm going to attempt to define some terms and summarize my understanding using them. Tell me if I'm understanding incorrectly.

Client: as defined above.

Peer: a continuously running node who attempts to maintain running account balances for every account in the EnCoin system. I think this means he at minimum, gets every transaction, gets the consensus agreed primary blocks, validates all transactions between the previous PB and the subsequent PB. After that, he may or may not keep the actual transactions and previous PBs. By my definition, a peer is *not required* to mine or participate in proof-of-work calculations in any way.

FNPeer: a peer in the above sense. But one who also chooses to belong to a FreeNet and to participate in mining along with the benefits of mining.

My intention for defining "peer" this way, was in relation to merchants or exchanges who have a business unrelated to mining. They have a vested interest in making sure the network is secure (free from theft, forgery, fraud, and history modification). If a merchant in this sense, identifies say "fraud". He knows with %100 certainty fraud has occurred. Even if a 51% plurality of the FreeNet trust vote denies any such fraud.

--- specific questions on your statement

In the terms I used above, it seems your use of "peer" would be my use of "client". Is this correct?
Your use of "freenet peers" is equal to my use of "FNPeer". Is this correct?

If both are correct, I understand your statement.

Do you have the role I called "Peer" defined? What do you call it?
I would identify a "Peer" in this role as someone who provides "security" and "continuity" to the EnCoin system as a whole. I assert this is true even if such a node decided to never participate in reputation building or mining activities.

Do you agree?

I understand what you are saying about the cloud. However, I'm not particularly concerned about the use-case. My thinking is, if some human demands anonymity, he should run his own peer. If we attempt to implement anonymity it should be defended at the peer-to-peer level.

If the human insists on only running a client, he must trust someone. He had better pick someone he trusts with his anonymity as well. If no one exists in this category, he must run his own peer.

I recognize you are saying, that each transaction gets put in a signed FN transaction block at the first FN hop it enters the network. That means any other peer can trace a particular transaction back to its FN of origin. If that FreeNet happens to be untrustworthy then it has your IP address. This is true for full peers as well as clients.

That is why I made my mental note above. If it turns out you can scale the inter-FN broadcasts without batching and signing, then you can avoid the intra-FN broadcast and reduce the number of nodes that can confirm the origin of a given transaction. I suspect that would put us back to closer to BitCoin's level of transaction origin anonymity. (3) above may be the case of "premature optimization".

However, as I pointed out above. I know there are other reasons for (3). I'm willing to listen to how they play out.

I have lots of other bits to say about the parts in between, but I want to say this first because I see you got the wrong impression.


The other guy, (John?) had expressed concerns about consensus. He didn't see how it might be possible absent bitcoin's proof-of-work-summation-function. I was trying to lay the ground work for agreeing with you.

You assert there are ways to reach 100% consensus absent that function. (Reputation weighted plurality voting of FreeNets, is how I understand it.) I assert there are ways to reach 100% consensus. (The simplest I have suggested is replacing the proof-of-work with a distributed random number generator.

It doesn't matter to (John?) he just wants to grasp the concept. I was trying to show how little value all of those khashes do and for how short a time that effort retains any affect. You acknowledged that (and I agreed) by saying there exists a simpler process for agreeing on primary blocks.

Your point is that if we all agreed and then locked in each primary block each dat (as you propose), then there would be no possibility for a long term history substitution attack. I totally agree! If bitcoin were to come up with a mechanism of dynamically inserting block locks for everything one day (or even one hour) old, they would do away with the possibility of long term history substitution attacks as well.

Your reputation voting process defines a "center of the EnCoin universe". The set of all FNPeers and the reputation voting process gets to define everyone's shared history. (At least that is the way I understand what you are saying.) You are also saying, it is going to cost people dollars if they want to move toward the center of the ENC universe. Perfectly reasonable.

Then I did a dumb thing. I tried to conflate two points into one post.

1) Bitcoin already has a "center of the bitcoin universe" even if others don't notice or want to acknowledge it.

Re-writing this:

No matter what an attacker's chain's total effort count, if the exchanges dont agree, the attacker loses. Conversely, if the exchanges go with the attacker's branch. Anyone who attempts to continue the original branch, has created a NewCoin currency already pre-distributed to prior BitCoin owners. If a new exchange forms, bitcoin owners (who moved to the attacker branch) will simply cash out their free NewCoins (from the original branch) taking every dollar needed to incentivize NewCoin miners.


2) "If you analyze it completely you will see the same relationship will hold true for EnCoin."

Because, EnCoin mining incentive relies on the existence to ENC exchanges. (So that miner can cash in ENC to pay their electrical bill.) If the exchanges don't agree that the Primary Block (basic accounting) is correct. They can decide not to trade on that Primary Block. If they propose another Primary Block they will trade on, they win. There is no point in mining on a block the exchanges won't pay on.

This doesn't invalidate anything you are saying. It just acknowledges that the exchanges have inherent "reputation" that puts them near the center of the EnCoin universe.

It's like the US President. He doesn't get a vote in the house or the senate. But he gets a veto if he doesn't like their consensus. This seems to hold for exchanges in both the bitcoin and encoin governance.

----

I am in total agreement with you that it is possible to create a system where 1 ENC = 1 Loaf of Bread using the cost of electricity as the mechanism for adjusting monetary policy. I'm in agreement that this is a great goal for digital money.

The only place I am likely to disagree with you is in total system efficiency and how that relates to electricity and dollars. Otherwise we are in complete agreement that these goals can be met.

I'm doing a little too much of trying to make everybody happy, is the problem. Like I said in this revision and in revision 2, anonymity, if required, should be the client's own responsibility. I suppose though the more features there are, the more likely it is to draw different types of people. I don't particularly care if those people want to trade in illicit goods, that is up for the police to figure out, not the network. However, if that is one way the network gains popularity (like bitcoin), then it is likely to only be the starting point. However, with governments attempting to take more and more privacy away from the people, such as: http://threatpost.com/en_us/blogs/house-committee-passes-bill-force-isps-retain-user-data-12-months-072911 this, it makes me happier and happier to try thwarting their plans.

But yes, for a regular user, this should pose no problem whatsoever. And you actually brought up a valid point later, that they could be their own peer, using a different wallet, and be just as anonymous as bitcoin.


I disagree that you could leave out (3) and be even on the same order of magnitude as scalable. Instead of every single peer that was interested in achieving consensus (at this point, a FN peer), you compartmentalize that into 50-100 peers agreeing with each other, then that group of 50-100 agreeing with other groups of 50-100. So the system scales down by almost 50-100x the amount. This would be a pretty big deal if there are 1 million people interested in achieving consensus.


If an exchange decides to go rogue for whatever reason with a group of other peers, clients attempting to use this exchange will pay for ENC and receive nothing. The exchange would have to fork with a significant portion of the consensus-making peers AND the clients. If the clients receive nothing, I do believe they'd have an issue with this. Since "real" money is involved, the government agencies that investigate this sort of thing would get involved. If the fork involved manipulating the monetary/network structure, the clients would simply refuse this change unless the people behind those clients downloaded new software (or had their software maliciously replaced--but I have thought of that too, and a way to prevent it from happening). If the fork involved manipulating the account balances, then the client would ask to see the proof. Since it could not be provided, this venture could never (reliably) work. Since the exchange is risking all of their profits on even attempting this, I think they would be wise to leave it alone.


I'm quite sure long term history substitution attacks are not possible, or are rather an absolute waste of time. It makes worlds more sense to just attack the block chain as-is. Stopping current transactions or reversing old transactions will have the same effect, and the former is much easier to do than the latter, so why bother? I think this was implemented early on when it might have been easily conceivable to rewrite history, but as it is now there is no danger other than some theoretical attack--that again, would serve no purpose better than just attacking the current chain.


Well, see my other new post about that.

In not generally contesting what you say. I'm in general agreement. I'm just essentially brain storming so you can hear my logic. (Even if you don't want to! :))


I was thinking of the case when say you had a FN of 10 nodes and every human was personal friends with the others and fully trusted among the group. As an extreme example, say one human owned all 10 nodes. In this case, what you must absolutely guarantee is that at least one node is always doing the work for the FN as a whole. If that node fails, another has to step in. Perhaps two or three did the work redundantly, while the other 7 concentrated on mining.

In that case, the 7 mining nodes don't have to get every transaction. They don't have to be available for contact by clients either. As long a someone is there to serve them, the clients won't know the difference.

So in that model, a client contacts your primary FN access point. This node forwards the transaction to the other FN primary access points. Each each primary access point would then intra-FN broadcast *every* transaction to the backup nodes. Those nodes wouldn't have to care which originated from which FN.



I don't think we are very far apart here. We both think that if this situation were to occur, it would be a human problem to sort out. Not an algorithmic problem. Clearly, FN humans are part of the problem solvers, as are the programmers and the exchange humans. It is these humans that have to create the 100% consensus for the rest of the user humans.



I'm not sure if you are talking about bitcoin or encoin here. But in both case I agree with you. Most other bitcoin posts I read, tend to have too much fascination with the 51% of miners take over and change the block chain attack.

In EnCoin as history substitution attack is equivalent to changing the balance of an account absent a valid transaction. Then claiming that transaction happened in a past that most people have discarded transactions from.

I doubt your system would let this happen. I'm presuming you are using cryptography to avoid transaction forgery, and a hash chain to protect transaction block/primary block chain. If any group tried to commit fraud, any single "compliant" peer would be able to detect this. Then it very likely becomes a human problem.


OK! I'll respond to that one in a few. I need to run out.

Well, this is partially my fault, but I've sort of readjusted what my definition of a freenet is. I think it is primarily just groups of random people. I didn't include the "message board/groups of friends/etc" thing in rev3 that I had in rev2. The reason why is that I realized that a malicious agency could then more easily get away with something malicious if they could create groups of their own choosing and not allow anyone else in. They have to be completely rethought out because I was aiming for say, a FN that had a reputation of 180 would require peers with 180 RPs to join. But this makes things complicated for brand new users trying to join a FN. Something kitschy could be done such as allowing FNs with less than 30 RPs to allow peers with any amount of RPs to join, but then you open up the reputation system to a slight attack. It would be kind of silly if people had to be kicked out once the FN RP reached a certain point and the peer RP was too low.

So now... with my new look, I'm kind of thinking of having separate FNs, ones that mint coins and do all of the network stuff, and ones that just do the network stuff. But that brings up several new issues. How much reputation to award people for just helping consensus since they don't add value to the network other than being more points to connect to. Should there be a minimum amount of RP needed from those ConsensusNets before being able to move on to a MintingNet? Should the PB consensus have a minimum RP of say, 30 or so, and should it simply go by individual user RP (I mean about in terms of having someone sign it, because we don't want every single 1 RP peer signing it, it's spam)? What about confirming transactions? Do we take the total of the peer RP in a *Net and use that figure instead? The only way to really verify (proof-of-work et al) who is actually in a *Net though is from the FN blocks produced--because of the payout structure including those peer wallets. This was part of the protection I had envisioned. Now I'm not sure exactly how to do it.

These are a lot of questions that need to be solved in what you think is the proper way of doing things. I am starting to come around, but it took me a lot of effort to come up with what I did. I know the reasons why I did what I did were not always clear, but there were reasons. And those reasons are very important to preventing an attack on the consensus.


IMO, you're thinking too small-scale. Each member of a FN should have its responsibilities to the network. Divide the data load evenly. There will be A LOT of data if this network comes even remotely close to the likes of Visa (and I DON'T want you to need a supernode to run it!). Although if you read through my rants about bitcoin, I did say that it would be possible to have transaction sizes in the tens of bytes. I just wiki'd it, and apparently ECDSA signatures are 320 bits, a bit more than I thought. But that's 40 bytes, plus 12 bytes for the to/from/amount fields (4 bytes for amount since encoin does not need to be "infinitely divisible" and 4 significant digits is probably more than enough, so up to 400k ENC would be able to be sent in one transaction with an integer). I'm sure I'm missing additional stuff like the "this is a tx message" message, but I think <60 bytes is feasible per transaction, whereas bitcoin will have 1kbyte or more sized transactions. Still, I aim to be as efficient as possible wherever possible.


I was trying to avoid there ever needing to be a human problem except in the case of the complete Sybil attack scenario when a client is connected to only the dishonest network. Any other case should be able to be done automatically. Show the network proof, set the rep to 0 and carry on with the malicious nodes having to start all over again. Or quitting, because it's pointless and the system is bullet proof. :P

I see four roles. Tell me if you see the same ones.

Role	Network	Minting
Peer	yes	no
FN Peer	yes	yes
FN Miner	no	yes
Client	no	no

I'm not arguing how much reputation nodes in these roles should have. Just whether they will exist in the EnCoin universe.

Don't think I'm thinking small scale! And if a merchant like Apple or Amazon wanted to take ENC, I'm sure they would want to monitor the network, but not necessarily mine. They would certainly be willing to throw whatever network connectivity and hardware at the problem that it took. They probably wouldn't want to run 100 small peers, when 3 high end servers would do.

And if there are minting profits to be had, people are going to optimize their implementations. I doubt every node of those bitcoin GPU and ASIC mining pools is handling network traffic.

I have a thread on this forum proposing modifying bitcoin to use a distributed hash table approach to spread the load. I mean hell, all the p2p kids are doing it! It turns out I convinced myself it could not be done securely in an anonymous peer environment. Lots of things like sharding can be done if you trust the other shards. But if there is even a chance they are malicious things go to hell fast.

Now that's not to say you can't minimize network messaging like you suggest. But you seem to be suggesting that each of your 100 FN members does the same redundant tasks as the others. I'm not saying you are wrong. I just don't know if you are saying that is mandatory for some reason.

As a side note: I still don't understand which FNPeers will provide a client interface. Or if clients view the FN as a whole as one entity? Or do they see each Peer separately? If they see each Peer separately, do they know which FN a peer belongs to?



I met the Jason Scott recently. He runs Archive Team (http://archiveteam.org/) for the internet archive. It changed my sense of scale. I no longer worry about storing bits. I barely worry about transmitting bits now. Still, I'm old school. Don't waste thing you don't have too!


Understood. There were times at the beginning you mentioned reputation and consensus as being problems I know now you want to solve using cryptograph. Over time I'll ask you which are which. But not now. Now I've got to go out!

I have an issue with the FN miner.
This system needs to be un-attackable. If you read the wiki quote on the sybil attack, giving away cheap identities is what makes this attack easier.

The reputation system, as I had originally envisioned it, would require both minting and networking to prove your reputation. This means you can't put in a bunch of computers together in a pool and use them as one node, or you get only the rep for 1 node. This means you can't use a botnet (or use a lot of IPs if you have access) to make lots of cheap identities, because you can't get the computing power.

Not either or, but BOTH to help make sure that these identities are actually going to trustworthy individuals.
By giving consensus power to identities that are not using BOTH, you are opening the system to easier attacks.

Another undetailed idea I have (sorry there are so many, but the system is pretty complex) is that FN peers, as you describe, would be checking for hashes periodically from other FN peers. This means that a Peer/FN peer could not pay out a FN miner for doing work they didn't do, just to increase the identity's RP. (each peer would be working on a hash with their public key involved, so it's easy to prove that that individual is actually working on a hash)

By allowing FN miners, one pool could create 100 "trusted identities" and make it much easier to attack the consensus.

The reputation system is of paramount importance, unless you want constant interruptions and confused clients.

That is why I devised the transaction fee, so that there would always be demand for new coins and it would require a relatively constant, small fraction of the total userbase to replace it. So if there's 50k clients, there need to be 500 peers. If there are 500k clients, there need to be 5k peers. How else can I keep people from making cheap identities from attacking the consensus? If it's just the network stuff, the only factor I can see is time. Give them some RP for their time, slower than minting obviously. But time is relatively cheap, especially when you could use 1 computer to generate a thousand nodes on a computer with a big connection and plenty of IPs.


Well then amazon can make an FN peer and run it at 1/20th and get all the info they need already. They're not worried about rep or coins. I'm assuming during stable economies most FNs will be running 1/10 or 1/20.


Right, and I believe this is a serious security flaw. Pools have WAY too much power in bitcoin. They discourage being a node, and they control too much of the hashing resources.


Absolutely not. Each FN peer would be connected to a different set of other FNs. If there are 100 total FNs, each peer would be connected to 2-3 peers from other FNs so that there is the capability to double and triple check that everything coming out of 1 FN agrees. This means for 100 networks, there are a total of 6-8 connections per FN peer (4-5 for their own fn, 2-3 for others). That leaves many connections open for incoming and outgoing data to the clients. It also means that transaction confirmations can happen very, very quickly.

BTW - who connects to whom would be chosen randomly! And it would change relatively often! That way malicious entities cannot collude between networks or even within networks.


Any of them. The FN blocks contain a random selection of IP addresses of peers within the FN. So when a client gets a new PB, they have a list of all kinds of IP addresses to connect to. And yes, the FN peer will communicate what their wallet ID is and so on. In the actual client software, lots of info would be available on the FNs that are out there and so on.


I hate to say it, but I'm starting to re-convince myself I had it mostly right. ;)


It makes quite a big difference between storing and transmitting between a few hundred transactions per day and a few thousand per second. I want this to be available to a regular computer in the future. Not some corporate supernode. Some people have bandwidth caps too. I realize in the future this stuff will be more accessible, but still, it needs to be accessible to almost everyone, imo.


As Encoin matures, there would be very few miners required. They would get replaced only as some quit or whatever and others can step in. I know a lot of bitcoiners will find this to be a shitty deal, but they aren't going to make much anyway. The objective is to have a STABLE ECONOMY. What bitcoiners don't realize is the $4.30 they're paying in costs to make 1 BTC and sell for $5, $2 of those costs are going to the early-early adopters, $2 is going to the mid-early adopters, $0.30 is going to the real cost to produce. It's a pyramid, and the more people that mine, the more profit it makes the people before. Why does everyone have to be so set on making a profit? I realize it's motivation, but why not use a real system that isn't some bullshit scam.

Everything you write seems sensible, but it points out to me that I don't yet understand your reputation system well enough to comment yet. I'm also a little slow understanding exactly what consensus decisions are subject to attack.

I'm going to try to summarize what I think I understand. Hopefully, you'll tell me where I'm wrong.

In encoin, theft through forgery, is prevented by cryptography. Nobody can create a transaction drafting money out of an account without the private key.

In encoin, there doesn't seem to be anything equivalent to bitcoin's double spending of out-points. Instead, encoin has "over drafts", meaning transactions that would cause a negative balance.

In encoin, fraud via over draft, is prevented by transaction validation rules that say, current PB account balance (minus) draft transaction can't be negative. In situations where two simultaneous (intra-PB) transactions combined to cause an overdraft, which transaction is rejected, and which is accepted is non-deterministic. (As is a bitcoin double spend)

In encoin, PB account reconciliation follows rules which say, previous PB account balance (minus) draft transactions (plus) receipt transactions = subsequent PB account balance. AND subsequent PB account balance can't be negative. (It is not clear to me if you order account transactions as must be done in bitcoin's DAG.)

Note:
It is not clear to me how things are ordered if multiple receipts and a drafts show up in a single transaction block. Or if both show up in multiple transaction blocks affecting the same primary block.

Unlike bitcoin double spends, encoin overdrafts are not necessarily malicious. It is possible for overdrafts to be caused by network lag in receipt transactions. Differing network propagation of receipts seem extremely likely, due to their differing origins. If a strict "order received" queue is followed (rejecting all transactions that would cause a negative balance) then inter-peer balances will become inconsistent.

Without buffering and re-ordering of transactions during a PB building period, individual peer acceptance and rejection will be non-deterministic. This will complicate "confirming" transactions.
/Note:

In encoin, there is one, and only one, ordered transaction log. Only valid transactions are listed in the transaction log. If a transaction isn't in the log, it didn't happen. There is also one, and only one, ordered Primary Block (balance sheet) log. The two logs are encapsulated in separate parallel block chains. The two chains are staggered so that each primary block summarizes all transactions that happened prior to any given primary block.

In encoin, theft via history modification, is prevented by protecting the block chain using a "hash chain". This protection does not require a proof-of-work.

In encoin, there must be 100% consensus *in order to* finalize a primary block. Once a PB is finalized it, and its preceding transaction block, become part of our absolutely immutable shared history.

------

That just leaves me three things I'm absolutely sure I don't understand.
Perhaps I just need pointers to the correct sections in the proposal.

1) In the process of finalizing a Primary Block, How is consensus reached?

a) I know the decision to finalize is partially time based. How is consensus reached that time has elapsed? (meaning which transactions should be in and which held for the next period.)
b) If some transactions haven't propagated to every FN, how are the discrepancies reconciled? I'm assuming it is the union of all valid transactions. But what is the process for forming that union? Who broadcasts what to who?
c) If the above mentioned non-determinism causes conflicts, how are they resolved?
d) Which peers are responsible for the process?

Except for (d), I don't see any need for reputation to weigh in on any of these decisions. I can think of deterministic ways to complete all of them. (Except guaranteeing that a peer doesn't backdate the transaction time of a personal transaction.)

2) history substitution: How is network partitioning handled and reconciled?

If some sub-set of EnCoin claims to have been completely cut off from the rest, can they go on processing transactions and/or minting? What about the main body of encoin, can they go on? How is either to decide who is main and who is cut off? If both continue, how is the fork reconciled?  Do some minters lose their minting transactions in reconciliation? How long can a fork go on and still be reconciled, can it cross PB boundaries? If so how are the history PBs reconciled.

I'm absolutely sure this is a place where inter-FN reputation plurality comes in. I'm just not sure how it works.

3) Are there any other inter-FN plurality decisions where reputation is involved?

I know minting rewards figure in. But that just seems like a mathematical formula. If peers award themselves minting rewards that don't match the formula, they are wrong. That is more like a transaction validation/rejection rule. There doesn't seem to be room for weighted influence.

===

I'm really hoping my basic (above the ----) understanding is close. I really want to get on to understanding the stuff at the bottom.

OK, I understand what you are saying here. But the question I have is: Suppose Amazon doesn't want to mine, and just wants to monitor the network and assure that the common history never changes. They don't even want an automated vote in any decisions.

Why do they care what others think their reputation is? Is it just because FreeNet peers only discuss these topics with other FreeNet peers?



This seems to be a significant part of your focus. I have no problem with that. But understand I'm still more interested in the transactional and monetary policy parts. That is the direction most of my questions with be coming from.



Most of these are topology decisions. It's good to understand the reasoning though.

But you seem to be agreeing with me in the sense of redundant I intended. Every FNPeer receives interFN transaction block broadcasts and rebroadcasts them intraFN. Every FNPeer then consolidates all of the received transactions, removes duplicates and validates them all. You seemed to confirm that was required behavior for every FNPeer. Understood.



OK, so I'm understand now that a "human client" CAN choose which FN they trust to download the current PB from.
The PB gives them a nested list of FreeNets and FNPeers belonging to each. The "human client" CAN choose which FNPeer, of which FN, they trust to handle their transactions. Got it!



Unsure to which antecedent you are referring.



Understood. Totally!

This is something that can be worried about later I suppose. Some FNPeers may be willing to send all data, but I would think it has to be optional to avoid overloading their connection. Or there could be "clouds" that have many members where each member has its FN that it requests data from, so they could all pass around all the data.


It's not a matter of reputation, just avoiding wasted bandwidth. But like I said, it could be handled, I just haven't accounted for it yet.


Not exactly. 1 peer is randomly selected to make the transaction block so that they can all agree--in the odd case of someone quitting or being disconnected or whatever. It's still relatively the same though, I guess every peer needs to make sure each transaction is valid anyway before they sign it themselves. However, if the 3-4 peers the selected member is connected to don't agree that all the transactions are valid, they bring up a "Something Is Not Right" issue before passing stuff on.


To some degree. I mean if Amazon has a trusted peer they want to connect to without using the regular procedure, that could easily be set up. However, clients won't know who they're connecting to until they see the wallet ID. I suppose if they think the individual's rep isn't high enough they could add more or whatever.


Needing transaction fees to ensure a decent number of people have a high reputation so that the consensus cannot be easily attacked.

But yes - my system is demanding to be too efficient. Too few peers are required for consensus, it means DoS'ing is too easy. That's why I wanted such a high transaction fee so that more peers are required to be part of the consensus to keep the price stable. More peers, less chance of DoS attack. Otherwise how can we be sure they're trusted? How can we penalize them?

To require the same 50k miners that bitcoin has, we would need 5 million people using the network (edit: with a low transaction fee like 5 encents). So as the network becomes more popular, it would be less vulnerable. But that would be a long ways away, and DoS'ing in the mean time could keep its popularity down.

I'm assuming you are agreeing with me here. Hash chain exists, but no direct proof-of-work required. Cool.


Good this is what generally I was expecting.

What I wasn't grasping was the ramifications of the "confirmation" message. There are a few more states that I wasn't considering. Re-summarizing what I understand now:

1) You receive all transactions and confirmations into a sort of rotating buffer (a carrousel?)
2) You process the next transaction in the buffer,
2a) If that transaction fails validations you skip it, leave it in the buffer and move on to the next
2b) If the transaction passes validation, you
2b1) Increment the transaction's RP with your reputation points
2b2) Broadcast a confirmation through your signed FN transaction block
2b3a) If the transaction has 51% RP, you remove it from the buffer and place it in the log.
2b3b) else the locally confirmed transaction sits in the buffer awaiting remote confirmation messages
2ca) As remote confirmations are processed, you increment the appropriate transactions RP
2cb) If the inc results in a transaction with 51% RP, it is pulled from the buffer and placed in the log.

I'm assuming all transactions left in the buffer at PB build time, remain in the buffer for the next cycle. Bitcoin dumps unconfirmed transactions during its consensus mandate. It gives the client the responsibility to resubmit them.

I don't see EnCoin's way of "rejecting" a transaction and removing it from the buffer. Is my assumption correct? Do transactions stay around presuming a receipt will make them valid? Or do peers "bounce checks" at the PB boundary?


You answered my question twice. You use the reputation system to guarantee consensus on when time has elapsed. The no-proof-of-confirmation rule is the no-backdating rule.

No one can say, my minting transaction finished at the last second, it was just delayed in network transit.
Your rule says, 51% confirmation propagation must be finished by the time we start.

So basically, confirmations are transactions in the sense that, reconciliation requires the union of all confirmations, in addition to the union of all monetary transactions. Like other transactions, these confirmations are protected from forgery by cryptography.




Good, this is what I was calling the "center of the universe" rule. It defines who is the center and who is the periphery at the time of the split. NOT at the time of the reconciliation, like bitcoin does.

I think it is absolutely fair game to say, "You guys are cut off from the main network. You know it's you who are cut off. So, warn all your peers, (some things) will not function as they would if we were all connected.

I don't claim to know what the set of (some things) is at the moment. You say transaction confirmation is definitely in that set. I was assuming minting would be in that set. If not, even better.

It is unclear to me how unavoidable partitioning should affect reputation. Or how deliberate partitioning would affect it. Or how to tell the difference.

OK, understood.


Yes. In this case, to me it means, assuring no transaction confirmations go out for transactions that can't possibly have been validated yet. It seems fair to continue the broadcast of even "overdraft" transactions at this point. It is part of creating the union of all existing transactions. But if you see your fellow FNPeer signing confirmations for overdrafts in the FreeNet's name, you'd better shut him down fast!


OK, so now I understand the default case differently. The "human" client's machine arbitrarily makes multiple connections to known peers without considering their reputation, or the reputation of the FN to which they belong. I can see that working for the average user. It is equivalent to bitcoin (I think).

The case I was thinking of is, say I a want some anonymity but I'm too lazy to run a full peer. But I know my friend Fred lives in Sweden where they have lax IP logging laws. So I pick him as the peer entry point to relay my transactions and poll for confirmations. It's not that I want guaranteed anonymity. I just want to guarantee that my connection point is not the Department of Justice.

I think it is a fair enough answer to say. In this case, just run TOR and quit bugging me.

But in your example, I can see people saying, "I just feel more comfortable submitting my transaction through Amazon. I trust them even if their official RP number is low." This could be a marketing feature.



I see why you want lots of participating parties. I'm not sure I understand all the calculations between fee rate, and number of participating parties.

But what I find most interesting is that *everything* seems to come down to distributed clock synchronization. Deciding what happened before a certain time and what didn't.

--- EnCoin ---

Gaining 51% of the RP does nothing that could possibly force the other 49% to allow theft, forgery, fraud, history modification or history substitution. (This is awesome!) It is what I was trying to get at with all of that blabbering about "security". In my sense of the word, EnCoin is always a 100% secure system

What 51% of the RP does give you is the ability to declare what has and hasn't happened YET. This brings to mind two situations.

1) Denial of service

You've talked about this a lot. Basically the ability to stop other valid transactions indefinitely. If you have malicious peers with 51% RP, you are in the "deliberate network partitioning" scenario. The 51% can't declare the 49%'s transactions "rejected". They can only fail to acknowledge their existence.

2) Past Posting

A 51% RP plurality allows "past-posted" confirmations to be generated in the reconciliation phase. This allows valid transactions to being included in a PB, when they should have been disallowed by time constraints.


Combined, these two can conspire to create an "unfair" system. Say by delaying others mining transactions, and past-posting your own.

Interestingly, I showed in a post on the other thread, this itself *cannot* cause monetary policy instability. If your 1 ENC requires 10 kwh rule continues to hold, exactly the same amount of minting will be profitable. It's just that the profits will be distributed only to the 51%.

Should the other 49% of minters drop out of the network? From the client's perspective, nothing at all changes. Every client submitted transaction is still equally secure. The prices are equally stable. EnCoins operation is equally continuous. So long as the 51% doesn't deliberately sabotage their own self-interests, there will be no client perceivable changes at all.

The 51% can only compromised the reliability of client transaction confirmations. In that situation Humans would cease to perceive of EnCoin as a dependable transaction processor. Or worse, perceive their coins as having been stolen. As the 51% cannot possibly gain possession of these DOSed coins, the mass exit of transacting humans serves only to destroy any particular future profit they hoped to receive.

--- BitCoin ---

Bitcoin solved this same "distributed clock synchronization" problem using a variable difficulty proof-of-work. Difficulty is adjusted to mandate consensus at roughly 10 minute intervals.

--- My Algorithm ---

My algorithm also requires reaching consensus on time. I deliberately hand waved on that, because I was concentrating on the monetary dynamics. The plan was, first, get the monetary dynamics to seem sensible.  Then, provided that worked, Google how NASA does remote clock synchronization. I doubt that anyone on the planet has done more research on this problem than them.

I think it is time to do my Googling.

So is this going to be easily GPU or easily CPU minable !? I think go for CPU as bitcoin is already dominant in the GPU market etc.

Any input ?

Found some interesting directions to pursue regarding the time problem.

Vector Clocks (http://en.wikipedia.org/wiki/Vector_clocks)
Internal Tree Clocks (http://code.google.com/p/itc4j/)

But then I realized my algorithm has only one condition bounded by time. That is when prices are inflated and it is time to destroy coins. In this condition, there is no minting and no profit at stake, therefore no race conditions. You simply can't make something profitable when it's not.

---

There is one other thing I wanted to mention about EnCoin minting in a down market. I'm pretty sure you haven't mentioned it.

If inflation is occuring in an ENC world, that means ENC coins are selling for less than the 10 kwh of electricity it would take to mint a new one. You see this as causing a lack of incentive to "minters". As such, they would shutdown nodes and stop wanting to monitor/support the network. Perhaps that's the reason for your aversion to a non-minting peer use-case.

I realized it is not as bad as you think.

If someone was minting, then they believe in the concept of stabilizing 1 ENC = 10 kwh.
When they can mint at the cost of 10 kwh, and sell the coins at 11 kwh, then they MINT and SELL.
Conversely, when they can mint at the cost of 10 kwh, but only sell for 9 kwh, then they BUY and HOLD.
That is the most profitable move if you really believe that things will stabilize at 1 ENC = 10 kwh. It is also exactly what you want them to do to stabilize monetary policy.

In order to buy and hold in a down market, they are going to need a functioning network. If the EnCoin network fails as a whole, they won't have a future to sell in. Hence my most, compelling case for a non-minting peer.

I'm not averse to non-minting peers, I just don't know how they can be given reputation in the consensus. I am averse to non-peering minters.


And that's why I conceded that maybe I was wrong about the transaction fees, they could be much lower. But there is no incentive for the people who did earn their RP to stick around--besides the continuing prosperity of the network. That might be good enough, but it's not enough to rely on.


But HOW do you avoid these non-minting peers from attacking the consensus!? There is no real cost involved, just time as I said. If these non-minting peers can easily overtake the consensus, they can disrupt the network easily time and time again. Am I overthinking this? I don't believe so.

I'm quickly running out of time to continue thinking about EnCoin. But now that I have a pretty grasp of the concept. And because you PMed me for comments. I want to summarize my current views.


First off, I think you have two unsolvable problems in the "halting problem" sense. There simply are no algorithms that can solve the problem.

1) You can't detect if a node is generating 1 ENC = 5 kwh.

Sure if they behave badly, you might detect it. But if they simply want to reap an outsized share of the minting profits they can do so undetected. See Charlie and his tit-for-tat approach.

2) You can't detect if some human collective has 51% of the RP.

Sure if they behave really badly, you might detect it.  But if they simply want to reap an outsized share of the minting profits they can do so undetected. Simply delaying an occasional competitor's minting transaction, while past posting your own would do it. Then you get sell on the exchange first at the higher price.


The good news is, neither of these destabilize your monetary policy. They just remove some of the populism you are working to hard to add back in.


Second, any attempt to fix the above issues, to add back in the populism, results in a philosophical issue.

Resolving CPU efficiency or consensus monopoly issues, requires falling back on Human Consensus. You can't even count on plurality voting based on RP. If someone can generate at 5 kwh, they can sway enough collaborators to gain 51% RP.

Human consensus means humans talking to humans. Someone must research the issues and propose alternatives for everyone else to debate. Programmers must implement the changes. All users must adopt the modified clients. However,

3) Humans can't reach an intelligent consensus if everyone is anonymous.

The idea of an anonymous trusted party is inconsistent. Unless everyone can read the code and decide for themselves, they have to trust someBODY. The benefits of being trusted comes with the responsibility of being held responsible for violating that trust.


Finally, I think you have one logical mistake.

4) 10 kwh need not be burned to guarantee 1 ENC = 10 kwh.

There is a great early bitcoin thread on this. My favorite quote is:


EnCoin's philosophy seems like burned wheat.

As I've said before, I see ways to keep the 1 ENC = current_value(10 kwh) while minimizing the amount of electricity that must be burnt. I agree with your goal. I disagree with your logic.

I also showed in the Charlie tit-for-tat example that someone burning 0.01 kwh can be indistinguishable from someone burning 10 kwh. In that case the first is better. In every case burning less electricity is better.

As I showed in the burn 10 kwh and sell it for 10 kwh using dollars. That burned value must come from clients. This represents overhead that cannot be used as Minting incentive. It doesn't matter what the fee is and how you justify it. If you give the resulting minting award to the electric company, that part represents zero incentive for minting.

So, to build consensus to cut Charlie out of the system. You must first convince everyone that burning 1,000 times the electricity to do Charlie's job is sensible. Then explain, this sensibility comes because the new system is fairer. Not fairer to the clients who are paying for the electricity. But fairer to those trying to get rewarded for leaving their computer running. This is going to be a hard sell.


The algorithm I proposed uses electrical value as a boundary condition to prevent generating coins. It gives minting zero profit when minting is inappropriate. It should not however be a requirement for generating coins. If new coins are necessary, the amount of overhead in generating them should be as small as possible. Just like Charlie, competing arbitragers get paid by lowering the total overhead of the system.

Anyway, you asked for comments. So there! :-)

I see what you are saying. I thought I suggested this but I guess not. If you are a non-minting peer your RP could be zero (or some zero valued token). You do the work, other nodes don't have to believe you. But if the non-minting peer doesn't believe the consensus, it is going to alert its Human owner immediately. Merchants like Amazon make great non-anonymous sentinels trusted to watch for trouble.

As for minters who earned RP, but have now current profit to continue minting at the moment. Perhaps they could become non-minting peers without increment or decrement of their RP. As long as they continued to support the network, their reputation continues. When minting became profitable again, they would change to minting-peers and their RP would begin increasing again. This is kind of like my algorithms (0) state. Do some work to avoid incurring unnecessary losses of RP.

I'm not that worried about this. That is why the payout is structured so that this cannot be abused too badly. Plus like 3 other things in the proposal.


:sigh: You aren't focusing on the right things. This won't realistically achieve anything. Coins do not or won't need to be added to any wallets until the PB block. If someone disagrees that your mint block is valid, that is a breach of consensus. Besides, we're talking about a few coins per day, not a lot of money to try and take advantage of.


The problem with trying to get 51% of the RP to agree to 5kwh is that it falls apart when someone gets greedy and wants double the coins for 10kwh. And eventually it starts lowering the value of all of their coins.



Your explanations of what you're thinking are frustrating. You keep going off on these tangents that care nothing for the security/continuity/dependability of the network and basically say "blah blah this will happen, I don't care if 4chan griefs the network, it works."


"Blah blah it works because I said it does." What gives zero profit when minting is inappropriate? A coin costing 10kwh to produce but being worth only 9kwh? Well that sure as hell isn't gonna stop charlie who is paying .01kwh. Or bob who is paying 5kwh. You make far too many assumptions about your perfect society without seeming to understand the ramifications. If there are not people always making coins, it is literally impossible to know who might be gaming the system or knowing how to adjust for it. You just assume the programmers can do it (FORK). Maybe Charlie just hates himself and wants to burn electricity at a loss. Since he's the only one making them, the difficulty adjusts to him and him alone, so who the hell knows?

Truly, I'm baffled to the point of futility. This was your main thesis. 1 ENC = 10 kwh Difficulty had to be scaled to by changing algorithms to prevent people from being too efficient. That was what chased the last guy out of here. If that is no longer the thesis. Great. That's what I've been saying since the beginning.

But if some people can mint for 5 kwh and others have to mint for 10 kwh. It's not hard to see that the 5s will drive out the 10s. If one is minting at 10 kwh and selling for 11 kwh. And the other minting at 5 kwh and selling for 11 kwh. The second is making six times the revenue of the first. No amount of payout constraints is going to make that up.



Again, I'm baffled. You went on about FN needing to generate so many blocks per day to maintain their reputation points. The need of 51% confirmation on every transaction being the time lock for closing the PB. If minting transactions are not subject to the time lock or confirmation then great. Weird but great.

Reputation Points seem to have very little effect on anything. They speed up a validation/reconciliation process you deliberately slowed down. They're of minor help during partitioning. The rest of the time the entire mechanism serves only as a way to "fairly" divide up minting spoils.


Yes, that is exactly the problem with your plan. The code that can generate at 5 kwh will replicate and the 10 kwh code will die. But it will happen undetected in secret. It's better for people to generate at 5 kwh, and pretend they are generating at 10 kwh. Then they take their extra profits and go drinking.

Nobody generating at 5 kwh will vote to waste the extra kwh. At worst they will pass their code around 51%. Then the 49% will drop out and everyone will be generating at 5 kwh. If they all keep pretending to generate at 10 kwh, the clients will not be any the wiser. Everyone's profit will go up because clients are still paying the bills thinking electricity is being consumed at 10 kwh/ENC.

If the 5 kwh minters attack each other in a battle over the pie, yes they will drive the price down to 1 ENC = 5 kwh and all the mint lose the majority of their profits.

This is called the "prisoner's dilemma" problem.


I tried to explain it once more above. If you still can't get it. I can't explain it any clearer. Maybe I can explain it louder?

I acknowledged security/continuity/dependability are perfect. Nothing left to talk about. Just monetary policy.


I can't explain it any clearer. But the other guy didn't have a problem understanding.

Let me see if I've got this:
1) 51% agrees to mint at 5kwh using regular hardware - wait this doesn't work because people minting at 10kwh make double the coins - if they do it in an attempt to lower the difficulty, people minting at 10kwh make more than double the coins
2) 51% agrees to mint with super secret hardware that is doubly efficient that only 51% of the people know about - wait this is relying on something to exist that doesn't exist and that only select individuals will know about it - and the changing of the algorithms (not the difficulty) was proposed to help prevent this
3) what 51% has to do with either of these scenarios is beyond me, but it has something to do with consensus which doesn't affect coin generation or difficulty of coin generation so I dunno. apparently this group of secret individuals will get together to undermine the value of a coin to somehow make a profit while denying the 49% their mint blocks to achieve something, I'm not sure what that something is, but it's something - apparently getting the couple hundred coins they mined to market first so that the 1 or 2 microcents they might devalue a coin in this time isn't realized before they sell

Do you see why I'm the one who should be baffled?


No, FNs need to generate one block per day to gain reputation. And the only time this "time lock" could legitimately come into play would be for anything that came within a few seconds of the consensus time. I don't know what waiting til the next consensus period will do to a block that awards 6 coins. It *might* just crash the economy.


"fairly" in quotes because it means "spreading the wealth" which translates to "I don't understand the purpose of the reputation system and how it is critical to preventing attacks on the consensus even though you have repeatedly bashed me over the head with it -- I would rather have it as 1 IP 1 vote because that is fair and isn't exploitable at all. Or if it is, we'll just let 'people' worry about fixing it every time something goes wrong."
"If I can pretend that a FN with 180 RP wants to risk extra money given by virtue of that 180 RP by denying minting blocks that occur within seconds of the PB until the next day--I CAN MAKE AN EXTRA .02 CENTS PER COIN ON MY 12 COINS! HAHA! MAD GENIUS!"


"if I pretend he never said that clients won't agree with anything that changes the structure of the monetary system [which most certainly includes difficulty] I can pretend 51% can vote for 5kwh in secret instead of 10kwh. HAHA! MAD GENIUS! NEXT--double the coins!!"


You have failed time and time again to acknowledge that the two are interrelated. You fail to acknowledge that "charlie" in your scenario will become the only one who is profitable, which means everyone else dies out, which means he can set the difficulty wherever he wants which means he can continually put coins into the market for zero cost. But that's ok for you because it doesn't use electricity. Because for whatever reason, the whole basis of my proposal on using something concrete as a foundation for price stability can be counteracted by using "arbitragers." Perhaps they will be able to arbitrage credit swaps on subprime encoins before you know it.

I'm sorry, I just can't follow your completely "Up" dog random thought processes that don't have explanations or fully conceive of the outcomes anymore. I'm done.

Really. One more time...

If you build *any* bitcoin like tunable proof-of-work implementation using hardware and software.
Then you tune the difficulty so that it requires (WAG) 1,000,000 khashes to solve,
because 1,000,000 khashs on the existing (or average) hardware/software combination burns 10 kwh.

Then I claim, *inevitably* and *undetectably*, that some Charlie will (choose one or more)
- Unroll your loops, there by speeding up your implementation, and finishing 1,000,000 khashes in <10 kwh
- Buy the latest 3 volt pentium, and finish 1,000,000 khashes in <9.8 kwh
- Rewrite your algorithm to run on his cheap ass GPU, and finish 1,000,000 khashes in <9.5 kwh
- Buy a $30 ARM cell phone processor with (Z) hash implemented in hardware, and finish 1,000,000 khashes in <9.3 kwh

You can't argue that something like this isn't going to happen.
I claim that you can't detect,
-who is running the original 10 kwh implementation vs
-who are running <10 kwh implementations.

If you allow, simultaneously created new FNs named "Bill" and "Charlie" to form.
And despite your *drastic* 1/10th restriction limiting each of them to minting (X) coins a day at 1,000,000 khashs. (Because, before they can get the full reward, they both need to prove their worth by continuously generating RP over time thus avoiding Sybil attacks)

And as stated above, since you *cannot* detect Bill nor Charlie's *actual* electrical usage. Then,
if Bill's hardware is 10 kwh/1,000,000 khashes, and
and Charlie's hardware is 9.5 kwh/1,000,000 khashes,
and both sell their (X) newly minted coins for dollars at 1 ENC = 10.1 kwh
Then at 10.1 kwh, Charlie makes six times (6x) the profit in dollars as Bill.

The problem is not that your system isn't working. The monetary policy is working great!
And the better it works, the higher Charlie's advantage is!
If coins sell at 10.01 kwh, Charlie makes (51x) the profit of Bill.
If coins sell at 9.99 kwh, Charlie can claim in the forums that he and Bill are both losing money, but...

Charlie's a hero for sticking it out for the security of the system.
But Bill, the lamer, is dropping out because he's not making money anymore. Greedy bastard!


If you don't think this is a significant difference. Well, off you go then...
And if you don't think this news will get around out-of-band to Charlie's personal human friends. Well, OK then...
And if you don't think Charlie's 6x or 51x more profitable friends could possibly grow to 51% RP. Well then, awesome plan!...

--- Summary For the Thinking Impaired ---

1) You can't detect if a node is generating 1 ENC = 5 kwh.

You can't detect if people are minting at greater efficiency then specified. This turns out to be very significant to each individual's profitability and incentive to continue minting.

4) 10 kwh need not be burned to guarantee 1 ENC = 10 kwh.

But, it is less significant to monetary policy. The ENC value barely deviates from optimal.

2) You can't detect if some human collective has 51% of the RP.

The efficient will drive out the inefficient whether you notice it or not. It's math.

3) Humans can't reach an intelligent consensus if everyone is anonymous.

If Ryan is the last 10 kwh FN, he has little hope of forming a RP based consensus for changing the hashing algorithm. Everyone else will claim that $9.99 to offset their $10 electrical bill is good enough. They'll all willing to sacrifice the additional penny for the security of the system.

If Ryan can't throw in a penny for the security of the system, why are we giving him any RP at all?

I mean that was why the RP system was created! To weed those who care about the system from those greedy bastards only out to make a quick profit! The system is working perfectly and Ryan is whining about a penny! Greedy Bastard!


$1 = 10 kwh
10 ENC = $10.10
Efficiency Advantage = 0.5 kwh
Completive Advantage = 6x

Bill's Profit = $10.10 - $10.00 = $0.10
Charlie's  = $10.10 - $9.50 = $0.60

---

$1 = 10 kwh
10 ENC = $10.01
Efficiency Advantage = 0.5 kwh
Completive Advantage = 51x

Bill's Profit = $10.01 - $10.00 = $0.01
Charlie's  = $10.01 - $9.50 = $0.51

---

$1 = 10 kwh
10 ENC = $9.99
Efficiency Advantage = 0.5 kwh
Completive Advantage = INF

Bill's Profit = $9.99 - $10.00 = ($0.01)
Charlie's  = $9.99 - $9.50 = $0.49



-QED-

Wow, the end is nigh, you actually stayed on one point without straying off to useless side topics that only serve to divert from what you are trying to say.

"- Unroll your loops, there by speeding up your implementation, and finishing 1,000,000 khashes in <10 kwh"
You're going to have to explain what "unrolling your loops" means because I don't get it.

"- Buy the latest 3 volt pentium, and finish 1,000,000 khashes in < 9 kwh"
If Charlie is buying the latest 3 volt pentium to finish @ 9kwh, then Charlie has to account for the cost of that 3 volt pentium which won't be paid back for months on end. In the mean time, everyone else has a chance to catch up and get the same benefit by the sunk cost of purchasing new computer hardware. And by then, the difficulty has adjusted so that now Charlie is not making an extra profit for being ahead of the curve.

"- Rewrite your algorithm to run on his cheap ass CPU, and finishing 1,000,000 khashes in <8 kwh"
Rewrite a cryptographic hashing algorithm in some way that results in the same hash for less cpu cycles? NSA and NIST would be very interested to know about this mad genius--considering they generally have some of the smartest people in the world making sure that this isn't possible.

"- Buy an ARM processor with (X) hash implemented in hardware to run on a cell phone, and finish 1,000,000 khashes in < 6 kwh"
So let me get this... now charlie is putting hundreds of thousands or millions into R&D to get a processor that only he and his 51% friends will have, and they will somehow profit from this? And they will profit before the hashing algorithm randomly changes?

NEW algorithms are added by vote, by the way, to make sure that the network doesn't break compatibility with itself. I don't know how well application-specific hardware handles SHA1(SHA2()) vs SHA2(SHA1()) vs XXX(SHA2(SHA2())), but that is something that could be answered by a cryptography expert during the development process. And those who are NOT voting in new algorithms would be quite obvious, just like a consensus attack.

"Then at 11 kwh Charlie makes 6x the profit in dollars as Bill.
(If the coins sold at 10.1 kwh, Charlie's multiple would be MUCH (60x?) higher.)

If you don't think this is a significant difference. Well, off you go then."

It's not as if I didn't have a section devoted to this in the proposal. FPGAs cost 400-500 dollars. The profit on one coin is probably going to be $.50-$1. FPGAs run very few mhash/s for a slightly higher mhash/J than GPUs. If their FPGA doesn't get the minimum hash value, whoops they don't get paid, so they'd probably need multiple FPGAs. And they would need many, many years just to break even on this hardware that has no use other than to hash. And in the mean time, GPUs or CPUs will get more efficient as well per mhash/J, but the difficulty will compensate for that. So FPGAs might have their utility wiped out as they can't be upgraded to hash faster without sinking more money into a piece of hardware that serves no function other than to try to squeak out an extra few cents per coin.

To top it all off, you're grossly misrepresenting the profit margin. A coin that costs 10kwh to produce isn't selling for 10kwh, it's selling for around 13-15kwh. So while Charlie can focus on sinking thousands of dollars into making an extra 5kwh in profit, he's still only doubling his margin, not 6x or 60x. Unless Charlies take over the network in which case they must compete against themselves and lower the profit margin. So all this effort goes into making a short-term profit on thousands or hundreds of thousands of dollars on investment that will even out and make their profit almost the same as before if they had just used honest hardware. Not very logical, now is it?


edit: you just completely changed your post while I was writing this, I will see if there is anything new worth responding to

I would like to add that I think I have found the perfect solution. My tx fee was always designed around keeping people minting in a stable economy.
But... similar to your idea Red, but requiring much less breaking the foundation of my proposal, have TxFeeFreeNets. Perhaps it requires some minimum of 30 RP earned in MintingNets or whatever, that could be worked out later. But anyone in a TxFeeFreeNet runs at 1/20th or hell maybe even 1/50th, doesn't matter now as long as it's something, and they will get a refund on all tx fees associated with their account instead of a coin payout. That way you know that these accounts are legitimately trying to secure the network, and it doesn't require coins to replace those that are lost, except for very casual users. Any business would want to be in a txfeefreenet as the savings would easily outweigh the costs, and everybody wins!

http://www.nashvillescene.com/imager/quick-hits-motley-crue-twestival-your-band-sucks-etc/b/original/1484192/5bf6/haha-using-internet.jpg

Ah! I supposed you had at least a little background in computer science. Or at least some software engineering experience. I guess not. Loop unrolling is an optimization technique you learn in your sophomore year. But in my example it is a place holder for one of the numerous optimization techniques available to any hacker who isn't completely clueless.
http://en.wikipedia.org/wiki/Loop_unwinding


Now it is you that is being deliberately dense. I said clearly, (and I guess I'll have to link the halting problem too.) (http://en.wikipedia.org/wiki/Halting_problem) it is algorithmically impossible for you to detect this. And by consequence of not being able to detect it, you cannot adjust the difficulty.


I'm not saying you can't do it because you are a stupid fuck. I'm saying in 1936 Alonzo Church and Alen Turing proved that some things are computationally undecidable (http://en.wikipedia.org/wiki/Undecidable_problem)



First off, CPU was a typo. I fixed it to be its intended GPU. But that doesn't change the fact that you are still clueless about cryptography (as you point out in your first section). Optimizations in calculating basic cryptographic functions happen every day. My 10 year old PC calculates the same exact SHA(2) hashes as your speedy new laptop. It just take more time an electricity to do exactly the same work.

Speeding up how fast I can calculate a SHA(2) has no bearing on the cryptographically hard problem of reversing the SHA(2) hash. I'm not going to explain this, nor am I going to bother even giving you a wiki link. It should be obvious to the casual observer.



Closing your eyes doesn't really make the world cease to exist.

Plug Computers (http://en.wikipedia.org/wiki/SheevaPlug) cost less then $99 and run at about 5 watts. Check the block diagram (http://www.marvell.com/application-processors/armada-500/assets/Marvell_Armada510_SoC.pdf) and look for the little block labeled "Cryptographic Engine and Security Accelerator"



Ah, that is what you mean by new algorithm! I've got news for you! SHA2(SHA2(X)) is not a difficult new algorithm. It is running the same SHA2() algorithm twice! It takes exactly twice as long as running it once. If I was 5% faster then you at SHA(X), then I'm 5% faster than you at SHA(SHA(X)). We are both working on the same linear problem. If I have SHA() and SHA() implemented on an ASIC then I already have SHA2(SHA2()), SHA2(SHA1()), SHA1(SHA2()), SHA1(SHA1()) implemented as well. They come for free.

There are a limited number of trusted cryptographic algorithms. All can be done in software. All can be done in hardware. All strive for simplicity and efficiency making hardware acceleration cheap.



I'm not going to bother responding to this section, since above I've already done so above. If by this point in my post, if you don't realize your crypto presumptions are so far off as to make this logic nonsense, I can't help you. 



If your coins are selling for 13-15kwh then write in your thesis, "Clients are intended to buy coins for 13-15kwh but FNPeers are intended to buy/mint them for 10kwh." All that 10kwh=1ENC sounds like bunk now. And it is clear that you see this as a government cost+award_fee situation. But even on government contracts, the contractor only gets an 8% return on the Government's investment. Here you want clients to pay 30-50% award, for their privilege of paying for FNPeer's intentionally inflated electric bills.

Spare me your math about how I don't see that this is insignificant to clients compared to the benefits they receive. Your response is not necessary. I understand how rationalization works.

But even acknowledging your silliness. Let's do the math.

$1 = 10 kwh
10 ENC = $15.00
Efficiency Advantage = 5 kwh
Completive Advantage = 2x

Bill's Profit = $15.00 - $10.00 = $5.00
Charlie's  = $15.00 - $5.00 = $10.00

---

$1 = 10 kwh
10 ENC = $12.00
Efficiency Advantage = 5 kwh
Completive Advantage = 3.5x

Bill's Profit = $12.00 - $10.00 = $2.00
Charlie's  = $12.00 - $5.00 = $7.00

---

10/5, 9/4, 8/3, 7/2, 6/1, 5/0
2.00, 2.24, 2.66, 3.5,  6, INF

I mean WTF! You don't think my logic still holds?


You are totally missing the point, Charlie can take over the network and CHOOSE not to reduce his profit margins. All he has to do is keep doing whatever what most profitable when he ran everyone else out of business.

Should Charlie and his friends turn on each other, only then is it mutually assured destruction. Until someone more efficient comes along. Wash, rinse, repeat.

Excellent, you are stating to see the lack of necessity in burning when not necessary! There may be hope for you yet! :)

BTW, Cool image!

No, I was being deliberately dense. Optimizations have already been discovered to improve the efficiency of the same GPU by 10% or so in bitcoin's history. And they were shared with the community. While I suppose it's possible that some awesome hacker could find a great way to optimize and be ahead of the curve, these optimizations cannot continue to improve forever, and you assume that only one person could ever find them. Then only share it with more and more of his friends, which hurts himself as there is competition, and "loose lips sink ships" so they say. The more people that know the more likely it will become public. Oops, patch and now you have no advantage. If it's only kept among a small group, the effect on the economy is negligible. And they can't vote to keep a software patch from hitting everybody else.  :-\


The incentive to have a more efficient processor is to use it, is it not? It is either more efficient and uses the same amount of power--this is dead easy to adjust for as the difficulty will go up as more mhash/s/user are put into the system--or it is the same or more efficient and uses less maximum power--this is a problem I outlined in the proposal which could be mitigated by the mild deflationary measure described in 8-2. If they decide to not run the processor at 100% to save energy and have a higher mhash/J, then the same problem happens when everyone upgrades and starts using full power--they make less money. If EVERYONE decided to use less power, then you have an issue. But then again, you always have to worry about greedy people using full power and making more money. So, not really an issue. The halting problem has fuck-all to do with this.


It's SHA2, not SHA(2) broseph. I'm not going to explain this, but it should be obvious to the casual observer. See I can be a nit-picky dick too.



Wait a minute, so you're saying there is specific hardware--that may or may not even meet the minimum hashing requirements--that supports cryptographic functions that are 15 to 20 years old, and it still costs $100 (6 months to recoup first assuming they can even hit the minimums, THEN assuming it provides enough mhash/s to even be average)--and I need to be worried about this completely crashing down the whole system? It's great that your argument revolves around ignoring unsunk costs and inability for these specific machines to perform anywhere near the same magnitudes of hashes/s as a GPU, but perhaps you could provide some specific details as to why this has not overtaken bitcoin, for example? Which does not even have a need for a minimum hash/s, btw.


See, now this is a topic worth discussing. It's amazing when you're mad how much more sense you can make. Instead of babbling off for pages and pages about useless bullshit, we can finally get to the heart of why I wanted to see if this proposal would be feasible or not. Now, by the fact that there have been about 3 or 4 secure hashing algorithms devised per decade in the world of modern computing, do you think it is feasible to stay ahead of the curve of application-specific hardware, including its unsunk costs, for the future?


Coins will sell for whatever the market will bear. Apparently bitcoins have no problem selling for 70 cents over their cost to produce. Coins still require a large time investment. If you want to buy that TV for 1000 encoins, you can either mine for 5 years or buy 1000 encoins off the market. The choice is yours. Once there are enough coins for a stable economy, coins do not need to be produced and in fact would be penalized by the RP system I had devised. I did not claim it was perfect, but it was a starting point. But having to devote your computer to nothing but the search for coins is not a profit-free enterprise. This should be obvious. 10kwh is the STABLE COST TO PRODUCE. Not sell price.


Your logic is based in a conjured up scenario where someone can pay 5kwh (or .01kwh) to produce a coin rather than 10kwh without rationalizing it--other than "hackers efficiensize the code" or "asics do it for low watts" scenarios of which both have happened to bitcoin, neither has caused a crash of the miner economy. Because "hackers" released their code, and "asics" cost too much--when the price isn't inflated by hoarding. Which wouldn't be a problem in encoin because scarcity is not what creates value.

--- Marketing ---

One of the reasons I'm so obsessed with not burning needless CPU power when not absolutely necessary is for marketing reasons.

Bitcoin had a great bootstrapping plan,
1) Appeal to anarchist libertarians who don't trust the fed to keep monetary policy stable.
2) Appeal to those who hate banks because they return low interest, when inflation is low. And return almost no interest while everything is deflating.
3) Appeal to those who hate stock investing because the market was currently crashing.
4) Convince them bitcoin was like investing because it was a deflationary currency and therefore anything bitcoins you stuffed in your mattress today were going to make you rich tomorrow.
5) Start giving out free bitcoins and hope (1,2,3) buy into the (4) logic.

Turns out in retrospect, it was a brilliant plan.

--------

A stable currency has to make a different appeal. I'm not even exactly sure who it appeals to. Certainly it serves exactly the same niche as paypal, visa, mastercard, etc. There is not much to differentiate it if you compete for clients only on price.  

However, the one thing that attracted me to bitcoin was its promise of anonymity. I don't mean its "strong" anonymity. Like, "The police can't catch me while I'm buying drugs!" To me even bitcoin's "weak" anonymity has value.

Especially marketing value!

You are never going to generate mass appeal for a system that claims to let criminals get away with being criminals. I accept that as a given.

However, it may be possible to generate mass appeal for a system that "prevents monitoring" of behaviors that most people are repelled at the thought of having monitored. Say buying controvercial books, porn, visiting strippers, cheating on your spouse, etc. It is for these types of activities that people currently use cash. Cash doesn't have "know your customer" laws like electronic banking/credit does.

There is a growing number of activities being suggested for additional monitoring. For example, buying fast food cheeseburgers. Or french fries, or beer, or cigarettes, or ice cream. A lot of progressive thinkers advocate tracking  these sorts of activities and reporting behavior patters to either the government or private health care plans.

It is very easy for people to imagine the government telling MasterCard to turn over everyone's purchase records to the Obamacare administrators. Or to tell Google to turn over everyone's search records. That way people can be targeted for specific "education" about the dangers of these behaviors.

I think it is these people to which EnCoin could appeal.

A subgroup of potential early adopters/advocates might be the Freedom Box Foundation (http://www.freedomboxfoundation.org/). They advocate everyone having their own low power home server, specifically to protect their personal privacy. The project is still in its beginnings but they are proposing to use 5W plug computers like I linked previously.

These boxes will tunnel browsing over TOR. Host personal mail servers. Share personal files. Enable other folks to jump firewalls. etc. In general, the set of all plug boxes reinvents the cloud computing concept, except people own their own parts of the cloud. Their philosophy is very complementary your intentions for EnCoin.

However, I'm guessing they would be much more interested in running non-minting Peers. They already don't mind buying and running their own cheap server to participate in shared cause (like TOR). But they would be opposed to *literally* overheating their plug servers to prove their dedication. Or to burn so much CPU power that the other "Freedom Box" features wouldn't function as intended.

I put myself in this class of possible EnCoin users. I don't mind telling my server to help EnCoin with bandwidth and transaction monitoring. But, if it slowed down my browsing, email, or required me to add a fan to the plug. Poof, the EnCoin process would be gone. Minting profits are not part of my personal value calculation. I wouldn't waste the CPU cycles stressing the server, even if the electricity was guaranteed to be offset by minting awards.

But that is just me.

Do you have any thoughts on bootstrap marketing?

I never said I had a problem with non-minting peers. I said I had a problem with non-peering minters. I think non-minting peers can easily be solved without worrying about any effect it might have on minting peers. If the data load is too much, minting peers could start charging a small fee, for example. In bitcoin, you don't have a choice. If you want anonymity, you need the whole shebang.

As far as marketing goes, there is a sizable number of people that believe bitcoin is bullshit, those could be the starting user base. Getting demand up to 10kwh+ sell prices would be difficult and would take time, but I don't think it would be impossible. Since there is no threat of the early coin collapse, perhaps the drug trade would take to it over bitcoin. I don't know. Once coins get stable, everyone powers down and waits until the market expands. Without the required tx fee, businesses have an even bigger advantage to use encoins over something else. I'm glad I was able to figure out a happy medium there. I didn't want to take their money away, but I had not yet thought of an idea to do it while protecting the consensus. Now the new way seems that it will actually improve the consensus. A boon for everybody.

And to grab some other bitcoiners, it could award bitcoins and encoins by the merged-mining process during bootstrap. But miners don't make the economy. They do, however, spread the word.

No. That was why I said Computationally Undecidable. That is the point I and (John?) and others have posted from the beginning.



This is the closest of your examples to what I wrote. However you use the work efficiency to mean how many khashes/sec I use efficiency to mean how many kwh/khash.

The way I understand your minting process, each FN works in collaboration to solve a single minting proof-of-work. Exactly analogous to a bitcoin mining pool. I also understand (but could be wrong) that each FN submits only one minting transaction per Primary Block. I'm under the understanding that this has to be done under a time constraint that, at maximum, starts at one PB and ends at the completion of the subsequent PB.

You scale the difficulty of this proof-of-work (I think) based upon time in a similar manner to how bitcoin does. Meaning, in bitcoin's sense, one POW solution per (all miners) per 10 minutes. If on average (all miners) produce a solution faster than one every 10 minutes the difficult is made harder. Slower the difficulty is made easier.

Your system seems to replace (all miners) with (FreeNet). You allow each FreeNet to produce one solution per fixed-length period. You completely remove the competition between FreeNets. In bitcoin, the competition is the incentive used to keep miners honest about their solution timing. That timing is what makes it possible to adjust the difficulty.

In your system, you can't tell the differences between a FN that took 99% of the period to complete their solution. And one that took 5% of the period to complete the solution and idled their electrical consumption for 94% of the time. Then lied to you about running full blast for 99% of the period.

If you tell me, I'm wrong and each team can submit as many blocks as they want during a period. It really doesn't change the problem. You can scale to any average of completed blocks per period you choose. The faster system can always lie.

If you can't tell the difference between the truth and a lie, you can't make compensation. That is where the halting problem comes in. Specifically, since there is no algorithm that can tell if an arbitrary SHA2() implementation will complete ("halt") for any given input. There is no algorithm that can tell if it will complete in a certain number of instructions or clock time.

In this particular problem, "lying cooperatively" has a greater long term monetary benefit than, "honestly competing" for higher initial gains. That is why it is called the prisoner's dilemma (http://en.wikipedia.org/wiki/Prisoner's_dilemma). If the same scenario is repeated over and over, it is called the iterated prisoner's dilemma. In its iterated version, it is used to evaluate competing algorithms for maximizing long term gain. Exactly as EnCoin is doing.



Closing your eyes and pretending that people are not trying to optimize things for reasons other than your network, doesn't make it so.

Technology will improve. Improvements will be obvious to some. Not to others. That is how knightmb got 710,000 bitcoins for a trivial investment. I'm not saying he destabilized the network. I'm saying he profited handsomely without even trying to destabilize the network. And he did it secretly, right in front of everyone while posting daily in the forums.



Really the exchange price is what all clients are going to care about. When I said stable I meant outside of extreme circumstances like Amazon adopting ENC, of Silk Road getting busted. On a day to day basis, ENC prices should vary between say 9.9 kwh and 10.1 kwh. (2%) At worst maybe 5-10%. But you are saying 15kwh which means that maybe it falls to 5kwh? That is a 100% variation. Doesn't seem that stable if I'm a client. I'm definitely going to try market timing with those swings.



I'm saying even an accidental +-5% variance among clients is going to mean the more electrically efficient, chase out the less electrically efficient. Most people won't even recognize why. It won't crash the client economy. It will make the minter community's breath smaller than you anticipate. I've said from the beginning I don't care about this. I don't care if there is only a single minter. So long as client facing ENC prices stay stable.

You, however, suggest this will effect EnCoin's long term viability. If so, that's a design flaw. First fix the flaw, then make if fair to minters again. That's all I'm saying.

I plan on becoming a client, not a minter. I might even run a peer to keep everything flowing. But I'm not tolerating CPU fan noise just to feel good about myself. That was why I shut down bitcoin.

I'm absolutely sure plug computers could handle all the non-minting tasks without breaking a sweat. That is a lot of network support if the Freedom Box project makes. (A huge if!)


I looked for this in the proposal, but I didn't immediately find an implementation. I don't see how it can be done cryptographically. In bitcoin the proof-of-work must be derived from the bitcoin block. In Encoin it must be derived from the Encoin transaction block (?). Two different hash values can't be calculated simultaneously.

What am I missing?

Oh and I saw this in the proposal.

9-3) Blind Signatures; “Mixing” coins

I have a thread on this forum about anonymizing bitcoin that way. It was part of my series on how to fix some of the anonymity flaws.

https://bitcointalk.org/index.php?topic=624.msg6793#msg6793

You have an incorrect understanding. Any FN can make as many blocks per day as they want. In fact, in rev2 and several times throughout the first thread, I showed the formula of 6 hours x 50 peers x 200wh = 60kwh or 6 ENC. The 6 hours and 50 peers were averages. If there are 100 peers in a FN, it should take 3 hours on average.

Let's say 50% of the network runs at 1mh/s (at 50% power) and 50% runs at 2mh/s (at 100%) and there are 1000 people. 500mh+1000mh=1500mh/1000 or 1.5mh/s avg, so encoin thinks 1.5mh/s = 200W. 200kwh, 13.33 coins are awarded to the 2mh/s, and 6.67 coins are awarded to the 1mh/s. 2mh/s gets a 3.33 coin bonus for the same work than if 1mh/s had been going at 2mh/s. Encoin may be mistaken about how much the coins cost to produce, but the 2mh/s people can sell their coins for cheaper thanks to the 1mh/s people because they get more coins for the same work. That's why I had a whole section on why this doesn't matter. Market. Forces. If you want to nitpick that 50% may be able to run 1mh/s at 47% power or 2mh/s at 94% power or whatever, this does not matter because whatever efficiency gain they have was either at a cost, or because of "hackers" that have to try to keep an efficiency gain secret. Newer, more efficient hardware is most decidedly not a secret.

People are not going to just blindly assume that a coin costs 10kwh to produce. They could, with their ghetto 5 year old rig, start making coins and see that they're doing better than that if the network were conspiring to make cheap coins. As more realize this, the coins will go back to costing 200W to produce, and the effort was a failure.


They can, but it benefits everybody, not just them. And the lie won't hold for long when people realize cheap coins are to be had.


Lol a couple of 64-core servers is a secret? He just had easy access where others did not to a highly exploitable system early on. I'm not saying there won't be a similar exploit to encoin, but it is a lot less likely with GPU mining from the start and a lack of 2 week difficulty changes and the fact that he'd have to subsidize his superfast cpu/gpu with the rest of the freenet that he's in.


How does 15kwh mean it could fall to 5kwh? It's 10kwh+ROI. If the economy is bootstrapping or dead, yes it will be below 10kwh.


And all of this is already covered. There are 100% variations in the cost of electricity around the world, this doesn't mean there will be 100% variations in the cost of an ENC. Yes, the value of ENC could very gradually go down if fusion power were invented and rapidly adopted. But market forces will work against this. "I can run at 400W on fusion and still be profitable, so I will." (the sec 8-2 deflation helps against fusion too!) And as the world catches up, the cost to produce goes back to where it was. I might be able to come up with something to prevent mass coin makings in a stable economy. I'll have to think on that.

I can't predict the future, but I know for damn sure it will be a hell of a lot more stable than bitcoin. And there is no threat of early coin sell-off. Or 51% attack disrupting the network permanently. Or childishly simple attacks on the production costs that I must have never thought of when designing this proposal.

I am not the best person to explain this as I could not believe this could be done. But namecoin is already working on it. Anyone mining encoins could add whatever data is necessary to their own hash to ensure it is valid for a bitcoin hash. Bitcoin is very forgiving about what you use. And encoin would just need to allow for it as well. A simple extra spot in the GUI to enable it and provide the pool info on where to send it.


I didn't read the thread yet, but AFAIK it is not possible for bitcoin to handle this by itself, it has to be done through a 3rd party, which sort of invalidates the point.

BTW, a solution to the whole network conspiring to lower the cost to produce is to never decrease the difficulty. I had thought this up months ago in the first revision of the proposal that never got released. I didn't include it in later proposals because I was worried about pools screwing everything up. But there are ways to counter that too. So never decrease difficulty, as long as at some point people were honestly mining, it could never be later abused.

And another way to thwart ASICs and FPGAs and the like is to add some memory usage to the algorithms. They don't always have to be a straight SHA or WHIRLPOOL or whatever. It would be more annoying to use the software, but it would pretty much prevent application-specific hardware from going anywhere.

SO are you doing it the CPU only way ? Nice.

I'm really trying to understand your math, but not trying to criticize. The math tends to go backwards and forwards at the same time.

OK, by definition: 50 peers burning the standard 200w each should generate 1 ENC per hour.


I understand the 2 to 1 ratio. But I have no idea why you awarded 20 coins.
1000 peers / 20 coins = 50 peers/coin
Because 1000 peers were around for 1 hour you split up 20 coins?

My bigger question is how do you know 50% were running at 1mh/s and 50% at 2mh/s. I assume this has to be deduced from how many blocks were generated and each block's difficulty level

I'm assuming at primary block time, you could see
24 blocks at an average of (X) mh    and
24 blocks at an average (X/2) mh
over one 24h period

That gives you 1 block/hour
2mh/s * 60s/hour = 120mh/hour

so 12 blocks took an average of 120mh to find
and 12 took an average of 60mh to find

difficulty-1 = log2(120m)
difficulty-2 = log2(60m)

So your difficulty level was about 28 leading zeros.

Which brings up another puzzling thing for me. You define a proof-of-work similar to bitcoin. It's difficult can only change in powers of 2. That makes your 1/10 difficulty and 1/5 difficult to grasp.

The secret was he rented an Amazon farm of servers for a few months. Wrote custom code. Took every coin when it was easy and cheep. Tried not to run up his own difficulty. And did it without mentioning anything to others. By the time he posted the image he was done. The basic lesson is, keep your mouth shut! ;)


Ah, now I see the issue You think ROI is a cause, not an effect!

You are thinking people will mint around 10kwh but you plan to try and stabilize the market around 14kwh? Did you mean it would vary between 13kwh and 15kwh? Unless something catastrophic happens?

Sorry for skipping an oh-so-important step of multiplying by 1 hour. I thought this could be deduced.


Where did I mention anything about there being different difficulty levels? I am assuming half of the peers, as you try to argue, would be trying to subvert the 10kwh figure. If they were running at 1/2 difficulty or some such, then this example really wouldn't make sense, now would it? Or are we just trying to conflate and confuse instead of accepting that we are wrong?


So puzzling. Reminds me of grasping at something else. Can't think of what though.

Whatever makes you happy.


I don't plan on stabilizing dick squat. I make the cost to produce 10kwh and the market can figure it out from there. I doubt people will be paying 10kwh and tying up their computer for months at a time to make pennies per coin. But that's just me. I was just pointing out that in your real world scenario where you kept bringing up the sell price, that it is not going to be 10 or 10.1 kwh. I assumed a 33% ROI would be reasonable since the cost is high (can't play video games, occasional aero lags, for months at a time), and the payout is very low--15 ENC a month for an average machine.

Oh, I really thought you were trying to say something insightful. None of my example said anything about running at 50% of the hash rate. That is some random fantasy you made up.

I'm saying that a 190W (2mh/s) machine is going to be significant. And I'm saying that a 200W (3mh/s) machine saves a full third. A 400W (16mh/s) GPU machine saves 3/4s, even if the 400W number looks bigger.

Each block at a single difficulty level takes on average 2^(D-1) hashes to find. Where D is the number of leading zeros. This has nothing to do with (/second). The block doesn't care if you do it in one second or one hour. If all of my peers are averaging 1 block/day. Then if I can average the same block faster, I have hours to save electricity by loafing. There is nothing anyone can do about that.

You seem to think you can average everything out and each peer's individual variance doesn't matter. Woot! Ignore it! Tell everyone it won't matter! Yell it to the world!

I promise to keep my mouth shut. I'll do the same hashes as my peers. Get paid same ENC as my peers. And win, because my costs are lower. I will command the marketplace. I'll cash out faster because I can take the existing "highest bid", but still end up with a higher ROI then those waiting for a "lowest ask" that will never come.

Woot! Trust me! You'll never know the difference. This is the last thing I'll ever say on the subject. I may even go back and delete any mention of it from this thread. Knight will be so proud!

So we're back to the hardware that doesn't exist again. k

gl commanding the marketplace with 20 enc a month instead of 15 or 15 for the cost of 12. you'll make millions

Anyway, good luck with it. I'm pulling for you to make it work. By the way, what does the "En" in EnCoin stand for?

I do appreciate you pulling me back here to talk about something that is not austrian economics, the wonders of the gold standard, or how hoarding bitcoins is just like buying stock in a new company! That used to be really tedious.

It was nice to hear someone else is a fan of stable digital money. Really, a year ago you could get shouted off the site just for mentioning it. It is a bit sad to see that you are not getting more interest.

Probably has to do with 3 pages of runaround arguments that are already covered in the proposal.

And En, predictably, stands for energy.

Very complex design. Does not achieve the stated goal of making one ENC require 10KWh - nor could any cryptocurrency. Does not achieve the revised goal of making 1ENC require 50 hours of computation from an "average" computer. No code available.

Even if achievable, the goal of pegging currency to electricity is a bad idea from a macroeconomic point of view. Electricity price hikes choke the money supply increase clamping economic growth. Electricity gluts create inflation.

Sorry, but this design is a nonstarter.

That is the part I, and everyone else, have been trying to explain to him. That exercise is futile.



These effects are true, but they turn out to be temporary in the sense that the price will re-stabilize. It will not tend toward zero or infinity. It will simply pick a new level and continue from there.

The thing that made that side effect less abhorrent to me was the relationship of the price of electricity to the outside economy as a whole. Electricity is a government regulated commodity.

If there is a "glut" of electricity then the "fuel charge" part of your electric bill tends to go down. However, random fees and transmission line maintenance costs tend to rise. As with water, it doesn't matter how much conservation everyone decides to do. The gross monthly billing to consumers is never allowed to fall so far that it bankrupts the utility.

Conversely, electricity tend to rise in proportion to general inflation. If your electric bill goes up, the price of bread is up, and *hopefully* your salary will rise to match. (I know salaries tend to lag. Such is life.)



While I agree with you about this specific proposal. I agree with Etlase2 that stable money would be good. I also think using electricity as a benchmark worth further investigation and discussion.


But naming your currency as if it was an Enron product, seems a silly, silly thing!

There is no stated goal of requiring 10kwh. It was a number chosen that was based on the assumption that the average computer would dedicate about 200W of electricity to making coins. Competition and market factors would determine the final price.
Bitcoin does quite well at achieving an average award of 50 btc every 10 minutes; it is little different from an average computer achieving 1 ENC every 50 hours. Lack of difficulty reduction is a simple answer to anyone trying to game the system.
And thanks for pointing out that no code is available.


Did you forget that there is an entire planet out there?


Baited question after baited question seems like you possess the mentality of a 12 year old! And the argumentation skills to boot! So quick to attack, yet so very few ideas. I wonder if it's jealousy.

Wasn't a baited question. I'd never given it two seconds thought.

It was a witty retort to your smug reply.

As for ideas. I defend your good ones. I defend no one's stupid ones. I don't mind starting another thread to actually discuss principles leading to a stable currency. Perhaps, someone who didn't reply to every question with, "It's obliquely referenced in my 28 pages of incoherent blathering about minting reform." would foster some discussion.

This would be fantastic. Staying on one topic at a time would be an added boon. Makes it a little easier to follow which of the 4 different purported attacks we are discussing, and a bit less easy to claim one meant a different one when I have an answer. Just sayin'.

Before I start a new thread however (with rev3.1 that addresses the issue of this thread), I want to figure out a way to do the freenet reputation differently.

As I had it, users would gain reputation with the freenet, and freenets would require a minimum user reputation based on its own reputation. This has a few flaws. Users could be "grandfathered" in to a higher FN reputation bracket for one, giving them an unequal weight in the consensus.

I thought maybe a FN's rep could be the aggregate of its users, but this has flaws as well. As users come and go, broadcasts would have to be sent to adjust the network's opinion of that freenet. Could get spammy if there are a lot of users. Although having a minimum of 30 RP or so to be considered part of the consensus is one option to mitigate that. Additionally, it would be difficult to judge if >50% of the reputation has confirmed a transaction. If a lot of high RP people are missing (assuming we go by total rep of the network, whether present or not), >50% reputation confirmations would be impossible.

So I'm kind of thinking of network-managed freenets (this would also apply to the "mercnets" or whatever the merchant-based ones would be called). Say there are RP level networks in the range of 0-29, 30-59, 60-119, something like that (each one in each range is weighted equally). Whenever a 'net hits a certain number of users, it will force a split into two. Say at 80 users, it splits into two 40 user nets. If a 'net drops below a certain number of users, say 15, then the net's reputation is no longer weighed in the consensus (users could set the option to automatically join another 'net if this happens). This means no confirming of transactions, and probably no minting blocks either. Every 10 minutes or so, each member of a 'net would have to sign a transaction block so that other 'nets can be sure no funny business is going on.

New 'nets that are created from a split won't have reputation weight until after the next PB so that current 'nets always know how much reputation is required to confirm a transaction in a given PB. They will be able to mint blocks though.
'Nets that die and effectively disappear would still be required for consensus so that intentional or unintentional network splits have no bearing on whether or not a transaction gets confirmed. At the next PB, 'nets that don't show up will be "set aside" for a certain period of time, say a few PBs or so, so that if they do return, whatever happened between the two networks can later be reconciled--but in the mean time, they are not required for consensus. They will begin confirming transactions under the new setup (perhaps they wait 1 PB?), but with a warning to users that a massive split has occurred and details on why this might have happened.

Splitting a network would be controlled by a pre-determined, random function so that it could not be subverted. Anyone not conforming to this function gets reported.

What do you think?

IMHO instead of thinking about it all day long JUST DO IT so it can compete with SC2, Tenebrix and Fairbrix etc. as a cpu only coin etc. please  ;)

Clearly, I don't feel qualified to really come to terms with most of those details. But I can offer what (I think) are insights.

I always visualized your reputation idea as two layered. You have FreeNets which gain reputation as a whole. And you have individuals, who are ranked (for lack of a better term) by their FreeNet Peers. To make a lame example, I may be a "made man" in the Italian Mob. But if I quit and go to the Russian Mob, my rank doesn't necessarily travel with me.

I assumed in between when someone asked to become part of a FreeNet and when they were accepted into the FreeNet there was some sort of vote based on the existing FN Peers. I guess I'm suggesting that when you apply to be a member of a FreeNet. That the application contains an "rank" that you are applying for. If members don't think you are proven enough for that rank, they reject you.

To make an example, I might say "Yo! I'm currently ranked 100% in Fred's (90 RP 3 block/day) FreeNet. I'll quit Fred, if you let me join Ryan's (180 RP 4 block/day) FreeNet at 75% rank. That way, I don't have to start from the bottom again.

I was presuming, the FreeNet reputation dictated the total number of coins the FN could generate in a block. And the intraNet rank somehow affected how those coins were split among members.

Continuing on a slightly different point.

-----

FreeNet reputation seems intended to be a measure of a network's combined Reliability over time. In my mind, I define that Reliability as made up of two parts Availability and Accuracy.

Availability means at least one of the FreeNet's peers must be online to receive transactions, validate them, and to batch and send those transactions around. The goal for the FreeNet is 100% availability.

Accuracy means every transaction must be validated and confirmed exactly according to the crypto and accounting rules. Each FreeNet is required to be 100% accurate. If even one invalid transaction is confirmed, action must be taken.

So if a FreeNet is 100% available and 100% accurate for some period of time, they reach a max Reputation. I know you had said validation/confirmation errors would really hammer a FreeNet's reputation. I began wondering if it should be a death penalty. That seemed overkill at the FN level.

---

When I thought about these two concepts at the peer level I noticed a difference. Each peer must still be 100% accurate. But each peer is not required to be 100% available. Also, minting effort seems to be more important intraFN than between networks.

So if a peer solves minting blocks he might increase in rank. If a FN member peer is not 100% available he might lose rank. But if a FN member peer is not 100% accurate, the FreeNet either has to kick him out, or shut down. No other FN should trust a net that is even partially non-compliant.

If a guy is shopping for a new FreeNet, I'd want to know if he got kicked out of his previous one!

---

You seem to be seeing network membership as more flowing and flexible then me. I'm interested in hearing more about that. But this is the original picture I got in my mind when I read the proposal.

So of course not I realize you are trying to PREVENT people from deliberately building particularly reputable FreeNets. I'm guessing this is to prevent 51% transaction confirmation DOS attacks.

I was never able to identify any other power a 51% majority gave a malicious group. You weren't worried about past posting, and falsifying transactions is still impossible. It doesn't seem to be a minting issue.

If I'm missing an issue, I really am clueless I guess.

But if you are worried about the transaction DOS issue I realized that such an attack is trivial to detect. If you see a valid transaction that doesn't make the next primary block. If that transaction is still valid after PB reconciliation, then it MUST be appear in the next PB or a DOS is happening.

Any way. I hope at least one thing was insightful.

5-2
"Peers gain reputation in a similar manner as FreeNets: firstly, be apart of a FN that creates a block; secondly, the peer must be present and sign the new Primary Block at the time of creation—and a point of reputation is gained. Peer reputation is used as a minimum requirement to join more reputable FreeNets. "


8-3
"While the payout structure itself is TBD, the biggest, fastest hashing machine will not be rewarded as much as they would hope. It will be based on a set percentage given to the final placement of each peer’s best hash value. For example: you could throw the biggest super computer in the world in a FreeNet, but if the winning hash value only gets 20% of the pot, this supercomputer is subsidizing everyone else in that FreeNet.

So this encourages people to simply use their normal, everyday computer for making coins. There is little incentive to build a massive, 4x GPU machine to mint coins faster. It will not benefit you much, and the costs of the hardware may take years to recoup."

I realize there is a lot to take in, but this did have its own sub-section under the section "Energy Equilibrium", something that might sound like required reading before arguing that the system has major flaws. Someone getting 3mh/s for 200W is going to be subsidizing someone getting 2mh/s for 220W, and in the end this cancels out someone getting 2mh/s for 180W.

Anyways, one of the reasons I want to randomize freenets more is so that there can't be a freenet of just 190W people or one supercomputer and a bunch of duds. You can't know who you're up against, so you don't have data to manipulate the system.


Which is somewhat why I want to switch to this system. The freenet rep no longer has any bearing except minimum user rep to join. If a user does something irrationally bad, they get like -1000 rep and whatever coins they have on that account. -1000 rep so they can't join other networks with the same wallet. Not that it matters since they can just use a new wallet, but perhaps an IP address can be added to that list. And -1000 so that it can eventually go back to 0 so that it doesn't stay on the list forever and waste bandwidth.

Also, in the revised design, I'm planning on having it so that only one user signs anything for a set period of time (I'm thinking 3 hours) with a private key only they know. Which user is determined randomly each time so that there could not be collusion between freenets to try to sign an invalid transaction. If he tries to sign something the freenet doesn't agree on, they immediately notify the rest of the network. If he is disconnected for more than say, 2 minutes, he'll lose some rep as the FN needs to get a new member to be the signer and notify the other networks.

I'm also thinking the MerchNets will hide behind the freenets (I'm calling them corenets in the next proposal per your suggestion). As in, their IPs won't be publicly available. In the future, in a stable economy, merchnets should dominate the reputation. If most of their IPs are not casually available, it should be a lot more difficult to successfully DoS the network.


They could change whatever they wanted in the PB. Clients not connected to the network at the time wouldn't know. It's a very unlikely possibility, but if it did happen, there had to be a way to stop it. Having randomized freenets makes it an even more impossible situation. the "signer" could be evil, but all that will accomplish is wasting time to consensus.

For the MerchNets, I'm pretty sure they are going to gain rep based on how much in tx fees their account receives (and amount of time in a merchnet). The higher up in merchnet, the greater a % of the transaction fees refunded, but the more minimum amount is required to be in your account. Thus, do evil, lose account balance. muahahaha. Plus it creates demand by forcing merchants to save some money in ENC. Brilliant! imho

One problem I see though is merchants might not like users being able to see their account balances. I suppose the ability need not be added to the client software, but it would be easy to hack it in.
Do you think they will care? I suppose this applies to everybody.

OK, you are going to have to acknowledge that the version I started with stressed at the beginning at some human paid to start a TrustNet. Got the privilege of naming the TrustNet. And could invite his (presumably Trusted) friends et. al. to join his new TrustNet.

In that scenario, it doesn't make a lick of sense to say, Hey Bill let me tell you about EnCoin... Fire up a peer, join someone else's shitty TrustNet until you build up enough Trust to join my TrustNet, then maybe I'll Trust you enough to let you in.

Really, when I read it, I figured it was a caveat to keep the rabble out of the Network you had paid money to start and were busy investing money in building.



OK, I did read "best hash value" as something figuring into the ranking. But ranking hashes didn't make a lick of sense. I presumed you wanted to do some sort of non-linear distribution (value only gets 20%) based upon each peer's Trust (Reputation/Placement/Rank).

You appear to have been serious about what I called non-sense. So let's discuss it. How could you possibly rank random numbers over time? If I have a supercomputer and I generated one block. You have a busted old 386 and you generate one block. Then the hashes of these blocks have are randomly distributed across the difficulty range. You can rank the blocks based on this randomness and say the 386 wins this time. But the overall distribution is still 50-50 as we repeat this exercise.

The goal here seems to be to keep the supercomputer from gaining a minting advantage. So just say all member of the group participating in the PB get an equal share.  Maybe you mean minting members. I'm not sure sure. But that's not important. If the distribution isn't equal, and it isn't based on RP, what is it based on?



I don't know if you meant that as a light tease, but I'm going to take it that way. Then I'm going to work some math to show you are wrong.

Say you are at a difficulty level with 31 leading zeros. That means you have a 50% chance of generating a block in 2^30 hash tries. Sure someone could generate the block on their 1st try or it might take all the way to the 2^31st try. But it averages out to 2^30 Hashes. Note: a block's units are hashes, not hashes/second.

So if m=2^20 then,
1mh/s will take 2^10 seconds (on average) to complete a block. 17 minutes, 0.28 hour.
2mh/s will take half the time, 8.5 minutes, 0.14 hour.
3mh/s will take one third the time, 5.66 minutes, 0.09 hour.

3mh/s for 200W * 0.09 hour = 18.0 Wh/block
2mh/s for 220W * 0.14 hour = 30.8 Wh/block
2mh/s for 180W * 0.14 hour = 25.2 Wh/block

If each of the peers (on average) gets an equal share for doing equal work. Then the most efficient in electrical cost (Wh/block) Wins! Again, electrical efficiency has nothing to do with (h/s).


This seem to acknowledge you recognize what I'm saying as true. But you are ACTIVELY trying to make the more electrically efficient subsidize the less electrically efficient.

It can't be done.

All your logic presumes that someone who is generating a block every 5.66 minutes will, WILLINGLY do more work than those generating a block every 8.5 minutes. This is a bad presumption. Each peer has access to the historical record. Each knows the exact the results of his fellow peer's productivity. If an efficient peer endeavors only to be average in blocks, he wins in DOLLARS!

There is a whole famous book (http://www.amazon.com/Atlas-Shrugged-Ayn-Rand/dp/0451191145) about why your philosophy is a bad idea. Give it a quick read. It's awesome!

I couldn't agree more with your re-definition of "private key". The section that said distribute the group's private key was a crypto mistake. In crypto a private key really means one and only one person. Once you give it to someone else, it is no longer serves its crypto function.

That said, I was under the impression that everything else in the PB was both deterministic and validated by every other group. (In the same way that transaction confirmations are.)

FreeNet Block minting allocation rules are based upon the previous PB so other groups should be able to detect invalid transactions. Since they are signed by a particular malicious peer, he should get the death penalty network wide.

Reputation Block seems to be deterministic. Did the peer vote "present" during the PB. This is presumably signed so it can't be forged.

Miscellaneous Block seems deterministic as well. If there were module change majority votes. I'm assuming the votes would be signed to prevent forgery.

That just means you need a way to prevent one person or even a 51 majority from prematurely ending the PB reconciliation before everyone gets to submit their sets of data to the Network wide union.

This is again what I was referring to as the problem of controlling time.

I was just pointing out that the individual peer rep is what was required to join a net. Since the nets weren't network-managed, I needed some way to get people to make new ones. Again, it's a proposal, not a white paper.


It isn't over time, it's per motherfricken block. Each net works to make as many blocks as it can, just like they would in a bitcoin pool. But instead of breaking it up into smaller proofs of work, freenets can simply use a fixed header (we're not securing a block chain!) with each member starting with a random nonce. Whenever someone finds a valid target, the block containing the value and payouts is created based on the best hash value for each member in the freenet. If it were a share system, the supercomputer will dominate time and time again. With a payout structure, the maximum value per block is set. You can't get paid more by going faster without also paying more to each member of the freenet.

edit: the header will probably be based on each user's public key so that this can't be cheated. Either way the target is still the same.


If everyone had the exact same mhash/s and one guy is 40W more efficient than average, he makes a whopping $3.45 additional profit over the course of a month, assuming 12c/kwh. WOW! If he spent $200 on a fancy new GPU that he had no reason to buy other than to be more efficient, he will take 57 months to break even (and even if he bought it for gaming, he can't use it while he's mining!). During that time, everyone who was less efficient than he will probably have upgraded their computers so that now he has no efficiency advantage anymore. If you can get every single person in the network to collude on using less electricity in lieu of hashing power, then the value of ENC would gradually lower over time based on how many ENC already exist. If you can't get every single person in the network to collude then users will see that if they run full blast, they make more money (and everyone else less!), thus bringing up the difficulty over time and requiring everybody else to match or get left behind.


Either clients are required to have every single transaction or they're not (I prefer not). If they're not, the 51% could take advantage of those by giving themselves money from other accounts without those clients being the wiser, if they are only connected to bad nodes. Yes, it's a stupid attack, but I put it up there because of a discussion in IRC that concluded "lol it relies on trust".

This is called an "isolation" attack. Yes, it should be prevented if reasonably plausible, but it is in a completely different class from the rest of the discussion. It fits more in with DNS spoofing, or fishing attacks.

If I can surround a "dumb" client completely I can lie to that client sure. But I still shouldn't be able to man-in-the-middle that client by redirecting his transactions to different accounts. At least not while I'm talking to others.

I think IRC is just making life harder for you. What IRC channel is it by the way?

You are correct, in your edit. It is still the same problem even with different starting conditions.

I guess it doesn't matter what "best hash value" means, since you claim it is equally distributed "per motherfricken block".

You claim the supercomputer would dominate because it did more hashes than the other machines over the same period of time. To rectify this problem, you want the super computer to do only the same amount of work as the others, or give away its excess effort to the others. We both agree that the super computer wouldn't want to do that.

You claim, therefore, there will be no supercomputers.

I claim, if the supercomputer is more efficient in hashes/W, it will simply just do the average hash rate for multiple networks simultaneously. Thus avoiding your penalty. I could run a hundred nodes on 5W plug computers doing all the network stuff. Then have each plug outsource the hashing to one supercomputer in China that works cheap.

You can't detect this. Nor can you prevent it. Nor as it seems, can you see it.

And you continually ignore unsunk costs. Did I not bold enough stuff for you? Have you no concept that one instantaneous flash of the network is not how it will remain forever?
You can build your 20 rig 5W mini-machines, but it's gonna cost you 2 grand. That 2 grand is as effectively put into the market as every watt of electricity. And in the years of you paying off those unsunk costs, standard computer hardware will become more efficient than it was, and you will eventually no longer see any return whatsoever as your fixed mhash/s is dwarfed.

If a significant number of peers are colluding to lower the cost-to-produce, the other peers still working benefit as well (and by more as I showed in the 1mh/s vs 2mh/s example). This will encourage even more people to start minting coins at full blast because there is a profit to be had. No higher power halting-solved computer intervention is required. And no lowering the difficulty means that this problem could only occur over a significant time frame or from the beginning of the network. And if it happened from the beginning of the network, competition will make sure that the market value is what it should be (and if it's not, more people will mine!).

I can only believe you are being intentionally dense now and only selectively quoting what suits you. That, or you have absolutely no sense of economics.

I deliberately ignore them because they have no bearing on any of my mathematical arguments. I could just have as easily said, talk 20 outdated old PC I got for free, and outsourced the hashing. Or created a botnet and outsourced the hashing.

You're answer is always, "Yeah, but everyone's going to notice. Then they'll all start doing it too! Inflation will start. Everyone will decide inflation is bad, so will will agree to increase the difficulty. So there!"


I clearly demonstrated how they are not REQUIRED to "benefit others as well." You did not refute my point.


Again, you just said, "Of course everyone will take the path that's least profitable to themselves. How could they not want to maximize their momentary gains while sabotaging their long term profitability?"


But what you fail to acknowledge is you've just run all the machines off the network that you designed the network for. Now you have a network of people who understand the benefit of minimizing hashes/watt. All secretly competing to minimize their hashes/watt cost.

That was what I have tried to explain from the beginning. You simply cannot algorithmically force the efficient to subsidize the inefficient. That has to be done at the point of a gun.



You took the word right out of my mouth! If you wouldn't mind, why don't you invite some of your IRC friends here to critique my density!

----

I know you addressed the FreeNet Sybil problem by adding a fee to create FNs. I'm assuming you've already solved the Peer Sybil problem.

I'm sure you already noticed that in the grand scheme of things, it is trivial for one computer to serve as a FN Peer to multiple FreeNets simultaneously. Most of the work is completely redundant. If I'm receiving transactions, validating them, and signing them with one FN key. Then it is no more bother to sign the blocks as a representative of 10 different FNs. The additional broadcasting is really not a barrier with today's bandwidth.

The only thing that can't be done simultaneously is hashing at 100% cpu power for each network. However, I've clearly shown that is not required.

I could take my one already efficient machine (or plug plus an outsourced hashing rig) and create 10 virtual machines. Each would hash at 2mh/s and claim to running at 220W (or whatever the minimum requirement). Then I would be the someone in your, "subsidizing someone getting 2mh/s for 220W" example. But Woot! I would be getting whatever subsidy you are proposing ten times over!

---

What if I did that with my 10 plug computers creating 1,000 virtual peers for $1,000 and then outsourced hashing to one of those big bitcoin rigs looking for a little steady revenue. I'd fake being 1,000 slow peers and take the subsidies you propose from the others greedy supercomputers.

Then if word got out, people would compete with me by faking having the most slow inefficient boxes! How perverse! We'd be 3 guys with 30 plugs, simulating 3000 crappy peers taking subsidies from 3000 slightly above average peers. All while paying off one high-end bitcoin GPU rig to do as little hashing for us as we could get away with.

No, you deliberately ignore them because they clash in the face of your argument. Your magical, 100% more efficient hardware is simply free! And nobody else knows about it! And 20 outdated PCs are somehow cheaper to run than 1 modern PC! I guess?!?!

Here's a link: https://en.bitcoin.it/wiki/Mining_hardware_comparison

Notice how the more efficient hardware gets significantly less mhash/$? :GASP: Who'd have thunk it? Oh, maybe me! And that today's 5970 is tomorrow's 5770 and what affect this has!


Difficulty - Known by everybody! For the sake of simplifying, we will say it means "amount of hashes on average it takes to find 1 ENC"!
ENC Sell Price - that would be market price in case this is confusing. Determined by competition (supply) and demand!

Then We Get:

(Difficulty / (MHash/s * 3600)) * (kWattage * kWhCost) = Cost To Produce!

Then We Get:

(ENC Sell Price - Cost To Produce!) / (Cost To Produce!) = RETURN ON INVESTMENT

If this number is positive that means it is profitable to mine! It does not matter if an ENC costs 10kwh or 8kwh or 5kwh or 15kwh to produce! The market will figure it OUT!


Computational Unpredictability LOL! How would a new user know that everyone else is only running at half mast? They would only see that they are making twice as many coins! You assume the same flaw in logic that you think I have! Why would they not want as many coins as possible when the price is profitable? Because half the network might be secretly pretending to run a less efficient system?

ROFL


See above!


LOL @ "claiming" & "minimum watt requirement"! "Hey Bravo, this is inefficient system ZQ-Alpha punching in at 220W. Please provide my subsidy!"

Altera EP4CE115C7   80 Mhash/s 18.18 Mhash/J   $299 academic
6950      0.336062 Mhash/s   1.8 Mhash/J  $250

The Altera does 18.18 Mhash/(watt second) = 65,448,000 Mhash/kwh
The 6950   does  1.8 Mhash/(watt second) = 6,480,000 Mhash/kwh

The Altera is 10 times more energy efficient than the 6950. Both cost less than $300
The Altera is 240 times faster than the 6950.

The Altera doesn't have to produce 240 times as many coins as the 6950 thus burning more total dollars.
It can simply produce 10 times more for equal dollars and loaf.
Or it can an equal number of coins for 1/10 the price and loaf.

The Altera has the choice to decide what is the most profitable way to run the 6950 out of business. It just watches the ENC sell price fall until the 6950 quits. That means as you pointed out that:
ENC price = 6950 cost to product
ENC price = (10x) the Altera's cost to produce.

Now at this point, the Altera doesn't have to be a total dumbshit and mint until the coins fall to ENC/10. Or show off and invite everyone else into his game. He just holds the prices steady making maximum profit, while telling everyone else, he's losing money for the good of the network.

Still don't get it?

The whole point of the system is to reach price equilibrium. This is exactly what would happen if every node was a 6950. ENC would reach the exact same price. Lots of people would mint a little and sell them off. Sometimes they'd make money and the ENC price would fall. Sometimes they lose money and the ENC price falls.

The Altera just makes money every time. As a side effect everyone else makes less, without the ability to know they could be doing better. The Altera guy could just be a better market timer than them. He's certainly not doing anything crazy looking.

If they upgrade and mint faster, everyone will upgrade and what good would that be? Just more sunk costs for everyone and no more profit to offset it. Better to stick with Ryan's original plan.

I'm honestly curious how the 6950's 360MHash/s turns into .336. I mean it's only off by a factor of 1000.
So if we use the real numbers, the Altera is 4.5x slower than the 6950.

I'll even give you a bonus and say the 6950 was specifically purchased for 50/50 gaming and mining. So the mining unsunk cost is $125.
$299 if you're a student, sure I'll give that to you, minus $125 = $174 unsunk cost difference.

Since the Altera is 4.5x slower, it will earn 4.5x less coins, on average. If 15 ENC is average and the average card is a 6950, that means it earns 3.33 ENC per month. Fuck it let's just say the Altera is completely free to run, and an ENC is worth $2. 26 months to break even ruffalo (and in the mean time the difficulty is going up as people gradually upgrade their computers, so really we're looking at more like 30-36 months. And since it will probably miss the minimum hash value on occasion, probably 36-38 months.)

Oh did I mention that if the economy goes through a big expansion, the Altera will have 4.5x less coins to try to make a big profit with? A shame, really. (This is called Opportunity Cost - I'd give you a wiki link but I'm sure you can find it.)
Or that in the 3-4 years it takes to break even, the algorithm could change to something else and render it useless? Whether this is a new crypto hash or simply the same hash but with memory/cpu work. The EnCoin design is a shitload more forgiving of changing this. And merchants would be eager to accept any change that keeps the value of their ENC stable.

Or that in the 3-4 years it takes to break even, it might just break. LOL!

I have to admit, I don't even know. Too much cut and paste and bleary eyes. But too many little boxes for me to dig through and find a different example. But it doesn't matter! I don't have to match the 6950 in Mhash/s.

(I don't really remember any of the details for "minimum requirements" to maintain your reputation and assure your spot in the minting pool. But I think it was generate at least one FNBlock a day.)

Say when ENC hits "6950 equilibrium", the 6950 is generating 5 blocks a day and the Altera is generating 1 block a day. Now the (ENC_price - 6950_cost_to_produce) = 0. The 6950's ROI is zero. It has to stop minting or continue at a loss.

This is your intended behavior, nothing more. I'm not making any wild claims.

The Altera on the other hand is still profitable at 1 block a day. It can keep minting. So can all the other Altera equivalents. They are 10x more efficient than the 6950. From this moment on they continue earning a ROI.

If there are enough Altera equivalent peers to hold the price steady, just below the 6950's break even, the 6950 peers are for all intents an purposes dead. They don't have to be 10x more efficient. 2x is probably enough.

teehee, you forget that there need to be 4.5x the alteras as 6950s! Otherwise they can't support the demand. I wonder how many people are going to program circuit boards to make a few extra cents a month?


I believe you are making the wild claim that a $600 machine is free.

I was going to make that point but realized I didn't have to. The Altera is supported by every other GPU that is even a little more energy efficient than the 6950. The chart shows lots of possibilities.

And Altera and company don't have to keep driving the ENC market price down at the velocity the 6950's were driving it down at. They just have to hold it down. Its much easier to drown someone if they're already underwater.

And as you obviously know, all that fee money has to go somewhere. Now it is going to the most efficient where it belongs. The irony is, to bring the 6950s back to profitability, you have to increase the difficulty while the market is stable. This increase is only to drive out electrically efficiency and add overhead. Sounds totally sensible.

I'll admit the previous post was lame. I was a little defensive when I should have read a little further into your post.

Suppose that 6950 equilibrium comes at our long coveted 1 ENC = $1 = 10 kwh
Did you work through the math?

6950 sells coins at $1 with a cost of $1 for a net of 0.
Altera sells coins at $1 with a cost of $0.10 for a net of 90 cents per coin.

Even if the sell price goes up. And the 6950 begins minting 5 coins for each 1 Altera mints. Until the ENC price reaches $1.23, the Altera still generates more proft on its one coin, than the 6950 generates on its 5.


More than you might think!


I'm sure 90 cents on each generated coin will pay back even a $600 machine pretty quick. Much faster than the nickels you keep mentioning.

Those goals are entirely different. Bitcoin achieves 300 coins per hour axiomatically, and it does not attempt to control who gets it. You are trying to guarantee an average computer gets close to one ENC, yet there is no way a computer algorithm can do that. You can only check for the solutions to a hard puzzle that takes about 50 hours to solve on a PC, 100 hours on a laptop and 10 seconds on a botnet. You will never be able to determine algorithmically that the results were submitted by a botnet.
The payout structure you have devised to counter this phenomenon seems arbitrary and stems from a lack of understanding of the sybil attack. If anything please (re)read the conclusions of JR Duoceur's paper on sybil attacks and try to apply it to your system. It seems you are achieving what he claims is impossible, a distributed system that can discriminate against powerful peers and exclude them without using a central identity issuer.

If you drop the whole egalitarian/community BS what you get is a bitcoin-like system with fixed difficulty, in which inflation is proportional to hashing efficiency. Various schemes have been proposed in this board that attempt to counteract the effects of Moore's law, but the general idea is the same, the most efficient miner wins. The best you can do is adopt a scheme similar to scrypt/*brix that should keep ASICs or FPGA at bay for a few years, but you open the door wide to botnets.


Stable prices are a worthy goal. Pegging currency to any one commodity is not a good idea. The greens are in kill-mode against nuclear energy. Germany is shutting down it's reactors. Renewables are too expensive even in this era of cheap oil. Assuming a major energy crisis hits the planet, the effect is high prices of energy, inflation and recession. The Enron-Coin algorithm counteracts by halting monetary expansion, hopelessly pro-cyclical. In such a situation inflation is necessary to enable higher prices to relocate the lost wealth.

If you are declaring that 1ENC=10KWh you are giving an unfair advantage to holders of ENCs, you treat them as if the energy crisis did not happen and they can buy the same amount of goods and services as before. Well, the crisis did happen, and this can only mean the rest of the populace needs to further constrain their consumption to fulfil the needs of the ENC aristocracy.

I also have a visceral dislike for proof of work currency (a.k.a waste of useful resources), but it's very hard to solve that problem with a distributed currency.

Awesome post BubbleBoy! I'm going to jumble the order of some of your quotes so I can clearly delineate where I am in agreement and disagreement with the EnCoin concept.



I totally agree with you. Which is odd, because it clearly I'm saying something that seems very close to the opposite!

The part I'm agreeing with is 1 *coin should *not* be pegged at 10 KWH as EnCoin suggests. Specifically, by requiring each coin to represent burning an average of 10 KWH. I find that impossible for the same reasons you do. What I'm saying is, electricity is the only commodity I've noticed that has even the potential to become a tool for stabilizing *coin prices.

Electricity has one unique characteristic. As Etlase2 points out, we can require someone to purchase at least some energy prior to creating a new *coin. This means the coiner has "skin in the game" prior to creating/selling coins. I don't see any other basket of goods that has these characteristics. I can't force someone to burn wheat in the process of manufacturing a *coin.

The question then shifts to how much electricity do we need to require at this moment? While it is impossible to determine exactly how much any particular person must purchase, fortunately, it is possilble to dictate that they purchase more relatively speaking or less than was required in the previous period. (Changing difficulty)



I totally agree with these statements. Both would be bad and should be avoided.

What I'm proposing is the (coin/kwh) requirement is constantly changing algorithmically based upon market conditions and the demonstrated need for new coins. The price of electicity serves as a limit constraining two non-linear functions. The (coin/$) exchange rate and the (kwh/$) exchange rate.

Again, even that sounds impossible. But, here is the edge.

I'm not suggesting the algorithm dictates when coins must be made. That remains a human decision. Human's make coins when Arbitrage between (coin/$) and (kwh/$) makes it profitable to do so.

In a stable economy with a *coin price at a stable equilibrium, there is ZERO need to create new coins. Therefore, the proposed algorithm must give zero incentive to creating new coins. At this point 1 Coin = X kwh and there is no arbitrage profit. An algorithm CAN monitor the lack of coin creation.

If the economy is increasing (more $ of goods to trade), then the (coin/$) relationship will vary from the (kwh/$) relationship. This creates arbitrage incentive to create new coins. An algorithm CAN monitor demonstrated coin creation.

If the economy is decreasing (less $ of goods to trade), then the (coin/$) relationship will vary from the (kwh/$) relationship. This creates an incentive destroy coins and/or discourage selling coins. I propose a transaction TAX burning coins for this. Again, an algorithm CAN monitor coin destruction.

I proposed the beginnings of an algorithm in a prior thread (https://bitcointalk.org/index.php?topic=44682.msg546418#msg546418). But the gist goes.

If people are minting excess coins, then make it more expensive to mint coins. (increasing economy)
If people are being taxed, then make it cheaper to mint coins. (decreasing economy)
If people want to mint just enough coins to rebate their tax, let them. (stable economy)



I totally agree with you. I'm suggesting competition between arbitragers to monitor the market and keep prices stable. This is the opposite of "Everyone can run minting in the background without thinking about it."



Totally agreed. In this model I want to minimize the number of people who have to burn needless electricity. That is just unnecessary added overhead to the *coin economy. Only arbitragers would need to solve proof-of-work problems. And then, only when they see it as profitable to do so.

--- Note ---

If electricity prices vary dramatically, or even if the economy varies dramatically (Walmart accepts coins), then coin/kwh relationship we move from the previous equilibrium.

The goal for the system, is to assure that it always moves to a new stable equilibrium rather than tending to zero or infinity.

Why would I care if a botnet is trying to earn coins? It doesn't undermine the system. And with the payout structure, it will be a much more complicated endeavor (nigh impossible with randomly assigned peers as I am now describing) trying to maximize the payout. With Bitcoin, all an entire botnet needs to do is send data to one peer and that peer will earn coins as though he were the entire botnet. Now instead the controller must often force his botnet to compete against itself and try to be average to avoid penalties of being too fast or too slow. If we assume these botnets are CPU mining (as the bitcoin community does), they need to be split into 40-50 computer computer sub-botnets, and each sub-net must actually participate in the network, unlike bitcoin. This means over 20 times the bandwidth required for a 1k computer botnet. Admittedly, this wouldn't mean much for a long time. In the mean time, anti-malware or firewall software should have no problem detecting this activity.


The payout structure has nothing to do with the sybil attack scenario I described. I wanted to make sure that for an agency trying to subvert the reputation system that it would cost dearly and accomplish little.


The difficulty isn't fixed, and inflation is created by demand. As of yet there are no supermachines that are less costly, more efficient, and capable of keeping up with everyday GPUs in both speed AND versatility. Until this is the case, GPUs will remain king of setting the difficulty. The best I can do is not adopt a scheme similar to *brix as it is aiming to be a CPU miner; rather, the two could be simply combined, or any other various algorithms could be used over straight SHA or whatever the hash is at the time.


Darn, EnCoin can't account for a major energy crisis. I knew there was something I was missing in trying to solve every single existing or future problem of the world.


So it takes a world crisis for an early adopter scenario to emerge with ENC, but with BTC it takes 1 person and a pre-mine. Hmm.

And if you are curious about Red's proposal, this is the gist of it:


The issue he keeps trying to bring up with Encoin is precisely the same. Except that with his system, you have a technological elite with a monopoly on the money supply (sure Bill will keep going at a .009% ROI for 720 computer-hours a month of work) who can simply just hoard and drive up the prices at will without ever a whit of a chance for anyone else to make coins because he can simply make them when the difficulty falls back in his profitability range but no one else's. Drive up the price/let difficulty fall, sell, mine. Hey look we've got a more convoluted version of Bitcoin. And no incentive for anyone to secure the network but arbitragers and those who they've got by the balls.

This is a nasty sounding, but pretty fair summary of what I am suggesting.

Arbitragers will compete, not on how fast they can hash, but on how cheaply they can hash. The arbitrager with the lowest overhead wins. The mathematics of the minting algorithms prevent even the last rogue minter from driving the system away from stability.

If the latter holds. The former is always perfectly sensible. Otherwise, you are arguing to allow others to do exactly the same job, but at a higher cost. As all electrical costs are directly born by clients transacting in the *coins, minimizing this overhead expense benefits everyone.

Anyone is allowed to mint. However, the vast majority of people using this system won't mint, and won't want to mint. The arbitrage competition requires too much *human* mental effort, and it requires gambling with ones personal dollars.

However, as with bitcoin, anyone can run a client which keep tabs on the honesty of the rest of the network. These clients require trivial hardware to run and very little electricity. Absent all the needless hashing, monitoring honesty is a trivial problem.



This however is not a correct summary for any reasonable definition of "secure the network". I claim that security will be provided (as it is with bitcoin) by cryptography. This prevents all theft, fraud, forgery and transaction related mischief. Denial of service (preventing valid transactions from being acknowledged) and history substitution (chain swapping) is not subject to the minters at all.

Network continuity, and denial of service prevention become the responsibility of those non-anonymous parties that profit in the actual *coin marketplace. However, it is never compromised by 51% attacks. Denial of service/history modification requires 100% consensus among well known non-anonymous parties that can be held legally responsible for their actions.

So, I claim if even 99% of non-anonymous parties attempt to block valid transactions or change history, the last 1% has 100% of the evidence necessary to file charges against (or publicly disgrace) the others. Even if 100% of non-anonymous parties are compromised, every anonymous monitor holds the same evidence.

That is what I call "security".

Etlase, the EnCoin concept seems very promising! It's what I've been hoping for since I started my infamous thread (https://forum.bitcoin.org/index.php?topic=57.0) almost two years ago. You're welcome to read the initial post and kick some skeptic butts if you feel like as I revived it again today after the hacking of Bitcoin7. I believe the instability of prices is making users vulnerable to exchangers as they need to keep their "bitcoiny" wealth in fiat form to avoid price fluctuations, which defies the whole point as puts us back to square one.

I don't address any security issues or drastic changes like you do here though. The whole premise is about the economic necessity and the practical plan to tie bitcoin's price to electricity.

It'd be very sad if you had to go through publicity and advertising from scratch for EnCoin though. I was hoping the Bitcoin's developers would listen to the sound of reason and introduce these changes to the original client instead. If no steps are taken to ensure the coin's price stability it will never go mainstream. It'll be regarded as a very risky investment almost like gambling instead of being a friendly medium of exchange which everybody can use to escape the control of big corporations and big brothers.

I was completely unaware of your thread, thanks for pointing it out. I don't believe the Bitcoin developers will be listening to the sound of reason any time soon. And the vocal majority around here is very pro-pyramid, so that could very well be used as the reasoning for not changing it.

I haven't read the whole thread, but it appears you want to stabilize the price of a bitcoin with the dollar, based on the estimated number of CPUs mining. This has 3 major problems, imo: 1) it doesn't protect against dollar inflation (which isn't terrible, but if the fed prints more dollars so does bitcoin), 2) estimating the number of CPUs is difficult if not impossible with the bitcoin proof-of-work design, 3) the security/continuity/dependability of the network still relies on massive amounts of hashing power, and always will. Bitcoin also has terrible scalability issues.


This opens up the network to attack, unfortunately. edit: Or would your "cooling down" settle up transactions too? Then that isn't bad. I'll have to read some more.

Although it's not in the proposal yet, I did mention somewhere in this thread I came up with a very reasonable solution to not require hashing power at all: let merchants put their money on the line to secure the network, and in return, refund most or all of their mandatory transaction fees. So if the economy is completely stable, no hashing power is necessary.

I'll peruse the rest of the thread when I have time as there might be some good discussion in there somewhere (I hope). I'm probably going to work on one final, major revision to the proposal, then that will be it from me for the rest of the year at least. If enough interest has been generated, I might be persuaded to even hire some coders if necessary. I simply don't have the skills to make this happen and I have no problem admitting that. And I don't have the time to invest in acquiring the skills for a non-profit venture of this scale. I love the concept of bitcoin, it's such a shame its vision is based on greed.

Woot! One more!

That makes at least 5 people who have shown up and expressed support for stable money. I think if we get two or three more we can take a shot at occupying wall street! :)

But seriously, Suggester. Thanks for joining the discussion!

That is what I call "trusted central authority." That's great if that's what you want, but it's not p2p. Make your own proposal.

"HEY GUISE I got this idea where a small group of people make, control, and distribute the money supply! And if someone disagrees, they can post a message on a message board!"

Actually I wasn't going to bother since there is so little interest here. But I checked the survey results on Suggester's poll and 26% of the people support his proposal and 10% partially support him. That is 36% interest in stable money. I guess I will start a thread.

Funny? Why do you think all these people are not interested in you?


Yeah, it is going to come as a real shock to bitcoiners that a small group of people, make control and distribute their money supply! Most of the posts on this forum are from people who are in that group or want to be in that group.

P2P means peer to peer. Anyone in my system can be a peer. Anyone can be a trusted peer. They just can't be an "anonymous trusted peer". As you pointed out, that concept is just stupid. Anyone can however mint all the coins they want. Even anonymously! But only the ones who are both smart and efficient will be able to do so profitably.

Which is as it should be. Because only a complete moron thinks you should penalize the smart and efficient, to benefit the stupid and inefficient. That is the closest thing this site has to a core principle.

How does "smart" = "efficient"
and "stupid" = "inefficient"

in the case of achieving a stable currency based around a commodity? This is the exact same thought process that suggests "smart" = "early" in bitcoin.

A commodity is neither smart nor stupid, efficient nor inefficient. Megahashes are not the commodity, electricity is. I am not looking to reward who can get the most megahashes in a watt of electricity. I am not proposing the exchange and trade of megahashes. Megahashes are not a product. The goal is not how much profit can be made, the goal is a stable medium of exchange. When the goal becomes who can make the most money, the medium of exchange is lost. Instead you have an ever-continuing competition and the absolute clusterfuck waste of resources that accompanies it and absolutely no one benefits besides whoever comes out on top--for the time being. Is it so wrong that I want miners, sellers, traders, hoarders, savers, spenders, and aunt jemima all to benefit from my system? Not just the privileged, "smart" few?

This thread is too much talk and no action.

I think you need to actually start making this a reality. Is this going to be CPU or GPU based ?

Thanks !

Agreed. That was what I proposed.

Agreed. That was why I make it clear most people wouldn't be minting or benefiting from minting. It is a pure, stable, medium of exchange.

Agreed. That's why we should involve as few people as possible in that cluster fuck. That's why I said only "Smart" gamblers will take part in arbitrage. "Dumb" gamblers are welcome to try, however their dollar losses need not be born by aunt J. Dumb gamblers should pay their own bills.

Clients don't even have to know the arbitrage process is going on. Hell it happens everyday with dollars/gold/etc and I pay zero attention to who is winning and who is losing their arbitrage positions.


Stable money is a benefit to everyone. Making the currency stable should cost everyone as little as possible. Every penny that goes to the electric company is overhead that comes out of sellers, traders, hoarders, savers, spenders, and aunt J's pockets. None of it, in your model is intended to come out of the minter's pocket. Instead, everyone else's overhead, becomes the minter's ROI.

This is true in my model as well. But my model works to minimize the number of dollars that goes to the electric company. Therefore it minimizes the overhead charged to sellers, traders, hoarders, savers, spenders, and aunt J's.

If you have a link to where I can find coders who can code extremely secure and efficient network protocols for cheap, let me know.


It is going to be 100% GPU based to start, using the exact same algorithm as bitcoin so that it can make use of merged-mining and award both encoins and bitcoins.
At some point in the future it will break away from this. Whether it's to CPU or CPU+GPU or some ubiquitous other card or device I don't know.

This is of course assuming it goes anywhere beyond proposal stage.


The only serious argument you've brought against my idea is the increased efficiency of expensive, slow, application-specific machines potentially reaping an outsize profit. And that this will somehow exclude everyone else from being part of the game. Assuming this is the case, how is it any different from your system? Because your system relies on a timer?


Pennies that go to the electric company do not come out of anyone's pockets. Sellers, savers, etc. buy a value of electricity plus a ROI for the hours of computer work involved. Getting the cost to produce back is not a ROI--nor is the ROI overhead a burden on everyone else, the coin is the electric value+ROI. You can sell the coin for the same price you bought it for. You aren't losing money because someone made 50 cents on creating the coin. Gold you purchase doesn't lose value because of the cost to mine it, that is inherent in the price of gold. You are free to go and mine your own gold if you find the price to be too high.

You suggest everyone competes for the same batch of coins, all wasting resources and only one benefiting. Where are the savings, exactly? That an eventual technological elite monopoly will occur to force out competition? And no one will ever contest it? And somehow this is inflation-proof? Instead of money going to the electric company, money goes to the elite, but yet everyone else benefits because less electricity was wasted? What is to keep them honest about keeping the price stable instead of just going for the more immediate profit (or the longterm profit in hoarding)? Goodwill towards mankind?

How about you try to put some actual numbers and equations together so we can see how this will work out. Rather than difficulty+1 and transaction fees/2. I'm interested in the concept, and willing to steal some of it, but at this point it is too far from an actual system for me to fully comprehend the implications. I don't care about security or dependability or whatever noun you want to give the network. Just the monetary policy. You're completely willing to assume your system is bullet proof while shooting holes in mine and ignoring the costs involved, but you haven't given me anywhere near enough ammo to try yours. Put your money where your mouth is.

Really, we agree on about 90% of our principles. The 10% we disagree on is worth arguing over though.


I'm not saying I have an "attack" on your system. I'm saying that the electrically efficient hashers driving out the electrically inefficient is a natural consequence of your design. It is a natural consequence of my design too. Electrical efficiency is not something either of us can detect, so it is not something we have any power to prevent.

It is analogous to bitcoin, except there the temporally efficient (faster) hashers drove out the inefficient. There was no way to prevent that, so satoshi made it a feature.


I don't know what this means, so I don't know how to respond.


My use of ROI was probably too smug. But let me be clear this is a closed system. The number of dollars going out of the system, cannot be greater than the number of dollars going into the system. It doesn't matter what happens in between.

Let's say buyers have $10,000 to spend buying ENC.

Now lets say there are 1,000 peers who burn 200W*24hours*30days. That's 144,000 kwh or about $14,400 to the electic company. Or about $14/peer say we want to give each peer $5 on average for their trouble. 35% ROI. Now we have $19,400/month in costs to run the system. That means minting somewhere near 20,000 ENC. So the price will be $1 = 1 ENC.

So the peers take these coins to the exchange and get... $10,000. Because that is all the dollars there are.

You can say 500 peers sold 20 ENC each for cost+ROI=$19.40 (after transaction fees), and the other 500 have to wait to pay their electric bills. Or 1000 peers sold 10 ENC each for $9.70 and nobody can pay their $14.40 electric bills. That doesn't change the fact that the electric company is still going to want their money, and they can't take it in ENC.

(You have the same potential problem with gold. If I spend $1,000,000 in electricity mining gold. And buyers want to buy $500,000 worth of gold. Then the electric company is still going to be just as pissed.)

The bigger problem is, that out of $10,000 exchanged for ENC, there are zero dollars left for merchants to exchange for, once purchasers have spent their 10,000 ENC. All the liquid dollars have gone to the electric company.

----

I'm not trying to say anything really earth shaking or dramatic.

I'm just saying that 1,000 non-minting peers who burn an extra 5W*24hours*30days (running this app in the background like bittorrent while doing other things). Comes to about 36 cents each. This can go without reimbursement.

Say 10 committed competing arbitragers running 500W only when profitable, say 6hours*15days when things are stable. That is 450kwh or about $4.50 in overhead (45 cents each)

So out of $10,000 exchanged for ENC, the arbitragers take $4.50 to cover their overhead. Then they take $50 each as 10X ROI. But this still leaves $9,495.50 not permanently extracted from the system.

----

Yes I realize this example is contrived, and maybe you can poke fun at different non-sensical bits. But the main point is, every dollar that goes to minters, comes from the pocket of someone buying ENC on an exchange. Those dollars will never be available to swap on the exchange again.

I know there is a little multiway exchange diagram somewhere that shows this problem.

Alice has an Apple but wants a Banana
Bob has a Banana but wants a Caramel
Carl has a Caramel but wants a Dollar
Don has a Dollar but wants an Apple

So Don give he dollar to the electric company in exchange for an ENC.
Carl says, "Hey WTF! I needed that dollar! And eats his caramel.
Bob says, "Hey I wanted that caramel, and punches Carl.
Who slips on the loose banana and falls into Alice,
distracting her just long enough for Don to grab her Apple and run like hell!

---

So in summary

$14,400 fixed cost, bad
$364.50 fixed cost, better
$4.50 fixed out of pocket, best

$5,000 @ $5 each profit, expensive and not so motivating.
$500 @ $50 each profit, cheeper and more motivating.

---

Yes, somewhere during that post I lost my mind. I'll respond more coherently to the rest of your post tomorrow.

And Yes, I'll put my concepts up and let you poke holes in them. I'm pretty sure there are a few unexpected consequences I haven't noticed. I am a little disappointed no body else pinged me to do so from the other thread. Maybe we are alone.
 

You said coins would be competed for every 10 minutes.


While I realize the overall sense of the proposal is very idealistic, there is nothing wrong with this. If ENC becomes a stable medium of exchange, dollars do not need to leave the system in greater number than the value those dollars produced. You are selling someone a token of value that remains relatively constant. This 1 token can be used over and over again. Yes I realize tx fees eat into that, but since my enlightening with merchants, I have a feeling very few tx fees will actually occur (I also plan on having miners get free transfers out). So $->ENC should cost little to nothing, and ENC->merchant should cost little to nothing.

My vision now is that only people who do nothing for the network actually pay any fees. It will be harder to account for a contracting economy, but anyone who bought high will know that the value was well above what the market is trying to achieve.


There's no reason to mint if the demand is not there. Unless you want to save the 30 or 50 cents or whatever to buy your loaf of bread. But it still cost you 50 hours of an unusable computer.


If the currency is widely adopted, the merchants don't need to exchange those ENC for dollars. And there will always be people who want ENC more than $, just as there will be people who want $ more than ENC. This happens every single day in huge quantities around the world in currency markets. People who mint coins are not going to be the only ones selling.


I don't know where you come up with these genius arbitragers, but if you leave the door open for people to make a profit on making currency, competition is going to increase and that profit will eventually go to nothing. Everybody loses as the value of ENC goes down, just like an early adopter sell-off.


Yes, $50 each profit is cheaper and more motivating, meaning more people will do it and eventually the profit will be cents again. Everybody but the "arbitrager" loses.

I'm going to respond in detail to your questions but I have limited time today. It is the first Friday of the month and I go to my local 2600 meeting. I just mention this so that you know if I disappear, I'll be back tomorrow.

Second I want to start of with a little preamble to say, I'm going to call some things "my ideas" but only to distinguish the concept from previous things we've talked about. However, I don't personally consider any of these things "my" ideas. You claimed, "it was possible" to do these things, I just presumed your were correct. My goal was/is to understand how you are correct.

So in pursuing my personal understanding of your correctness, I obviously disregarded anything you said that I already knew to be a false path. I just presumed it was miscommunication on your part or misunderstanding on my part. I then asked questions and tossed the concepts around in my head until I could figure out what your path really was. I hate it when somebody claims to know something is provably true, when I can't prove it to be true. I'd long given up on proving this was possible. I never proved it was impossible. It seemed possible. But I never noticed a plausible path to proving it was possible. As such, if we manage to prove stable money as being possible, I claim that it is just the natural termination to the path you started down. Hence, "your" idea.

I realize now, that your goal is a variant of satoshi's. Create a coin that can be used in the absence of any exchanges. EXCEPT unlike BTC, you want ENC to be stable in value. Yes, this should have been obvious to me from the beginning. Let me explain why it was not.

Your initial premise was:
1) If coins creation could be made dependent on the consumption of a fixed amount of electricity, THEN (logical implication) coins would have a stable value absent any exchanges.

Yes, I recognized from the beginning that this statement is logically true. That implication does indeed hold. However, I recognized immediately that the antecedent "could be made dependent" was actually, False. While that does not disprove the consequent it doesn't help prove it either.

That was when I asked if you meant ENC = $ = KWH. Whatever your answer was, I interpreted it to be "close enough!"

So I substituted the original implication with:
2) If coins creation could be made dependent on the price of electricity, THEN (logical implication) coins could have a stable value. However, that *will require* an active ENC to $ exchange.


My substitution of premise (2) for (1) is the root of almost every argument we've had. In reality both assertions (1) and (2) are logically true. And in both, the truth of their consequent comes down to the truth of the statement "could be made dependent".

So the real question comes down to:
What made me "recognize immediately" that "could be made dependent" in (1) was False?

Well, technically, it is not false. If you made peer participation dependent on purchasing a specially made, tamper proof, efficiency matched, processing box that was cryptographically signed by a trusted supplier. Then you could assure that 1 ENC required 10 kwh. I dismissed solution out of hand, because it conflicted in philosophy with everything you wrote. But absent that, there is no way to remotely detect a processor's electrical consumption rate.


Everything in bitcoin is based around remotely monitoring (MHash/s). Hashes are monitored by knowing the difficulty level (2^(D-1)). Seconds are monitored by averaging block creation intervals. This gives you an accurate ratio, that you can use to recalculate difficult based upon a target interval of 10 min.

Note however, that monitoring the block interval accurately requires you to prevent parties from lying about block creation times. That is why bitcoin is winner take all. It prevents even collaborative lying. With block chains, the shortest intervals (most blocks) trump the longer intervals (fewer blocks). All of that is really about monitoring time.


Combined electrical efficiency (MHash/ws) cannot be monitored. You still understand Hashes. You can divide the number of blocks created (non-competitively, in a given interval), by the interval time. That give you a slightly sloppier measurement for seconds. But even given these, you have no way to monitor watt consumption (hence your 200W constant).

Side note: You proposed that block creation could cross PB intervals. That means you lose the ability to monitor seconds at all.

But even if you accept the above measurement of (MHash/ws) as being useful, changing difficulty (Hashes) does nothing to affect electrical efficiency (200W constant). You can only effect seconds. This leads to my example of the more electrically efficient driving out the less electrically efficient.

So, I presumed the (1) premise could not be yours, because the only solution to its antecedent was one you would completely oppose.

That is why I began thinking about (2) as the premise you were having trouble conveying to me. Really, it was nothing personal. I was just trying to figure out how you solved (what I called) the more important problems, that come later.

At this rate, this is going nowhere soon. Please use CPU only algorithm like scrypt etc.

No, what you did is misinterpret what I said and continually beat the shit out of a concept I did not propose. Even in the face of my correcting you.


I later clarified in the first thread that "price" meant "cost to produce."



Is there somewhere in that equation that says 1 ENC != 5kwh based on 100Wh per person? It was an assumption that need not be true for the system to function exactly the same except for the market price.

In revision 3, I more specifically pointed this out:


Now, the real problem:


In this thread especially I pointed out that someone with their big bad brand new GPU is going to be making more coins than average; possibly much more. As people gradually upgrade their hardware, this will level out again and the difficulty is increased to match.

You can't get the minting base to agree to run at half power (it will be obvious to anyone with a comparable piece of hardware--they will profit much more than the deceptors, and difficulty will rise). You can't have super secret hardware that nobody knows about. And even if nobody knows about it, it has a negligible effect on the economy.

You can't pretend unsunk costs don't exist for practicably useless hardware to prove your point. Part of the benefit of the GPU is that you already have one! And people are always upgrading them for reasons much more important than making coins. Fixed hardware is just not going to keep up unless it somehow drops like a rock in cost.

BUT if that big bad new GPU uses only 100W when all the prior coins have been created at 200W, then and only then is there a real problem. And I proposed a semi-solution to this:


In thinking more on this, the only real way to do this is to increase difficulty for no reason. The amount of coins can't be controlled this way (I suppose if they were on a 10 minute timer they could, there are other options to explore). So "koomey's law" would probably have to be used for gradually increasing difficulty over time (1.57 years to double computations per kwh) if it doesn't increase by this much at least naturally. Since the idea of a constant generally sucks, imo, I think at some point down the road developers may have to intervene. Nobody can predict the future based on the past.

The price of electricity could rise faster than inflation, or it could lower in the case of a new source of energy. Computations/kwh may double every 1.57 years forever, or they may hit a ceiling. Without a doubt they will go through slow periods. None of this can be accounted for now. So in that sense, the proposal is a failure. But throwing ridiculous scenarios at it to disprove 1 ENC = 10kwh does not help or solve anything, especially considering I already more than accepted this.

So, given the above post about electrical efficiency.

In any system where stable coin value is a priority, (Exchange or no-exchange) as coin values approach stability, electrical efficiency becomes exponentially more important. If coins trade within 1% of minting cost, and I can mint for 2% less than you. Then I can mint and your can't. This is not so much a competition as an unavoidable axiom. (The efficient drives out the less efficient.)


Since I can't remove the axiom I'm attempting to use it as a feature.

The most electrically efficient state of the system, is where NO ONE has incentive to mint at all. This does not effect continuity of the network. Merchants continue to make money, clients continue to see the efficiency of the system as a personal benefit. It just means arbitragers don't mint, don't make profit, and don't extract value from the system in anyway.

Optimally, this would be the stable currency state. No new coins are required. No minting is done. No arbitraging is done.
However, I couldn't get my system this optimal. Maybe it is possible but I haven't notice that solution yet.

In the -1, 0, +1 system I proposed, in the stable state, some minting is required. However, it is collaborative (like you are proposing) and it does NOT involve arbitragers. In the stable state, only people with transactions will attempt to mint. If enough people attempt to mint, EVERYONE's tax is refunded. This is in effect a consensus vote that coin values are stable. It requires the combined tax rebate pool to spend only 1/2 the number of hashes as it would take arbitragers to create new coins.

The under valued state is the most efficient in my proposed system. If coin values are below stable values, nobody will mint at all. This serves two functions. Most importantly, it represents a consensus vote that coins are undervalued. Second, it removes all excess overhead from the system when overhead is the biggest hinderance to coin value recovery.

The over valued state is the only time Arbitragers attempt to mint at all. For maximum savings (to the system as a whole) arbitragers should mint as quickly and efficiently as possible. So if the most efficient minter can bring the value immediately back to stable himself that is optimal. If that is not possible other less efficient minters can step in to lend a hand.



The goal is that no monopoly of minters be allowed to drive the prices away from stability. (Tending prices toward zero or toward infinity.) That is how to best judge what I suggest. If we can show multiple solutions meet this goal, they can be ranked by how far they allow the stable prices to shift when drastic economy changes occur.

This already would happen in my proposal. The newer GPUs oust the older. The older will still be profitable for a time, but the difficulty will increase as more and more new GPUs are added to the pool, eventually weeding out the old. The new GPUs can either take the coins while they have the opportunity, or make less coins and keep the difficulty down. But eventually, people are going to see the opportunity and make more coins, especially if there's an expansion.


But then it costs money to maintain this stable state, does it not? Minters are paying to receive their transaction fee back. What are we using to determine this stable price? Do we use the original cost to produce?
How do we determine how money initially enters the economy? --this has a big effect on what would be considered stable, imo.


Aren't we burning the picture of burnt wheat here to return to stability? I came up with a solution to solve this, and you are reintroducing it.


But why are these arbitragers doing this when it's over valued? When is it considered over valued? How do you separate these arbitragers from the rest of the population? How do you think you can keep it a secret (if this is still what you're basing this on) that the arbitragers are doing this for exceptionally small amounts? Do you think, for example, awarding 10 or 12 ENC for the highest levels of reputation would suit this purpose? But this is obvious, and likely it will make people angry. If all the motive here is to sell, what is to prevent them from using this ability to "arbitrage" during times of stability? Your answer is increased difficulty. But that brings me back to the question of what determines stability. Since "the people" don't decide when to arbitrage, the "arbitragers" decide what stability is. And the funny thing is is that they could arbitrage themselves a lot of money, raise the difficulty so that it isn't profitable to refund transaction fees, and then sell when demand is high. And they create a never ending cash flow straight to their pockets. I see ripe potential for abuse.


Again, define stability. In my system, 1 ENC equals the average price the minting world pays for the electricity (AND associated costs) to mint 1 ENC. It is sort of a self-fulfilling prophecy. The only problem is you can't be sure 1 ENC costs the same to make in 2022 as it did in 2012.

Instead of koomey's law or any other constant, what I think is worth discussing is changing the award with some kind of modifier. This would actually work for my deflationary scenario that I talked about earlier (extending the 6 hours to 8 or 10 hours). If more coins are required, more people are required to produce them. In 15 years, if you only get 3 ENC for a block instead of 6, you make sure you're using 100W instead of 200W or you're minting for a loss (unless the price of electricity has halved [adjusted for inflation]). So twice as many people are required to mint the same number of coins, BUT for the same amount of electricity. If demand is not high, then twice as many people do not need to mint coins. I have to think more on this. Think there are any equations or algorithms that could possibly determine when to change the awards?

I mentioned in another post that I'm really not so worried about inflation anymore. This isn't going to be bitcoin where so much interest is generated on trying to make a profit off of latecomers. REAL speculators could come in, see that it is obvious that the coins are selling for less than what they cost to produce. Buy them up, hoard, and wait for the economy to grow again. If nobody is minting, could a possible incentive be to redistribute transaction fees (ones that actually got burned, not the ones that merchants get refunded) based on the percentage of coins owned? Would it ever make up a significant amount of money to incentivize hoarding? Is incentivizing hoarding in this way bad for the economy during inflation? It wouldn't seem that way. We want circulation to go down, right? Isn't that the same as burning coins in the short term? And then in the long term, those coins don't need to be remade.

Should burned transaction fees always be redistributed this way? It creates another incentive for demand. And this could potentially counteract the reduced cost to produce of an ENC in the future.

Wow. Is this the solution?

edit:
Ran a quick scenario, 50k savers with an average of 1k enc each, 50k spenders with 500 enc each putting 0.10 enc each in fees into the economy a day
Assuming 75% of these fees are refunded to the merchants, a 1k savings will earn you 6 enc a year, or 0.6%. Not that bad considering price inflation should be at a minimum.

I'm going to respond to this tonight because I read this post earlier and I've been thinking about it already. I'll respond to the others later.

OK, I get what you are trying to say. (I Hope!) To paraphrase:

---
Each minter uses the same proof-of-work difficulty for minting.
As such, the value of ENC will tend toward the electrical consumption of the most electrically efficient minter. (MHash/ws)
Left alone, this electrical consumption would tend to decrease over time according to Koomey's law.
To return ENC minting to its original electrical consumption constant,
EnCoin offsets Koomey's law by doubling the proof-of-work difficulty every 1.57 years.
---

This makes total sense to me. I completely agree with this statement. I really hope it is what you have been trying to say.

Now a little needless bitching. ;)


The part that needlessly confused me for two weeks was your use of averaging. While it is true that if one guy mints coins for 8 kwh and another mints coins for 10 kwh, the average amount of electrical consumption is 9 kwh. You seemed to also be saying that the sell price and value of each coin will reflect this 9 kwh average.

That seems ill conceived. In a marketplace, all the lowest price ENC sells first. Higher prices might not sell at all. Thus prices would tend toward the lowest cost, not the average cost.

I know now that is not what you were attempting to say. You were trying to say the more general, "If peers use more electricity prices will be higher. If they use less, prices will be lower." The use of specific numbers made it seem you were proposing precise targets.



This goes down as the worst sentence of the entire proposal! It made me think you were dismissing the likelihood of electrical efficiency increasing. All the talk about sunk costs, and the expense of upgrading made it seem like you were framing changes in overall efficiency as implausible. Having zero discussion of how you methodically change the difficulty level made everything seem even more hand wavy. "If in the unlikely chance that technology improves, we'll fix things by voting to change the difficulty." it was not very inspiring.

---

But anyway, I now understand the main trust of your proposal. (I hope.)

Perhaps my suggestion for phrasing it with help make your proposal easier for other doubters like me to wrap their head around.

I don't want to use a constant like koomey's law. I'd prefer to figure out a way to lower the award instead somehow. And raise it if necessary. I'm trying to think of a way to do it based on an algorithm that could determine how profitable it is. Or something. I don't know yet.


You're missing the ROI again (and the difficulty in time). Nobody is minting for free. People who pay 10-15c/kwh will not likely be able to supply all demand. The cost per kwh is a much bigger factor than how much kwh was actually used. If 75% produces at 11kwh and 25% produces at 9kwh, we have an average CTP of 10.5kwh PLUS 33% ROI (it may be higher, who knows, there aren't early adopters selling off) or 13.96kwh. That means someone can mint for 12kwh and still make a small profit. But the market (and the people) all has to determine this.


This is why I used "about", "approximately", and "based on" throughout the proposal anytime 10kwh or 200W was mentioned.


Well, it was a lead-in to the very next paragraph explaining a way that could help solve it, after all. Although at the time I didn't realize that specific scenario wasn't possible with the way coins are distributed.

I'm not saying koomey's law is the perfect final solution. But I'm saying koomey's law is perfect way for the proposal to introduce people to your concept. It is well known, and it makes a good concrete example of canceling a known tendency with a known function to create your proposed constant. No hand waving is involved. That is what you want at the beginning of a proposal. It is like an establishing shot in a movie. It helps people suspend their disbelief.

But it's fine to say "koomey's law[1]" and refer to a footnote that says, "See section 10.5 for a discussion of koomey's law and other possible alternatives for maintaining this constant."



I'm not missing it. I'm not disregarding anything you are saying. Certainly, the price will never get too the lowest cost minter's cost. But that is the whole system's limiting condition.

I'm using the phrase "tends to" in the mathematical sense, as with Big O notation (http://en.wikipedia.org/wiki/Big_O_notation). "The time it takes to solve the proof-of-work based upon  difficulty (D) tends toward O(2^n). Sure that's not exactly right. The exact calculation would be: POW time = setup time + (time for one hash) * 2^(D-1) + completion time. But that just obfuscates the point I'm trying to make.

Again, I'm saying this is the best way to introduce the topic so unfamiliar people can grasp the system's dynamics. You can certainly put "electrically efficient minter[2]" and a footnote, "See section 10.6 on hashing speed vs hashing efficiency and how these effect total coins minted and the potential ROI of each minted coin.


I'm not saying your intentions weren't correct. I'm saying your execution confused me repeatedly.

(addition)
By the way, ROI in the absence of a $/ENC exchange becomes a much more nebulous concept. Sure nothing really changes, someone spends $1 in electricity but takes their ROI in 1.3 loaves of bread. But I would certainly leave that discussion to a later section.

Quite frankly, given your target audience, I don't think you are going to have any trouble convincing people to mint. They are already used to paying high electrical bills in hopes of higher future payback. In the absence of an exchange, I don't think the early minters/merchants would have a problem trading among themselves at (1 ENC = 1 loaf of bread). Then when an exchange appears, pricing their coins for sale at (1 ENC = 1.3 loaf of bread = $1.30), to those who don't want to mint. Over time, those two prices will tend to converge toward a single market price.

But even accepting all of that, I still have trouble wrapping my head around the ROI dynamics of that final single market place. I'm sure it is describable. I'm just suggesting it is not where initial discussion of your concept should start.

The next version of the proposal already has bits of a first section that goes into this market effect because nobody really got it. I understand that it wasn't clear now. So yes, the first section is basically all just economy and why I think the system will work.


We've established this. Now HELP ME TRY TO FIX IT! :) If we establish a baseline of 150W instead of 200W and a gradual decrease in the award from 6 ENC to 2 ENC, the baseline goes from 150W to 50W. If the difficulty doesn't increase on the order of koomey's law, then the people are adjusting lower because technology is not keeping up. But once we hit whatever the final award is, 1 or 2 ENC, we can no longer adjust lower, only higher. Could this somehow be based on a year-to-year system? I wonder. -- Though in trying to keep coin production down in a stable economy, there might be very few miners at times from which to draw conclusions. This could lead to mistakes.


I really don't think it does. I even mentioned this concept in one of the Q&As (on ukraine electricity). If I want to trade 1 ENC for a loaf of bread to the baker, the baker has some idea of what it took to make that ENC, just like he has a good idea of what it took to make his bread. Bakers in ukraine charge more because electricity is cheaper. Bakers in western Europe charge less because electricity is more expensive. Obviously there is little way of knowing if the coin was made in france or ukraine, but there are costs involved in that transport such as currency conversions.


I don't know how it will work out either. We'll have to wait and see. :P

I'm not exactly sure what you are tying to fix?

But my first guess you are trying to smooth out the function so that it does not change so dramatically by doubling in difficulty at 18 month boundaries. If that is the case, you want to reduce the ENC awards per block say every month, so you have an 18 step smooth exponential curve from 2 to 1. Then at 18 month intervals, you both double the difficult and double the ENC award/block and start down the curve again.

I can't give you the exact values for this because I forget how to calculate with logarithms. But in effect if you had Log base 2 graph paper. You plot one point at 1 on the bottom left, 2 at the top right and draw a line between them. Then you divide the line  into 18 intervals and read the intercepts. That is the old school, before calculators way.

So the answer is, if I understood the correct question, there is an easy answer that I don't know, but could probably look up.
If you are asking, "What if it MHash electrical efficiency doesn't follow koomey's law?" Then I really don't have any answer at all.



Honestly, I never bought that premise. I think (absent a currency exchange) the baker never sets prices based upon electrical costs. Instead he bases them on the cost of flour, eggs, rent, etc. delimited in ENC. He doesn't care what his customer's cost to acquire that coin was. The baker cares about the trade value of the coin when he goes to spend it.

Keeping the "value" stable over significant periods of time.


Right I'm not too worried about the details of how it changes, just how to adjust based on missing the expected curve. But I didn't think about doubling the difficulty and doubling the ENC, it's so simple that it passed me by apparently. We get it down to 2 ENC per block so that there is a baseline of the current, most efficient machines in the 50W range. Then we have a new baseline for bringing it back up again. If difficulty was the same at 75W as it is at 50W, then we know people have been cheating (or some other world circumstances have changed--or hardware has a new lower range on wattage output). Then we 3x the difficulty and 3x the award back to 6 and do it again. Damn, this might just work. The implications this might have on the network could be a bit tough to figure out though. More thought required.

But essentially, if common hardware uses only 50W in the future, when tripling it back up to 6, earning blocks will take 3x as long. It doesn't matter if it's 50W--it will be whatever equivalent is most efficiently possible to keep a reasonable profit and stable prices.


same difference! A baker doesn't care about the customer's cost to acquire a gold coin either, he cares about its trade value.


What do you think about my post on giving interest?

Please just get this started already. Too much thinking no doing around here.

Cannot wait to buy 10 000 EnCoins then dump them ASAP as price rises. Please hurry up ! Thanks !

I'll sell you 10,000 now from the initial pre-mine. Just send $10,000 to... Wait, you are right. You deserve a pre-adopter discount so you can get some serious return on your investment. Just send $8,000 to me!

Maybe more like 8 cents !

I have so many different versions in my head right now. I would have to read your latest on fee and interest to be able to respond coherently. I know anything I say right now would sound hopelessly lost in the weeds.

Merchants get whatever fees that they can back based on how much money they are willing to put on the line. Anyone else just loses their fees. These lost fees get redistributed to people hoarding currency. So in down times, instead of selling, people can hoard and earn interest on those who do sell or trade at inflated prices. No one who buys cheap is going to care that they're getting inflated goods, only people who saved would care. So instead of freaking out, savers can just sit back, earn interest, and wait for the economy to get back.

And as an addendum to the other stuff, instead of basing the ENC reduction on time, we could do it based on the number of coins produced. This means if we get to a period where things are too cheap, it will last a shorter amount of time while ENC gets to a new baseline. HOLY SHIT.

I think I've fricken solved it. :P

OK now get coding and send me over 10 000 coins please. Thanks !!!

I'm pretty sure I'm in general agreement with you. Not sure I understand all the mechanisms you have for paying interest. But I agree you are pushing the system in the right direction.

The hardest thing about monetary policy is that you are optimizing against a hidden variable. Nobody really knows what the break even point is for ENC. Once you have a $/ENC exchange, individual decisions becomes easier (I know what my cost, and immediate return would be). But still if you wanted to know what the system's optimal ENC price should be, there are too many hidden variables to get an accurate calculation.

That's what led me to try and detect what the "human" consensus on the money supply was (too high, just right, too low). Technically, I think you could get away with detecting just two states (too high, too low). In that case the stable (just right) state would be when the system was oscillating between too high and too low. However, in my personal analysis, I always tend to think about the optimal stable state first. Then I look at how the other two differ from optimal.

I'm pretty sure you are working on the same detection issues. It sounds like you are detecting money supply is "too low" by how many coins are minted. Or perhaps a ratio of minted coins/traded coins over a fixed period. Your money supply is "too high" as that ratio tends toward zero.

I'd like to propose is ratio for discussion. (minted coins/trading fees) Where minted coins is the total number of minted coins in a given period.  Trading fees is the total number of destroyed coins in the above period. Meaning total number of traded coins times whatever fixed fee you decide on.

(total minted/trading fees) < 1
If this ratio is zero, there is a 100% consensus that there is too much money currently available for circulation.
In this situation, I propose you attempt to do two things.
1. Encourage potential buyers NOT to buy. (Hoard coins until prices recover)
2. Destroy the coins of panicking actual buyers. (Your coin destroying fee)
3. Encourage potential sellers to sell NOW! (Stop hoarding goods)

Psychologically, I suggest charging your *panic* fee ON TOP OF the price the seller is asking. As opposed to requiring the seller to hide that included fee in his price. The former tends to make clear to *panicked* buyers that prices are *already* considered too high. It also makes it clear to sellers that NOW is a great time to actually close the deal. The later tends to encourage sellers to inflate their prices (which is what we are fighting against). And if they think prices are moving higher, they are further encouraged to hoard goods.

I think you are saying, "Instead of actually destroying these coins, they go into a system managed hoard for later re-distribution." If that is what you are saying, then I agree. Hoarding those coins is monetarily indistinguishable from destroying them.


(total minted/trading fees) = 1
If you are minting exactly what it take to replace your fees then there is a 100% consensus that the money supply is "just right".
Who should receive the newly minted coins is NOT a monetary policy decision. It can be adjusted to encourage other behaviors as you see fit.


(total minted/trading fees) > 1
This ratio is unbounded, so it has no way to express 100% consensus that the money supply is "too low". But the farther this ration moves above one, the closer you get to that consensus.
In this situation, you have too many goods trading for the existing amount of coins. So I propose you attempt to do two things.
1. Encourage, hesitant buyers to buy NOW! (Stop hoarding coins)
2. Discourage sellers from panicked selling of goods. (Hoard goods)

As this ration tends above 1, your fixed transaction fee tends to fight against your monetary policy goals. You are destroying coins during a period where everyone is in agreement that more coins need to be minted. The consequences of this should be minimized whenever possible.

This is a good time to re-distribute all fees. Both the system's previously hoarded fees, AND the current transactions fees. Who receives those re-distributed fee coins is NOT a monetary policy decision. It can be adjusted to encourage other behaviors as you see fit.



I think I'm generally agreeing with this, as stated above.


I'm not sure I understand this enough to comment.

EDIT: LMAO, I really didn't understand what you meant when I started typing below. (Basing ENC reduction on time.) I thought you were talking about the logarithmic reduction to compensate for increasing CPU efficiency. Now that I read what I wrote, and re-read what you suggested. It seems like I just re-wrote exactly what you said. If that is the case, I guess I do understand it enough to comment!


But I wrestled with a similar sounding conundrum:
If (total minted/trading fees) greater than one, persists for multiple periods in a row. It seem like coins should be easier to mint. That is what I was getting at when I added the +2 level to my system.
If (total minted/trading fees) less than one, persists for multiple periods in a row. It seem like fees should be higher. However, both of these lead to more abrupt final transition states.

I hadn't considered the above ration when I was thinking about that though. Perhaps things could be smoothed by considering the ratio rather than time? [edit: :)]

Say perhaps, the number of coins awarded per block is in proportion to (total minted/trading fees). Does that tend toward stabilization or toward more dynamic swings?

Fee's are more difficult to adjust because they affect the ratio itself. But you could add a "surcharge" as the ratio moved below one toward zero. Perhaps a surcharge using the inverse ratio (trading fees/total minted) makes sense. (As minting moves to zero, the surcharge moves to infinity.) That would provide a strong disincentive to panicked selling!

Can you at least give us an ETA for this please  ::)

No, because this is not a trivia: Take bitcoin's code base, change one constant, recompile and offer a release. At least we haven't figure out if it could be done that way yet. Some ideas actually take work.

I'll keep working on this until we can simplify the idea into something easy to implement. If that becomes the case, I'll just do it. But if the minimal implementation is going to take several man years of coding, I can't commit that much time and energy for free.

Eitherway the work would go so much faster if you would send in that $8,000 already!

Me too!

I think it might be possible to implement this economic model on top of the bitcoin code base. I'm kicking around in my head if the reconciliation/consensus stuff could be avoided by using varying speed block creation.

Someone wrote GeistGeld was experimenting with 15 second block creation times? I think the feasibility of that depends on how many peer nodes they have in the network. But if they could substantially speed up the rate without overwhelming the network, then their appears plenty of room for flexible block creation rates.

Right, this is why the award would gradually (or perhaps not so gradually) lower on occasion, to weed out the less efficient.
If FPGAs or low-wattage GPUs become prevalent, these devices are making coins at a lower cost to produce than previously possible.
If the award is dramatically lowered to 3 instead of 6 coins, inefficient cards have to lower their output while efficient cards can remain at the same output (assuming they use about half the electricity). This provides a new baseline that I mentioned. Inefficient cards will have to quit, and efficient cards will have to compete against each other instead of siphoning off the inefficient cards. Then, after a period of time, the award and difficulty can double back to 6 so that the process can start over.

Since, in a stable economy, coins may not need to be produced all that much, I came up with the idea of doing this by the number of coins produced rather than time. Perhaps the award could adjust every 250k coins or something.

But this provides a potential attack. Supercomputers and/or pools could get in and intentionally raise the difficulty if not too many people are making coins. This could be alleviated by having a minimum amount of time before producing a block and having a maximum difficulty increase per chunk of coins produced (this figure will be hard to determine though because we have both Moore's and Koomey's Laws we need to account for). It's a band-aid though. Intentionally raising the difficulty means the coins would start trading for more than their CTP, and this gives an opportunity for hoarders to make a lot of money. So it might encourage them to raise this difficulty. That's why I'm thinking a bigger chunk like 250k coins, it would cost a lot of money to do it. But by making it so high, this means that coins may be produced for a long time at less than the CTP, but at least there is a cap on it.


Not trying to detect anything; trying to foster competition among the more efficient so that it can happen automatically.


I think if you encourage hoarders to hoard during inflation (via interest), this works itself out. As I said, new buyers won't care if prices are inflated because they paid less for their coins. If 1 ENC costs 0.5 ENC from a year ago, they have no issue with paying 2 ENC for a loaf of bread. They shouldn't be penalized for buying in during inflation. It sounds like you are trying to prevent an inflationary spiral which I think is awfully unlikely with the monetary policy. No one is going to make coins during inflation, so the economy should eventually recover, so this will encourage people to buy coins and remove them from circulation.


But they are minimized. Merchants will be providing a service to the network by confirming transactions and so on, and in doing so they are receiving a large chunk of these transaction fees back. Hoarders receive a small interest payment and this payment could be used to sell on the market. May as well sell now before the coins get back to CTP.


I think it is more fair to go to the hoarders as they are people who already believe in the system. Distributing these fees to miners only encourages more people to mine when the price is high, sell, and be done with it.


I think it is just too hard to predict what will happen by doing this.

If the award lowers over time, people have to adjust their output or risk making coins unprofitable. This is kind of annoying because people who want to go full blast still can (supercomputer/pool problem). Certainly the software can automatically adjust when the award changes, but each time every person will have to look at their mhash compared to their watts compared to the market price to see if what they are doing is profitable (going full blast is likely going to subsidize others as described before). But I think this is the only way to do it and really let the market decide. 1 ENC tends to 1 ENC.

If prices of electricity increase faster than fiat inflation, people will have to wait until more efficient hardware can catch up. In the mean time, hoarders will have the opportunity to smooth out deflation by selling. They will make a profit, but not by their "early" investing, just by an unpredictable consequence of the world.

If fiat inflation increases faster than the price of electricity, there will be more competition to make coins and this will cause the difficulty to go up and the market price to go up, as it should.

If the price of electricity falls or hardware becomes more efficient faster than expected, the lowering of the award causes renewed competition that will increase the difficulty faster than normal (it's profitable for me to mint at full blast, so I will).

The *only* problem I see is, like I said, someone with the time and the means to intentionally try to drive up prices. If there are always people minting it is a lot less easy to do, but during times of inflation it would be even easier to accomplish. I'm not sure how to safely account for this yet.

Some of it could be applied, sure, but certainly not all of it. Bitcoin is secured by hashing power. This is a joke that needs to be eliminated. I've spent too much time thinking how to get away from how bitcoin works, so no offense, but I'm not spending any effort on trying to figure out how to hack the encoin idea in.

Agree with you there mate !

I think we are in, what an old professor of mine used to call, violent agreement. I think we are saying very much the same thing, but using different words. Inflation for one tends to be a maddening word for me. Normally I use it to mean goods prices are inflated against ENC. Meaning bread used to cost 1 ENC and now bread costs 2 ENC. But talking about buying and selling ENC using dollars the terms get more complicated.

In my mind if,
before: 1 ENC = 1 loaf = $1
after: 1 ENC = 1 loaf = $2   Then we are stable and have met our goals
after: 1 ENC = 2 loaf = $2   Then goods pricing, with respect to ENC, has deflated. Meaning mint more coins. Discourage hoarding.
after: 1 ENC = 1/2 loaf = $1  Then goods pricing, with respect to ENC, has inflated. Meaning destroy coins. Encourage hoarding.

But I think we are both pushing in the same direction, no matter what definitions we are using. So much so, that if I didn't reply to something in the previous post, assume we are in agreement.


I agree with everything in that section, but I'm confused by your use of "lower on occasion".

Wasn't the plan to lower deterministically (and smoothly) based upon the presumption that Koomey's law will hold? I think that is what you are saying. If so, I agree.

But on first read "on occasion" sounded like, "If things get wonky..." 


If you mean, "When the award lowers over time" then I totally agree with the rest of your statement. As far as I have been able to figure, people are required to pay attention and make decisions in their own self interest. Otherwise, they pay their own consequences with the electric company. (Like a gambler losing in Vegas)

However, THE GENIUS OF YOUR ENC=KWH IDEA means nobody else has to care.

If the award reduction/difficulty increase keeps everyone else aligned with Koomey's law. (for argument 1 ENC = 10 kwh) Then the run away minter is now minting at 1 ENC = 11 kwh. If he continues to do so causing an ENC glut and price inflation then he is compounding his loss because his 1 ENC buys < $1.

If enough people mint at a loss, it will temporarily trick the system into thinking the consensus is to add more money into circulation. Your proposed fee refund will begin dumping money into the market. This will temporarily increase inflation for the minter, but your "interest" compensates everyone else as an offset. This further compounds the runaway minter's losses.

But there is no way a runaway minter can profit. Like in Vegas, a time will come when he has to pay the piper. And that electric company piper is a real bitch!

---

"If the award lowers over time" makes it sound like, you still entertaining other concepts besides adjusting awards & difficulty towards Koomey's law? Are you considering another alternative.

I agree with you here as well. Any idea I would propose would contain a smaller "trusted" core of peers with the basic characteristics you designed into your "TrustNet/FreeNet/CoreNet" entity. I just think it could simplify the (transaction union/reconciliation procedure) that you go through in creating Primary Blocks.


Fair enough!

Well, I'm still speculating here. I don't have anything set in stone.
We can't assume koomey's law will hold, so we have to let the market figure it out.
To account for Moore's Law, I believe the difficulty should adjust every 25k coins (up for debate) based on coin-hours. Coin-hours = # of users in a block * # hours between blocks. Though I haven't released proposal 4.0 obviously, this can be determined correctly based on the way my new design for freenets/corenets will work. People won't be able to just join or leave willy-nilly.

Then, to account for Koomey's Law, the award will adjust every 250k coins (up for debate). How the award will adjust I'm not sure yet. It can't be from 6->3 because that will just bring in the reign of FPGAs and kill GPUs. So I'm thinking from 6->4.5->3->6 or 6->5->4->3->6 (probably this). If it goes too fast, we are likely to give low wattage high efficiency miners an even bigger advantage by making GPUs totally unprofitable way before their time--thus killing the supply and causing a permanent increase in the CTP before its time. So "on occasion" is sort of referring to the fact that when it happens is not very predictable. "if it lowers over time" is just me speculating on how this scenario would work.

Perhaps # of coins shouldn't be the only factor though, because if ENC explodes in popularity, 250k coins could go pretty fast. Then again, I dunno, because people might just be mining like mad because the CTP is much lower than 1 ENC. So perhaps it has to stay rigid. Then again, perhaps the change in award could be based on how long it took to get there.

All this is assuming that the difficulty never goes down which I think needs to be part of the plan. Difficulty is based on coin-hours, not amount of computing power, so I really don't think it should be an issue unless someone is trying to grief the system or intentionally make coins cost more to produce so their existing hoard is worth more. To do it will cost them a lot of money, but I'm trying to think of the far-future.

SC2 is using a method of trusted peers which also prevents 51% attacks. Might wanna look into it. Bitcoin implementation is a joke that was not thought out properly by them Japanese scammers.

I'm just curious. Do you have a link? I'm searching the solidcointalk.org board and I see that claim. But I can't seem to find an explanation.

I wasn't trying to tie it to the dollar per se, that was just an example for the initial stabilization phase. The coin's price will essentially be tied to the global average electricity cost. So if global electricity suddenly got 10% cheaper (eg. new invention) all coins will lose 10% of their value and be worth, for example, 90 cents each (and vice-versa). I find that a very reasonable drawback though, not to mention unavoidable. But if the fed prints a trillion dollars tomorrow that will make the dollar cheaper, so it'll cost people more cents per Kilowatt worldwide, so the coins remain essentially unchanged.

But who will the merchants pay their money for to acquire bitcoin credit? How will it be decentralized? My suggestion keeps everything in the current design intact except for the number of coins each new block will contain. That's why I believe it requires very simple modification to the current code, plus it will be just as familiar to the existing audience.

I'm proposing that it is avoidable in the newest version of my proposal. :)


Not sure what you mean. By putting their money on the line, I mean they must maintain a certain balance in their account to get transaction fees refunded. It is basically security against approving bad spends. The penalty for attempting to subvert the network is losing whatever balance you have.


It will be less decentralized in that each node in the network is aware of what other nodes are approving transactions. It will be less anonymous in that nodes that are approving transactions will have to sign those transactions. But these trade-offs mean that the network does not rely on hashing power and it will ultimately be far more scalable and far more adjustable than bitcoin. The endgame for bitcoin is that bank-like entities will be running the show as regular nodes have no hope of actually being a part of the network (8Gb/s bandwidth, a terabyte of space every few days). It puts the power back into the hands of the elite.

Not to mention that any direct competitor to bitcoin that is forked from bitcoin is going to have the major issue of 51% attacks on the network. See fairbrix, SC2, namecoin, etc.

a taste of the next proposal:

TD-1) Determining Speed of Currency Creation; Adjusting for Processing Power
Coin-Hours are used to determine how quickly currency has been created.

Coin-Hours = Number of Peers Per Mint Block * Time Between Mint Blocks

If there are 35 users paid in a given Mint Block and 3 hours have passed since the last Mint Block from that CoreNet, the Coin-Hours for this block is 35 * 3 or 105 Coin-Hours.

Coin-Hours are added to a value stored in the Consensus Block. The number of Coin-Hours and the number of coins created is kept track for a period of 30 coin-creation CBs. These 30 CBs are called a Coin Creation Period (CCP). 10 of these such periods are maintained in each CB with the newest overwriting the oldest. For a CB to count as a coin-creation CB, the following formula is used:

Minimum Coins to Count for CCP = # of Coins Minted in Last 10 CCPs / 300 * 0.50
OR
Minimum Coins to Count for CCP = 1,000

Whichever is higher. By multiplying by half in the first formula, the amount of coins required to increase the difficulty can go down over time so that it is not trivially easy to avoid increasing the difficulty by staying just under the coins necessary to do so. However, even during CBs when not enough coins are produced, the Coin-Hours and coins are still recorded so that a maximum number of coins can be created before changing the difficulty.

Maximum Coins Before Difficulty Change = # of Coins Minted in Last 10 CCPs / 10 * 1.5

To determine the increase in processing power, it is simply a matter dividing the number of coins by the Coin-Hours to get the number of hours it took for an average computer to make one coin, then compare it to the previous CCP. The increase in this power is determined with a simple formula:

Processing Power Increase = (Previous CCP Coin-Hours / Previous CCP Coins) / (Current CCP Coin-Hours / Current CCP Coins)

If this number is less than one, one is used so that the difficulty can never go down. To avoid intentional, large increases in difficulty as an attack on the network, a weighted system based on the last 9 difficulty increases is used as follows (with example increases):

Oldest (10th-9th) CCP weight: 0.05 x 1.06 increase (0.053)
9th-8th CCP weight: 0.05 x 1.09 (0.0545)
8th-7th: 0.05 x 1.04 (0.052)
7th-6th: 0.05 x 1.00 (0.05)
6th-5th: 0.10 x 1.08 (0.108)
5th-4th: 0.10 x 1.07 (0.107)
4th-3rd: 0.10 x 1.03 (0.103)
3rd-2nd: 0.20 x 1.07 (0.214)
2nd-current: 0.30 x 1.25 (0.375)

A very large increase was used as the last amount to show what might happen if someone were to attack the difficulty of the Network: a 1.1165 final number, or an 11.7% increase in difficulty. Unless this attack is sustained, the difficulty will not increase for some time afterwards.



The difficulty attack will probably go in a separate section, but there it is for an example. At bitcoin's estimated $10,000 cost to run per day, this attack would require $300,000 of electricity just to equal the network, so whatever increase it was trying to achieve would be cut in half unless it does more than half the network, then it would only be weighted 30% (perhaps less, first run of numbers). Much of the coins would be distributed to other people in the same Net, so most of that electricity is lost too.

It's a ton of work as I am completely revising it again, and I got stuck at one point which now I think I have a solution. Still so much stuff to put down as I'm trying to go a lot more into technical details. But I'm keeping the tech details separate so they don't cloud up the basic stuff. Haven't had the time to put into it yet, it'll be out when it's out. ;)