Topic: [ANNOUNCE] EnCoin - An alternative with a completely different paradigm - page 3. (Read 12158 times)

I'm going to take one more shot at this. Your calling me back here has been fun. I want to thank you for that.

I understand what you are saying about: trust = hash * time vs. bitcoin's way. I don't think that is "trust" though. I think hash * time = "effort". I'd don't think I'd even call it "work" because I'm not sure anything is actually getting done for the effort.

I'm also absolutely sure you overstate the dangers to bitcoin accounting. In bitcoin if you gain 51% of the hash power and you want to delete a transaction that happened 5 blocks back, you basically have zero hope of accomplishing that. If you have 51% of the hash power you CANNOT generate a fake transaction. You also can't transfer money from one account to another. You can't even do more than stall a transaction with 51% probability.

The dangers you hypothesized for encoin were much harsher than those bitcoin is currently suffers from.


I'll let most of this slide, since I'm under a pseudonymous handle. But trust me, I have more P2P experience than you know.

The important part of my message is about compliance to the protocol. In bitcoin, even with 75% of the hashing power, you can't stick a transaction into a block if it won't pass the validation rules. Every other honest node will reject your block. Worse, they'll all know you are a liar. That is what compliance means.

If I have your previous PB balances and all of the new transactions for this period, you had better not try to give me a new PB with balances that don't match the known transactions. If you do, you sure as hell better be able to produce a valid transaction I'm missing that reconciles the differences. I don't give a flying fart if your (hash * time) effort is 100% and my effort is 0%. If the math doesn't work you are still lying. That is what compliance means.

For that matter, previous investment of time adds nothing to ones trustworthiness. Say, I take a copy of the bitcoin block chain and validate it. I am now equally as capable as any other node at spotting fraudulent activity. I've spend no time and generated not a single hash. But even if the 10 longest running nodes agree to accept a new block with an invalid transaction in it, I can still publicly call them faulty at best liars at worst. Compliance means agreeing with the specification, not with the majority.

My recourse to compliance violations is not to bend over and take it because others have 51% of an imaginary quantity. My recourse is to publish the data on this forum. Call you a liar. Call the authorities and start sending out press releases. That is what compliance means.

---

If the only digital currencies you've ever seen are bitcoin analogs, I know it maybe hard to understand that most digital currencies and money transfer services strive to not waste CPU cycles or electricity. Expending needless effort is simply not required to guarantee the validity of crypto-currency accounting.

If you changed bitcoin into a client server system with only a single bitcoin server doing the accounting, it would remain equally as trustworthy and secure as it is now. So long as everyone can download the server's history and validate the current state, there are simply very few ways for the server to cheat. If every client keeps track of the most recent couple of block hashes, then periodically checks to make sure they don't leave the chain, there is simply nothing the server can do while still remaining in compliance. Every false move is instantly detectable by even the simplest of client.

Never fail quietly! It's one of the most important rules of software design.

---

I can show you how to take bitcoin's current implementation, remove the proof-of-work nonsense, and turn it into P2P network of Trusted Servers as you described. In the process you'll lose none of bitcoin's current security. If you want to add back in constant kwh mining and transaction fees, to help sustain a stable monetary policy that's awesome!

If you want to add a complicated history of effort model to rationalize sharing the wealth, that's your own business (literally). It adds, however, neither security nor trust.


A while back there was a bitcoin hack where a trojan stole wallets and transfered money out of people's accounts. There is nothing in the rules of bitcoin that prohibits that. There is certainly nothing in the rules that enables anyone to reverse that. But the programmers changed the rules and rolled things back.

That is what "Trust" means.

take a gander at this and see if you can make it to the 1:30 mark and beyond:

http://www.youtube.com/watch?v=hx16a72j__8&feature=player_embedded

additionally, this is a lot to ask, but try to see if you can draw any parallels

There is no central issuer of Bitcoins, and Encoin doesn't exist.

By the way, everything I have stated that is not in regards to economic policy could have been done with bitcoin.

The goal of Encoin's economic policy is not to facilitate a large transfer of wealth from late adopters to early adopters. It is to provide a stable medium of exchange. While unpredictable future events (fusion power for one) could slightly devalue the currency, it is absolutely nowhere even close to even being remotely in the same solar system as what someone with 25k or 100k or any large sum of bitcoins could do to the network that is based solely on scarcity with no inherent value to back it up. Please keep that in mind before dismissing encoin out of hand because you don't think that it can work.

Bitcoin is fiat, just like dollars and euros and whatever else. Encoin is not.

