Topic: [ANNOUNCE] The Proposal for EnCoin - page 6. (Read 9439 times)

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?

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

Found some interesting directions to pursue regarding the time problem.

Vector Clocks
Internal Tree Clocks

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.

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 ?

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.

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.

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.

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!

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.

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.


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.

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

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.

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.

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.

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.

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.

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.