Pages:
Author

Topic: [ANNOUNCE] The Proposal for EnCoin - page 5. (Read 9455 times)

hero member
Activity: 798
Merit: 1000
October 03, 2011, 07:06:10 PM
#47
Ah, now I see the issue You think ROI is a cause, not an effect!

Whatever makes you happy.

Quote
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.
hero member
Activity: 798
Merit: 1000
October 03, 2011, 06:59:56 PM
#46
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.

Quote
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?

Quote
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.
Red
full member
Activity: 210
Merit: 115
October 03, 2011, 06:32:31 PM
#45
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! Wink

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?
Red
full member
Activity: 210
Merit: 115
October 03, 2011, 06:21:23 PM
#44
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.
hero member
Activity: 518
Merit: 500
October 03, 2011, 04:40:04 PM
#43
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.
hero member
Activity: 798
Merit: 1000
October 03, 2011, 04:13:43 PM
#42
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.
hero member
Activity: 798
Merit: 1000
October 03, 2011, 03:15:29 PM
#41
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.

Quote
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.
hero member
Activity: 798
Merit: 1000
October 03, 2011, 03:01:55 PM
#40
The way I understand your minting process, each FN works in collaboration to solve a single minting proof-of-work. Exactly analogous to a bitcoin mining pool. I also understand (but could be wrong) that each FN submits only one minting transaction per Primary Block. I'm under the understanding that this has to be done a time constraint that at maximum starts at one PB and ends at the completions of the subsequent PB.

You have an incorrect understanding. Any FN can make as many blocks per day as they want. In fact, in rev2 and several times throughout the first thread, I showed the formula of 6 hours x 50 peers x 200wh = 60kwh or 6 ENC. The 6 hours and 50 peers were averages. If there are 100 peers in a FN, it should take 3 hours on average.

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. 2mh/s gets a 3.33 coin bonus for the same work than if 1mh/s had been going at 2mh/s. Encoin may be mistaken about how much the coins cost to produce, but the 2mh/s people can sell their coins for cheaper thanks to the 1mh/s people because they get more coins for the same work. That's why I had a whole section on why this doesn't matter. Market. Forces. If you want to nitpick that 50% may be able to run 1mh/s at 47% power or 2mh/s at 94% power or whatever, this does not matter because whatever efficiency gain they have was either at a cost, or because of "hackers" that have to try to keep an efficiency gain secret. Newer, more efficient hardware is most decidedly not a secret.

People are not going to just blindly assume that a coin costs 10kwh to produce. They could, with their ghetto 5 year old rig, start making coins and see that they're doing better than that if the network were conspiring to make cheap coins. As more realize this, the coins will go back to costing 200W to produce, and the effort was a failure.

Quote
If you tell me, I'm wrong and each team can submit as many blocks as they want during a period. It really doesn't change the problem. You can scale to any average of completed blocks per period you choose. The faster system can always lie.

They can, but it benefits everybody, not just them. And the lie won't hold for long when people realize cheap coins are to be had.

Quote
Technology will improve. Improvements will be obvious to some. Not to others. That is how knightmb got 710,000 bitcoins for a trivial investment. I'm not saying he destabilized the network. I'm saying he profited handsomely without even trying to destabilize the network. And he did it secretly, right in front of everyone while posting daily in the forums.

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.

Quote
Really the exchange price is what all clients are going to care about. When I said stable I meant outside of extreme circumstances like Amazon adopting ENC, of Silk Road getting busted. On a day to day basis, ENC prices should vary between say 9.9 kwh and 10.1 kwh. (2%) At worst maybe 5-10%. But you are saying 15kwh which means that maybe it falls to 5kwh? That is a 100% variation. Doesn't seem that stable if I'm a client. I'm definitely going to try market timing with those swings.

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.

Quote
I'm saying even an accidental +-5% variance among clients is going to mean the more electrically efficient, chase out the less electrically efficient. Most people won't even recognize why. It won't crash the client economy. It will make the minter community's breath smaller than you anticipate. I've said from the beginning I don't care about this. I don't care if there is only a single minter. So long as client facing ENC prices stay stable.

And all of this is already covered. There are 100% variations in the cost of electricity around the world, this doesn't mean there will be 100% variations in the cost of an ENC. Yes, the value of ENC could very gradually go down if fusion power were invented and rapidly adopted. But market forces will work against this. "I can run at 400W on fusion and still be profitable, so I will." (the sec 8-2 deflation helps against fusion too!) And as the world catches up, the cost to produce goes back to where it was. I might be able to come up with something to prevent mass coin makings in a stable economy. I'll have to think on that.

I can't predict the future, but I know for damn sure it will be a hell of a lot more stable than bitcoin. And there is no threat of early coin sell-off. Or 51% attack disrupting the network permanently. Or childishly simple attacks on the production costs that I must have never thought of when designing this proposal.
Red
full member
Activity: 210
Merit: 115
October 03, 2011, 02:05:26 PM
#39
I never said I had a problem with non-minting peers. I said I had a problem with non-peering minters. I think non-minting peers can easily be solved without worrying about any effect it might have on minting peers.
I'm absolutely sure plug computers could handle all the non-minting tasks without breaking a sweat. That is a lot of network support if the Freedom Box project makes. (A huge if!)

And to grab some other bitcoiners, it could award bitcoins and encoins by the merged-mining process during bootstrap. But miners don't make the economy. They do, however, spread the word.

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?

Oh and I saw this in the proposal.

