[ANNOUNCE] EnCoin - An alternative with a completely different paradigm

[jago25_98]

Back on topic,

 I think it is really important to improve Bitcoin and I'm glad to see the paper.

I think if starting again is necessary then I am prepared to risk a lot of my coins to achieve improvements.

 In general, in the paper there are still a few too many arbitrary numbers that need to be replaced by carefully weighted and balanced formulas that adapt according to market conditions. We need to replace arbitrary values with maths.

 Can some of the changes proposed can be added to Bitcoin.

 I particularly like the idea of being able to subdivide the network.
 I'd like to see the possibility of hiding communications.
All these extra functions I'd like to see in forked clients, I'd like to see another less popular but more hardened network in place should there ever be a problem with the Bitcoin network, ideally that network would run more like a virus, not just over tcp but also other protocols, Bluetooth and radio.


 I know people don't like forks because it costs money but I'd rather have progress and protection of core Bitcoin ideas of decentralisation.

[1713469261]

1713469261

[1713469261]

1713469261

[1713469261]

1713469261

[1713469261]

1713469261

[1713469261]

1713469261

[1713469261]

1713469261

[Etlase2]

In general, in the paper there are still a few too many arbitrary numbers that need to be replaced by carefully weighted and balanced formulas that adapt according to market conditions. We need to replace arbitrary values with maths.

I agree wholeheartedly which is why I warned about it early on in the paper. I've been looking into the transaction fees, and they are terribly high as I described in the paper. Might end up being something like E0.10+0.25% or something, to make certain that it undercuts credit cards and paypal and such by a significant margin. It sucks that if someone wants to transfer from a "checking" account to a "savings" account that they'll have to pay a fee though. But as with Bitcoin, general banking services could be added as a layer on top of the system.

But debating these finer points is for naught if no one steps up to help.

Can some of the changes proposed can be added to Bitcoin.

Certainly the economic issues can't be addressed, unless bitcoin becomes a fork of itself. Might not be outside the realm of possibility when/if faith is lost in the system.

I particularly like the idea of being able to subdivide the network.
 I'd like to see the possibility of hiding communications.

These issues are somewhat interrelated, and I was also pondering this subject. Bitcoin uses so much unnecessary bandwidth in the name of anonymity. Why when Tor, I2P, VPNs, and general proxy servers exist? All of these can be easily added on top of encoin or bitcoin. And laundering services, should they be required, will also get better. None of this requires the protocol itself to do anything. People who want to be anonymous can find their own ways to be anonymous--why put that pressure on the network? Especially when it barely works with bitcoin. The encoin proposal uses smart ways to push the data around so that it is not duplicated unnecessarily, only enough to be sure that no one is doing something shady. But IP->wallet id anonymity is most definitely not preserved.

[Minsc]

I hope you don't become a detective when you grow up.

He's an internet detective!

[Etlase2]

V2.3 UPDATE: Moved some of the technical details into the main proposal. Network Trusts, Transactions, The System of Trust, Anonymity, and Why EnCoin have been updated.

The second paragraph here was added to "Why EnCoin"

So, the nature of EnCoin proposes a reasonable solution. The cost to produce one ENC equals approximately 10kWh of electricity. This is achieved by allowing anyone who wants to mine equal access to EnCoins, always at the same rate throughout its history. To keep demand up, EnCoins are “used up” by making trades, creating networks, sending messages, and so on. An actual cost is paid to pay for the network and keep people minting new coins.

It is a similar concept to demurrage, where the storing of currency has a fee, but in this case it is an option that is only available in an electronic medium: the spending of currency has a fee. The overall concept promotes both spending and saving. Saving, because there is inflation inherent in most fiat currency that is counteracted by nothing—EnCoins are destroyed on a regular basis and the cost to produce new EnCoins rises as fiat currency inflates. Spending, because the receiver bears the fee—and there is no promise that “what one EnCoin can buy today will buy two of tomorrow” with the deflationary concept of Bitcoin. As well, what one EnCoin can buy today could theoretically buy ten years from now, unlike inflationary fiat where what one buys today may only buy 4/5ths of in ten years. And with reduced transaction fees compared to credit cards, merchants may well be able to profitably charge less in EnCoin than they could in a comparable amount of world currency as those prices have 2-3% fees inherent.

Anyone care to discuss?

[Lolcust]

Could you outline, in layman's terms, how does the system physically measure energy expenditure that goes into a "coin" ?

[Etlase2]

There is obviously no way to physically measure energy expenditure. So it's a guess, as stated in section 3:

The cost to produce one ENC will not ever truly be at par with 10 kWh of electricity. It is merely a gauge in designing the difficulty of the algorithms while assuming an average amount of electricity used to solve those algorithms. The algorithms can only determine computational complexity—not the price of electricity or efficiency of the computers running the computations. However, assuming community support, EnCoin will have factors that smooth out variations in efficiency (see Technical Details).

