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

BTW, Cool image!

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


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


I'm not saying you can't do it because you are a stupid fuck. I'm saying in 1936 Alonzo Church and Alen Turing proved that some things are computationally undecidable



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

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



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

Plug Computers cost less then $99 and run at about 5 watts. Check the block diagram and look for the little block labeled "Cryptographic Engine and Security Accelerator"



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

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



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



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

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

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

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

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

---

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

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

---

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

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


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

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

Really. One more time...

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

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

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

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

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

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

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


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

--- Summary For the Thinking Impaired ---

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

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

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

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

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

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

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

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

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

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


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

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

---

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

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

---

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

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



-QED-

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

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



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

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


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

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

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

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


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

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


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

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

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.

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.

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

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

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.

*Needlessly Ranting* Hoping you will change your ways

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

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

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

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

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

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

I 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?

Epiphany!

Now I understand your insistence on a transaction fee! It destroys the evidence of the scam!

If that 5 ENC gets traded around enough, it eventually evaporates via the fee! There is no last client to go back to exchange and find the backing $5 is long gone!

Brilliant! Or, Sinister! I'm not really sure yet. :-)



I see that your intention is for the system to be honest. I'm pretty sure you understand what is happening. But your explanations are sorely lacking.

Indeed, there is zero possibility of taking 1 ENC back to the electric company and asking them to provide you with 10 kwh or electricity in exchange. That is the obvious concept that every potential client can't help but grasp intuitively. This is where your explanations need to focus.

In your explanation, "But that $5 that was put into ENC stays in the ENC economy; it can never leave." is either fallacious or intentionally misleading. The $5 becomes 5 ENC, and it wanders the economy. But is evaporates as it wanders in increments equal to the fee. It doesn't stay in the economy at all.

If the fee was 10%, to exaggerate the speed of the example, after one transaction the 5 ENC would become 5.00-0.50=4.50 ENC. After the next, 4.50-0.45=4.05 ENC. After the next, 3.65 ENC, 3.29 ENC,... It is an infinite regression that will eventually be rounded off as ZERO.

Done "fairly" all the clients pay a fee that equals exactly the miner's cost of electricity. The miners don't profit at all for their effort. They only benefit by having access to a system, to which even miners use as and pay as clients.

Done! I get it.

But the best way to convince people to become clients of such a system, is to convince them that the system, as a whole, does its absolute best to MINIMIZE overhead=electricity=fees. This is where I think your persuasiveness is currently failing.

No, I'm serious. I've been convinced from the beginning that the system should use as little electricity as possible to assure the monetary policy goals were met. If no new currency is needed in circulation then I propose they should be infinitely expensive to create in kwh. If many are needed in circulation they should be cheep to create in kwh.

You seem to counter propose that each ENC coin must represent *having already burned* precisely 10 kwh. This is the part I think is implausible. I'll submit a simplified example.


This is precisely the situation I was trying to allude to in the previous example. Let me make it clearer.

I have $5 excess that I don't want to use to buy 50kwh of ELECTRICITY to run my air conditioner THIS MORNING.
So I buy $5 worth of ELECTRICITY and mine 5 ENC.
In the heat of the afternoon, I take my 5 ENC to the exchange and sell them to a client for $5.
I spend my $5 to buy 50kwh of ELECTRICITY to run my air conditioner.

No matter how you try to convince them otherwise, the electric company is going to expect $10 from you. Even though, you only purchased $5 worth of air conditioning. You took $5 out of your pocket and gave it to the electric company, so you think the system is fair. ("valuable as a medium of exchange")

However, the anonymous exchange client you took $5 from to make it seem fair, (to you) is likely to see otherwise. The fact that this anonymous stranger purchased your right to take $5 from some other anonymous exchange client, doesn't make the issue go away. It just delays anyone noticing the scam until you can get away.

In this world, miners can only sell ENC on an exchange. They can never buy ENC. If they were to buy ENC on the exchange, they would be buying back the same debt they already sold. But, (and this is the most important part to close the loop) they can't even try to buy back the debt they previously sold. Because they don't have the money. The electric company has that money.


I look forward to your new proposal. Please address this scenario in place of the previous. It states my point more succinctly.