Sometimes I click away and then only notice the ad "wait! what was that?"... it would be kinda nice if they were stable on the back button press... maybe only stable within a few minutes would be fine, and probably not lower impressions substantially.

Or is there some page that shows everything in rotation that I can browse through?

The default is zero, or— if your transaction doesn't meet the network's relay rules as a free txn, which yours wouldn't because you had an output value >0.01— 0.0001.  Are you potentially running really old software?  Either that or you've already got a setting in there for something greater than 0.0001.

I think people here should show some evidence that they really were shipped out of order before anyone really believes it...

Could just be a mistake, a coincidence, ... or an effort to trigger mass refund requests.

It's interesting to me that they were careful enough to empty the website before emptying the wallet, is that really the case?

In any case, I'm sorry to hear of your loss.

Your feedback is requested at this pull request, also at this one. You might want to see if you can get a refund from GHash.io.

This fee would not be possible with the reference software unless you've set your fees per kb higher than 0.0001. ... What did you _set_ your fees to?

The normal procedure for websites that allow withdraw is to simply charge a static withdraw fee which is somewhat higher than your typical one, as exact fees depend on the data size of the transaction, which depends on the denominations of the coins in your wallet at the moment. The worst case size transaction that the reference software will build is 100k, so if your fee is set to 0.0001/kb then the _most_ (in the should never happen, wallet attacked and full of only dust case) would be 0.01 BTC.

With setting your withdraw fee to some small increment above the typical you make a small profit and give users a very regular interface.

You appear to be under the "mining is a race" mode of misunderstanding.  Pooling does not increase your earnings (typically it decreases them somewhat), it lowers your variance— meaning it makes your payments more stable. Mining is a linear process, and having more hash power doesn't increase your income except in proportion, no more.

