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

I see from your previous two posts that I have taken a mental tangent from some of your proposal details. I went back and re-read your proposal again. Doh, I hadn't snapped that you are using the word "trust" in multiple ways. Network Trust in the sense of "a body of trustees/a charitable trust". In later sections you talk of Trust in the "firm belief in the reliability, truth, ability, or strength of someone or something sense."

Anyway, my bad.

On the other hand, you say "EnCoin eschews the entire need for pools by having network trusts... There is no competition between Networks for coins." Which seems to mean that you take the most wastefully inefficient process in bitcoin, then make it redundantly wasteful in its inefficiency.

Now keep in mind that I'm long on record in my opposition to using needless proof-of-work calculations to prevent tampering with the transaction DAG. It's a little clever and a lot ridiculous.

--- History ---

Bitcoin was invented to solve one particular philosophical problem. Say we have a set of anonymous individuals, none of whom trusts any of the others. To whom are we going to trust the common transaction history? The concept of a digital currency using a trusted record keeper was already well developed. The design decision was of course we'll all keep our own copy of everything and we'll all redundantly do all the work ourselves.

That came coupled with another problem. How do reconcile our individual transaction DAGs to guarantee they remain constant over time? The design decision was of course, every 10 minutes we'll *randomly* choose one person's new transactions and pass them around as a block to everyone. The others will throw away all their personal knowledge of new transactions and start again. Then, hopefully, the transaction participants will keep redundantly resubmitting the same transaction until someone notices.

But what if the network becomes partitioned and nobody notices? How do we reconcile forks of the block chain? The answer of course, is throw away one fork and those folks adopt the other fork and start again. Which fork? The longer? The one with the most transactions? The bigger network? What if someone claims they've been partitioned for six months and want us to throw away everything and user theirs? What if, what if, what if...

The design decision was of course the proof-of-work concept. The real question you should be asking yourself is, why would somebody design a distributed transaction processing system that might throw away a ridiculous number of previously verified transactions—WITHOUT telling anyone! I mean WTF? The developers acknowledged this by adding specific block locks into each new client release.

How do they decide which blocks to lock in as the one true fork? Human consensus! "Hey, anyone got a problem with me locking the chain to here? OK, done!" Poof! Millions of hash computations tossed into the trash bin with one line of code.

--- EnCoin ---

So what's my point?

EnCoin is deliberately making different design choices than bitcoin.

1) You have a set of non-anonymous peer networks who intend to "trust but verify" each other's work. They all intend to know and trust their network members as well.
2) You treat and reconcile transactions individually, rather than as opaque blocks. Hopefully you also detect and notify some humans on simultaneous double spend attempts.
3) Your network of known trusted peers can't be forked without someone noticing.
4) Your system can never throw away blocks of transactions willy nilly.

As far as I can tell, you have *zero* need for a complicated proof-of-work to keep your "primary block" transaction accounting safe.

The only reason to start proof-of-work *mining* calculations is in hopes of arbitraging some newly created coins. If there is no hope of arbitraging these coins, there is no point in *mining* coins that are worth less then the cost to mine them. That is the key dynamic in your system that I see keeping the monetary policy stable.

So who, does all the Primary Block accounting if the miners don't?

EVERYONE who owns coins! Are you going to accept a hundred dollar bill from a stranger without looking for the hologram and security strip? That's what the transaction DAG/"primary block list" is for.

In your case you might delegate the dynamic transaction validation to at least one trusted individual in each trust network. But that is just an optimization to allow trusting lazy clients. As a general rule, receiving, validating and storing incoming transactions is trivial compared to the current proof-of-work calculations. You could run the transaction account part of your trust network peer on a cell phone using batteries.

---

Anyway, end of rant.

I'll address the rest of your responses in another post, but I needed to say that for context.

I'm interested to know if you think you still need to throw kWh of electricity at your Trust Network just to keep up with transaction accounting. I see zero reason for that.

I do understand why you might want to throw discretionary kWh at the monetary expansion problem.

Well, if you want, you could propose that certain networks work to remove coins from circulation. I'm not sure how it would be accomplished, but I guess it could take a percentage of coins from every wallet. Then the dynamics could be quite similar.


Yes, but you are trying to unmake that which has already been made. No matter what, it is still an improvement over inflationary fiat.


It would not perform well, in my estimation. But at least real market forces are at work to cause this, not an early adopter flooding the market with coins. At some point I will try to run some numbers to see how they come out. It will be imaginary, but at least it could provide a guideline around possibly setting the transaction fee.


Tying it in to the price of electricity means the software needs to know the price of electricity. This can't be done in a reasonable or reliable way. The software has no way of knowing if the market is in an inflationary period, they are two very diverse entities. The consistency of the contraction, as you call it, would be one possibility that could be programmed. However, then you are relying on more magic numbers to control the economy rather than letting itself work it out. This is dangerous, and if you get it wrong, you're stuck with it (or a chain fork). And yet still, the network can stay just as secure as before (or at least a sizable percentage as secure), but using a lot less electricity. Bitcoin can't stay as secure in a contraction because miners won't keep putting effort into a completely unprofitable venture.

And all of this ignores the possibility of an expansion relatively soon after the contraction. If all of those coins are removed as quickly as possible to reach equilibrium, you deny people the opportunity of their value in expansion--especially to those who were actually spending and helping reach equilibrium. You also waste a lot of previously used electricity. Food for thought.

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.

It is essentially the same manner as bitcoin.

Technical details:

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.


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.

Going to leave trust for another post.


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?

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.

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.

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


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.


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.


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.


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.


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.


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.

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.


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.


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.


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



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.

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.

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.

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.



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 certainly don't have myself convinced that I've figured it out, so good luck with that.  


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

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?

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

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.

Yes.


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:


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


And in times where supply outstrips demand, section 4:


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

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?

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


Section 11:


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:


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.

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

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"


Anyone care to discuss?

He's an internet detective!