Bitcoin Forum
January 16, 2019, 05:06:35 AM *
News: The copper membership price will increase by about 300% around Friday.
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 [87] 88 89 90 91 92 93 »
1721  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANNOUNCE] The Proposal for EnCoin on: October 04, 2011, 11:56:24 AM
Probably has to do with 3 pages of runaround arguments that are already covered in the proposal.

And En, predictably, stands for energy.
1722  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANNOUNCE] The Proposal for EnCoin on: October 04, 2011, 02:26:23 AM
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
1723  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANNOUNCE] The Proposal for EnCoin on: October 04, 2011, 12:06:10 AM
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.
1724  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANNOUNCE] The Proposal for EnCoin on: October 03, 2011, 11:59:56 PM
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.
1725  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANNOUNCE] The Proposal for EnCoin on: October 03, 2011, 09:13:43 PM
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.
1726  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANNOUNCE] The Proposal for EnCoin on: October 03, 2011, 08:15:29 PM
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.
1727  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANNOUNCE] The Proposal for EnCoin on: October 03, 2011, 08:01:55 PM
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.

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.

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.

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.

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.
1728  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANNOUNCE] The Proposal for EnCoin on: October 03, 2011, 05:48:46 PM
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.
1729  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANNOUNCE] The Proposal for EnCoin on: October 03, 2011, 05:15:38 PM
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.

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

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.

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.

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.

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?

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.

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.
1730  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANNOUNCE] The Proposal for EnCoin on: October 03, 2011, 03:10:11 PM
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!

1731  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANNOUNCE] The Proposal for EnCoin on: October 03, 2011, 02:00:19 PM
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
1732  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANNOUNCE] The Proposal for EnCoin on: October 03, 2011, 05:25:30 AM
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?

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.

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!"

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!!"

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.
1733  Bitcoin / Bitcoin Discussion / Re: Are GPU's Satoshi's mistake? on: October 03, 2011, 02:47:27 AM
No. The causal chain is Market => Price => Total mining reward => Incentive to mine => Amount of miners => Difficulty => Cost to mine. The other direction, the direct influence of the specifics of mining on the coin price, is negligible. If cost per hash was lower, there would simply be more hashes and larger difficulty thus maintaining market equilibrium. (though there are indirect effects due to network security, popularity etc).
The causal chain is Amount Hoarded => Scarcity => Price => How much can I sell that will leave miners still profitable for the security of the network so I can sell more later => Cost to mine
1734  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANNOUNCE] The Proposal for EnCoin on: October 03, 2011, 02:15:50 AM
First off, I think you have two unsolvable problems in the "halting problem" sense. There simply are no algorithms that can solve the problem.

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

Sure if they behave badly, you might detect it. But if they simply want to reap an outsized share of the minting profits they can do so undetected. See Charlie and his tit-for-tat approach.

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.

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

Sure if they behave really badly, you might detect it.  But if they simply want to reap an outsized share of the minting profits they can do so undetected. Simply delaying an occasional competitor's minting transaction, while past posting your own would do it. Then you get sell on the exchange first at the higher price.

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

Resolving CPU efficiency or consensus monopoly issues, requires falling back on Human Consensus. You can't even count on plurality voting based on RP. If someone can generate at 5 kwh, they can sway enough collaborators to gain 51% RP.

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.

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

EnCoin's philosophy seems like burned wheat.

As I've said before, I see ways to keep the 1 ENC = current_value(10 kwh) while minimizing the amount of electricity that must be burnt. I agree with your goal. I disagree with your logic.

I also showed in the Charlie tit-for-tat example that someone burning 0.01 kwh can be indistinguishable from someone burning 10 kwh. In that case the first is better. In every case burning less electricity is better.

As I showed in the burn 10 kwh and sell it for 10 kwh using dollars. That burned value must come from clients. This represents overhead that cannot be used as Minting incentive. It doesn't matter what the fee is and how you justify it. If you give the resulting minting award to the electric company, that part represents zero incentive for minting.

So, to build consensus to cut Charlie out of the system. You must first convince everyone that burning 1,000 times the electricity to do Charlie's job is sensible. Then explain, this sensibility comes because the new system is fairer. Not fairer to the clients who are paying for the electricity. But fairer to those trying to get rewarded for leaving their computer running. This is going to be a hard sell.

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

The algorithm I proposed uses electrical value as a boundary condition to prevent generating coins. It gives minting zero profit when minting is inappropriate. It should not however be a requirement for generating coins. If new coins are necessary, the amount of overhead in generating them should be as small as possible. Just like Charlie, competing arbitragers get paid by lowering the total overhead of the system.