Perhaps it should inspire some confidence that I have had defense to this type of attack in mind in designing every facet of my proposal.


See above. In simple terms, where Bitcoin and Encoin differ is that Bitcoin associates hash power with trust whereas Encoin associates hash power times time with trust. Because the value of time is a recorded figure (in the form of points of trust), this figure can be changed when there is proof that it needs to be changed.

In simple equations:
trust = hash
trust = hash * time

In bitcoin, an attack with >50% computational power can only be thwarted by more computational power. This means, as long as the attacker feels like attacking, the network is interrupted and may be permanently damaged thereafter.
In encoin, an attack with >50% trust can be thwarted by setting the time factor to 0. This means, the attacker gets one shot at doing something bad when they have enough trust, then that shot is over unless they reinvest hundreds of thousands or millions of dollars and a whole lot more time.

To "hack" the trust time, an attacker would need the private keys of hundreds or thousands of users. In which case they could just spend all of their money and cause havoc anyway. To "hack" the hash, an attacker need only overtake several pools, or invent some kind of hardware that performs hashes magnitudes more quickly than typical hardware, or wait for the network to contract such as when the btc award halves.

If the average amount of trust in the working network is 180, the attacker essentially has to put 180 times the effort TIMES >50% of the number of network trusts into disrupting the network. For one shot. In bitcoin, the attacker can keep on shooting and there is nothing that anyone can do about it.

Is it any clearer now why I think a system of trust is far superior?


As I mentioned before, a sybil attack relies on gaining trust before performing an attack. If this "authority" pretended to be trustworthy, everyone would think they're trustworthy. Until they're not. Since Encoin relies on heavy amounts of electricity to gain this trust, it is very difficult and hard to come by. It cannot be forged. It can be revoked completely by consensus.

EDIT: I skimmed over the first sentence when replying. The non-anonymous relationships are nowhere near what you suggest. The non-anonymous relationships only refer to ip address->wallet (tied to user trust) relationships. With bitcoin, you never have any idea of who you're dealing with. There is no recorded history other than transactions.


Both of these sentiments are somewhat naive. There is no central authority that says what being compliant is or what the rules are. A decentralized network has to agree on all sorts of different things with the potential for infiltrators/attackers to try throwing a wrench in the mix whenever they feel a dash of whimsy. Part of the decentralizing rules (a large part) are how to handle it when someone does decide to go rogue.


There is no need for humans to do anything but run their honest clients.


Every user that is a member of a TrustNet (one of many) gets the private key to that TrustNet, so they can pretend to sign something that the TrustNet did not agree to sign.


It only is if you can't possibly get away with it. If there were no safety checks for keeping in mind that there is no guarantee that everyone is honest, then these types of attacks would cause major issues with the network.


What if a malicious entity controls more than 50% of the trust networks? How will clients know that there is a problem if more than half the network says "everything's fine here, move along."


This is highly centralized and won't be a part of any P2P protocol. (except maybe ripple, hehe)


If I didn't, the network couldn't be secure.


Again, you say "compliant" with a naive understanding. Compliant is what the network says is compliant. Honest networks will detect it, but honest networks can't guarantee that they will be connected to every user. If a user is connected to only dishonest networks, how will he know that the rules have been broken? The dishonest networks certainly aren't going to volunteer this information. But, because it will be obvious that the network has split in half based on half of the normal trust in the primary block (the dishonest networks have set the trust to the honest networks to zero in their version of the new encoin), the client can demand the transaction log for the last block and discover that account balances do not match up with the transactions (or they will refuse to send it). So now the client knows empirically that something is massively wrong. In bitcoin, everyone except the people who got screwed will continue on, none-the-wiser. Save maybe a forum rant or two where the evidence is hard to verify.


See above. The network will reach a consensus among honest TrustNets. They cannot force dishonest TrustNets to agree to something they are intentionally not agreeing to. The network will fork between honest and dishonest TrustNets. This is by design. Cut out the cancer.


They can. But they can't make a client be connected to them to let them know.


I think you have a gross misunderstanding of the client/server model here (which was probably clarified in my last long post). I'm sure it's more my fault than anything by not being completely clear in the proposal. But TrustNets are a replacement for pools, I thought that was made obvious. Regular users of the bitcoin network are not involved in any pools. The people in TrustNets are being paid in the form of new demand for currency by the expansion of the network or gradual destruction of existing currency. Their services are not just to make coins, but to secure the network. Secure, secure, secure.

Perhaps some of my design decisions will make a little bit more sense now.

