Topic: EnCoin Proposal v4.0 - scads of technical details - now with a WIKI! - page 3. (Read 6134 times)

No it isnt. Its quite clear, accurate and a key point. Short term fluctuations are irrelevant and averaged out. If your point is that difficulty adjustments are too slow, I might even agree, but that issue is more easily addressed by.. you know, a minor tweak in the algorithm. But there are also arguments to be made for a slow difficulty adjustment, as it allows miner to plan at least a little bit ahead. Fact is on average, 1BTC will cost around 1BTC to produce. That for a week or so it might be more or less expensive is a non issue.


So?


What are you blabbering? Instability of what? This has nothing to do with BTC valuation, it only affects the hash rate which, for short periods of time, might be comparatively high or low compared to the exchange value of the block chain. So what?


I havent fully read your proposal, as Im still waiting for an executive summary outlining the basic underlying principles, rather than just the goals and long pages descibing what certainly appears like an overly complicated scheme. It should not be hard to describe the main principles in a few paragraphs. Price is the meeting of supply and demand. Am I correct guessing you intend to vary money supply to match demand, using aggregate hash power (a proxy for electricity cost) as a measure of demand?

That "on average" is quite misleading. When the price of BTC was $30 USD, the average cost to produce was around a dollar or so. And it doesn't change the fact that millions of coins will have always been produced for pennies. Yes, the effect of this will be lessened over time assuming those coins make it in to circulation, but it happens in the manner of transferring wealth. Whether or not they deserved it or whatever, I don't really care, because no matter what it leads to instability. This is bad for the future prospect of bitcoin.

If the price of ENC rises vs. fiat because of hoarding, either the hoarders need to sell to get coins in circulation or more people are going to take up minting coins. Hoarders can win by selling, or they can lose by waiting. In bitcoin, hoarders win by selling and win by waiting. In winning by waiting, other people are forced to pay more than what the coins really should be worth, and eventually the price will correct itself when a hoarder decides that the fiat value is too great to keep hoarding. Then with the potential rush of selling because the impending doom cries, these same people can buy their coins back for half or less of what they sold them for and retain their power. This is not the basis of a healthy currency.

ENC still allows for a profit margin based on what people are willing to pay for the convenience to have someone else spend 50 computer-hours or whatever it takes to create each coin. There may well be a 100% margin, who knows. But it will be determined by the market and the market alone, not someone(s) who hoards the lion's share of the currency. Isn't putting the power back in the hands of the people supposed to be what bitcoin is all about?

Beyond this, there are many other flaws addressed, such as no need for hashing to secure the network at all. I'm sure coming from a background in bitcoin this concept may be hard to grasp, but I do believe it is possible and I believe it will be better for the future of the network. I do need to make the proposal into a wiki though so that it's easier to follow. I'm trying to explain a lot of concepts that work very differently from bitcoin, and doing it in a 20+ page paper is not the easiest thing to digest. I'm gonna start working on that.

By the way, if you have something specific that you don't think will work, please point it out. Generalizations and ad hominems do not legitimately help. I do want discussion after all, and the previous threads have helped me come to this proposal which I think is very close to being the stable medium of exchange that a lot of people do want.

? No it doesnt. The amount of BTCs created is not variable, its constant, 50BTC / 10 minutes (for now). Whats variable is the amount of hashing power securing the block chain. The more valuable the block chain, the better protected it will be from 51% attacks. The less valuable it is, the less hashing power will be wasted securing it. That makes *perfect* sense regardless if you are designing a casino or the next paypal.

BTW, your proposal is illegible to me. If you can make an executive summary I might (likely waste) some time reading it, but Im not going to wade through the entire document when it appears you arent grasping the basics of even bitcoin. News flash, 1BTC will cost on average 1BTC to produce. Is that the big flaw you guys are addressing?

Actually, I'm going to have to think more on this, but I think a blind signature/voting protocol (such as: http://ethesis.nitrkl.ac.in/1683/1/Thesis_evoting.pdf ) could possibly be tweaked to work with transactions. The only trouble is it requires the list of unclaimed transactions to be maintained between consensus blocks. With some of the other designs I have in my head for reducing bandwidth and storage requirements, I'm thinking this might not be a big deal though even if there are a ton of unclaimed transactions.

I'm not making the argument it is too complex. I'm only saying, I'm too lazy to put in that much work.

I've always imagined that a website would be available where one could check the entire history if one so desired. I believe it will be somewhat necessary for people to have faith in it and that the earliest group of people didn't do anything shady. There's really nothing that can be done to prevent someone from checking up on you, so may as well make it available to all. This is why I wanted blind signatures to be part of the protocol. I really don't believe that it is anyone's business what you do with your money. It is a very visible thing though, and it might draw some undue attention to the money laundering capability. With bitcoin it is obviously possible (although not as secure as you generally have to trust a third party), but it isn't handled by the protocol.