"Blah blah it works because I said it does." What gives zero profit when minting is inappropriate? A coin costing 10kwh to produce but being worth only 9kwh? Well that sure as hell isn't gonna stop charlie who is paying .01kwh. Or bob who is paying 5kwh. You make far too many assumptions about your perfect society without seeming to understand the ramifications. If there are not people always making coins, it is literally impossible to know who might be gaming the system or knowing how to adjust for it. You just assume the programmers can do it (FORK). Maybe Charlie just hates himself and wants to burn electricity at a loss. Since he's the only one making them, the difficulty adjusts to him and him alone, so who the hell knows?
1735  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANNOUNCE] The Proposal for EnCoin on: October 02, 2011, 09:05:20 PM
There is one other thing I wanted to mention about EnCoin minting in a down market. I'm pretty sure you haven't mentioned it.

If inflation is occuring in an ENC world, that means ENC coins are selling for less than the 10 kwh of electricity it would take to mint a new one. You see this as causing a lack of incentive to "minters". As such, they would shutdown nodes and stop wanting to monitor/support the network. Perhaps that's the reason for your aversion to a non-minting peer use-case.

I'm not averse to non-minting peers, I just don't know how they can be given reputation in the consensus. I am averse to non-peering minters.

I realized it is not as bad as you think.

If someone was minting, then they believe in the concept of stabilizing 1 ENC = 10 kwh.
When they can mint at the cost of 10 kwh, and sell the coins at 11 kwh, then they MINT and SELL.
Conversely, when they can mint at the cost of 10 kwh, but only sell for 9 kwh, then they BUY and HOLD.
That is the most profitable move if you really believe that things will stabilize at 1 ENC = 10 kwh. It is also exactly what you want them to do to stabilize monetary policy.

And that's why I conceded that maybe I was wrong about the transaction fees, they could be much lower. But there is no incentive for the people who did earn their RP to stick around--besides the continuing prosperity of the network. That might be good enough, but it's not enough to rely on.

In order to buy and hold in a down market, they are going to need a functioning network. If the EnCoin network fails as a whole, they won't have a future to sell in. Hence my most, compelling case for a non-minting peer.

But HOW do you avoid these non-minting peers from attacking the consensus!? There is no real cost involved, just time as I said. If these non-minting peers can easily overtake the consensus, they can disrupt the network easily time and time again. Am I overthinking this? I don't believe so.
1736  Bitcoin / Bitcoin Discussion / Re: Are GPU's Satoshi's mistake? on: October 02, 2011, 01:59:10 PM
First of all, FPGAs are more power efficient than GPUs. GPUs get about 2 Mhash/J, but good FPGAs get about 20. Getting the same work done with less wasted energy (and environment) should be the goal of any sane person. Of course, the initial cost of FPGAs is a problem, and GPUs are better in the short run.

You say this but don't understand the real-world relevance. Bitcoins have most certainly gone up in price due to GPU mining and lack of energy efficiency. The more energy put into the system, the more coins cost to make, the higher the bitcoin price is. If less energy is wasted, more people mine because it is profitable. For now, of course. But the more demand that is created, the more tempted coin hoarders are to sell and waste your effort. Such a self-sustaining system.
1737  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANNOUNCE] The Proposal for EnCoin on: October 02, 2011, 12:50:18 PM
OK, I understand what you are saying here. But the question I have is: Suppose Amazon doesn't want to mine, and just wants to monitor the network and assure that the common history never changes. They don't even want an automated vote in any decisions.

This is something that can be worried about later I suppose. Some FNPeers may be willing to send all data, but I would think it has to be optional to avoid overloading their connection. Or there could be "clouds" that have many members where each member has its FN that it requests data from, so they could all pass around all the data.

Why do they care what others think their reputation is? Is it just because FreeNet peers only discuss these topics with other FreeNet peers?

It's not a matter of reputation, just avoiding wasted bandwidth. But like I said, it could be handled, I just haven't accounted for it yet.

But you seem to be agreeing with me in the sense of redundant I intended. Every FNPeer receives interFN transaction block broadcasts and rebroadcasts them intraFN. Every FNPeer then consolidates all of the received transactions, removes duplicates and validates them all. You seemed to confirm that was required behavior for every FNPeer. Understood.

Not exactly. 1 peer is randomly selected to make the transaction block so that they can all agree--in the odd case of someone quitting or being disconnected or whatever. It's still relatively the same though, I guess every peer needs to make sure each transaction is valid anyway before they sign it themselves. However, if the 3-4 peers the selected member is connected to don't agree that all the transactions are valid, they bring up a "Something Is Not Right" issue before passing stuff on.