Well, it might not be. But just in case it is, I'm going to write down my logic. Maybe we can all bash on it and see where the logic takes us.

----

The whole concept is based upon Arbitrage. The instantaneous buying and selling of something in different markets. In this case, we want to buy ENC in the "electrical market" using dollars and sell them in the ENC marketplace for dollars. (Your currency may vary) The tendency toward a fixed value is based upon the self-interest of the participating humans. They only participate if it seems profitable. If it appears unprofitable the humans do nothing.

So specifically, if a human thinks he can generate excess ENC for less dollars of electricity than the dollars he can IMMEDIATELY sell the ENC for, he begins mining. If he thinks it will cost more dollars of electricity than the ENC are worth, he stops mining. It's an intellectual gamble like in any financial marketplace. You have to put your dollars at risk to play.

---

For the sake of discussion I'm going to propose a hybrid system that's like bitcoin, except that instead of using mining to add the next transaction block to the chain, it adds the block through consensus. 100% of the existing nodes decide that all transactions in that block are valid. Then they lock that block into the chain forever. There is also no standard 50 BTC award. Transaction accounting is NOT rewarded. For this discussion, just pretend I can prove that it's a secure process.

So in my version of the ENC system, mining is a completely optional process to that of transaction accounting. Mining DOES NOT secure transaction accounting.

The process works like I've discussed in this thread.

1) Every transaction has a X% tax that is destroyed. This provides a baseline tendency that reduces the ENC supply. Transaction are grouped into 10 min blocks like with bitcoin.

2) Mining is optional and can be run by anyone at any time. Mining generates new ENC transactions through a proof-of-work concept similar to bitcoin. The main differences more complicated ENC generation rules, and the process for varying the proof-of-work's difficulty.

Mining takes place in the 10 minute interval after the previous (consensus created) transaction block. The proof-of-work can be solved at increasing difficulty levels, leading to increasing rewards.

The transaction generation rules are as follows:

If the miner solves the proof-of-work at the (current+0) difficulty level, the transaction must contain:
a) Tax reimbursements for every transaction in the prior transaction block, paid back to those from which the tax was taken.
b) ZERO additional reward for the miner.

If the miner solves the proof-of-work at the (current+1) difficulty level, the transaction must contain:
a) Tax reimbursements for every transaction in the prior transaction block, paid back to those from which the tax was taken.
b) (Total Tax)/2 as reward for the miner.

If the miner solves the proof-of-work at the (current+2) difficulty level, the transaction must contain:
a) Tax reimbursements for every transaction in the prior transaction block, paid back to those from which the tax was taken.
b) (Total Tax)*2 as reward for the miner.

Mining is a competitive process. Whoever generates the proof-of-work transaction with the highest difficult in the 10 minute window wins. If there is more than one at the highest difficulty, the first wins.


Difficult is algorithmically adjusted for the next 10 minute period based upon the results of the previous.

If ZERO mining transactions were submitted, the current difficulty is adjusted (-1).
If a current+0 transaction wins, the current difficulty remains unchanged (0).
If a current+1 transaction wins, the current difficulty is adjusted (+1).
If a current+2 transaction wins, the current difficulty is adjusted (+2).

---

As far as I can tell this tends to cause the following dynamics.

If the current difficulty causes higher electrical cost than the dollar value of ENC, there is minimal incentive to try and add new ENC coins to the system. As such the Tax will be lost, tending to slightly inflate the dollar value of ENC. The difficulty will also be reduced, tending to slightly lower the electrical cost of ENC.

If the current difficulty causes near equivalent electrical cost to the dollar value of ENC, anyone with a transaction in the prior block, has interest in mining for their tax reimbursement. This means the appropriate monetary action was to do nothing. (No tax penalties)

If the current difficulty causes less electrical cost than the dollar value of ENC, then there is a momentary arbitrage opportunity. No tax will be lost. New ENC will be added tending to slightly deflate the dollar value of ENC. The difficulty will also be increased, tending to slightly increase the electrical cost of ENC.
 
---

I think those rules tend toward some wandering equilibrium measured against the cost of electricity. I'm not totally sure of the exact function.

What does anyone else think?

Yes, having people actually vote to determine economic policy is certainly the best way. I mean, it works for politics after all.

And I love how you take my concession that it is impossible to maintain the exact rate of energy used per encoin as some kind of proof that the currency will fail. It is childish and willfully ignores the 5 pages of discussion in this thread.