I think I said previously that I wondered if merchants would have a problem with how visible transactions are. Arguably most merchants would be fairly visible in bitcoin anyway even if they used a different wallet for each transaction or customer. At some point they are going to have to move this money, and it will link the accounts. So it just takes longer. But with Encoin they are essentially required to always use the same account so that they can refund the most possible transaction fees.

If the benefits of using Encoin outweigh the cons for merchants, then we may enter a new era of accountability. Banks would certainly not be able to manipulate the money like they can in the real world, and businesses would not be able to cook the books, at least the books based on encoin anyway. It is interesting to think about, but very unpredictable at this point. I worry that it would lead to merchants using a bank-like intermediary to receive funds, which perhaps isn't that big of a deal.


I've briefly thought about it, but I can't come up with anything even close.


You're not the first to make the argument that the system is too complex. I, predictably, disagree. While there are many rules that govern how the network operates, independently all the rules are quite simple and it is easy to come to a consensus by following the transaction block chain.

It took me several weeks to comprehend bitcoin, and I still learn new things about it all the time. It is nowhere near a simple system, but it sometimes gives off that vibe because it has worked almost flawlessly to date. I really doubt you could have convinced even 1% of the people that post on this board that what bitcoin has achieved was possible and that it would work before the implementation was proven in front of their eyes.

Still working my way though your new section on how you do this in Encoin. I'm behind on my reading.

Koomey's law is the best way I could explain what the goal is. I am still not sure how variances from Koomey's law could be measured of automatically compensated for. I do still think those differences will be swamped by actual economic changes though. This compounds the measurements.



The basic problem is that given varying necessity for coin generation, there is no absolute way to resolve network partitioning like Bitcoin proposes. Both Encoin and GEM attempt to avoid the problem, by identifying network partitioning up front. Nodes should know ASAP if they have been partitioned from the main network.

GEM does this on a 10 minute block basis using the announcements from non-anonymous nodes. Encoin does it for each transaction independently.


Both require a benchmark for how a node can measure if they are in the majority or minority network partition. This benchmark is a very difficult thing to name. Encoin proposals have called it by several different names "Trust" being the most common. GEM also uses the term "Trust" but it does so differently than Encoin.

Trust in GEM is basically human to human pragmatic trust. If you don't see your friend, you get worried. Trust in Encoin is more of a mathematical relationship. It is (sort of) a summation of "node compliance to the specification" (times) "node availability over time". Consistency or Dependability might be good alternate terms to describe what Encoin is measuring. But these terms don't work in most of the sentences discussing how a node can "trust" that its transactions have been confirmed.


Both of these Encoin and GEMs "trust" benchmarks are designed to frustrate Sybil attacks. In this case that means creating additional entities in hopes of convincing a node it is in the majority partition when it is indeed in the minority partition. GEM frustrates this by requiring trusted nodes to be non-anonymous and trusted in the human to human sense. Encoin frustrates this by requiring anonymous nodes to put in extended effort over time (electricity) to build "trust". If a node violates the compliance rules, their expensive trust is easily revoked.


The main drawback with Encoin's "trust" implementation is it requires almost as many words to describe (and lines of code to implement) as is needed for the rest of the transaction processing. This does not imply that it won't work or that it isn't worth doing.

The main drawback with GEMs "trust" implementation is that it is difficult to guarantee that it is sufficient to frustrate deliberate network DOS or forking attacks. I tend to think it is. However, it requires acknowledging that when things get deliberately wonky, humans are going to step in no matter how much we hope they won't.

I don't have a deep understand of all the Encoin details, but I understand the concepts and what drove the decision making.

Basically nothing in GEM is superior to Encoin. However, given the tools at hand (meaning Bitcoin's code base) GEM is easier to implement. That goes a long way when you are lazy like me.

A major difference is Encoin uses a balance sheet approach, in addition to recording all the transactions. This means every node does not have to download and keep the entire block chain. It just starts with the balances and runs. However, this requires a bit of "faith" that those you received the latest balance sheet from never lied in creating it. There is really nothing stopping bitcoin or GEM from rolling the old blocks up into a balance sheet for efficiency. However, Bitcoin isn't big on faith in ones peers.

A subtile difference is that Bitcoin relies on a plethora of "accounts" to aid in anonymity. I'm pretty sure this is why Satoshi opted not to create a rolled up summary of accounts. If everyone uses a new account for every transaction, and keeps hundreds of funded personal accounts, then the balance sheet would grow pretty huge pretty fast. The block chain tends to grow linearly with the number of transactions but it is agnostic to the number of accounts.

The balance sheet in Encoin will grow linearly with the number of accounts but it is agnostic to the number of transactions. This will be substantially smaller than the total block chain. However, Encoin does record every transaction into its own chain. It's just that every node isn't required to keep up with them all. This adds slight historical risk to Encoin. Since fewer nodes keep up with every transaction, those that do not are required to trust those that do to accurately maintain the historical record. Losing historical transactions does not invalidate the current balances of course, it just makes auditing them impossible.

Depending on how you spin this, it either adds to or detracts from anonymity. Having fewer accounts detracts and makes it easier for those with every transaction block to profile account holders. However, not distributing every historical transactions to every node removes the triviality of anyone poking through the history. I tend to think it adds anonymity than it takes away.

If the destruction of historical transaction records could be automated and mandated, anonymity would greatly improve. It does not appear to be plausible though.

Almost everything I would have a problem with in GEM is a problem I have with Bitcoin.

Two GEM-specific things I can think of:

1) The koomey's law adjustment is a constant. Hard constants are bad for something should be able to adapt to future circumstance without intervention. It is possible that with further thought it could work similarly to the latest encoin proposal.
If the computer hardware cycle fell outside of koomey's law (and, like Moore's, it always does to some degree and is only a measure of history, not predictive of the future), the value of GEMs would be less stable than ENC.
2) It centralizes trust. It would be very complicated to use the block chain to keep track of this trust (or reputation), so Red's idea was to have peers use well-known merchants/exchanges as the basis for trust. I'm sure it would end up being more complex and more secure than just that, but his implementation ideas are still at the early stages; I've had a bit of a head start. But since the bitcoin block chain does not scale well at all, it is likely always going to revolve around a small number of entities.

I believe Encoin is capable of scaling to the point where anyone with a reasonable internet connection and CPU will always be able to fully participate in the network if they so choose (the "cloudnet" per the proposal). This adds immense amounts of security against DoS attacks, hacking, un/intentional network splits, and other undesirable outcomes when any part of the network is centralized.

It appears someone had Encoin in mind when proofing this: http://nslab.kaist.ac.kr/courses/2009/cs712/paperlist/2-12.pdf (red you would be very interested in this as you mentioned low-power wireless network groups)

Adding signatures together can be used to prove that those signatures were added together based on adding the public keys together. Cryptography really is amazing.

One signature verification can validate an unlimited number of signatures. This would reduce the CPU and bandwidth load of approving transaction blocks infinitely. It was essentially the last thing I needed.

I believe this absolutely can work. I have always had doubts prior to this version of the proposal, but I am getting very confident. The pieces are falling into place.

And Red, thanks for being more eloquent at explaining things than I am.

Folly! Woot! I thought only I used that word.

Clearly, Encoin and Bitcoin have different goals. Encoin is in no way designed to become a digital scarce commodity. No one will get rich by becoming an Encoin early adopter.

Encoin is attempting to design digital currency with the specific goal of facilitating trade. With Encoin, if you have willing traders but no money to facilitate trading then you have a flaw in monetary policy. To rectify the flaw you simply make more money. However, to avoid price inflation, you constrain the creation of money by assigning it a specific proof-of-work cost to create. That cost must be paid-on-demand to the electric company.

As such, in Encoin, money is created only when it is profitable to do so. The makes Encoin creation extremely market based.


Bitcoin uses a similar electricity cost constraint, but instead of fixing the proof-of-work cost it raises the cost in scale with coin demand. Each bitcoin now costs about $3.41 to create. But if a bitcoin becomes worth $30 again, it will cost $30 in electricity to create each new coin. So when there is little demand for BTC, bitcoin makes them cheaper and easier to create. When there is high demand, bitcoin makes them expensive and hard to create.

This seems like folly in a system designed to facilitate trade.

But Yes, Bitcoin makes a much better digital scarce commodity than Encoin. Bitcoin will always crush Encoin in the digital coin speculation marketplace.

There is no manipulation, only encouragement by opportunity. What you quote is referring to the price of ENC vs fiat. In the end, it always rests in the hands of the people to decide what happens, not a central authority and not early adopters.

Supply or demand manipulation for the purpose of controlling any price, whether for goods or monies, is folly. Price of all things SHOULD fluctuate, it is how scarcity is measured against demand and resources are, over time, arranged in efficient order.

I've seen you and Red going back and forth about GEM/Encoin.  Both of your proposals go over my head, but you guys seem to have an intimate understanding of what ya'll are talking about.

Looking forward to the tl;dr though!

The primary goals of EnCoin are as follows:

•   To maintain a relatively stable cost-to-produce where 1 ENC costs about 1 ENC to produce.
•   To maintain a relatively stable exchange point where the effects of price inflation or deflation are smoothed out by economic and monetary policy.
•   To provide a stable currency that merchants and the people can rely on in value, security, and dependability.

Some features:

•   10 second initial verifications that debit the "from" account and are pretty much impossible to reverse.
•   No bloated block chain, only a tiny file that is updated once a day that stores account balances and other information. Detailed info (such as specific transactions) is available on request.
•   Mandatory transaction fees are partially refunded to merchants by securing the network. Hashing power only creates new coins.
•   Any transaction fees not refunded are paid as interest to all holders of ENC.
•   Bandwidth usage becomes more efficient as the network increases in popularity.


edit: A backup of the encoin wiki is available here: http://justinbporter.com/encoin/doku.php but it is not my site so I can't guarantee that it will remain available.