OK, so I'm understand now that a "human client" CAN choose which FN they trust to download the current PB from.
The PB gives them a nested list of FreeNets and FNPeers belonging to each. The "human client" CAN choose which FNPeer, of which FN, they trust to handle their transactions. Got it!

To some degree. I mean if Amazon has a trusted peer they want to connect to without using the regular procedure, that could easily be set up. However, clients won't know who they're connecting to until they see the wallet ID. I suppose if they think the individual's rep isn't high enough they could add more or whatever.

Unsure to which antecedent you are referring.

Needing transaction fees to ensure a decent number of people have a high reputation so that the consensus cannot be easily attacked.

But yes - my system is demanding to be too efficient. Too few peers are required for consensus, it means DoS'ing is too easy. That's why I wanted such a high transaction fee so that more peers are required to be part of the consensus to keep the price stable. More peers, less chance of DoS attack. Otherwise how can we be sure they're trusted? How can we penalize them?

To require the same 50k miners that bitcoin has, we would need 5 million people using the network (edit: with a low transaction fee like 5 encents). So as the network becomes more popular, it would be less vulnerable. But that would be a long ways away, and DoS'ing in the mean time could keep its popularity down.
1738  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANNOUNCE] The Proposal for EnCoin on: October 02, 2011, 12:37:13 PM
In encoin, theft through forgery, is prevented by cryptography. Nobody can create a transaction drafting money out of an account without the private key.

In encoin, there doesn't seem to be anything equivalent to bitcoin's double spending of out-points. Instead, encoin has "over drafts", meaning transactions that would cause a negative balance.

In encoin, fraud via over draft, is prevented by transaction validation rules that say, current PB account balance (minus) draft transaction can't be negative. In situations where two simultaneous (intra-PB) transactions combined to cause an overdraft, which transaction is rejected, and which is accepted is non-deterministic. (As is a bitcoin double spend)
yes, whichever transaction gets >50% of the rep first wins

In encoin, PB account reconciliation follows rules which say, previous PB account balance (minus) draft transactions (plus) receipt transactions = subsequent PB account balance. AND subsequent PB account balance can't be negative. (It is not clear to me if you order account transactions as must be done in bitcoin's DAG.)
the FN transaction blocks do not need to be ordered, but the whole transaction log needs to be ordered so that all FNs can agree on the same hash during the PB - FNs won't add a transaction to the overall log until it has >50% rep confirmation

It is not clear to me how things are ordered if multiple receipts and a drafts show up in a single transaction block. Or if both show up in multiple transaction blocks affecting the same primary block.
would be another deterministic function, alphanumeric sort based on from acct/to acct/amount/etc.

Unlike bitcoin double spends, encoin overdrafts are not necessarily malicious. It is possible for overdrafts to be caused by network lag in receipt transactions. Differing network propagation of receipts seem extremely likely, due to their differing origins. If a strict "order received" queue is followed (rejecting all transactions that would cause a negative balance) then inter-peer balances will become inconsistent.

Without buffering and re-ordering of transactions during a PB building period, individual peer acceptance and rejection will be non-deterministic. This will complicate "confirming" transactions.

In encoin, there is one, and only one, ordered transaction log. Only valid transactions are listed in the transaction log. If a transaction isn't in the log, it didn't happen. There is also one, and only one, ordered Primary Block (balance sheet) log. The two logs are encapsulated in separate parallel block chains. The two chains are staggered so that each primary block summarizes all transactions that happened prior to any given primary block.

In encoin, theft via history modification, is prevented by protecting the block chain using a "hash chain". This protection does not require a proof-of-work.
not directly, no.

In encoin, there must be 100% consensus *in order to* finalize a primary block. Once a PB is finalized it, and its preceding transaction block, become part of our absolutely immutable shared history.
yes, anyone that disagrees is booted


That just leaves me three things I'm absolutely sure I don't understand.
Perhaps I just need pointers to the correct sections in the proposal.

1) In the process of finalizing a Primary Block, How is consensus reached?

