[ANNOUNCE] The Proposal for EnCoin

[Etlase2]

I looked for this in the proposal, but I didn't immediately find an implementation. I don't see how it can be done cryptographically. In bitcoin the proof-of-work must be derived from the bitcoin block. In Encoin it must be derived from the Encoin transaction block (?). Two different hash values can't be calculated simultaneously.

What am I missing?

I am not the best person to explain this as I could not believe this could be done. But namecoin is already working on it. Anyone mining encoins could add whatever data is necessary to their own hash to ensure it is valid for a bitcoin hash. Bitcoin is very forgiving about what you use. And encoin would just need to allow for it as well. A simple extra spot in the GUI to enable it and provide the pool info on where to send it.

I have a thread on this forum about anonymizing bitcoin that way. It was part of my series on how to fix some of the anonymity flaws.

I didn't read the thread yet, but AFAIK it is not possible for bitcoin to handle this by itself, it has to be done through a 3rd party, which sort of invalidates the point.

[1713443537]

1713443537

[1713443537]

1713443537

[Etlase2]

BTW, a solution to the whole network conspiring to lower the cost to produce is to never decrease the difficulty. I had thought this up months ago in the first revision of the proposal that never got released. I didn't include it in later proposals because I was worried about pools screwing everything up. But there are ways to counter that too. So never decrease difficulty, as long as at some point people were honestly mining, it could never be later abused.

And another way to thwart ASICs and FPGAs and the like is to add some memory usage to the algorithms. They don't always have to be a straight SHA or WHIRLPOOL or whatever. It would be more annoying to use the software, but it would pretty much prevent application-specific hardware from going anywhere.

[bulanula]

BTW, a solution to the whole network conspiring to lower the cost to produce is to never decrease the difficulty. I had thought this up months ago in the first revision of the proposal that never got released. I didn't include it in later proposals because I was worried about pools screwing everything up. But there are ways to counter that too. So never decrease difficulty, as long as at some point people were honestly mining, it could never be later abused.

And another way to thwart ASICs and FPGAs and the like is to add some memory usage to the algorithms. They don't always have to be a straight SHA or WHIRLPOOL or whatever. It would be more annoying to use the software, but it would pretty much prevent application-specific hardware from going anywhere.

SO are you doing it the CPU only way ? Nice.

[Red]

I'm really trying to understand your math, but not trying to criticize. The math tends to go backwards and forwards at the same time.

OK, by definition: 50 peers burning the standard 200w each should generate 1 ENC per hour.

Let's say 50% of the network runs at 1mh/s (at 50% power) and 50% runs at 2mh/s (at 100%) and there are 1000 people. 500mh+1000mh=1500mh/1000 or 1.5mh/s avg, so encoin thinks 1.5mh/s = 200W. 200kwh, 13.33 coins are awarded to the 2mh/s, and 6.67 coins are awarded to the 1mh/s.

I understand the 2 to 1 ratio. But I have no idea why you awarded 20 coins.
1000 peers / 20 coins = 50 peers/coin
Because 1000 peers were around for 1 hour you split up 20 coins?

My bigger question is how do you know 50% were running at 1mh/s and 50% at 2mh/s. I assume this has to be deduced from how many blocks were generated and each block's difficulty level

I'm assuming at primary block time, you could see
24 blocks at an average of (X) mh    and
24 blocks at an average (X/2) mh
over one 24h period

That gives you 1 block/hour
2mh/s * 60s/hour = 120mh/hour

so 12 blocks took an average of 120mh to find
and 12 took an average of 60mh to find

difficulty-1 = log2(120m)
difficulty-2 = log2(60m)

So your difficulty level was about 28 leading zeros.

Which brings up another puzzling thing for me. You define a proof-of-work similar to bitcoin. It's difficult can only change in powers of 2. That makes your 1/10 difficulty and 1/5 difficult to grasp.

[Red]

Lol a couple of 64-core servers is a secret? He just had easy access where others did not to a highly exploitable system early on. I'm not saying there won't be a similar exploit to encoin, but it is a lot less likely with GPU mining from the start and a lack of 2 week difficulty changes and the fact that he'd have to subsidize his superfast cpu/gpu with the rest of the freenet that he's in.

The secret was he rented an Amazon farm of servers for a few months. Wrote custom code. Took every coin when it was easy and cheep. Tried not to run up his own difficulty. And did it without mentioning anything to others. By the time he posted the image he was done. The basic lesson is, keep your mouth shut!

How does 15kwh mean it could fall to 5kwh? It's 10kwh+ROI. If the economy is bootstrapping or dead, yes it will be below 10kwh.

Ah, now I see the issue You think ROI is a cause, not an effect!

You are thinking people will mint around 10kwh but you plan to try and stabilize the market around 14kwh? Did you mean it would vary between 13kwh and 15kwh? Unless something catastrophic happens?