9-3) Blind Signatures; “Mixing” coins

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.

https://bitcointalksearch.org/topic/m.6793
Red
full member
Activity: 210
Merit: 115
October 03, 2011, 01:53:49 PM
#38
See, now this is a topic worth discussing. It's amazing when you're mad how much more sense you can make. Instead of babbling off for pages and pages about useless bullshit, we can finally get to the heart of why I wanted to see if this proposal would be feasible or not. Now, by the fact that there have been about 3 or 4 secure hashing algorithms devised per decade in the world of modern computing, do you think it is feasible to stay ahead of the curve of application-specific hardware, including its unsunk costs, for the future?

No. That was why I said Computationally Undecidable. That is the point I and (John?) and others have posted from the beginning.


--or it is the same or more efficient and uses less maximum power--this is a problem I outlined in the proposal which could be mitigated by the mild deflationary measure described in 8-2. If they decide to not run the processor at 100% to save energy and have a higher mhash/J, then the same problem happens when everyone upgrades and starts using full power--they make less money. If EVERYONE decided to use less power, then you have an issue. But then again, you always have to worry about greedy people using full power and making more money. So, not really an issue. The halting problem has fuck-all to do with this.

This is the closest of your examples to what I wrote. However you use the work efficiency to mean how many khashes/sec I use efficiency to mean how many kwh/khash.

The way I understand your minting process, each FN works in collaboration to solve a single minting proof-of-work. Exactly analogous to a bitcoin mining pool. I also understand (but could be wrong) that each FN submits only one minting transaction per Primary Block. I'm under the understanding that this has to be done under a time constraint that, at maximum, starts at one PB and ends at the completion of the subsequent PB.

You scale the difficulty of this proof-of-work (I think) based upon time in a similar manner to how bitcoin does. Meaning, in bitcoin's sense, one POW solution per (all miners) per 10 minutes. If on average (all miners) produce a solution faster than one every 10 minutes the difficult is made harder. Slower the difficulty is made easier.

Your system seems to replace (all miners) with (FreeNet). You allow each FreeNet to produce one solution per fixed-length period. You completely remove the competition between FreeNets. In bitcoin, the competition is the incentive used to keep miners honest about their solution timing. That timing is what makes it possible to adjust the difficulty.

In your system, you can't tell the differences between a FN that took 99% of the period to complete their solution. And one that took 5% of the period to complete the solution and idled their electrical consumption for 94% of the time. Then lied to you about running full blast for 99% of the period.

If you tell me, I'm wrong and each team can submit as many blocks as they want during a period. It really doesn't change the problem. You can scale to any average of completed blocks per period you choose. The faster system can always lie.

If you can't tell the difference between the truth and a lie, you can't make compensation. That is where the halting problem comes in. Specifically, since there is no algorithm that can tell if an arbitrary SHA2() implementation will complete ("halt") for any given input. There is no algorithm that can tell if it will complete in a certain number of instructions or clock time.

In this particular problem, "lying cooperatively" has a greater long term monetary benefit than, "honestly competing" for higher initial gains. That is why it is called the prisoner's dilemma. If the same scenario is repeated over and over, it is called the iterated prisoner's dilemma. In its iterated version, it is used to evaluate competing algorithms for maximizing long term gain. Exactly as EnCoin is doing.


Wait a minute, so you're saying there is specific hardware--that may or may not even meet the minimum hashing requirements--

Closing your eyes and pretending that people are not trying to optimize things for reasons other than your network, doesn't make it so.

Technology will improve. Improvements will be obvious to some. Not to others. That is how knightmb got 710,000 bitcoins for a trivial investment. I'm not saying he destabilized the network. I'm saying he profited handsomely without even trying to destabilize the network. And he did it secretly, right in front of everyone while posting daily in the forums.


10kwh is the STABLE COST TO PRODUCE. Not sell price.

Really the exchange price is what all clients are going to care about. When I said stable I meant outside of extreme circumstances like Amazon adopting ENC, of Silk Road getting busted. On a day to day basis, ENC prices should vary between say 9.9 kwh and 10.1 kwh. (2%) At worst maybe 5-10%. But you are saying 15kwh which means that maybe it falls to 5kwh? That is a 100% variation. Doesn't seem that stable if I'm a client. I'm definitely going to try market timing with those swings.


Your logic is based in a conjured up scenario where someone can pay 5kwh (or .01kwh) to produce a coin rather than 10kwh without rationalizing it

I'm saying even an accidental +-5% variance among clients is going to mean the more electrically efficient, chase out the less electrically efficient. Most people won't even recognize why. It won't crash the client economy. It will make the minter community's breath smaller than you anticipate. I've said from the beginning I don't care about this. I don't care if there is only a single minter. So long as client facing ENC prices stay stable.

You, however, suggest this will effect EnCoin's long term viability. If so, that's a design flaw. First fix the flaw, then make if fair to minters again. That's all I'm saying.

I plan on becoming a client, not a minter. I might even run a peer to keep everything flowing. But I'm not tolerating CPU fan noise just to feel good about myself. That was why I shut down bitcoin.
hero member
Activity: 798
Merit: 1000
October 03, 2011, 12:48:46 PM
#37
I never said I had a problem with non-minting peers. I said I had a problem with non-peering minters. I think non-minting peers can easily be solved without worrying about any effect it might have on minting peers. If the data load is too much, minting peers could start charging a small fee, for example. In bitcoin, you don't have a choice. If you want anonymity, you need the whole shebang.