Section 11:

•   Network Trust Block difficulty will be based around an average network being able to find one block every six hours. 6 hours x 50 people x 200Wh = 60kWh or 6 ENC.

200Wh being the magic number.

The guess doesn't particularly matter. If the average person is using 300Wh, then an average encoin costs 15kWh to produce instead of 10. Factors such as whether a person would leave their computer on with or without running encoin would come in to play, so there is no real way to be sure even if we could know how much power everyone was using.

What does matter is if the fundamental efficiency goes up (like everyone uses cheap machines designed to produce encoins for a very low electricity usage). Long term this would affect the price negatively, and people who saved would lose value.

However, I do have some comments related to this in section 11:

•   Probably will be an initial set of varying hash algorithms besides SHA256(SHA256()). These algorithms will change at every X Primary Blocks (randomly based on previous block hashes). Prevents ASICs from taking hold, etc.
•   When switching hashing algorithms, there should be a difficulty factor included. Perhaps a secondary vote to determine this. Really not sure yet, but obviously all different types of computers will react differently to a change in the hash. If the new hash is twice as difficult on average, the difficulty should be cut in half (assuming GPUs are still used). Community input will obviously be necessary. This or a 10 PB grace period where trust won’t be lost and the network can determine a new difficulty (perhaps even retroactively award ENC based on the new difficulty so as not to discourage people who are not minting new blocks).
•   Standard Network Trusts will have a minimum computational speed and a minimum payout for each wallet. Perhaps also an enforced maximum of 10% or so, so again that highly advanced processors that do not use a comparable amount of electricity can not gain an unfair advantage. Another possibility is to have a simple payout structure that awards fixed percentages based on who did the most computations. Network Trusts do not have to agree to this, but people using “honest hardware” would want to be in networks that do so.

The third comment is mostly related to when the machines first start infiltrating the market and it puts others at a competitive disadvantage. Even before that, more efficient machines will not get quite the bonus that they do in bitcoin. The goal is not to reward efficiency, only electricity.

The bolded part in comment 2 is quite important. These algorithms will have to be tested beforehand to make sure they do not perform better on CPUs because there is a big difference in electricity usage. But if some kind of hashing-specific card gets popular, it needs to be taken into account. It will be a tough situation.

For now, these issues are fairly moot, but I'm trying to leave it as open as possible for the future.

[Red]

Hi Etlase2,

I re-read the "on hording" thread to see why you found me. If you liked that thread, this and this are others that were running about the same time.

I'm on record here, (review my canon if you are interested) as being a big fan of the bitcoin concept. But also as presuming bitcoin will bubble and inevitably fail because of bitcoin's fixed monetary policy.

Now the summer bubble doesn't make me prescient. When I first came here bitcoins were 5 for a dollar. I didn't buy any because, as a result of the slashdot effect, they had just appreciated 100 fold. At that time there was a website called "the bitcoin faucet" that gave anyone who asked 5 BTC just to spread them around. After the 100 fold inflation it had to switch to giving out "bit nickels" instead. As such, I own precisely .05 BTC. I didn't even ask the faucet twice. If, like I rhetorically postulated in some of my posts, I had purchased $1,000 of BTC AND sold them when BTC hit $30, then I would have been prescient. (See knightmb for an example. I hope he cashed some out!)

---

I did spend a lot of time and mental energy trying to come up with a bitcoin analog with a stable monetary policy. I'm assuming that is what you are going for too. I've read through all four pages of this thread and part of your proposal. I think I'm only at about 50% comprehension though.

It looks like you are trying to come up with a way to generate EnCoins so that their value stays constant. I'm a big fan of that idea. In your case you've chosen a certain amount (or value) of electricity as your reference constant. Is that correct?

I'm presuming that if the value of an ENC increases too fast, you want to generate ENC faster. I'm not sure I understand the mechanism yet. I'm guessing arbitragers notice the opportunity and fire up new nodes. The cost of electricity (somehow I'm not clear on yet) serves as a lower bound. If ENC values go too low, arbitragers won't waste the electricity to generate them.

Am I on the right track, or have I missed the train of thought entirely?

[Etlase2]

It looks like you are trying to come up with a way to generate EnCoins so that their value stays constant. I'm a big fan of that idea. In your case you've chosen a certain amount (or value) of electricity as your reference constant. Is that correct?

Yes.

I'm presuming that if the value of an ENC increases too fast, you want to generate ENC faster. I'm not sure I understand the mechanism yet. I'm guessing arbitragers notice the opportunity and fire up new nodes. The cost of electricity (somehow I'm not clear on yet) serves as a lower bound. If ENC values go too low, arbitragers won't waste the electricity to generate them.

