Difficulty could be a sliding window based on the average time of the last 1000 blocks, so it doesn't jump in big leaps or 'get stuck' at a high difficulty, like namecoin, where it can take two hours for the next block and two months for a difficulty reset. Bitcoin could also have 1 minute 5BTC reward blocks - transactions would be confirmed fast even if you triple the required confirmations and increased orphan blockchain lengths, and mining wouldn't be as much a lottery. Devs would just have to make a client that decides a point far in the future (like block 300,000) is where the new calculations kick in, so that it can be widely distributed before the change. |
|
|
|
|
Just so you know, this latest version has a bug where it doesn't remember fan speed settings between starts. If you rely on your cards running at 100%, or have a custom profile, this is no good.
Does anybody have a link to the 4.0.1 installer, since the Sapphire website only lets you download the latest version regardless of the link you click on? I had to copy binaries between machines because I was foolish enough to delete the old download.
|
|
|
|
|
I get lots of 'unusual opencl behavior. hardware problem?' on the latest version, using a fresh Catalyst 11.6 driver (not CPU buggy hotfix) on WinXP on two different miners, going back to stock phoenix and 07-11 kernel is fine.
|
|
|
|
34,560,000,000,000,000 hashes
p.s. This round did not actually happen, the administrators corrected the error. Nor has a 9+ million share round ever occurred on any pool as of today. Deepbit has had 5-6 million share rounds, bitcoins.lc and slush have had similar, but that's about it. Well here is one : block 136589 9089199 round on BTCGuild.... so it is possible... Well that round didn't happen (as I said "imaginary round" in the post that was quoted), but this one did, setting a record that btcguild didn't match yet - bitcoins.lc round 266, solving block 135944 only after 10,048,350 shares! |
|
|
|
You never know if the workers are even working on a block. Stales go through the roof. Multiple rounds become stacked as a huge round & you never know if an ultra-long round is even genuine or if it's just variance. Maybe 3 rounds disappeared for all eternity as unclaimed blocks, untracked by the software. Maybe they didn't. I check up on workers, just to see they had 'connection problems' for the last 5 hours even after patches, and the pool is not even under DDoS. It gets solved for a day or two & begins again. The pool has degenerated into solving less blocks than pools 5-10x smaller. http://pident.artefact2.com/pool/Bitcoins.lcFact is, I don't want to quit. Seems many other people are not quitting either. But this stuff adds up to huge losses over mining at other pools & is soon not worth the 0% fee perk. Not everyone is casually mining with a CPU, this is starting to cost hundreds of dollars in the short term unrecoverable even by a few lucky rounds. Can you please be quiet with these rants? "Stales" are not going through the roof, efficiency is the same as it always has been, about 2% and markedly decreasing with a new patch that was put in. The pool is having some difficulty right now, it is probably is similar to what was basically a DDOS earlier today when someone pointed a botnet or a pool-hopper proxy at the pool and made thousands of connections for little work, which only points out that the pool should be aggressively blocking low efficiency workers and delaying stats way beyond where it gives any information about the current round. All pools have had downtime from DDOSs, fake share floods, etc, so you should have a backup miner ready to go, or run two miners per GPU so one pool's outages don't affect your earnings. The pool is is as lucky as it should be, in fact luck since this difficulty started is +1.7%. How do I know? Because I did the actual stats using real math:  Thread-crappers are seeing patterns in random data where there is none and clinging onto it like religion even when presented with outstanding reason. Your perception of rounds being too long is skewed, as the delayed stats don't even show you short rounds. Variance is like a bicycle in the hills: You go uphill at 5mph and downhill at 25mph, so you spend 83% of your time going uphill. And then you bitch about how the roads are unfair when you get to your destination, and piss everybody off. |
|
|
|
How to connect: https://www.btcguild.com/how_to_connect.phpYou also need to create a worker, which is another username/password just for your miner. Go here after you log in (btcguild really shouldn't let you see this page unless you've authenticated): https://www.btcguild.com/my_workers.phpThey tell technical writers to break things into steps, less steps for less technical people: Windows computer setup: 1. Install video card 2. Install lastest ATI Catalyst driver v11.6 3. Install latest GUIMiner Pool setup: 1. Go to pool website 2. Create a user account 3. Create a new worker username and password for your miner Mining configuration: 1. Start guiminer 2. On OpenCL tab, pick server: BTC Guild, put in worker username, worker password 3. Verify Device is set to Cypress 4. Press Start Mining! Get paid: 1. Install Bitcoin, leave it running for many hours to update (8 connections, or more if port-forwarding 8333 to Bitcoin computer) 2. Put your Bitcoin address into the pool website (the incorrectly named 'wallet' link on BTC guild) 3. Watch your pool account balance go up from mining 4. Press withdraw button to have money sent from pool to you |
|
|
|
https://en.bitcoin.it/wiki/Base_58_Encodingit is a character coding that reduces the chance of mistaking 1 for l or 0 for O if you re-type addresses, passwords or other information. The same format is used for other things, like product keys etc. Google comes up with flickr URLs. There's enough reason for it to stay in wikipedia.
|
|
|
|
What's invalid? The fact that the timestamp is the same doesn't mean that the blocks happened at the exact same time. The time stamp of the later block can actually be earlier than the earlier one. Why? Because the timestamp is taken from the system clock of the computer doing the mining, which is likely not synchronized with atomic time.
Bitcoin doesn't validate the timestamps to precision - it only validates them to be within a reasonable window, like two hours.
I see: A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you. So there is no joy in this statistic... either miner's time could have been off - and a clock time could be up to ~1 hour negative and still be valid depending on the previous blocks. |
|
|
|
Block 136583:
{
"hash":"00000000000001d7635c5037bd97519b583cd995a56edc0018dfb9a39106f758",
"ver":1,
"prev_block":"000000000000003f767918da359ac0dd5728edc90552b0e4f4af59419d1b70f5",
"mrkl_root":"2d9712cefa0f81ac0fb6cb0812567c5f572ab9f0309e803fb01b039e1938fdf6",
"time":1310829862,Block 136584:{
"hash":"000000000000035ac219a1a52dde48ccd7348deed858b1da47b0f16b7ac70ea2",
"ver":1,
"prev_block":"00000000000001d7635c5037bd97519b583cd995a56edc0018dfb9a39106f758",
"mrkl_root":"61e5c0c6a611568131217f21b69a4ac96c5bb5598a704627a3aecf8584d1ff9c",
"time":1310829862,Is this a first? Did deepbit just figure out the ultimate hack to avoid invalid blocks? 
|
|
|
|
Just because the coin landed on tails four times in a row doesn't mean that going to someone else's coin-flip game is going to get you any more wins in the future. You could make the argument that maybe my coin or dice aren't perfect and favor one side, but bitcoin has perfect dice.
I don't think you understand why pool hopping really is profitable over the long term as compared to switching roulette tables or slot machines and why gamblers fallacy doesn't apply to block finding probability. Proportional pool luck is determined by current difficulty factor and hash rate. There is a certain statistical point at which blocks will be *usually* found given a large enough statistical sample (100, 1000 or more blocks) A gambler can't *expect* to get a certain amount of heads or tails in a coin flip because the statistical probability of either one is always 50% (assuming it can't fall on it's side) over the long term. A miner can expect 95% of blocks to be solved in the long term at 1.56m difficulty and roughly 9½ hours spent at 600ghash/s. If the occurrence of rounds surpassing 9½ hours becomes significantly more than 5% in the long term (let's say 20%), the miner can expect foul play. Just as if a coin would consistently fall on the tails side over 1 million throws (let's say to a 70:30 ratio), you could suspect the casino has a weighted/rigged coin. 3-8% would probably pass as variance I certainly understand the maths behind pool hopping; if you had five identical proportional pools and just hopped to the next at the start of its new round, hoping to sip the cream from short rounds, you could hope for a significant return above the baseline (at the expense of full-time miners). I do not address the quantum valuation of individual shares; quote: "The past luckiness of a pool, or even how long the current round is, has nothing to do with how much you will make in future rounds". Actually that should be clarified to "how much you make over a period of time in future rounds", for in rounds you simply get your share of 50BTC. You are saying if some rounds go three times as long as the average (ignoring the ones that are one third length), I should expect foul play?? As my example above, that is like saying if I flip heads three times in a row (87.5% chance of that not happening in three coin flips), then the coin is probably fixed. Your previous posts with some graphs and the statement that a round "already passed 100% probability of hitting block" shows that you are not estimating probability correctly when making your assessments; a statistician can expect an average of 89.753% of rounds to be solved by 9.5 hours at 600Gh/s. Feel free to change to a different proportional pool if you desire, for their past luck does not predict or affect future winnings either (but their fees will..) I would recommend a high hashrate pool, because their 80th percentile variance will be 5 minutes to 2 hours instead of 26 minutes to 9.6 hours, and you might get less bent out of shape. Their pool threads will probably get an earful of "why are my round payments 1/5 as much" though... |
|
|
|
I just don't see the need to roll bitcoin into an obfuscated exe to run a command line option, there aren't too many people using bitcoin that can't do that, and I am apprehensive that you think this is novel. If you are going to be copying wallets around for people (which might actually be of utility if done right, but again, you haven't spelled out that you understand why you are doing it), it is very important you understand the 100 key problem. I'll just cut and paste here for reference: The wallet contains a pool of queued keys. By default there are 100 keys in the key pool. The size of the pool is configurable using the "-keypool" command line argument. When you need an address for whatever reason (send, “new address”, generation, etc.), the key is not actually generated freshly, but taken from this pool. A brand new address is generated to fill the pool back to 100. So when a backup is first created, it has all of your old keys plus 100 unused keys. After sending a transaction, it has 99 unused keys. After a total of 100 new-key actions, you will start using keys that are not in your backup. Since the backup does not have the private keys necessary for authorizing spends of these coins, restoring from the old backup will cause you to lose Bitcoins. To summarize, as long as less than 100 addresses are ever used per wallet (and you know this wasn't overridden at the command line because your program can actually understand the berkley db format used in wallet.dat), you can have multiple copies of the wallet on several client instances, and all of them can send and receive bitcoins. However you are opening a pandora's box, because even with deep inspection of wallet contents, you can not avoid the potential for monetary loss by users when arbitrarily copying around wallets. I will spell out the chronology of how you directly can cause and enable losses (by the way, this somewhat applies to wallet backups too): 1: I have a wallet with 200 unique addresses and corresponding private keys for re-sending those addresses' funds, 2: I let your utility copy my wallet to a USB stick, 3: I run the local computer version of bitcoin, press "generate new address", and receive bitcoins at it, 4: I run the portable usb version of bitcoin, press "generate new address", and receive bitcoins at it, 5: Now the seperate wallets are the only ones that can send their respective bitcoins, 6: Your program copies one of these wallets over the other one, and I lose the ability to send all the bitcoins that were at that address. I hope your idea for a "wallet manager" isn't a copy command in a batch file that you ran through your BAT2EXE... I doubt it can understand the -datadir option I'm already using to frustrate trojans that are just as naïve. |
|
|
|
No, its been at least two weeks. I switched my main pool two weeks ago and switched again a few days ago, and have been monitoring them all to see if I made the right decision. MtRed has consistently made more than bitcoins.lc would have for me up from the time i switched until a few days ago, and now deepbit is doing the same. Bitcoins.lc before that point was making me a LOT more than I would have made at other pools. I would be right back to bitcoins.lc as I really liked the pool except for the no full payout thing if it was earning me the most for my mining. The best day bitcoins.lc had in the last 2 weeks was the 13th, and I would have made ~.45btc. Instead I was mining at deepbit and mined .47BTC. Every other day pretty much I would have been off by at LEAST .1 BTC mining at bitcoins.lc, which is 20%, save for the 5th of july. On the fifth of july I was able to mine half at MtRed and half at bitcoins.lc and really made a fairly good gain, even though I would have been better off probably just staying at bitcoins.lc for that one day.
This post documents a basic misunderstanding of the variance of Bitcoin. The past luckiness of a pool, or even how long the current round is, has nothing to do with how much you will make in future rounds. Every single time your computer trys a block hash, it has a very small chance of solving it that is always the same, a chance that is only based on the difficulty setting of Bitcoin. Your average earnings are completely based on how many shares you submit in a round, which is completely based on your hashrate. Whether you solo mine, or join the biggest pool, your expected earnings from your personal hash rate against this 'difficulty' problem will always average out to be the same. Only pool fees (and rejected shares or downtimes) can affect your expected earnings; and you can buffer against possible pool downtimes by running a second miner per GPU pointed at a different pool. The same fallacies persist in other games of chance, like how some people think a slot machine (fruit machine) in a casino might be "hot", or "due for a win", when the chance of you winning is purely random, just like every hash the pool trys, and has nothing to do with the past (this inability to recognize bad human intuition and apply logic is a driving factor in gambling addiction, since to even play a game once with losing odds is illogical, and to play more than once only reduces the variance and further guarantees your loss). It would be like if I had a coin flip game where I flip the coin and heads wins. Just because the coin landed on tails four times in a row doesn't mean that going to someone else's coin-flip game is going to get you any more wins in the future. You could make the argument that maybe my coin or dice aren't perfect and favor one side, but bitcoin has perfect dice. |
|
|
|
Probability is not defined for negative values. Probability is defined for all x, where 0 < x < 1.
I'm going to assume you're being sarcastic in that comment though.
I think he meant to convey less than one percent, but accidentally typed less than zero percent. Such as 0.5% or similar. I was speaking as a counterpoint to the naysayers, but in their original tone and knowledge of statistics. Please see my earlier posts here and here in this thread to understand that although my humorous comments may have a subtle "whoosh" sound for some, at least on statistics I can make up some pretty believable stuff. plz anyone can told me how to take my ALL BTC with 8 decimal?
Another pool operator describes why their pool is only set up to transfer accuracy down to bitcents here [forum.bitcoin.org] - it is to prevent you from losing the money through digit truncation in the client [BitCoin Git Repositories]. The code to zero out the first six digits of satoshis in each transfer was finally removed in the mainline client code only this year, and there may be several forks or mods circulating and in use based on this older code that would still outright discard this penny's worth of bit dust. |
|
|
|
Jine: Isn't it funny how everybody starts questioning the functionality of the pool during bad luck, but never bother to ask if the pool is "really solving all these blocks" when having great luck?  Hey, I just looked at the stats for yesterday, and although it should be about three hours per block at the pool's hash rate, there were six rounds in a row that were all under 1 hour 25 minutes! There were even three in a row that were 21 minutes, 41 minutes, and 55 minutes. The chance of this happening is less than 0%, so clearly you should investigate if there is something wrong with the pool. Since this looks strange to me, I'm going to tell all my friends to come here and get the easy bitcoins until you fix it! |
|
|
|
"You have to start somewhere", but maybe get rid of the teams, the rankings, the banner signatures with referral links, the gambling name, and the 2% fee for withdraws when there is something to withdraw. Then you still have to entice people to join, when their contribution in solving the first block will be diluted by the 700,000 shares in the first round already added by miners who have come and gone. Another recently started pool was knocking out four blocks a day at ten days in, by not looking shady.
Why remove the teams, rankings, and banner sigs ? if people dont want to use them then dont. re the fee, this is only for manual withdrawal, you can always use automatic for free and thats processed twice per day. you could even use it as manual if you wanted ie. set auto payout to 100000BTC then when u want to withdraw set it to 1btc the manual fee is a rushed version where i have to wakeup/come to the computer and manually process it, hence the fee. Teams: gives the impression some teams win and other teams lose, with the new member on the losing side Rankings: Having it there shows that one should value it. It can only discourage membership of those who would expect not to place on the list, or those that expected to but don't. Banners: Are referral links, encouraging more forum spam I get to ad block. When referrals are rewarded, they are rewarded out of the profitability of others, so if I see the obvious referral link, I'm not clicking. Betcoin: What am I betting on? Does the house always win? Another pyramid scheme? All of these make me want to join the pool as much as a slick talker in a plaid suit makes me want to buy a used car. |
|
|
|
My only issue so far has been adding voltage - when I move the slider in TRIXX then hit APPLY, all it does is go back to 1163. Are these particular cards locked?
I had the same experience and the impression that they didn't have voltage controller hardware on them. However, after several incidental driver removals and reinstallations, it magically started working! I know it is actually working because a card overvolted and overclocked to new levels will crash pretty quick if you remove its volts. I am using the full Catalyst driver package 11.6 with the included SDK 2.4, and the latest version of Trixx for Sapphire (a new version of Trixx just came out that supports independent overclocking of multiple GPUs too). I would try a complete ATI driver removal and reinstallation - just run the original installation package and pick "remove all ATI drivers". |
|
|
|
Therefore, it shows up as block 136,133 on my site, because we only check for new blocks every 5 minutes or so.
Doesn't do wonders for transparency IMO :| People are right to do due diligence and be paranoid because blocks really have been missing on some pools like bitcoins.lc (admins have so far decided to pay them out promptly though after being notified of the fact) I don't think that's a fair statement to make lest anyone get the wrong idea about the integrity of bitcoins.lc; a database problem at the pool made a block solve not pay out automatically, requiring manual correction - it was still instantly posted to the round history on the site. In fact, at least one pool block solve at bitcoins.lc was invalid (another miner or pool had also solved the block but with an earlier timestamp) but Jine still paid the block out-of-pocket, without making a big deal out of it except for a casual mention in the IRC channel. I donated my share of that block back. If a pool owner decided to steal a block's worth of BTC, you would never know about it or even have a clue, and that seems to be the issue up for discussion. If pool miner software doesn't have enough information to determine independently and report to the user that it submitted a block solve, it seems that you must trust your pool admin. |
|
|
|
Now you're trying to do this 136,000 times. That's 18 hours at 2 blocks per second.
You could just trust any block that is more than 1000 blocks behind the head of the chain. That creates a chicken and egg problem. You can't know the correct block X until you know the correct block X-1. So saying "if it's 1,000 blocks behind a valid block, it's valid" won't help. Suppose there are 136,000 blocks in the chain. You receive, from an untrusted peer, a block that purports to be block 53,000. How can you tell it's more than 1,000 blocks behind the block 136,000 that you don't even know exists yet because you have no way to verify it? If security is really required, then you could do the verification slowly once the entire chain has been downloaded.
So then why bother to download the blocks really quickly? There's nothing you can do with an unverified block -- you don't know it's valid. I'm suggesting having a deep queue of the next blocks ready for verification so the only bottleneck is processing them. If after verifying block #100 I have to hit the p2p network again, request block #101, and wait for the client I request a block from to respond (or not) and send it to me, that's adding that much more latency per block. Block #101 from the network is as likely to be valid if I get it on-demand, or if I've already downloaded blocks 102-500 too. If I've filled my queue and still have network speed to burn, I could have even requested block #101 three times and MD5'd them or have a pool of potential blocks in case I need to sort out which is the longest block chain (although this is silly, the chance of picking up in-the-wild invalid early blocks seems so low that we can almost assume everything we get is good and ignore optimizing the queue around this possibility). A basic proof to see if there is utility would be to bootstrap a fresh client on a local-only network with several nodes and see how close you can peg CPU to 100% (this still has the client idle requesting the next block). How long does it take to get all the blocks? Then do the same on the P2P network. If it takes longer, there is room for improvement. |
|
|
|
How about a mining for music service - as long as I keep sending 100Mhash/s of shares, the music stream with the songs I pick keeps playing. That's the only thing you aren't allowed to do in most countries with absolutely free Internet radio: narrowcast one stream to one user with just the songs they pick. |
|
|
|
|
This post does demonstrate a good point: someone that creates a turnkey shopping cart service for third-party sellers, calculates the current bitcoin price for the store item, takes the bitcoins, and sends the shop owner the fiat currency they are used to would further the Bitcoin currency movement much.
|
|
|
|
|
Show Posts