As far as marketing goes, there is a sizable number of people that believe bitcoin is bullshit, those could be the starting user base. Getting demand up to 10kwh+ sell prices would be difficult and would take time, but I don't think it would be impossible. Since there is no threat of the early coin collapse, perhaps the drug trade would take to it over bitcoin. I don't know. Once coins get stable, everyone powers down and waits until the market expands. Without the required tx fee, businesses have an even bigger advantage to use encoins over something else. I'm glad I was able to figure out a happy medium there. I didn't want to take their money away, but I had not yet thought of an idea to do it while protecting the consensus. Now the new way seems that it will actually improve the consensus. A boon for everybody.

And to grab some other bitcoiners, it could award bitcoins and encoins by the merged-mining process during bootstrap. But miners don't make the economy. They do, however, spread the word.
Red
full member
Activity: 210
Merit: 115
October 03, 2011, 12:23:58 PM
#36
--- Marketing ---

One of the reasons I'm so obsessed with not burning needless CPU power when not absolutely necessary is for marketing reasons.

Bitcoin had a great bootstrapping plan,
1) Appeal to anarchist libertarians who don't trust the fed to keep monetary policy stable.
2) Appeal to those who hate banks because they return low interest, when inflation is low. And return almost no interest while everything is deflating.
3) Appeal to those who hate stock investing because the market was currently crashing.
4) Convince them bitcoin was like investing because it was a deflationary currency and therefore anything bitcoins you stuffed in your mattress today were going to make you rich tomorrow.
5) Start giving out free bitcoins and hope (1,2,3) buy into the (4) logic.

Turns out in retrospect, it was a brilliant plan.

--------

A stable currency has to make a different appeal. I'm not even exactly sure who it appeals to. Certainly it serves exactly the same niche as paypal, visa, mastercard, etc. There is not much to differentiate it if you compete for clients only on price.  

However, the one thing that attracted me to bitcoin was its promise of anonymity. I don't mean its "strong" anonymity. Like, "The police can't catch me while I'm buying drugs!" To me even bitcoin's "weak" anonymity has value.

Especially marketing value!

You are never going to generate mass appeal for a system that claims to let criminals get away with being criminals. I accept that as a given.

However, it may be possible to generate mass appeal for a system that "prevents monitoring" of behaviors that most people are repelled at the thought of having monitored. Say buying controvercial books, porn, visiting strippers, cheating on your spouse, etc. It is for these types of activities that people currently use cash. Cash doesn't have "know your customer" laws like electronic banking/credit does.

There is a growing number of activities being suggested for additional monitoring. For example, buying fast food cheeseburgers. Or french fries, or beer, or cigarettes, or ice cream. A lot of progressive thinkers advocate tracking  these sorts of activities and reporting behavior patters to either the government or private health care plans.

It is very easy for people to imagine the government telling MasterCard to turn over everyone's purchase records to the Obamacare administrators. Or to tell Google to turn over everyone's search records. That way people can be targeted for specific "education" about the dangers of these behaviors.

I think it is these people to which EnCoin could appeal.

A subgroup of potential early adopters/advocates might be the Freedom Box Foundation. They advocate everyone having their own low power home server, specifically to protect their personal privacy. The project is still in its beginnings but they are proposing to use 5W plug computers like I linked previously.

These boxes will tunnel browsing over TOR. Host personal mail servers. Share personal files. Enable other folks to jump firewalls. etc. In general, the set of all plug boxes reinvents the cloud computing concept, except people own their own parts of the cloud. Their philosophy is very complementary your intentions for EnCoin.

However, I'm guessing they would be much more interested in running non-minting Peers. They already don't mind buying and running their own cheap server to participate in shared cause (like TOR). But they would be opposed to *literally* overheating their plug servers to prove their dedication. Or to burn so much CPU power that the other "Freedom Box" features wouldn't function as intended.

I put myself in this class of possible EnCoin users. I don't mind telling my server to help EnCoin with bandwidth and transaction monitoring. But, if it slowed down my browsing, email, or required me to add a fan to the plug. Poof, the EnCoin process would be gone. Minting profits are not part of my personal value calculation. I wouldn't waste the CPU cycles stressing the server, even if the electricity was guaranteed to be offset by minting awards.

But that is just me.

Do you have any thoughts on bootstrap marketing?
hero member
Activity: 798
Merit: 1000
October 03, 2011, 12:15:38 PM
#35
Ah! I supposed you had at least a little background in computer science. Or at least some software engineering experience. I guess not. Loop unrolling is an optimization technique you learn in your sophomore year. But in my example it is a place holder for one of the numerous optimization techniques available to any hacker who isn't completely clueless.
http://en.wikipedia.org/wiki/Loop_unwinding

No, I was being deliberately dense. Optimizations have already been discovered to improve the efficiency of the same GPU by 10% or so in bitcoin's history. And they were shared with the community. While I suppose it's possible that some awesome hacker could find a great way to optimize and be ahead of the curve, these optimizations cannot continue to improve forever, and you assume that only one person could ever find them. Then only share it with more and more of his friends, which hurts himself as there is competition, and "loose lips sink ships" so they say. The more people that know the more likely it will become public. Oops, patch and now you have no advantage. If it's only kept among a small group, the effect on the economy is negligible. And they can't vote to keep a software patch from hitting everybody else.  Undecided