Am I on the right track, or have I missed the train of thought entirely?

Definitely on the right track. As there is no set block award to divide among an increasing number of people--blocks are awarded to as many networks as there are--when the price of ENC rises due to a rise in popularity, more ENC can be produced accordingly. So instead of passing all of that profit on to the early adopters for no work, everyone (who chooses to) gets a piece of it. BUT, because the ENC reward increases as your trust with the network increases, there IS a benefit to being around before the sudden increase in demand. So if there are people who can actually time these trends then they will be "smart, early" investors, rather than "early" investors. ALSO, there is a cap on how these ENC rewards increase, anyone can get it, it just takes time and dedication to the network. How fair is that?

As usual, these hard numbers are up for debate, but the some of the pertinent stuff is in the technical details:

•   Network Trust levels and payouts: 1-29—5 ENC, 30-89—6 ENC, 90-360—7 ENC. Therefore it takes about 3 months to receive a full payout, but trust may be earned for up to 1 year. These figures are subject to much revision. 6 ENC is approximately 1 ENC = 10kWh based on 200Wh per person (based on an average of 50 people per network), but because some blocks will be lost that are not finished before the 24-25hr cooldown, 7 ENC will be awarded to very trusted networks as compensation. (update: I believe there should be a more granular progression for ENC payouts [5, 5.5, 6, 6.5, 7], with awards continuing to increase up to 180 points.)

Cooperatively, this also increases the security of the network as outlined in section 7 (in the newest revision of the proposal):

[T]hese wallets will be used to keep track, by other networks, how long an individual has worked for the network. This information can be used to make decisions on whom to allow joining a NT. For example, a well trusted NT with over 180 trust and a 7 ENC award may choose to have a minimum of 50 user trust (user has worked on over 50 PBs) required to join. This will help reduce the ease of an infiltration attack against the network’s trusts as well as making it easier for trustworthy members to continue to earn a bonus ENC award for their help to the network.

And in times where supply outstrips demand, section 4:

In times of high supply and low demand, Network Trusts with a significant amount of trust will be allowed to enter a cool-down mode. This mode will lower the difficulty required to find a block to 1/10th of its normal value, while awarding 1/8th the ENC. The client software will adjust the computer output accordingly. There is a maximum of 2 blocks per PB that may be awarded this way. This allows Network Trusts to maintain profitability while also continuing to secure the network.

Trusted users STILL benefit, and ANYONE can eventually become a trusted user. It just requires an ongoing dedication to the network.

[sd]

* EnCoin is based around a constant cost to produce, approximately 10kWh of electricity. In contrast, a BTC's cost to produce has increased by a factor of 2,250 from the 1st to the 7.3 millionth.

This does not seem possible; CPUs, GPUs, FPGAs all do different amounts of work for a given amount of electricity. The difference in power usage between FPGAs and CPUs or GPUs is many orders of magnitude.

[JohnDoe]

I did spend a lot of time and mental energy trying to come up with a bitcoin analog with a stable monetary policy. I'm assuming that is what you are going for too. I've read through all four pages of this thread and part of your proposal. I think I'm only at about 50% comprehension though.

Did you come up with any ideas that could be viable? Also what do you think about the decentralized central bank approach?

[Red]

I'm still kicking the concept around in my head Etlase2, but I like the overall direction. I'm less concerned about the technical details than in the overall system dynamics.

The constant value tendency of a coin must result from the ratio between the total (external) value of the goods trying to be exchanged divided by the number of coins available to be exchanged. Meaning those not being hoarded.

So if the economy increases (say we double the external value of goods needing to be exchanged each day) then to number of coins available to be exchanged must also double. Notice, I DID NOT say the number of coins in the system must double. Just that the number not being hoarded over that interval must double. That means if price deflation starts, you have to convince people to spend their current coins rather than hoarding them hoping they'll be worth more in the future. (Creating a bubble)

Likewise, if the economy decreases (say we amount of external goods falls by half) then the number of coins available to be exchanged must fall by half as well. This becomes the real tricky part. In the face of price inflation, you have to convince people to save/hoard rather than to dump all their coins before they lose value. (Popping a bubble)

The best way to motivate people to behave in this manner is to guarantee mathematically that the system will over the medium term always return every coin's monetary value to some constant. The question for me has always been, "What constant?" Meaning, what benchmark is to be used in a very dynamic economic marketplace?

--- Hopefully, that mostly paraphrases what you have written. i wasn't intended to contest anything in the above section. ---

I think the idea of using the price of electricity as that benchmark shows serious possibility. Satoshi suggested a similar thing, but with a constant BTC generation rate, a short term bubble seemed much more likely. Your idea of varying the generation rate of ENC makes the convergence much more likely.