[Etlase2]

I understand the 2 to 1 ratio. But I have no idea why you awarded 20 coins.
1000 peers / 20 coins = 50 peers/coin
Because 1000 peers were around for 1 hour you split up 20 coins?

Sorry for skipping an oh-so-important step of multiplying by 1 hour. I thought this could be deduced.

My bigger question is how do you know 50% were running at 1mh/s and 50% at 2mh/s. I assume this has to be deduced from how many blocks were generated and each block's difficulty level

Where did I mention anything about there being different difficulty levels? I am assuming half of the peers, as you try to argue, would be trying to subvert the 10kwh figure. If they were running at 1/2 difficulty or some such, then this example really wouldn't make sense, now would it? Or are we just trying to conflate and confuse instead of accepting that we are wrong?

Which brings up another puzzling thing for me. You define a proof-of-work similar to bitcoin. It's difficult can only change in powers of 2. That makes your 1/10 difficulty and 1/5 difficult to grasp.

So puzzling. Reminds me of grasping at something else. Can't think of what though.

[Etlase2]

Ah, now I see the issue You think ROI is a cause, not an effect!

Whatever makes you happy.

You are thinking people will mint around 10kwh but you plan to try and stabilize the market around 14kwh? Did you mean it would vary between 13kwh and 15kwh? Unless something catastrophic happens?

I don't plan on stabilizing dick squat. I make the cost to produce 10kwh and the market can figure it out from there. I doubt people will be paying 10kwh and tying up their computer for months at a time to make pennies per coin. But that's just me. I was just pointing out that in your real world scenario where you kept bringing up the sell price, that it is not going to be 10 or 10.1 kwh. I assumed a 33% ROI would be reasonable since the cost is high (can't play video games, occasional aero lags, for months at a time), and the payout is very low--15 ENC a month for an average machine.

[Red]

Where did I mention anything about there being different difficulty levels? I am assuming half of the peers, as you try to argue, would be trying to subvert the 10kwh figure. If they were running at 1/2 difficulty or some such, then this example really wouldn't make sense, now would it? Or are we just trying to conflate and confuse instead of accepting that we are wrong?

Oh, I really thought you were trying to say something insightful. None of my example said anything about running at 50% of the hash rate. That is some random fantasy you made up.

I'm saying that a 190W (2mh/s) machine is going to be significant. And I'm saying that a 200W (3mh/s) machine saves a full third. A 400W (16mh/s) GPU machine saves 3/4s, even if the 400W number looks bigger.

Each block at a single difficulty level takes on average 2^(D-1) hashes to find. Where D is the number of leading zeros. This has nothing to do with (/second). The block doesn't care if you do it in one second or one hour. If all of my peers are averaging 1 block/day. Then if I can average the same block faster, I have hours to save electricity by loafing. There is nothing anyone can do about that.

You seem to think you can average everything out and each peer's individual variance doesn't matter. Woot! Ignore it! Tell everyone it won't matter! Yell it to the world!

I promise to keep my mouth shut. I'll do the same hashes as my peers. Get paid same ENC as my peers. And win, because my costs are lower. I will command the marketplace. I'll cash out faster because I can take the existing "highest bid", but still end up with a higher ROI then those waiting for a "lowest ask" that will never come.

Woot! Trust me! You'll never know the difference. This is the last thing I'll ever say on the subject. I may even go back and delete any mention of it from this thread. Knight will be so proud!

[Etlase2]

So we're back to the hardware that doesn't exist again. k

gl commanding the marketplace with 20 enc a month instead of 15 or 15 for the cost of 12. you'll make millions

[Red]

So we're back to the hardware that doesn't exist again. k

Anyway, good luck with it. I'm pulling for you to make it work. By the way, what does the "En" in EnCoin stand for?

I do appreciate you pulling me back here to talk about something that is not austrian economics, the wonders of the gold standard, or how hoarding bitcoins is just like buying stock in a new company! That used to be really tedious.

It was nice to hear someone else is a fan of stable digital money. Really, a year ago you could get shouted off the site just for mentioning it. It is a bit sad to see that you are not getting more interest.

[Etlase2]

Probably has to do with 3 pages of runaround arguments that are already covered in the proposal.

And En, predictably, stands for energy.

[BubbleBoy]

Very complex design. Does not achieve the stated goal of making one ENC require 10KWh - nor could any cryptocurrency. Does not achieve the revised goal of making 1ENC require 50 hours of computation from an "average" computer. No code available.

Even if achievable, the goal of pegging currency to electricity is a bad idea from a macroeconomic point of view. Electricity price hikes choke the money supply increase clamping economic growth. Electricity gluts create inflation.

Sorry, but this design is a nonstarter.

[Red]

Very complex design. Does not achieve the stated goal of making one ENC require 10KWh - nor could any cryptocurrency. Does not achieve the revised goal of making 1ENC require 50 hours of computation from an "average" computer. No code available.

That is the part I, and everyone else, have been trying to explain to him. That exercise is futile.

Even if achievable, the goal of pegging currency to electricity is a bad idea from a macroeconomic point of view. Electricity price hikes choke the money supply increase clamping economic growth. Electricity gluts create inflation.

These effects are true, but they turn out to be temporary in the sense that the price will re-stabilize. It will not tend toward zero or infinity. It will simply pick a new level and continue from there.

The thing that made that side effect less abhorrent to me was the relationship of the price of electricity to the outside economy as a whole. Electricity is a government regulated commodity.

If there is a "glut" of electricity then the "fuel charge" part of your electric bill tends to go down. However, random fees and transmission line maintenance costs tend to rise. As with water, it doesn't matter how much conservation everyone decides to do. The gross monthly billing to consumers is never allowed to fall so far that it bankrupts the utility.

Conversely, electricity tend to rise in proportion to general inflation. If your electric bill goes up, the price of bread is up, and *hopefully* your salary will rise to match. (I know salaries tend to lag. Such is life.)

Sorry, but this design is a nonstarter.

While I agree with you about this specific proposal. I agree with Etlase2 that stable money would be good. I also think using electricity as a benchmark worth further investigation and discussion.

And En, predictably, stands for energy.

But naming your currency as if it was an Enron product, seems a silly, silly thing!

[Etlase2]

Very complex design. Does not achieve the stated goal of making one ENC require 10KWh - nor could any cryptocurrency. Does not achieve the revised goal of making 1ENC require 50 hours of computation from an "average" computer. No code available.

There is no stated goal of requiring 10kwh. It was a number chosen that was based on the assumption that the average computer would dedicate about 200W of electricity to making coins. Competition and market factors would determine the final price.
Bitcoin does quite well at achieving an average award of 50 btc every 10 minutes; it is little different from an average computer achieving 1 ENC every 50 hours. Lack of difficulty reduction is a simple answer to anyone trying to game the system.
And thanks for pointing out that no code is available.

Even if achievable, the goal of pegging currency to electricity is a bad idea from a macroeconomic point of view. Electricity price hikes choke the money supply increase clamping economic growth. Electricity gluts create inflation.

Did you forget that there is an entire planet out there?

But naming your currency as if it was an Enron product, seems a silly, silly thing!

Baited question after baited question seems like you possess the mentality of a 12 year old! And the argumentation skills to boot! So quick to attack, yet so very few ideas. I wonder if it's jealousy.

[Red]

Baited question after baited question seems like you possess the mentality of a 12 year old! And the argumentation skills to boot! So quick to attack, yet so very few ideas. I wonder if it's jealousy.

Wasn't a baited question. I'd never given it two seconds thought.

It was a witty retort to your smug reply.

As for ideas. I defend your good ones. I defend no one's stupid ones. I don't mind starting another thread to actually discuss principles leading to a stable currency. Perhaps, someone who didn't reply to every question with, "It's obliquely referenced in my 28 pages of incoherent blathering about minting reform." would foster some discussion.

[Etlase2]

As for ideas. I defend your good ones. I defend no one's stupid ones. I don't mind starting another thread to actually discuss principles leading to a stable currency. Perhaps, someone who didn't reply to every question with, "It's obliquely referenced in my 28 pages of incoherent blathering about minting reform." would foster some discussion.

This would be fantastic. Staying on one topic at a time would be an added boon. Makes it a little easier to follow which of the 4 different purported attacks we are discussing, and a bit less easy to claim one meant a different one when I have an answer. Just sayin'.

Before I start a new thread however (with rev3.1 that addresses the issue of this thread), I want to figure out a way to do the freenet reputation differently.

As I had it, users would gain reputation with the freenet, and freenets would require a minimum user reputation based on its own reputation. This has a few flaws. Users could be "grandfathered" in to a higher FN reputation bracket for one, giving them an unequal weight in the consensus.

I thought maybe a FN's rep could be the aggregate of its users, but this has flaws as well. As users come and go, broadcasts would have to be sent to adjust the network's opinion of that freenet. Could get spammy if there are a lot of users. Although having a minimum of 30 RP or so to be considered part of the consensus is one option to mitigate that. Additionally, it would be difficult to judge if >50% of the reputation has confirmed a transaction. If a lot of high RP people are missing (assuming we go by total rep of the network, whether present or not), >50% reputation confirmations would be impossible.

So I'm kind of thinking of network-managed freenets (this would also apply to the "mercnets" or whatever the merchant-based ones would be called). Say there are RP level networks in the range of 0-29, 30-59, 60-119, something like that (each one in each range is weighted equally). Whenever a 'net hits a certain number of users, it will force a split into two. Say at 80 users, it splits into two 40 user nets. If a 'net drops below a certain number of users, say 15, then the net's reputation is no longer weighed in the consensus (users could set the option to automatically join another 'net if this happens). This means no confirming of transactions, and probably no minting blocks either. Every 10 minutes or so, each member of a 'net would have to sign a transaction block so that other 'nets can be sure no funny business is going on.

New 'nets that are created from a split won't have reputation weight until after the next PB so that current 'nets always know how much reputation is required to confirm a transaction in a given PB. They will be able to mint blocks though.
'Nets that die and effectively disappear would still be required for consensus so that intentional or unintentional network splits have no bearing on whether or not a transaction gets confirmed. At the next PB, 'nets that don't show up will be "set aside" for a certain period of time, say a few PBs or so, so that if they do return, whatever happened between the two networks can later be reconciled--but in the mean time, they are not required for consensus. They will begin confirming transactions under the new setup (perhaps they wait 1 PB?), but with a warning to users that a massive split has occurred and details on why this might have happened.

Splitting a network would be controlled by a pre-determined, random function so that it could not be subverted. Anyone not conforming to this function gets reported.

What do you think?

[bulanula]

IMHO instead of thinking about it all day long JUST DO IT so it can compete with SC2, Tenebrix and Fairbrix etc. as a cpu only coin etc. please 

[Red]

Before I start a new thread however (with rev3.1 that addresses the issue of this thread), I want to figure out a way to do the freenet reputation differently.

What do you think?

Clearly, I don't feel qualified to really come to terms with most of those details. But I can offer what (I think) are insights.

I always visualized your reputation idea as two layered. You have FreeNets which gain reputation as a whole. And you have individuals, who are ranked (for lack of a better term) by their FreeNet Peers. To make a lame example, I may be a "made man" in the Italian Mob. But if I quit and go to the Russian Mob, my rank doesn't necessarily travel with me.

I assumed in between when someone asked to become part of a FreeNet and when they were accepted into the FreeNet there was some sort of vote based on the existing FN Peers. I guess I'm suggesting that when you apply to be a member of a FreeNet. That the application contains an "rank" that you are applying for. If members don't think you are proven enough for that rank, they reject you.

To make an example, I might say "Yo! I'm currently ranked 100% in Fred's (90 RP 3 block/day) FreeNet. I'll quit Fred, if you let me join Ryan's (180 RP 4 block/day) FreeNet at 75% rank. That way, I don't have to start from the bottom again.

I was presuming, the FreeNet reputation dictated the total number of coins the FN could generate in a block. And the intraNet rank somehow affected how those coins were split among members.

[Red]

Continuing on a slightly different point.

-----

FreeNet reputation seems intended to be a measure of a network's combined Reliability over time. In my mind, I define that Reliability as made up of two parts Availability and Accuracy.

Availability means at least one of the FreeNet's peers must be online to receive transactions, validate them, and to batch and send those transactions around. The goal for the FreeNet is 100% availability.

Accuracy means every transaction must be validated and confirmed exactly according to the crypto and accounting rules. Each FreeNet is required to be 100% accurate. If even one invalid transaction is confirmed, action must be taken.

So if a FreeNet is 100% available and 100% accurate for some period of time, they reach a max Reputation. I know you had said validation/confirmation errors would really hammer a FreeNet's reputation. I began wondering if it should be a death penalty. That seemed overkill at the FN level.

---

When I thought about these two concepts at the peer level I noticed a difference. Each peer must still be 100% accurate. But each peer is not required to be 100% available. Also, minting effort seems to be more important intraFN than between networks.

So if a peer solves minting blocks he might increase in rank. If a FN member peer is not 100% available he might lose rank. But if a FN member peer is not 100% accurate, the FreeNet either has to kick him out, or shut down. No other FN should trust a net that is even partially non-compliant.

If a guy is shopping for a new FreeNet, I'd want to know if he got kicked out of his previous one!

---

You seem to be seeing network membership as more flowing and flexible then me. I'm interested in hearing more about that. But this is the original picture I got in my mind when I read the proposal.

[Red]

So of course not I realize you are trying to PREVENT people from deliberately building particularly reputable FreeNets. I'm guessing this is to prevent 51% transaction confirmation DOS attacks.

I was never able to identify any other power a 51% majority gave a malicious group. You weren't worried about past posting, and falsifying transactions is still impossible. It doesn't seem to be a minting issue.

If I'm missing an issue, I really am clueless I guess.

But if you are worried about the transaction DOS issue I realized that such an attack is trivial to detect. If you see a valid transaction that doesn't make the next primary block. If that transaction is still valid after PB reconciliation, then it MUST be appear in the next PB or a DOS is happening.

Any way. I hope at least one thing was insightful.