Quote
Now it is you that is being deliberately dense. I said clearly, (and I guess I'll have to link the halting problem too.) it is algorithmically impossible for you to detect this. And by consequence of not being able to detect it, you cannot adjust the difficulty.

The incentive to have a more efficient processor is to use it, is it not? It is either more efficient and uses the same amount of power--this is dead easy to adjust for as the difficulty will go up as more mhash/s/user are put into the system--or it is the same or more efficient and uses less maximum power--this is a problem I outlined in the proposal which could be mitigated by the mild deflationary measure described in 8-2. If they decide to not run the processor at 100% to save energy and have a higher mhash/J, then the same problem happens when everyone upgrades and starts using full power--they make less money. If EVERYONE decided to use less power, then you have an issue. But then again, you always have to worry about greedy people using full power and making more money. So, not really an issue. The halting problem has fuck-all to do with this.

Quote
Speeding up how fast I can calculate a SHA(2) has no bearing on the cryptographically hard problem of reversing the SHA(2) hash. I'm not going to explain this, nor am I going to bother even giving you a wiki link. It should be obvious to the casual observer.

It's SHA2, not SHA(2) broseph. I'm not going to explain this, but it should be obvious to the casual observer. See I can be a nit-picky dick too.


Quote
Plug Computers cost less then $99 and run at about 5 watts. Check the block diagram and look for the little block labeled "Cryptographic Engine and Security Accelerator"

Wait a minute, so you're saying there is specific hardware--that may or may not even meet the minimum hashing requirements--that supports cryptographic functions that are 15 to 20 years old, and it still costs $100 (6 months to recoup first assuming they can even hit the minimums, THEN assuming it provides enough mhash/s to even be average)--and I need to be worried about this completely crashing down the whole system? It's great that your argument revolves around ignoring unsunk costs and inability for these specific machines to perform anywhere near the same magnitudes of hashes/s as a GPU, but perhaps you could provide some specific details as to why this has not overtaken bitcoin, for example? Which does not even have a need for a minimum hash/s, btw.

Quote
Ah, that is what you mean by new algorithm! I've got news for you! SHA2(SHA2(X)) is not a difficult new algorithm. It is running the same SHA2() algorithm twice! It takes exactly twice as long as running it once. If I was 5% faster then you at SHA(X), then I'm 5% faster than you at SHA(SHA(X)). We are both working on the same linear problem. If I have SHA() and SHA() implemented on an ASIC then I already have SHA2(SHA2()), SHA2(SHA1()), SHA1(SHA2()), SHA1(SHA1()) implemented as well. They come for free.

There are a limited number of trusted cryptographic algorithms. All can be done in software. All can be done in hardware. All strive for simplicity and efficiency making hardware acceleration cheap.

See, now this is a topic worth discussing. It's amazing when you're mad how much more sense you can make. Instead of babbling off for pages and pages about useless bullshit, we can finally get to the heart of why I wanted to see if this proposal would be feasible or not. Now, by the fact that there have been about 3 or 4 secure hashing algorithms devised per decade in the world of modern computing, do you think it is feasible to stay ahead of the curve of application-specific hardware, including its unsunk costs, for the future?

Quote
If your coins are selling for 13-15kwh then say Clients are intended to buy coins for 13-15kwh but FNPeers are intended to buy/mint them for 10kwh. All that 10kwh=1ENC sounds like bunk now. And it is clear that you see this as a government cost+award_fee situation. But even on government contracts, the contractor only gets an 8% return on the Government's investment. Here you want clients to pay 30-50% award, for their privilege of paying for FNPeer's intentionally inflated electric bills.

Coins will sell for whatever the market will bear. Apparently bitcoins have no problem selling for 70 cents over their cost to produce. Coins still require a large time investment. If you want to buy that TV for 1000 encoins, you can either mine for 5 years or buy 1000 encoins off the market. The choice is yours. Once there are enough coins for a stable economy, coins do not need to be produced and in fact would be penalized by the RP system I had devised. I did not claim it was perfect, but it was a starting point. But having to devote your computer to nothing but the search for coins is not a profit-free enterprise. This should be obvious. 10kwh is the STABLE COST TO PRODUCE. Not sell price.

Quote
I mean WTF! You don't think my logic still holds?

Your logic is based in a conjured up scenario where someone can pay 5kwh (or .01kwh) to produce a coin rather than 10kwh without rationalizing it--other than "hackers efficiensize the code" or "asics do it for low watts" scenarios of which both have happened to bitcoin, neither has caused a crash of the miner economy. Because "hackers" released their code, and "asics" cost too much--when the price isn't inflated by hoarding. Which wouldn't be a problem in encoin because scarcity is not what creates value.
Red
full member
Activity: 210
Merit: 115
October 03, 2011, 10:55:15 AM
#34
I would like to add that I think I have found the perfect solution. My tx fee was always designed around keeping people minting in a stable economy.

Excellent, you are stating to see the lack of necessity in burning when not necessary! There may be hope for you yet! Smiley

BTW, Cool image!
Red
full member
Activity: 210
Merit: 115
October 03, 2011, 10:52:20 AM
#33
"- Unroll your loops, there by speeding up your implementation, and finishing 1,000,000 khashes in <10 kwh"
You're going to have to explain what "unrolling your loops" means because I don't get it.

Ah! I supposed you had at least a little background in computer science. Or at least some software engineering experience. I guess not. Loop unrolling is an optimization technique you learn in your sophomore year. But in my example it is a place holder for one of the numerous optimization techniques available to any hacker who isn't completely clueless.
http://en.wikipedia.org/wiki/Loop_unwinding

In the mean time, everyone else has a chance to catch up and get the same benefit by the sunk cost of purchasing new computer hardware. And by then, the difficulty has adjusted so that now Charlie is not making an extra profit for being ahead of the curve.

Now it is you that is being deliberately dense. I said clearly, (and I guess I'll have to link the halting problem too.) it is algorithmically impossible for you to detect this. And by consequence of not being able to detect it, you cannot adjust the difficulty.

"- Rewrite your algorithm to run on his cheap ass [GPU], and finishing 1,000,000 khashes in <8 kwh"
Rewrite a cryptographic hashing algorithm in some way that results in the same hash for less cpu cycles? NSA and NIST would be very interested to know about this mad genius--considering they generally have some of the smartest people in the world making sure that this isn't possible.

First off, CPU was a typo. I fixed it to be its intended GPU. But that doesn't change the fact that you are still clueless about cryptography (as you point out in your first section). Optimizations in calculating basic cryptographic functions happen every day. My 10 year old PC calculates the same exact SHA(2) hashes as your speedy new laptop. It just take more time an electricity to do exactly the same work.

Speeding up how fast I can calculate a SHA(2) has no bearing on the cryptographically hard problem of reversing the SHA(2) hash. I'm not going to explain this, nor am I going to bother even giving you a wiki link. It should be obvious to the casual observer.


"- Buy an ARM processor with (X) hash implemented in hardware to run on a cell phone, and finish 1,000,000 khashes in < 6 kwh"
So let me get this... now charlie is putting hundreds of thousands or millions into R&D to get a processor that only he and his 51% friends will have, and they will somehow profit from this? And they will profit before the hashing algorithm randomly changes?

Closing your eyes doesn't really make the world cease to exist.

Plug Computers cost less then $99 and run at about 5 watts. Check the block diagram and look for the little block labeled "Cryptographic Engine and Security Accelerator"


NEW algorithms are added by vote, by the way, to make sure that the network doesn't break compatibility with itself. I don't know how well application-specific hardware handles SHA1(SHA2()) vs SHA2(SHA1()) vs XXX(SHA2(SHA2())), but that is something that could be answered by a cryptography expert during the development process. And those who are NOT voting in new algorithms would be quite obvious, just like a consensus attack.

Ah, that is what you mean by new algorithm! I've got news for you! SHA2(SHA2(X)) is not a difficult new algorithm. It is running the same SHA2() algorithm twice! It takes exactly twice as long as running it once. If I was 5% faster then you at SHA(X), then I'm 5% faster than you at SHA(SHA(X)). We are both working on the same linear problem. If I have SHA() and SHA() implemented on an ASIC then I already have SHA2(SHA2()), SHA2(SHA1()), SHA1(SHA2()), SHA1(SHA1()) implemented as well. They come for free.

There are a limited number of trusted cryptographic algorithms. All can be done in software. All can be done in hardware. All strive for simplicity and efficiency making hardware acceleration cheap.


It's not as if I didn't have a section devoted to this in the proposal. FPGAs cost 400-500 dollars. The profit on one coin is probably going to be $.50-$1. FPGAs run very few mhash/s for a slightly higher mhash/J than GPUs. If their FPGA doesn't get the minimum hash value, whoops they don't get paid, so they'd probably need multiple FPGAs. And they would need many, many years just to break even on this hardware that has no use other than to hash. And in the mean time, GPUs or CPUs will get more efficient as well per mhash/J, but the difficulty will compensate for that. So FPGAs might have their utility wiped out as they can't be upgraded to hash faster without sinking more money into a piece of hardware that serves no function other than to try to squeak out an extra few cents per coin.

I'm not going to bother responding to this section, since above I've already done so above. If by this point in my post, if you don't realize your crypto presumptions are so far off as to make this logic nonsense, I can't help you. 


To top it all off, you're grossly misrepresenting the profit margin. A coin that costs 10kwh to produce isn't selling for 10kwh, it's selling for around 13-15kwh. So while Charlie can focus on sinking thousands of dollars into making an extra 5kwh in profit, he's still only doubling his margin, not 6x or 60x.

If your coins are selling for 13-15kwh then write in your thesis, "Clients are intended to buy coins for 13-15kwh but FNPeers are intended to buy/mint them for 10kwh." All that 10kwh=1ENC sounds like bunk now. And it is clear that you see this as a government cost+award_fee situation. But even on government contracts, the contractor only gets an 8% return on the Government's investment. Here you want clients to pay 30-50% award, for their privilege of paying for FNPeer's intentionally inflated electric bills.

Spare me your math about how I don't see that this is insignificant to clients compared to the benefits they receive. Your response is not necessary. I understand how rationalization works.

But even acknowledging your silliness. Let's do the math.

$1 = 10 kwh
10 ENC = $15.00
Efficiency Advantage = 5 kwh
Completive Advantage = 2x

Bill's Profit = $15.00 - $10.00 = $5.00
Charlie's  = $15.00 - $5.00 = $10.00

---

$1 = 10 kwh
10 ENC = $12.00
Efficiency Advantage = 5 kwh
Completive Advantage = 3.5x

Bill's Profit = $12.00 - $10.00 = $2.00
Charlie's  = $12.00 - $5.00 = $7.00

---

10/5, 9/4, 8/3, 7/2, 6/1, 5/0
2.00, 2.24, 2.66, 3.5,  6, INF

I mean WTF! You don't think my logic still holds?

Unless Charlies take over the network in which case they must compete against themselves and lower the profit margin. So all this effort goes into making a short-term profit on thousands or hundreds of thousands of dollars on investment that will even out and make their profit almost the same as before if they had just used honest hardware. Not very logical, now is it?

You are totally missing the point, Charlie can take over the network and CHOOSE not to reduce his profit margins. All he has to do is keep doing whatever what most profitable when he ran everyone else out of business.

Should Charlie and his friends turn on each other, only then is it mutually assured destruction. Until someone more efficient comes along. Wash, rinse, repeat.
hero member
Activity: 798
Merit: 1000
October 03, 2011, 10:10:11 AM
#32
I would like to add that I think I have found the perfect solution. My tx fee was always designed around keeping people minting in a stable economy.
But... similar to your idea Red, but requiring much less breaking the foundation of my proposal, have TxFeeFreeNets. Perhaps it requires some minimum of 30 RP earned in MintingNets or whatever, that could be worked out later. But anyone in a TxFeeFreeNet runs at 1/20th or hell maybe even 1/50th, doesn't matter now as long as it's something, and they will get a refund on all tx fees associated with their account instead of a coin payout. That way you know that these accounts are legitimately trying to secure the network, and it doesn't require coins to replace those that are lost, except for very casual users. Any business would want to be in a txfeefreenet as the savings would easily outweigh the costs, and everybody wins!

hero member
Activity: 798
Merit: 1000
October 03, 2011, 09:00:19 AM
#31
Wow, the end is nigh, you actually stayed on one point without straying off to useless side topics that only serve to divert from what you are trying to say.

"- Unroll your loops, there by speeding up your implementation, and finishing 1,000,000 khashes in <10 kwh"
You're going to have to explain what "unrolling your loops" means because I don't get it.

"- Buy the latest 3 volt pentium, and finish 1,000,000 khashes in < 9 kwh"
If Charlie is buying the latest 3 volt pentium to finish @ 9kwh, then Charlie has to account for the cost of that 3 volt pentium which won't be paid back for months on end. In the mean time, everyone else has a chance to catch up and get the same benefit by the sunk cost of purchasing new computer hardware. And by then, the difficulty has adjusted so that now Charlie is not making an extra profit for being ahead of the curve.

"- Rewrite your algorithm to run on his cheap ass CPU, and finishing 1,000,000 khashes in <8 kwh"
Rewrite a cryptographic hashing algorithm in some way that results in the same hash for less cpu cycles? NSA and NIST would be very interested to know about this mad genius--considering they generally have some of the smartest people in the world making sure that this isn't possible.

"- Buy an ARM processor with (X) hash implemented in hardware to run on a cell phone, and finish 1,000,000 khashes in < 6 kwh"
So let me get this... now charlie is putting hundreds of thousands or millions into R&D to get a processor that only he and his 51% friends will have, and they will somehow profit from this? And they will profit before the hashing algorithm randomly changes?

NEW algorithms are added by vote, by the way, to make sure that the network doesn't break compatibility with itself. I don't know how well application-specific hardware handles SHA1(SHA2()) vs SHA2(SHA1()) vs XXX(SHA2(SHA2())), but that is something that could be answered by a cryptography expert during the development process. And those who are NOT voting in new algorithms would be quite obvious, just like a consensus attack.

"Then at 11 kwh Charlie makes 6x the profit in dollars as Bill.
(If the coins sold at 10.1 kwh, Charlie's multiple would be MUCH (60x?) higher.)

If you don't think this is a significant difference. Well, off you go then."

It's not as if I didn't have a section devoted to this in the proposal. FPGAs cost 400-500 dollars. The profit on one coin is probably going to be $.50-$1. FPGAs run very few mhash/s for a slightly higher mhash/J than GPUs. If their FPGA doesn't get the minimum hash value, whoops they don't get paid, so they'd probably need multiple FPGAs. And they would need many, many years just to break even on this hardware that has no use other than to hash. And in the mean time, GPUs or CPUs will get more efficient as well per mhash/J, but the difficulty will compensate for that. So FPGAs might have their utility wiped out as they can't be upgraded to hash faster without sinking more money into a piece of hardware that serves no function other than to try to squeak out an extra few cents per coin.

To top it all off, you're grossly misrepresenting the profit margin. A coin that costs 10kwh to produce isn't selling for 10kwh, it's selling for around 13-15kwh. So while Charlie can focus on sinking thousands of dollars into making an extra 5kwh in profit, he's still only doubling his margin, not 6x or 60x. Unless Charlies take over the network in which case they must compete against themselves and lower the profit margin. So all this effort goes into making a short-term profit on thousands or hundreds of thousands of dollars on investment that will even out and make their profit almost the same as before if they had just used honest hardware. Not very logical, now is it?


edit: you just completely changed your post while I was writing this, I will see if there is anything new worth responding to
Red
full member
Activity: 210
Merit: 115
October 03, 2011, 07:18:47 AM
#30
Really. One more time...

If you build *any* bitcoin like tunable proof-of-work implementation using hardware and software.
Then you tune the difficulty so that it requires (WAG) 1,000,000 khashes to solve,
because 1,000,000 khashs on the existing (or average) hardware/software combination burns 10 kwh.

Then I claim, *inevitably* and *undetectably*, that some Charlie will (choose one or more)
- Unroll your loops, there by speeding up your implementation, and finishing 1,000,000 khashes in <10 kwh
- Buy the latest 3 volt pentium, and finish 1,000,000 khashes in <9.8 kwh
- Rewrite your algorithm to run on his cheap ass GPU, and finish 1,000,000 khashes in <9.5 kwh
- Buy a $30 ARM cell phone processor with (Z) hash implemented in hardware, and finish 1,000,000 khashes in <9.3 kwh

You can't argue that something like this isn't going to happen.
I claim that you can't detect,
-who is running the original 10 kwh implementation vs
-who are running <10 kwh implementations.

If you allow, simultaneously created new FNs named "Bill" and "Charlie" to form.
And despite your *drastic* 1/10th restriction limiting each of them to minting (X) coins a day at 1,000,000 khashs. (Because, before they can get the full reward, they both need to prove their worth by continuously generating RP over time thus avoiding Sybil attacks)

And as stated above, since you *cannot* detect Bill nor Charlie's *actual* electrical usage. Then,
if Bill's hardware is 10 kwh/1,000,000 khashes, and
and Charlie's hardware is 9.5 kwh/1,000,000 khashes,
and both sell their (X) newly minted coins for dollars at 1 ENC = 10.1 kwh
Then at 10.1 kwh, Charlie makes six times (6x) the profit in dollars as Bill.

The problem is not that your system isn't working. The monetary policy is working great!
And the better it works, the higher Charlie's advantage is!
If coins sell at 10.01 kwh, Charlie makes (51x) the profit of Bill.
If coins sell at 9.99 kwh, Charlie can claim in the forums that he and Bill are both losing money, but...

Charlie's a hero for sticking it out for the security of the system.
But Bill, the lamer, is dropping out because he's not making money anymore. Greedy bastard!


If you don't think this is a significant difference. Well, off you go then...
And if you don't think this news will get around out-of-band to Charlie's personal human friends. Well, OK then...
And if you don't think Charlie's 6x or 51x more profitable friends could possibly grow to 51% RP. Well then, awesome plan!...

--- Summary For the Thinking Impaired ---

1) You can't detect if a node is generating 1 ENC = 5 kwh.

You can't detect if people are minting at greater efficiency then specified. This turns out to be very significant to each individual's profitability and incentive to continue minting.

4) 10 kwh need not be burned to guarantee 1 ENC = 10 kwh.

But, it is less significant to monetary policy. The ENC value barely deviates from optimal.

2) You can't detect if some human collective has 51% of the RP.