--- Controversial stuff starts here ---

Keep in mind that by adding the concept of "Trust" you completely remove the necessity for bitcoin's proof-of-work. As you pointed out in section 6. Transactions, EnCoin's transaction history immutability is based upon shared consensus. As such, it should be possible to solve the transaction recording problem using only a negligible amount of electricity. That guarantees the greatest participation in the consensus.

It also means, that time/power consuming proof-of-work calculations are required ONLY during the times it is advantageous to mint new coins. That could be a huge advantage in a shrinking economy.

The only real question in my mind is how do you distribute newly created coins, and destroy any unnecessary coins, in a way that best leverages the hoarders.

For example, in a growing economy, you want to penalize hoarding. Therefore you might award new coins ONLY to people who have current bitcoin transactions.

Likewise, in a shrinking economy, you want to penalize spending/dumping bitcoins. You might consider, taxing the spenders in each current transaction.  Destroying the tax would increase the value of each hoarder's stash.

I still haven't tied this line of thought to the optional generation and the price of electricity but I get the sense that it could be done. I have to re-read all your notes to convince myself you've figured it out.

---

I get the sense that your plan goes something like this:
1) Tax every transaction.
2a) If prices are inflating, make it electrically unprofitable to generate coins to replace the tax.
2b) If prices are deflating, make it electrically profitable to generate new coins in an amount greater than the above tax.
2c) If prices are stable, it should be electrically profitable to generate only the coins necessary to replace the tax. (Or perhaps there is just a gentle oscillation between the above two states.)

===

Am I anywhere close yet?

[Etlase2]

This does not seem possible; CPUs, GPUs, FPGAs all do different amounts of work for a given amount of electricity. The difference in power usage between FPGAs and CPUs or GPUs is many orders of magnitude.

This is covered somewhat 2 or 3 posts above this. With a hashing algorithm that randomly changes every so often, it would hopefully not be possible to profitably keep up with FPGAs or ASICs. Not being a cryptographic expert, I can't say how different algorithms would affect the CPU vs GPU debate, but that is something that can be worked out before releasing the software into the wild.

The major danger comes from GPUs suddenly requiring much less electricity than before--unlikely given the current and past state of hardware, but certainly not impossible. I do have a potential solution that can be pre-programmed in (i.e. without later forking the chain), but I'll bring that up at a later time.

The only real question in my mind is how do you distribute newly created coins, and destroy any unnecessary coins, in a way that best leverages the hoarders.

For example, in a growing economy, you want to penalize hoarding. Therefore you might award new coins ONLY to people who have current bitcoin transactions.

Likewise, in a shrinking economy, you want to penalize spending/dumping bitcoins. You might consider, taxing the spenders in each current transaction.  Destroying the tax would increase the value of each hoarder's stash.

This isn't exactly how it works, as the transaction fee is a set rate that never changes. I'm not excluding the possibility that it could change, but then you've got the software trying to calculate the economy rather than the economy working itself out naturally. And for now, I have it proposed as the receiver paying the fee, like a credit card or paypal transaction. I'm not sure how the spender vs receiver argument may work in the minds of hoarders. Interesting topic for discussion.

But, with the general design of the system, hoarders should be aware that a price deflation is temporary, so it is advantageous to sell some of their stash and make the immediate profit.

And conversely, businesses should be aware that a price inflation (compared to fiat currencies, at least) is temporary, so it isn't necessary to value Encoins based on their fiat counterparts. Ergo, the price of goods and services may remain relatively unchanged even in the face of market forces--the price of a loaf of bread does not change from day to day based on how the local currency compares to world currencies, after all. Once this model is established with historical data (assuming it works, of course), businesses could be secure in holding on to their encoins instead of immediately trying to sell them back for fiat.

Buying and immediately selling is a solution that many have proposed to generate new interest in bitcoins. Problem is, it doesn't create any new real demand. Businesses receive coins, businesses sell coins. No value is added to the economy because the coins are essentially just a temporary bargaining chip that facilitates easier transactions. And I think because bitcoins will *never* have an inherent worth (early coin sell offs will always be possible), it just won't ever become an economy that has actual value.

I have to re-read all your notes to convince myself you've figured it out.

I certainly don't have myself convinced that I've figured it out, so good luck with that.  

I get the sense that your plan goes something like this:
1) Tax every transaction.
2a) If prices are inflating, make it electrically unprofitable to generate coins to replace the tax.
2b) If prices are deflating, make it electrically profitable to generate new coins in an amount greater than the above tax.
2c) If prices are stable, it should be electrically profitable to generate only the coins necessary to replace the tax. (Or perhaps there is just a gentle oscillation between the above two states.)

That sums it up much better than anywhere I have written in the proposal. I may have to steal this.

[Minsc]