a) I know the decision to finalize is partially time based. How is consensus reached that time has elapsed? (meaning which transactions should be in and which held for the next period.)
mentioned in rev3, any transaction with >50% rep before the set time (87,300 seconds since the last PB) will go in the current block, anything after has to wait a day
b) If some transactions haven't propagated to every FN, how are the discrepancies reconciled? I'm assuming it is the union of all valid transactions. But what is the process for forming that union? Who broadcasts what to who?
this would be covered by who is connected to whom as I stated before. if FN A's transaction log hash value differs from FN B's, then they can compare byte sizes to see who has more as a starting point. I'm sure hash trees could be used to narrow down the window of what specific transactions are missing so that needless data doesn't get transferred
c) If the above mentioned non-determinism causes conflicts, how are they resolved?
once the missing transactions are discovered, whoever has the missing ones can send missing FN confirmation blocks. FN A could say "hey I've only got 30% rep confirmation on transaction Q, here are the hash values for the confirmation blocks I have." FN B says "oh ok you are missing these confirmation blocks [sends data]" - doing this one at a time would actually probably confirm other transactions if they are missing a lot
d) Which peers are responsible for the process?
each peer is responsible for making sure the peers that they are connected to all agree. So for Peer X in FN A who is connected to FN's B, C, and D, once Peer X has settled everything up he sends the "all clear" signal to his FN that B, C, D are in agreement. Since 1-2 other peers in the same FN would also be connected to other members of B, C, and D, this can be double/triple checked

Except for (d), I don't see any need for reputation to weigh in on any of these decisions. I can think of deterministic ways to complete all of them. (Except guaranteeing that a peer doesn't backdate the transaction time of a personal transaction.)
backdating a personal transaction won't work as there is no proof of confirmation. I'm not sure what it would achieve either, exactly.

2) history substitution: How is network partitioning handled and reconciled?

If some sub-set of EnCoin claims to have been completely cut off from the rest, can they go on processing transactions and/or minting? What about the main body of encoin, can they go on? How is either to decide who is main and who is cut off? If both continue, how is the fork reconciled?  Do some minters lose their minting transactions in reconciliation? How long can a fork go on and still be reconciled, can it cross PB boundaries? If so how are the history PBs reconciled.
they can process transactions, but the smaller subset would never get confirmations because they don't have >50% of the reputation (based on the freenets that signed the previous PB).
I had thought minters would lose their minting blocks, but now I don't know if it's necessary. I had thought they would work by using the PB hash as a starting point, but that could very well be the network time instead. However, if this netsplit affects intra-FN communication, the winning FN block would be missing the effort from the members who were cut off.
What happens when there is a communication disconnect during a PB is something I haven't covered. I mentioned that I wasn't sure what to do if a FN is missing from the PB consensus in rev2. I suppose the smaller half can build its own PB from previously confirmed >50% rep transactions for the day, and then accept a new PB when the networks reconnect. How long they would wait before assuming everybody else is gone is hard to say. In the mean time, transactions can't be confirmed. (I did mention that FNs that did not show up for the consensus in rev3 that they would lose 20 RPs, so it would take awhile but eventually the split would be able to start confirming transactions again.) Clients could be notified of this split though, so at least they know something's up.

Unfortunately, in general, this form of consensus is definitely more open to DoS. I actually mentioned this in a PM to someone who asked me a few questions
Performing consensus more often than every 24 hours might help things a little bit. I don't know, it's another big question I suppose.

I'm absolutely sure this is a place where inter-FN reputation plurality comes in. I'm just not sure how it works.

3) Are there any other inter-FN plurality decisions where reputation is involved?

I know minting rewards figure in. But that just seems like a mathematical formula. If peers award themselves minting rewards that don't match the formula, they are wrong. That is more like a transaction validation/rejection rule. There doesn't seem to be room for weighted influence.

Well, the weighted influence always comes in on depending what gets into a PB. If >50% rep has it before the consensus time, then it's in. Transactions, mint blocks, anything that matters.
1739  Alternate cryptocurrencies / Altcoin Discussion / Re: Coming Soon - Fairbrix on: October 02, 2011, 04:58:33 AM
At Fairbrix, the blocks seem to be empty.
Found 12 blocks now, 0 coins...

lol confirmed failbrix
1740  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANNOUNCE] The Proposal for EnCoin on: October 02, 2011, 12:26:03 AM
I see four roles. Tell me if you see the same ones.

FN Peeryesyes
FN Minernoyes

I'm not arguing how much reputation nodes in these roles should have. Just whether they will exist in the EnCoin universe.

I have an issue with the FN miner.
This system needs to be un-attackable. If you read the wiki quote on the sybil attack, giving away cheap identities is what makes this attack easier.

The reputation system, as I had originally envisioned it, would require both minting and networking to prove your reputation. This means you can't put in a bunch of computers together in a pool and use them as one node, or you get only the rep for 1 node. This means you can't use a botnet (or use a lot of IPs if you have access) to make lots of cheap identities, because you can't get the computing power.

Not either or, but BOTH to help make sure that these identities are actually going to trustworthy individuals.
By giving consensus power to identities that are not using BOTH, you are opening the system to easier attacks.

Another undetailed idea I have (sorry there are so many, but the system is pretty complex) is that FN peers, as you describe, would be checking for hashes periodically from other FN peers. This means that a Peer/FN peer could not pay out a FN miner for doing work they didn't do, just to increase the identity's RP. (each peer would be working on a hash with their public key involved, so it's easy to prove that that individual is actually working on a hash)

By allowing FN miners, one pool could create 100 "trusted identities" and make it much easier to attack the consensus.

The reputation system is of paramount importance, unless you want constant interruptions and confused clients.

That is why I devised the transaction fee, so that there would always be demand for new coins and it would require a relatively constant, small fraction of the total userbase to replace it. So if there's 50k clients, there need to be 500 peers. If there are 500k clients, there need to be 5k peers. How else can I keep people from making cheap identities from attacking the consensus? If it's just the network stuff, the only factor I can see is time. Give them some RP for their time, slower than minting obviously. But time is relatively cheap, especially when you could use 1 computer to generate a thousand nodes on a computer with a big connection and plenty of IPs.

Don't think I'm thinking small scale! And if a merchant like Apple or Amazon wanted to take ENC, I'm sure they would want to monitor the network, but not necessarily mine. They would certainly be willing to throw whatever network connectivity and hardware at the problem that it took. They probably wouldn't want to run 100 small peers, when 3 high end servers would do.

Well then amazon can make an FN peer and run it at 1/20th and get all the info they need already. They're not worried about rep or coins. I'm assuming during stable economies most FNs will be running 1/10 or 1/20.

And if there are minting profits to be had, people are going to optimize their implementations. I doubt every node of those bitcoin GPU and ASIC mining pools is handling network traffic.

Right, and I believe this is a serious security flaw. Pools have WAY too much power in bitcoin. They discourage being a node, and they control too much of the hashing resources.

Now that's not to say you can't minimize network messaging like you suggest. But you seem to be suggesting that each of your 100 FN members does the same redundant tasks as the others. I'm not saying you are wrong. I just don't know if you are saying that is mandatory for some reason.

Absolutely not. Each FN peer would be connected to a different set of other FNs. If there are 100 total FNs, each peer would be connected to 2-3 peers from other FNs so that there is the capability to double and triple check that everything coming out of 1 FN agrees. This means for 100 networks, there are a total of 6-8 connections per FN peer (4-5 for their own fn, 2-3 for others). That leaves many connections open for incoming and outgoing data to the clients. It also means that transaction confirmations can happen very, very quickly.

BTW - who connects to whom would be chosen randomly! And it would change relatively often! That way malicious entities cannot collude between networks or even within networks.

As a side note: I still don't understand which FNPeers will provide a client interface. Or if clients view the FN as a whole as one entity? Or do they see each Peer separately? If they see each Peer separately, do they know which FN a peer belongs to?

Any of them. The FN blocks contain a random selection of IP addresses of peers within the FN. So when a client gets a new PB, they have a list of all kinds of IP addresses to connect to. And yes, the FN peer will communicate what their wallet ID is and so on. In the actual client software, lots of info would be available on the FNs that are out there and so on.

I hate to say it, but I'm starting to re-convince myself I had it mostly right. Wink

I met the Jason Scott recently. He runs Archive Team for the internet archive. It changed my sense of scale. I no longer worry about storing bits. I barely worry about transmitting bits now. Still, I'm old school. Don't waste thing you don't have too!

It makes quite a big difference between storing and transmitting between a few hundred transactions per day and a few thousand per second. I want this to be available to a regular computer in the future. Not some corporate supernode. Some people have bandwidth caps too. I realize in the future this stuff will be more accessible, but still, it needs to be accessible to almost everyone, imo.

As Encoin matures, there would be very few miners required. They would get replaced only as some quit or whatever and others can step in. I know a lot of bitcoiners will find this to be a shitty deal, but they aren't going to make much anyway. The objective is to have a STABLE ECONOMY. What bitcoiners don't realize is the $4.30 they're paying in costs to make 1 BTC and sell for $5, $2 of those costs are going to the early-early adopters, $2 is going to the mid-early adopters, $0.30 is going to the real cost to produce. It's a pyramid, and the more people that mine, the more profit it makes the people before. Why does everyone have to be so set on making a profit? I realize it's motivation, but why not use a real system that isn't some bullshit scam.
Pages: « 1 ... 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 [87] 88 89 90 91 92 93 » is not available or authorized for sale. Do not believe any fake listings.
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!