The efficient will drive out the inefficient whether you notice it or not. It's math.

3) Humans can't reach an intelligent consensus if everyone is anonymous.

If Ryan is the last 10 kwh FN, he has little hope of forming a RP based consensus for changing the hashing algorithm. Everyone else will claim that $9.99 to offset their $10 electrical bill is good enough. They'll all willing to sacrifice the additional penny for the security of the system.

If Ryan can't throw in a penny for the security of the system, why are we giving him any RP at all?

I mean that was why the RP system was created! To weed those who care about the system from those greedy bastards only out to make a quick profit! The system is working perfectly and Ryan is whining about a penny! Greedy Bastard!


$1 = 10 kwh
10 ENC = $10.10
Efficiency Advantage = 0.5 kwh
Completive Advantage = 6x

Bill's Profit = $10.10 - $10.00 = $0.10
Charlie's  = $10.10 - $9.50 = $0.60

---

$1 = 10 kwh
10 ENC = $10.01
Efficiency Advantage = 0.5 kwh
Completive Advantage = 51x

Bill's Profit = $10.01 - $10.00 = $0.01
Charlie's  = $10.01 - $9.50 = $0.51

---

$1 = 10 kwh
10 ENC = $9.99
Efficiency Advantage = 0.5 kwh
Completive Advantage = INF