This is covered somewhat 2 or 3 posts above this. With a hashing algorithm that randomly changes every so often, it would hopefully not be possible to profitably keep up with FPGAs or ASICs. Not being a cryptographic expert, I can't say how different algorithms would affect the CPU vs GPU debate, but that is something that can be worked out before releasing the software into the wild.

Okay let's make it change each block and be different each time.  But that's not good enough, we also should make this change boost the encryption of the cryptocurrency too.

[Red]

Did you come up with any ideas that could be viable? Also what do you think about the decentralized central bank approach?

Ideas, yes. Viable, perhaps. At least they are not implausible. ;-) Nothing was put down as a formal proposal. When I was arguing for a stable monetary policy, it was a very unpopular idea. Free appreciating gold was the big draw. There are a couple of threads discussing GETS/LETS systems. But let's ignore them for now. I'll try to bring what I learned to this idea.

I like the central bank approach, but I'd rather see it automated as this idea tries to do. Well, I still don't understand how it does it, but I hope it automates it.

[Red]

I re-read your proposal and thought about this some more. In general, I think there are a lot of things in the proposal that seem more complicated than necessary. In particular, the bit about trust networks. Now I do see this as a key part of your proposal, so I'm outright disputing it's necessity. However, I think it is a composite solution to several problems that didn't get enough ink individually. I think the discussion could benefit from discussing the individual issues before deciding on a technical solution.

The other thing I still don't grasp clearly from the proposal is the mapping back to quantities of electricity.

This does not seem possible; CPUs, GPUs, FPGAs all do different amounts of work for a given amount of electricity. The difference in power usage between FPGAs and CPUs or GPUs is many orders of magnitude.

The major danger comes from GPUs suddenly requiring much less electricity than before--unlikely given the current and past state of hardware, but certainly not impossible. I do have a potential solution that can be pre-programmed in (i.e. without later forking the chain), but I'll bring that up at a later time.

The point sd brought up is certainly significant. I can only offer the obvious empirical evidence. Over time, all CPU's will use less electricity to do the same amount of work. As such, you need a (hopefully) auto-adjusting parameter that keeps the proof-of-work load constant in kWh.

I see lots of proposed constants in your technical information. What I don't see is anyway to vary those constants over time. JohnDoe has a proposal based upon voting but this is your thread so I prefer to understand your ideas.

But, with the general design of the system, hoarders should be aware that a price deflation is temporary, so it is advantageous to sell some of their stash and make the immediate profit.

This is an absolutely key dynamic to keeping the value of coins stable.

That means *ALL* 2b)/excess coin generation is an arbitrage situation. Meaning *everyone* generating coins in my 2b) sense will be immediately spending them or cashing them out. *Never* hoarding them. It doesn't make sense to spend 10 kWh to generate a coin worth 12 kWh, then to hoard the coin while expecting its value to drop back to 10 kWh.

And conversely, businesses should be aware that a price inflation (compared to fiat currencies, at least) is temporary, so it isn't necessary to value Encoins based on their fiat counterparts. Ergo, the price of goods and services may remain relatively unchanged even in the face of market forces--the price of a loaf of bread does not change from day to day based on how the local currency compares to world currencies, after all.

Agreed. This is what makes your idea interesting to me. Story time...

I spent some time in San Diego a year or so back. During that time, they had a huge "save water" campaign across the region. Its success far exceeded their expectations. Big win right? Conservation means less competition for a shared resource means lower resource prices. Less individual usage means compounding lower individual expenses in a recession. Woot! Except, the resulting conservation meant lower revenue flowing to the water district. The district could no longer meet its fixed expenses. So the district raised the water rates! Which of course encourages more conservation...

What's my point? As a friend of my once said, a gun always costs about the price of one gun. Meaning that since the wild wild west, a gun has alway been expensive enough to be considered valuable. Yet never too expensive for the average person to save for and buy. A gun represents a fixed fraction of the average person's salary over time.

I suspect electricity, like water, like a gun is one of those fixed fraction commodities. Electricity cost different prices in different places and people use varying amounts. But any particular person's electrical bill is not likely to jump from 10% of their salary to 30% of their salary. Neither is it going to fall to 3% of their salary even if everyone tries really hard. (arbitrary made up numbers to stress the point.)

This isn't exactly how it works, as the transaction fee is a set rate that never changes. I'm not excluding the possibility that it could change, but then you've got the software trying to calculate the economy rather than the economy working itself out naturally. And for now, I have it proposed as the receiver paying the fee, like a credit card or paypal transaction. I'm not sure how the spender vs receiver argument may work in the minds of hoarders. Interesting topic for discussion.

I think you are probably right on the fixed transaction fee/tax concept. However, that means the elasticity of your model can expand as fast as it needs to, but it can only contract at a fixed rate. This gives me pause.

