[ANNOUNCE] The Proposal for EnCoin

[Etlase2]

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

[1714007911]

1714007911

[1714007911]

1714007911

[Red]

•   To provide a stable currency that merchants can rely on in both value and security.

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?

[Etlase2]

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.

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).

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?

Not at all.

[Red]

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).

*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.

[Etlase2]

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.

[Red]

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.

[Etlase2]

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.

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.

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.

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.

THIS FUNCTION PROVED INSUFFICIENT FOR PERMANENT PROTECTION.

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.

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.

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.

I can't convey these reasons unless we accept a more specific vocabulary.

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.

But mining clearly does not provide any additional protection from theft, forgery, fraud, or history modification.

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?

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.

...

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.

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.

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.

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

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.

[Etlase2]

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.

[Red]

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)

I always meant anonymity in IP->wallet terms.

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!

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.

I like this feature for anonymity reasons.

A huge waste of network resources and terribly unscalable.

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.

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.

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

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.

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?

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.

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.

[Red]

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.

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.

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.

[Etlase2]

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'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 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.

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.

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.

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.

Your point is that if we all agreed and then locked in each primary block each hour, 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 hour old, they would do away with the possibility of long term history substitution attacks as well.

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.

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.

Well, see my other new post about that.

[Red]

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 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.

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.

If an exchange decides to go rogue

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 quite sure long term history substitution attacks are not possible...

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.

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.

Well, see my other new post about that.

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

[Etlase2]

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.

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.

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.

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.

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. Any one "compliant" peer  should be able to detect this. Then it very likely becomes a human problem.

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.

[Red]

Well, this is partially my fault, but I've sort of readjusted what my definition of a freenet is. ...
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.

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.

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!).

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 did say that it would be possible to have transaction sizes in the tens of bytes...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 met the Jason Scott recently. He runs Archive Team 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!

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.

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!

[Etlase2]

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.

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.

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.

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.

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.

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.

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.

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.

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?

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.

I met the Jason Scott recently. He runs Archive Team 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!

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.

[Red]

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.

[Red]

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.

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?

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.

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.

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.

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...

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.

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.

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!

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

Unsure to which antecedent you are referring.

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.

Understood. Totally!

[Etlase2]

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

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.
yes

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)
yes, whichever transaction gets >50% of the rep first wins

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.)
the FN transaction blocks do not need to be ordered, but the whole transaction log needs to be ordered so that all FNs can agree on the same hash during the PB - FNs won't add a transaction to the overall log until it has >50% rep confirmation

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.
would be another deterministic function, alphanumeric sort based on from acct/to acct/amount/etc.

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.
yes

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.
not directly, no.

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.
yes, anyone that disagrees is booted

------

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.)
mentioned in rev3, any transaction with >50% rep before the set time (87,300 seconds since the last PB) will go in the current block, anything after has to wait a day
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?
this would be covered by who is connected to whom as I stated before. if FN A's transaction log hash value differs from FN B's, then they can compare byte sizes to see who has more as a starting point. I'm sure hash trees could be used to narrow down the window of what specific transactions are missing so that needless data doesn't get transferred
c) If the above mentioned non-determinism causes conflicts, how are they resolved?
once the missing transactions are discovered, whoever has the missing ones can send missing FN confirmation blocks. FN A could say "hey I've only got 30% rep confirmation on transaction Q, here are the hash values for the confirmation blocks I have." FN B says "oh ok you are missing these confirmation blocks [sends data]" - doing this one at a time would actually probably confirm other transactions if they are missing a lot
d) Which peers are responsible for the process?
each peer is responsible for making sure the peers that they are connected to all agree. So for Peer X in FN A who is connected to FN's B, C, and D, once Peer X has settled everything up he sends the "all clear" signal to his FN that B, C, D are in agreement. Since 1-2 other peers in the same FN would also be connected to other members of B, C, and D, this can be double/triple checked

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.)
backdating a personal transaction won't work as there is no proof of confirmation. I'm not sure what it would achieve either, exactly.

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.
they can process transactions, but the smaller subset would never get confirmations because they don't have >50% of the reputation (based on the freenets that signed the previous PB).
I had thought minters would lose their minting blocks, but now I don't know if it's necessary. I had thought they would work by using the PB hash as a starting point, but that could very well be the network time instead. However, if this netsplit affects intra-FN communication, the winning FN block would be missing the effort from the members who were cut off.
What happens when there is a communication disconnect during a PB is something I haven't covered. I mentioned that I wasn't sure what to do if a FN is missing from the PB consensus in rev2. I suppose the smaller half can build its own PB from previously confirmed >50% rep transactions for the day, and then accept a new PB when the networks reconnect. How long they would wait before assuming everybody else is gone is hard to say. In the mean time, transactions can't be confirmed. (I did mention that FNs that did not show up for the consensus in rev3 that they would lose 20 RPs, so it would take awhile but eventually the split would be able to start confirming transactions again.) Clients could be notified of this split though, so at least they know something's up.

Unfortunately, in general, this form of consensus is definitely more open to DoS. I actually mentioned this in a PM to someone who asked me a few questions
Performing consensus more often than every 24 hours might help things a little bit. I don't know, it's another big question I suppose.

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.

Well, the weighted influence always comes in on depending what gets into a PB. If >50% rep has it before the consensus time, then it's in. Transactions, mint blocks, anything that matters.

[Etlase2]

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.

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.

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

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.

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.

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.

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!

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.

Unsure to which antecedent you are referring.

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.

[Red]

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.
not directly, no.

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

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

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?

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.)
backdating a personal transaction won't work as there is no proof of confirmation. I'm not sure what it would achieve either, exactly.

Well, the weighted influence always comes in on depending what gets into a PB. If >50% rep has it before the consensus time, then it's in. Transactions, mint blocks, anything that matters.

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.

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

they can process transactions, but the smaller subset would never get confirmations because they don't have >50% of the reputation (based on the freenets that signed the previous PB).

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.