The possibilities available are also broader than "everybody on the biggest pool" vs "everybody solo", there are many ways to completely decentralize mining itself while retaining whatever kind of payment pooling you like. (See my comment to Eleuthria about having pools just handout coinbases, and miners return shares that include the pool's requested coinbase in order to get credited)

We could even have an outcome where 100% of the _payments_ were paying into a single pooling effort with no risk to the network consensus at all.  (e.g. big payment poolers participate in a P2Pool like agreement to mine coinbases which pay proportionally to the last N shares in some sub-block payment sharechain,  then distribute income according to whatever payment algorithm they choose as a function of work submitted to them by miners handing them compliant coinbases. Miners just mine honestly and use their preferred payment pooler's coinbase outputs).

You do not have to trust the coder behind the binary.

The binary is proven to be a result of the published source code— provable by you yourself, or indirectly by many unrelated parties performing the check and publishing a certification of their result (which already happens today).  The source code is open, transparent and generally developed with an open process so that you, your designees, and/or the general public can audit it and sound alarms if it does something unwelcome or suspect.

Gah. I'm sorry to invite the offtopic deflection, I should have seen it coming.  The point remains that there is enough ambiguity in "luck" to drive a bus through. A less personal example: Virtually every block mined by 50BTC for the next ~month after P2SH was orphaned, it hardly lost any hashpower and it's now one of the largest pools.

The nature of pooling encourages an arms length relationship between the hashers and the Bitcoin network. It would be in their perfect-knowledge rational best interest to behave otherwise, but it turns out perfect knoweldge is kinda expensive.   I can produce case after case of hashers behaving poorly in this respect. Counting on it to preserve security against attacks which could be over in hours— e.g. by someone trying to cause a huge negative event to make a profit off shorting Bitcoin— is unwise.

It's visible only in a purely abstract way. Deepbit was frequently "eating its own tail" due to running multiple bitcoin daemons which would end up on competing forks and then load balancing miners between them (if it doesn't do this anymore its only because it doesn't solve enough blocks).

Not a single person in the world noticed this until Luke-Jr, bless his occasionally trolly heart, added code to BFGMiner to refuse to mine when a pool appeared to be forking itself.  But not many people run that code.

Moreover, it's only a very partial solution:  Say the network is on block A,  you don't include the transaction you want to conflict in A. Then then another miner solves A and the network moves on to A+1 but you stay on A. Eventually you solve A'+1+1+1 ... and with some luck reverse the transaction.  Miners never see any self-forking, and so the protection in BFGminer cannot help.

Performing the attack in this way simply constrains when you can start the attack (only right after another pool found a block), it does not reduce the success rate.

A number of years ago your pool delivered earning of something like 40% of expectations for months. A number of people were convinced that you were a thief because of it (that something was subtly broken, or there was some witholding attack seems like a more likely explanation, in my view), but that hasn't inhibited you from having the largest pool by far.

I cannot believe that many people would notice or care about a decline in revenue on the timescale of a single day or two.

Maybe they would. But thats a big maybe to stake the future of Bitcoin on, especially with people trying to open up new markets that allow them to take short positions. A substantial successful attack would dramatically undermine confidence in Bitcoin:  The existence of major hashpower consolations already defeats the security assumptions, but its a theoretical weakness and until an attack happens many don't believe what incredibly shaky ground we are on here.


Control over mining is orthogonal with pooling payments.  There is no reason that a pool couldn't simply hand out coinbase transactions to miners and credit them for any remotely sane looking shares that includes the requested coinbase transaction.   The pool would then only be a consolidation of miners payments and would have no risk for consolidating control of the blockchain consensus. Miners would become miners again, and not just people selling computing services for coin.

The risk that miners would intentionally have some junk transactions that get blocks orphaned would be strictly less than the block withholding risk which cannot be eliminated, as you could still ask miners to occasionally send whole blocks.

Had Satoshi though of this in 2010 I believe we would have a very different world today.

33% of the hashpower will successfully reverse 6 confirmations 21% of the times it attempts.

33% can successfully reverse 2 confirms 53% of the times it attempts.

"51%" isn't a magical number. Large consolidations of control over hashpower undermine the security assumptions behind Bitcoin, Satoshi was opposed to centralized pooling, for good reasons— but sadly his vision didn't see quite far enough to offer the alternatives.

I don't think it's fair to single out BTCGuild here— though it is the largest pool— because you could get to the same number through combinations of compromising a couple of the smaller ones, which for all any of you know could already be run by the same parties.

It has one and has for years... including the ability to partially rescan if the lowest applicable height is known.

This thread has gone hopeless OT. /Locked. (I've asked the OP to start a self moderated thread if he is still helping people with this)

I always used the 'insulated' metallic twist tie that comes with the power cords. Thats what thats for, right?

If its synchronizing slowly because of your internet it shouldn't be adversely impacting your computer.

I will eat my hat if you can notice the difference in speed. You really should have it turned up a bit so that the data checked will at least cross several erase blocks.

Depends on a lot of things— the software is fairly sensitive to slow or unreliable behavior from its peers. With super fast peers on a fast connection and a fast host you can sync in a couple hours.   With lossy peers, a slow host, a slow connection and some bad luck it can take several days.  There should be some major improvements in the next major release which make the worst case much more like the best case— basically from fetching blocks in parallel and not letting slow peers wedge the process.

Online wallets are very popular, a fact which concerns me greatly as they present a huge systemic risk— but the usability is hard to argue with.  There are also thin client like electrum which have a stronger security model than online wallets and are basically as easy to use.

It means you are more likely to suffer from undetected corruption that could potentially be somewhat harmful to your peers. if you're trying to reduce your startup time, setting checkblocks to 6 would be a much better idea than reducing the checklevel.

Uh. The subtext here is that cancelling will make them ship yours right away.

It's almost a little hard to believe since, obviously, people would eventually figure that out and the result would be pretty easy to predict.

No no, I wasn't saying that you weren't quoting me, and as I said— and linked to, I have consistently said the same stuff, and said as much in the thread. It's absolutely my view.

Here I was saying that I wasn't sure if the quote came from github or someplace else. I can't find any reference to the text on google beyond your comment. You can tell if it's from github if you search your email, it'll be in your email if it was originally on github (but wouldn't be in mine).

Please do, forum search turns up nothing for me. Perhaps that was the original origin of it? I have no clue. My ability to turn up things in the thread to quote is limited by whats actually in the thread at this time.

I'm not sure why you think you've found some kind of zinger there: Its a position which I've consistently held, repeated many times, and which many people would repeat more or less exactly if asked what I thought about that kind of subject. (I note that Theymos advanced similar sentiment above— while I haven't consulted a market research firm, I don't believe it to be a rare one).

Its my experience and belief that voting is not a particularly effective decision method, at least not when there are alternatives and certainly not in an environment where it's so trivial to employ sock or meatpuppets. Basically the only positive qualities voting has is that its decisive and its sometimes available when all better alternatives are unworkable, but it loses its decisiveness when its trivial to cheat. I have no idea where you think I was willing to hold a vote, but I think it's unlikely that I've ever wanted to hold a vote on github or over some subject on github. (I can't help but find a little amusement in the notion of someone who claims to be opposed to state control advancing voting to control other people's activities against their consent as a go-to first choice tool for social involvement)