I don't think of coins like credit card or paypal transactions. I think of them like fucking coins! :-) My quarters don't lose value when I spend them or when someone receives them. I have one quarter less, someone else has one quarter more.

For me, this has to be the nominal case goal for any cash alternative currency. Meaning, specifically, in the case where the currency value is stable (2c), if I'm transacting in coins (buying or selling), I'd better not be penalized for using money as a medium of exchange that is of course our main point.

This *requires* that in cases (2c) and (2b) all transaction fees be refunded prior to bonus coins being awarded to so called miners. This is logically invariant no matter how much work a miner thinks they proved.

It is easiest to see in the stable (2c) case. If our coin value is stable, that means the appropriate monetary policy is to do *exactly* nothing. Do "no work" in the mass times distance sense. That doesn't mean nobody put in effort. It just means no work got done or should be rewarded. Why would we reward the people (do something) who just mathematically proved our best monetary policy decision is to do nothing?

In case (2b), you can reward people for mathematically proving there is a need for more coins. However, taxing transactors is still counter productive. It decreases coin velocity and encourages hoarding in the face of deflation. That works to defeat the purpose of adding new coins.

Only in case (2a) to we wish to penalize someone for participating in a transaction. If you analysis that situation, prices are inflating, taxing the seller will result in higher prices to extract the same coin value for their goods. This is opposite the direction to intended to move the system.

Purchasing during *temporarily* inflated times is illogical/desperate. We want to reduce the number of coins flowing for too few, over priced, goods. That drives prices back down. The only way to encourage that is to tax the spenders, thus rewarding the savers. This is critical because, as I pointed out above, this is the least elastic of your monetary directions.

[Etlase2]

I re-read your proposal and thought about this some more. In general, I think there are a lot of things in the proposal that seem more complicated than necessary. In particular, the bit about trust networks. Now I do see this as a key part of your proposal, so I'm outright disputing it's necessity. However, I think it is a composite solution to several problems that didn't get enough ink individually. I think the discussion could benefit from discussing the individual issues before deciding on a technical solution.

The trust networks are integral to avoiding a pooling of resources. The pooling of resources like bitcoin does allows for singular points of attack against the network. A pool or two goes down and all of a sudden the network is vulnerable. Also, as far as the trust system goes, there needs to be a larger amount of trust spread out across more people, or else you make it easier to attack the trust. And since these are not many-to-one but many-to-many, every individual is resistant to attack individually, not as a group.

It is such a different design from bitcoin because it needs to address the problems in how the network operates. 51% computational attack is thwarted. Now there is a reasonable system of voting. Signature proofs of who is being dishonest. Easier for a new user to get in and start making coins. Much more information available as to how the network is operating. I designed this idea over the course of several weeks to finally come to what it is now. I mean if you see weaknesses, please point them out. A big one is anonymity, but trading all of these features for a bit less anonymity is worth it, imo. Anyone who buys in for cash can still remain separate and anonymous from the network as a whole.

The other thing I still don't grasp clearly from the proposal is the mapping back to quantities of electricity.

The 10kWh figure was used because that is what most closely resembles the amount of a single unit of the world's most popular currencies. It is mostly irrelevant other than to gauge a general magnitude of what one coin is worth. Like I said earlier, if the average user is using 300Wh, then it is closer to 15kWh. Perhaps I will drop using 10kWh since it may just lead to confusion.

The point sd brought up is certainly significant. I can only offer the obvious empirical evidence. Over time, all CPU's will use less electricity to do the same amount of work. As such, you need a (hopefully) auto-adjusting parameter that keeps the proof-of-work load constant in kWh.

The amount of work is a non-issue, as difficulty will work similarly to bitcoin, just divided among the networks. The amount of electricity used to perform work is the issue. And this is only a problem if everyone starts using energy efficient hardware. Not a likely paradigm shift any time soon with GPUs requiring bigger and better power supplies, more and more power connections, etc.

I see lots of proposed constants in your technical information. What I don't see is anyway to vary those constants over time. JohnDoe has a proposal based upon voting but this is your thread so I prefer to understand your ideas.

Ok, lemme go through the list. Block award should probably be a constant. Being able to find a block every so often on average should be a constant to determine difficulty. Network trusts having 100 wallets, well if we don't limit that then the system of trust is very limited. Losing 10 trust for not finding a block, up for debate but certainly must be some kind of number--certainly could be a trust module vote. Minimum computational speeds and minimum payouts--up to each network. Fees for utilizing the network, probably should be a constant, really makes no difference if it's not but then I don't know by what measure to get them. 64 character maximum on transaction message, probably should be a constant unless we want to bloat the blockchain with useless data.

I mean is there anything specific that you take issue with other than a number being constant? None of the figures above constrain the network into one hole that is incapable of future expansion.

I think you are probably right on the fixed transaction fee/tax concept. However, that means the elasticity of your model can expand as fast as it needs to, but it can only contract at a fixed rate. This gives me pause.

It can't expand as fast as it needs to. There will be expansion pains. Coins still take time. And it does not contract at a fixed rate, it contracts based on how much money is moving around. So it might take a little longer to get back to equilibrium, that doesn't mean it won't get there. It doesn't mean it will take years. People minting coins can't vote for the transaction fee because they will always vote it higher; it is in their own best interest, this should be obvious. If you have the network try to decide its own transaction rate, going higher in times of high supply (which would be awfully complex to determine from programming), then you will get people who will hoard waiting for others to spend, or businesses that will raise prices to accommodate, or what have you.

For me, this has to be the nominal case goal for any cash alternative currency. Meaning, specifically, in the case where the currency value is stable (2c), if I'm transacting in coins (buying or selling), I'd better not be penalized for using money as a medium of exchange that is of course our main point.

What do you propose to support the network then? If there is no fee, inflation may go unchecked. If there is no fee, miners have no incentive whatsoever to mine. The network loses security. One can easily counteract the fee by joining a network trust, putting in your time, then moving on to a trust in cool-down mode and getting bonus encoins for the same amount of work (the 1/8th for 1/10th idea). Having people provide a secure, incredibly cheap, reliable form of sending money to anyone in the world in 30 seconds just simply can not be free and stable.

If you attempt to program in determining whether or not we are in a 2a, 2b, or 2c phase of the economy, then you are asking software to know what's best for the economy instead of letting it work itself out naturally. That's quite the can of worms.

This *requires* that in cases (2c) and (2b) all transaction fees be refunded prior to bonus coins being awarded to so called miners. This is logically invariant no matter how much work a miner thinks they proved.

You'll have to explain this further because I'm not sure what you mean. The bonus is a reward for being a highly trusted member of the community and putting in a lot of effort to make the network secure. Sending a transaction does absolutely nothing for the network security, it is a service that the network provides. You propose that a service should be free because there are employees that get paid more than others? I don't follow the logic here. If miners don't get paid, what is the incentive to mine? You are thinking about this from one side only.

It is easiest to see in the stable (2c) case. If our coin value is stable, that means the appropriate monetary policy is to do *exactly* nothing. Do "no work" in the mass times distance sense. That doesn't mean nobody put in effort. It just means no work got done or should be rewarded. Why would we reward the people (do something) who just mathematically proved our best monetary policy decision is to do nothing?

Now you are really losing me here. Again, miners are providing the service, spenders are making use of that service (and not even paying the fee). When we are in 2c, most miners will be in a cool down mode, only creating enough coins to replace what has been lost. And in doing so, they are securing the network.

Purchasing during *temporarily* inflated times is illogical/desperate. We want to reduce the number of coins flowing for too few, over priced, goods. That drives prices back down. The only way to encourage that is to tax the spenders, thus rewarding the savers. This is critical because, as I pointed out above, this is the least elastic of your monetary directions.

It is also, hopefully, the least likely. It means the economy has contracted, which no matter how you look at it, is not going to be good. Receivers paying the fee is not set in stone, so if that were to switch to the spender paying the fee, then this would be even worse for spending. Having the receivers pay the fee is a design decision I added to the proposal only a few days ago. It isn't set in stone. But I will think more on this.

An extreme contraction is a lot less likely than an extreme expansion, though imo. And a slow contraction would be counteracted by the effects of a transaction tax. Again, businesses don't have to change their prices, so no one is actually buying anything at an inflated amount.

[Red]

I consider my previous post an epic FAIL.

It's not that you didn't provide clear answers. I obviously didn't express myself clearly. I'm going to try again. Please bear with me.

[Red]

Going to leave trust for another post.

The other thing I still don't grasp clearly from the proposal is the mapping back to quantities of electricity.

The 10kWh figure was used ... Perhaps I will drop using 10kWh since it may just lead to confusion.

The amount of work is a non-issue, as difficulty will work similarly to bitcoin, just divided among the networks.

I didn't mean to contest the 10kWh constant. I just saw calculations that computed that number based upon todays technology.

What I was wondering was what you answered in the second line above. You are planing to change the difficulty like bitcoin does. I didn't see that in the proposal.

What I'd really like to know is what exactly causes the difficulty constraints to change?

Not a likely paradigm shift any time soon with GPUs requiring bigger and better power supplies, more and more power connections, etc.

This, I think, requires more consideration. Though it seems like GPUs require more gross power, if they double power usage but do 10x more calculations, then the cost per calculation has dropped by a factor of five.

I know you understand that point. I'm also confident you've somehow worked such cases into your thinking. I'm just asking for a reference to how you propose to detect and adjust to technology performance in order to bring the proof-of-work load back to a constant target.

[Etlase2]

I didn't mean to contest the 10kWh constant. I just saw calculations that computed that number based upon todays technology.

What I was wondering was what you answered in the second line above. You are planing to change the difficulty like bitcoin does. I didn't see that in the proposal.

What I'd really like to know is what exactly causes the difficulty constraints to change?

It is essentially the same manner as bitcoin.

Technical details:

•   Network Trust Block difficulty will be based around an average network being able to find one block every six hours.

Instead of everyone trying to find a block every 10 minutes, each network will attempt to find a block every 6 hours. The 6 hour figure may be adjusted, but I figure it's a decent compromise. It will keep a lot of networks missing that magical 4 blocks per 24 hour period, as once the network cool-down starts, any effort up to that point is wasted (new primary block, new hash, old hash chain is no longer valid). But, the 7 ENC bonus award counteracts some of that. This of course is up for discussion. I have not decided how often the difficulty should change. Assuming a large enough network, it could change every day without affecting much, but I don't think that is necessary so it will probably be 1 week or so. And 1 week will make it less volatile for when the network is bootstrapping and a wide variety of computers could have a large effect on the network.

As a bonus over bitcoin, lowering the difficulty does not have to lag behind miners leaving the network. 1 week and the difficulty changes no matter what--likely, it will change every day but as a reflection of the last week. If bitcoin miners halve at the 50->25 btc award halve, it could take a month or more before the difficulty lowers because it goes by number of blocks, not time.

This, I think, requires more consideration. Though it seems like GPUs require more gross power, if they double power usage but do 10x more calculations, then the cost per calculation has dropped by a factor of five.

I know you understand that point. I'm also confident you've somehow worked such cases into your thinking. I'm just asking for a reference to how you propose to detect and adjust to technology performance in order to bring the proof-of-work load back to a constant target.

It is not the increase of GPU power that we have to worry about. It is the decrease of energy used. This is why FPGAs and ASICs are a much bigger threat (and perhaps not even ASICs, I don't know how their power usage compares and I believe they are extremely cost prohibitive) than increasing GPU power.

Say, for example, the average GPU today uses 200W of electricity for 300Mhash/s. If the average GPU of tomorrow uses 200W of electricity for 600Mhash/s, there isn't an issue--difficulty will double. If the average GPU of tomorrow uses 400W of electricity for 600Mhash/s, there isn't an issue--users will have to scale back the total output though to get back to profitability (it is in everyone's best interest to do so--lol except for hoarders). If the average GPU (or FPGA, or encoin-specific machine) of tomorrow uses 100W for 600Mhash/s, then we have a problem because all the previous coins were made at 200W, and you certainly can't force the GPU to work double time. This would, over time, lower the value of each encoin unless the price of electricity has doubled in the mean time. Since the network has no way of knowing that everybody is using less electricity, it cannot compensate that with extra difficulty.

We could expect fully honest users to report, minimally, what video card or device they are using to hash, but this is inherently unreliable as there is no trusted way to verify this. And on top of that, changing the difficulty based on this would require developer intervention and community acceptance. Not the best of scenarios. Or a vote, but again, unreliable as miners will vote for what is in their best interest, even if it is not good for the economy.

So... I did come up with something. But since it is not an immediate threat and does not currently matter, I feel like holding it back at this time.

[Red]

I think you are probably right on the fixed transaction fee/tax concept. However, that means the elasticity of your model can expand as fast as it needs to, but it can only contract at a fixed rate. This gives me pause.

It can't expand as fast as it needs to...It doesn't mean it will take years.

People minting coins can't vote for the transaction fee because...

Now I wasn't criticizing the difference between expansion and contraction technologies. However, when I see differences in the dynamics I like to pause and think is that a requirement or a consequence?

In the expansion case I understood that additional miners could come in when it was profitable to create new coins. That makes expansion non-linear. Contraction on the other hand, while not linear, is less flexible.

As an extreme example, suppose Silk Road decided to move from bitcoin to encoin. The economy suddenly increased 10 fold. I'm sure miners would come in to create coins as profitably fast as they could. Now suppose Silk Road got busted by the FBI and the economy fell back to its previous state. I ponder whether the system could adjust with the given parameters. (I haven't reached any conclusions)

I don't mean to propose that voting for fees is a good idea. I think aligning incentives is a much better way to let the market handle itself. A way to make the contraction rate more flexible, would be to tie it directly to the price of electricity as is used for expansion. (If inflation goes up, fees go up.) Or to the consistency of the contraction. (After X months of consistent contraction, fees go up to Y to speed things up) Those are just idle thoughts. Not well thought out proposals.