Bill's Profit = $9.99 - $10.00 = ($0.01)
Charlie's  = $9.99 - $9.50 = $0.49



-QED-
hero member
Activity: 798
Merit: 1000
October 03, 2011, 12:25:30 AM
#29
Truly, I'm baffled to the point of futility. This was your main thesis. 1 ENC = 10 kwh Difficulty had to be scaled to by changing algorithms to prevent people from being too efficient. That was what chased the last guy out of here. If that is no longer the thesis. Great. That's what I've been saying since the beginning.

But if some people can mint for 5 kwh and others have to mint for 10 kwh. It's not hard to see that the 5s will drive out the 10s. If one is minting at 10 kwh and selling for 11 kwh. And the other minting at 5 kwh and selling for 11 kwh. The second is making six times the revenue of the first. No amount of payout constraints is going to make that up.

Let me see if I've got this:
1) 51% agrees to mint at 5kwh using regular hardware - wait this doesn't work because people minting at 10kwh make double the coins - if they do it in an attempt to lower the difficulty, people minting at 10kwh make more than double the coins
2) 51% agrees to mint with super secret hardware that is doubly efficient that only 51% of the people know about - wait this is relying on something to exist that doesn't exist and that only select individuals will know about it - and the changing of the algorithms (not the difficulty) was proposed to help prevent this
3) what 51% has to do with either of these scenarios is beyond me, but it has something to do with consensus which doesn't affect coin generation or difficulty of coin generation so I dunno. apparently this group of secret individuals will get together to undermine the value of a coin to somehow make a profit while denying the 49% their mint blocks to achieve something, I'm not sure what that something is, but it's something - apparently getting the couple hundred coins they mined to market first so that the 1 or 2 microcents they might devalue a coin in this time isn't realized before they sell