Again, a problem of poor terminology in the proposal. There are two types of computers that use the network--computers providing the service of running the network, and computers that are making use of the services offered by the network. Whatever I end up calling these will probably not be peers or nodes or users or whatever as those terms are confusing. So let's just use client and server for now. Client Joe wants to spend money so he signs a transaction that sends 5 ENC to Client Bob. Joe connects to server Mary and sends the signed transaction. Mary is a part of a TrustNet/NT and checks to make sure Joe has enough money in his account, signs it with her user ID and TrustNet ID, then passes it along to every other TrustNet. Once Mary receives confirmation back from >50% of the total network trust, Mary lets Joe know that the transaction has been approved.

Now one issue here is that Bob isn't notified of the payment unless he specifically tells his server to keep an eye out for him. So Bob tells server Hillary that whenever an approved transaction comes through with his address, let him know about it.

Since this system relies on a direct ip address->wallet address correlation, I am thinking on a layer of obfuscation that is similar to bitcoin, but one that removes a lot of the burden off of the servers and keeps it on the clients. So there would be, in effect, "the city" where the TrustNets operate and exchange information, and "the cloud" where clients communicate with each other about all the stuff that the city is doing. If Joe wants to send a transaction pseudo-anonymously, he can tell his connected peers in the cloud to send his transaction a random number of hops (client A to B, B to C, C to D, and so on) before sending it to the city. If everybody does this, it is not possible for city or cloud peers to know where the transaction originated. But it makes things a bit complicated when the city sends confirmations out, as they may have to roll around the cloud for awhile without much guarantee that the person who cares about the transaction will see it. This concept is very work-in-progress at this point.

Basically, in a perfect world, every server would be connected to enough other servers to maintain network cohesiveness, and must also each be connected to the total number of network clients divided by the total number of network servers.


Each member of a TrustNet is working on the hashing problem and reporting in on their progress (to the rest of their TrustNet). Each member of a TrustNet is also an open server that allows incoming connections from clients that bring in new transactions or requests for information.


This time it means intra-NT peers. Again, terribly sorry about the word confusion. The draft is still really rough but I have it clearly in my head, it just doesn't always come out very clear.
Individual servers of a TrustNet will pass any received transactions immediately on to their fellow TN members. They are connected to 4-5 out of the potential 100 TN members so as not to spam each other out and have 94-95 extra open connections that aren't necessary. Each member is aware of which 100 users are in their TN, what their IP addresses are, and so on, they are just not always connected to every one.

So, this is how it will happen for a new transaction:

1. One member of the TN receives an incoming transaction from a client.
2. This member passes this transaction, unadulterated, on to the 4 or 5 TN members they are connected to.
3. These 4-5 members pass this transaction on to the other 3-4 TN members that they are connected to. (and so on)
4. Every 15 seconds, one member of the TN will be randomly selected* to put a block of new transactions (a block because to do it for every transaction would be a terrible waste of resources, especially when there may be hundreds of transactions per second) together that are signed by the TrustNet's private key. Then this block of signed transactions is passed along back to every TN member in the same manner as a new incoming transaction. One member is selected to do this so that the TN presents a united, identical block to other TNs. This allows infiltrators to be spotted more easily trying to insert bad spends into transaction blocks, or other nefarious things.
5. Each TN member then signs this block with their own private key and passes it along to each other, separate TN that they are connected to as well as "the cloud" as described earlier.

* - Randomly selected by a function that everybody agrees on, so at the time it happens, everyone will know who it is that got selected.


Everybody is assumed to be trustworthy until they prove that they aren't. For an infiltration attack to have any chance of succeeding, the infiltrator must act as a trusted member of the (overall) network first. Computers are doing the trusting, not humans. That would be far too much work for any person to keep up with. I'll talk more about this in response to your other post.


Yes you aren't seeing things the way I see them in my head. WHY THE HELL NOT? Mining proof-of-work proves that, until you do something bad, at least you can be trusted more than someone who doesn't mine because you are putting time, money, and effort into creating currency for the economy. Proof-of-work still has a very important purpose in the EnCoin design.

An iphone could be a good client, but not a good server as I described earlier.


Third paragraph of section 4 on network trusts/trustnets:

"As TNs continue to mint coins and agree on transactions with the rest of the network, the TrustNet Rating (TNR) of that TN will increase."

This has been in the proposal in one form or another since the beginning, so I'm not sure why you're confused. If your trust could increase just by being a "yes man" and agreeing with everybody else, you have not put any effort or money into the system, just a bit of network data. People are not individually making any of these decisions, it is all done by computer. There has to be a real, hard cost associated with gaining trust, or a sybil attack is much easier.


You really seem to take offense that some of the users involved in this theoretical project are out to make a profit. Mining secures the network (albeit in a much more indirect manner than bitcoin), miners need to get paid. It's rather simple. I'm not going to rehash my reasoning for why there are incentives for being more trusted or whatever else at this point. And the tax is destroyed, so miners do not get that money. It is there to help the economic contraction, or to create new demand (continued security!) in times of economic stability.

I'll respond to the other post later, this took a bit out of me.

Astral entities?

Well I'm glad we are in agreement. Thank you, I don't have any further business with Encoin.

What I said at the end of that post was referring specifically to if the average power consumption of devices to run the software went down. I thought I was fairly specific about each case.


I am referring to the hashing algorithm. FPGAs are designed to run one specific set of instructions. If the hashing algorithm changes, you need to build a new FPGA. Not that useful!


Now you are being purposefully dense for the sake of argument. To expect that a currency based around a cost to produce that is based around computers using energy based around solving mathematical equations where that equation will always result in the same (value $$) amount of energy used until the end of time is ridiculous.

One huge, glaring flaw in bitcoin that is lacking the obvious foresight of this type is evident when the btc award halves. Since there is no comparable difficulty change, if the (sell) value of BTC is lower than what the new cost to produce will be, the difficulty is going to be far higher. If half the network leaves, difficulty is immediately doubled for the other half. Now difficulty is doubled AND award is halved. That means for the people that don't leave, they are now making 1/4th the amount of BTC for their energy and time output as the block before. Difficulty adjusts every 2 weeks on average, so it may not end up adjusting for over a month or more as people struggle to find very difficult blocks. This could cause a meltdown in the mining network.

How? I don't see how this is possible.

I agree. That is really the question I showed up to hear the answer to also.

I hear philosophy about why a constant value is good. I agree with that philosophy. I don't yet see how anything in the proposal facilitates that though.

---

As a side note, I think I have actually come up with the beginnings of algorithm that might suffice. It is clearly only a partial solution. I haven't solved the bootstrap problem.

Technically, in my case, it's not 1 ENC = 10 kwh. It's closer to 1 ENC = 10 kwh * avg($/kwh). One ENC trades in dollars at the same price that 10 kwh trades in dollars. I don't know if 10 is the right constant either. It's a little more nebulous than that.

So hypothetically, say we had a currently running ENC system where the price of 1 ENC = $X = cost_of(Y kwh).
The goal of my algorithm is to cause the $_value_of(1 ENC) to tend toward the value_of(const Y kwh). This relationship should hold over time, even with changes in technology and changes in the price of electricity.

Again, I can't bootstrap this yet. Nor can I drive the ENC price toward any particular Y value. But if it is currently at a particular Y value, I think I can keep it there over time.

Anyone interested?

This post does not inspire confidence at all.

You know of course that the Sybil attack was one of the prime motivations for developing the wacky proof-of-work calculation. The logic goes, if we are going to have a group of anonymous peers, and we need to vote on things...

The answer of course is, never let anonymous fictional entities vote. It's silly.

Fortunately for you, EnCoin has relationships between non-anonymous trusted parties that investigate scamming, broadcast notices to the public, ban the scammers, and report them to the appropriate authorities. If the authority in your trust network can't do this, why on earth would you "trust" them?


The fact that you consider these possible (but implausible) attacks on your proposed system shows that your basic consensus (100% agreement) mechanism is non-existent.

Validity means a transaction is 100% in compliance with the rules of the system. There is no negotiation involved. No vote is ever required.

ATTACK: TrustNet tries to pay itself too much money

This should be trivially detected and prevented by *every* other TrustNet. It is either a defect in that peer, or fraud committed by the peers owner. The defective/fraudulent TrustNet entity and all its users should be banned until trusted humans determine which problem it is.

ATTACK: User abuses a TrustNet’s trust by approving bad spends (equivalent of a double spend in bitcoin)

WTF? How can any group of peers abuse the TrustNet's trust? The TrustNet was supposed to be the party everyone else was trusting? The only way to attempt a double spend is to simultaneously submit two conflicting transactions to different TrustNets. Both would be accepted and each would "race" the other to see which got "51% Trust" first.

That whole concept is STUPID and IRRESPONSIBLE.

Both transactions are part of a single common attempt at fraud. This should be detected in 100% of the cases, by 100% of compliant Trust Networks. In EnCoins case it should happen within 30 seconds or so. Both transactions should fail immediately so the targets of the fraud can be notified before irretrievable property changes hands.

All source accounts (transaction in-points) of both transactions should be locked system-wide. That prevents further attempts at fraud. Notice of the fraud attempt should be broadcast globally so nobody attempts to deal with the fraudster again. The locks should not be removed until the account owner presents himself to a trusted human and offers a believable explanation of how the situation happened honestly. 100% of the trusted humans must agree to remove the locks.

ATTACK: Control 50% or more of the total network trust and use it to change wallet balances
STATUS: Possible, and may cause temporary, but correctable problems.

REALLY! You even consider this a possibility? Arrg! If this can't be immediately detected by 100% of compliant Trust Networks and broadcast system-wide, then really there is no reason for anyone to trust your EnCoin at all.

I mean really, you are claiming that periodically your system "cools down" to reach a common consensus (100% agreement) point. At that point 100% of the Trust Networks agree on 100% of the account balances. You are saying that somehow 51% of the networks can conspire to change a balance or submit a fraudulent transaction and the other 49% either can't detect and/or can't prevent this fraud?

Any single compliant network must be able to validate the compliance of every other network. If they can't there is zero point in anyone trusting even an honest "Trust Network".

---

Suddenly I have zero confidence in your proposed implementation.
Convince me that I'm wrong.

May not ever happen? You seriously think calculating won't get more energy efficient? It will happen. And actually it has been brought up. I asked how you intend to equate encoins to kwh in my first post in this thread. All I've heard is about a magical algorithm that somehow takes information impossible to predict into account to maintain the equation 1 ENC = 10 kwh accurate.


What algorithm? I don't see it anywhere. It's only a hypothetical algorithm.


You are going to fork every time technology screws your currency? I thought you had a super plan to prevent that. Or was that the super plan?

Part of my confusion is that you are not separating Physical entities from Logical entities.

As best I can tell, a "Network Trust" is a logical grouping of physical peers. I'm not sure if you consider these peers to be the humans or these human's (zero?, one or more) computer nodes. Can I be part of a "Network Trust" (to send and receive coins), without running a node at all? Do I have to be part of a "Network Trust" to send and receive coins? I guess I'm asking, are NT's optional just so I can share in your reward scheme?

I understand the logic of what you said. But who (what peers) is actually doing the work for a given "Network Trust" group? Does every NT member receive every broadcasted block from the other NTs? Or is there one-or-more delegates for each NT that NT members are *required* to trust? That was what I was referring to below.

I got really confused about your use of the term network peers here. Sometimes it seems to mean intra-NT peers. Other times it seems to mean inter-NT relationships.

And the statement "they will be putting" is completely nebulous. I understand why they will be putting together a block. I just have no idea who they are? Is there a single delegate for the NT? Do the members of the NT collaborate together? How do they share data? Who is responsible for resending the block every few seconds?

It seems like there is a delegation pattern at work here. But then you say "Each peer knows the address of every peer in their network in case Something Really Bad™ is happening (all 4 or 5 peers are disconnected, or all 4 or 5 appear to be doing shady stuff, or something similar)" which implies each peer is monitoring his NT peers, not trusting them.

I'm really confused.


Again, when I said "account(ing) part of your trust network peer," I was thinking about the delegate pattern. Supposed you delegated *all* the 1) receiving of NT member's transactions, 2) validation of NT member's transactions, 3) transaction block broadcasting and receiving, 4) validation and recording of inter-NT transactions. This could easily be done using only the power of an iPhone.

If you are not delegating the above 4 things to some "trusted" delegate node, then I'm totally confused about the dynamics of your NT group of nodes. If each member does these things individually without trusting the other members, then the batching, signing, and sending seems redundant.


I don't mean to be dense, but I'm totally baffled by this last paragraph.

We got all the way here, talking about a distributed system for trusted and verified transaction accounting. Never once did you mention any necessity for *mining* in order to guarantee transaction validity. Validity was guaranteed through transaction block signing (consensus notarization).

What on earth does mining secure? The only thing I see that it can possibly protect is the reward system for mining. This system seems to operate completely independently. In actually, it doesn't seem to secure the transaction system. It seems to rely on the consensus relationships of the underlying transaction system to frustrate subverting the mining reward system.

Again, I'm baffled.

I thought the mining system was a way to optimize monetary policy. Where "optimize" means, expand or contract the money supply as appropriate to maintain coin value stability. That is a hard problem and worth my time to think about.

On the other hand, levying a tax on every transaction and using *mining* as justification for redistributing this tax among miners... Well that seems to be an unnecessary problem to solve at all. At best it's a marketing problem. That's not at all where I want to waste my mental energy.

lol I come up with an idea to mitigate a scenario that may not ever happen, that had I not even mentioned probably wouldn't have even been brought up, and suddenly Encoin will be worthless if it doesn't adjust.

Not to mention FPGAs have already been covered by changing the algorithm, as those are the far more likely threat.

Not to mention if things really got out of hand, forking (in the sense that a major change must happen or the system is going to stop working effectively) is still always a possibility. One that I have a feeling bitcoin will make use of at some point soon.

Are you serious? This is the main point of your currency. If it can't adjust itself to match technological progress then Encoin is worthless. Do you really have a plan or are you just pretending to have a plan?

Since this came up in an IRC discussion, I want to see if anyone would care to poke holes.

http://en.wikipedia.org/wiki/Sybil_attack

"A Sybil attack is one in which an attacker subverts the reputation system of a peer-to-peer network by creating a large number of pseudonymous entities, using them to gain a disproportionately large influence. A reputation system's vulnerability to a Sybil attack depends on how cheaply identities can be generated, the degree to which the reputation system accepts inputs from entities that do not have a chain of trust linking them to a trusted entity, and whether the reputation system treats all entities identically."

A trusted identity does not come cheap in the EnCoin proposal. With a maximum TrustNet (temporary new name for network trusts) trust of 360, it would take 1 year to become among the most trusted. This would require finding at least one block a day. Someone else can calculate the variance, but to avoid losing 10 trust by missing a block, they would probably have to shoot for at least 3 blocks a day. At 4 blocks a day with average equipment, they would have to spend over $10k in electricity (not including hardware). So if we say 3 blocks, it would be closer to $7500, but let's just call it $10k for hardware costs.

In thinking about this actually before the IRC conversation, I realized it is more secure to force user id trust to be at minimum the same as network trust. So trying to infiltrate more trusted networks won't achieve anything. Also, on top of signing with the network ID, each user will have to sign their communications. This helps for scenario 2 below.

Anyways, if there are 100 networks (5,000 people, hardly out of line considering bitcoin has around 60k mining), they would need around 60 or more networks to keep up with the network if it is growing even slightly. Thus approximately $600,000 to perform a >50% trust attack. Now, for the scenarios I posited.

ATTACK: TrustNet tries to pay itself too much money
STATUS: Impossible. The total network decides on what the primary block is. TrustNets only put an award payout into their TNB (TrustNet Block) based on percentage. If >50% of the total network trust agrees to pay itself more, the clients will not agree with their primary block. In the honest network, all of those trusts will be set to 0. All of the user trusts will (most likely) be set to 0, and funds discarded. If an individual network attempts this, by whatever flawed reasoning, honest users will broadcast a message showing who agreed to the new block so that their network does not lose trust, and all the dishonest users lose all trust and funds.

ATTACK: User abuses a TrustNet’s trust by approving bad spends (equivalent of a double spend in bitcoin)
STATUS: Possible, but won't accomplish much. A “bad spend” happens when a spend is approved for more than what exists in a specific wallet. Every TrustNet does not necessarily know how much exists in a given account because they may not have received every transaction yet. If a TrustNet receives what it considers a bad spend, it will ask for all transactions to date (since the last primary block) for this wallet. Since TrustNets should be connected to more than one person from each other TrustNet (if not, they can still check with other TrustNets), they can multiply verify that they have missed a transaction, or that the node that originally sent the bad spend is being subversive. If the node is being subversive, a broadcast will be announced showing proof. They will have their trust set to 0 and funds removed.

ATTACK: Control 50% or more of the total network trust and use it to change wallet balances
STATUS: Possible, and may cause temporary, but correctable problems. If an agency takes control of 50% or more of the trust, they may decide to put whatever amount of coins in any wallet they choose. Assuming the client is brand new and has no previous blocks, they could get away with any amount. If the client has a recent block, warning flags will be raised for any suspicious amount of coins added to a wallet (e.g. more coins than the network could have created in the mean time). Since some clients will have the most recent block prior to the takeover, the attacker must account for this and make sure the amount is within reason. Note that the amount of effort required to pull off this attack would create far, far more coins than the attack itself. The attacker could also move balances from one account to another which would be less easily detected. Since this could only be proven by a complete transaction log (the size of which would be very high if the network averaged many transactions per second), being able to detect this easily might not be feasible in the future. Early on with few transactions, it will be easy to spot. This attack only works if the user is connected to only dishonest nodes. Honest nodes will be able to immediately point out that the dishonest network cannot prove that those balance transfers took place. Far in the future, this attack would cost months of time and could cost millions in electricity for a temporary disruption of service for some users. After that, the process would have to start completely anew as those TrustNets and users would lose all trust.


Can anyone give me actual scenarios of attack on the network that I can try to refute? Because the (2 person) consensus in IRC was "lol it's not even web of trust, just time"

$6m if there are 50,000 people on the network


edit: hell, I just realized that this attack could be thwarted even more easily by requiring all TrustNets to sign a hash of the new primary block with a hash tree of the signatures of the individuals that make up that that TrustNet. What like a few hundred bytes per TrustNet, a few hundred kb to verify that thousands of people agreed to this primary block, or that there has been a split...

Yeah, the terminology of the proposal is terrible at this juncture--I repeatedly swap between using "networks" or "trusts" to refer to Network Trusts too. That is #1 priority to fix in the next version of the proposal. Got any ideas on what to call Network Trusts? So far I have come up with "TrustNets". FWIW, I hadn't noticed you confuse the terminology anywhere...


Right, instead of the developers deciding this, every new primary block is decided this way. That why it isn't necessary for a new user to have any block but the most recent. Well, that and the fact that coins don't need to be traced back to their origin to prove they exist. I'm pretty sure there will be some kind of service (for a fee, of course) available to allow users to verify older transactions or get copies of older blocks, etc. But for how long someone retains a number of primary blocks is up to them. I'm thinking 30 days will be a minimum for the software to enforce, as the block chain will get very large very quickly with every account balance being stored in each block. And most likely those 30 days will be free to be queried by users so that they can check to see what transactions were made to them and so on while they were offline.

This again reduces anonymity though because when a user wants to know "what happened to wallet X" the network node that they're talking to has a reasonable idea that this IP belongs to that wallet. But I have ideas to obfuscate that a little bit (they aren't that good though, I will need help in designing this aspect).


Everyone who owns coins are not exactly doing the accounting. This is where the points-based trust level of the Network Trusts comes in to play.

Say there are network trusts A-D, with trust points like so:
A - 25
B - 100
C - 4
D - 75

The total trust of the network being 204.

User Q wants to send 50 coins to user I, so he contacts a node he knows to be on Network Trust A and sends the transaction. "A" gets the transaction, includes it with every other transaction they've received in the last 15 seconds or so, then signs it and sends it along to every other Network Trust that they are connected to (which, in a perfect world, should be nearly all of them). 15 seconds later, user I gets confirmation that networks A and B have signed it. Knowing that the total trust is 204 and A+B = 125, more than half of the network trust has agreed that this transaction is valid, and now it can not be overturned. If user I sees that only A+D have signed, that is only 100 trust, not more than half, and the transaction is currently not reliable. If A+D+C sign it, then again we are over half, the transaction can be trusted.


Actually, the way I see it is that members of a Network Trust stay in contact with 4 or 5 if their network peers regularly, and those stay in contact with 4-5 other network peers, and so on. Each peer knows the address of every peer in their network in case Something Really Bad™ is happening (all 4 or 5 peers are disconnected, or all 4 or 5 appear to be doing shady stuff, or something similar). But during this process they will be putting a block of recent transactions together (a block so EVERY transaction doesn't have to be signed independently by EVERY network trust--this is a big waste of resources as verifying signatures is much more CPU intensive than verifying hashes) and the network trust will agree as a whole on what block of transactions to sign and send out. The validation part should be trivial as all that needs to be done is take Current Account Balance, minus Current Transaction Amount, plus/minus Existing Transactions that are not in the primary block yet and make sure this number is Greater Than Zero.


Not exactly since the peers will also be working to mint coins. But since the primary block is so much smaller than the comparable bitcoin blockchain, a cell phone app only needs the most recent block and CAN verify, independently, whether or not a transaction is valid. Requiring only a few megabytes rather than potentially gigs and gigs that bitcoin will eventually require.


This is why I came up with the idea of the cool-down mode for network trusts. If the network is in contraction, or if some people don't feel like using 100% of their GPU for mining all the time, they can instead use 10% (figure up for debate, this may only be 5%), but still secure the network as if they were using 100% since it goes by trust instead of computational power. It isn't necessary to throw kWh at the network for accounting, but security. Security must be paramount. That is why I think giving a bonus for being in the cool-down mode is a good idea. You want as many people as possible to secure the network. And with good security comes accurate accounting.