Do you see why I'm the one who should be baffled?

Quote
Again, I'm baffled. You went on about FN needing to generate so many blocks per day to maintain their reputation points. The need of 51% confirmation on every transaction being the time lock for closing the PB. If minting transactions are not subject to the time lock or confirmation then great. Weird but great.

No, FNs need to generate one block per day to gain reputation. And the only time this "time lock" could legitimately come into play would be for anything that came within a few seconds of the consensus time. I don't know what waiting til the next consensus period will do to a block that awards 6 coins. It *might* just crash the economy.

Quote
Reputation Points seem to have very little effect on anything. They speed up a validation/reconciliation process you deliberately slowed down. They're of minor help during partitioning. The rest of the time the entire mechanism serves only as a way to "fairly" divide up minting spoils.

"fairly" in quotes because it means "spreading the wealth" which translates to "I don't understand the purpose of the reputation system and how it is critical to preventing attacks on the consensus even though you have repeatedly bashed me over the head with it -- I would rather have it as 1 IP 1 vote because that is fair and isn't exploitable at all. Or if it is, we'll just let 'people' worry about fixing it every time something goes wrong."
"If I can pretend that a FN with 180 RP wants to risk extra money given by virtue of that 180 RP by denying minting blocks that occur within seconds of the PB until the next day--I CAN MAKE AN EXTRA .02 CENTS PER COIN ON MY 12 COINS! HAHA! MAD GENIUS!"

Quote
Nobody generating at 5 kwh will vote to waste the extra kwh.

"if I pretend he never said that clients won't agree with anything that changes the structure of the monetary system [which most certainly includes difficulty] I can pretend 51% can vote for 5kwh in secret instead of 10kwh. HAHA! MAD GENIUS! NEXT--double the coins!!"

Quote
I acknowledged security/continuity/dependability are perfect. Nothing left to talk about. Just monetary policy.

You have failed time and time again to acknowledge that the two are interrelated. You fail to acknowledge that "charlie" in your scenario will become the only one who is profitable, which means everyone else dies out, which means he can set the difficulty wherever he wants which means he can continually put coins into the market for zero cost. But that's ok for you because it doesn't use electricity. Because for whatever reason, the whole basis of my proposal on using something concrete as a foundation for price stability can be counteracted by using "arbitragers." Perhaps they will be able to arbitrage credit swaps on subprime encoins before you know it.

I'm sorry, I just can't follow your completely "Up" dog random thought processes that don't have explanations or fully conceive of the outcomes anymore. I'm done.
Red
full member
Activity: 210
Merit: 115
October 02, 2011, 10:56:19 PM
#28
I'm not that worried about this. That is why the payout is structured so that this cannot be abused too badly. Plus like 3 other things in the proposal.

Truly, I'm baffled to the point of futility. This was your main thesis. 1 ENC = 10 kwh Difficulty had to be scaled to by changing algorithms to prevent people from being too efficient. That was what chased the last guy out of here. If that is no longer the thesis. Great. That's what I've been saying since the beginning.

But if some people can mint for 5 kwh and others have to mint for 10 kwh. It's not hard to see that the 5s will drive out the 10s. If one is minting at 10 kwh and selling for 11 kwh. And the other minting at 5 kwh and selling for 11 kwh. The second is making six times the revenue of the first. No amount of payout constraints is going to make that up.


:sigh: You aren't focusing on the right things. This won't realistically achieve anything. Coins do not or won't need to be added to any wallets until the PB block. If someone disagrees that your mint block is valid, that is a breach of consensus. Besides, we're talking about a few coins per day, not a lot of money to try and take advantage of.

Again, I'm baffled. You went on about FN needing to generate so many blocks per day to maintain their reputation points. The need of 51% confirmation on every transaction being the time lock for closing the PB. If minting transactions are not subject to the time lock or confirmation then great. Weird but great.

Reputation Points seem to have very little effect on anything. They speed up a validation/reconciliation process you deliberately slowed down. They're of minor help during partitioning. The rest of the time the entire mechanism serves only as a way to "fairly" divide up minting spoils.


The problem with trying to get 51% of the RP to agree to 5kwh is that it falls apart when someone gets greedy and wants double the coins for 10kwh. And eventually it starts lowering the value of all of their coins.
Yes, that is exactly the problem with your plan. The code that can generate at 5 kwh will replicate and the 10 kwh code will die. But it will happen undetected in secret. It's better for people to generate at 5 kwh, and pretend they are generating at 10 kwh. Then they take their extra profits and go drinking.

Nobody generating at 5 kwh will vote to waste the extra kwh. At worst they will pass their code around 51%. Then the 49% will drop out and everyone will be generating at 5 kwh. If they all keep pretending to generate at 10 kwh, the clients will not be any the wiser. Everyone's profit will go up because clients are still paying the bills thinking electricity is being consumed at 10 kwh/ENC.

If the 5 kwh minters attack each other in a battle over the pie, yes they will drive the price down to 1 ENC = 5 kwh and all the mint lose the majority of their profits.

This is called the "prisoner's dilemma" problem.

Your explanations of what you're thinking are frustrating. You keep going off on these tangents that care nothing for the security/continuity/dependability of the network and basically say "blah blah this will happen, I don't care if 4chan griefs the network, it works."

I tried to explain it once more above. If you still can't get it. I can't explain it any clearer. Maybe I can explain it louder?

I acknowledged security/continuity/dependability are perfect. Nothing left to talk about. Just monetary policy.

"Blah blah it works because I said it does."

I can't explain it any clearer. But the other guy didn't have a problem understanding.
Pages:
Jump to: