Ding ding! indeed thats informative.

As a workaround, set a rpcuser / rpcpassword and server=1 in your config. I am 92% confident that the issue will go away for you.

It's my understanding that the miner software authors have heard _nothing_ from KNC lately, though they were told they'd be given access for testing. So if it'll work in any particular situation is a crapshoot. Historically mining code from hardware vendors has been pretty crappy.

It takes a bit of time to install p2pool and bitcoind, so if you're planning on p2pool mining them I suggest getting it setup and running early.  You can happily look at the p2pool graphs even if you're not mining on it.  Your BFLs will run great on p2pool, or you could just use p2pool as a backup for them.

Sort of.  With the current protoco a set of otherwise independent parties can collaborate over an anonymous communications channel to safely produce a single transaction.  E.g. I can author a transaction which spends one of your coins and one of my coins and pays to a new address of yours and to a new address of mine. The transaction is not valid until we both sign it, which we can do in parallel and merge our half signed transactions after the fact.

Third parties who didn't witness our negotiations cannot discern if we are one person or multiple, or which of the outputs belong to which of the input owners. If there are more than two parties there are way to conduct the negotiation externally to the Bitcoin protocol itself so that none of the parties learn the input/output correspondence for the other parties.

You can perform these transactions using the raw transactions commands in the reference bitcoin software.

So while the inputs as a set and outputs as a set are linked, the collections could involve multiple parties like you achieve for a whole block with OWAS.   The OWAS removes the need for any bidirectional interaction or cooperation of the signing parties. A clear improvement for privacy, but perhaps not quite as much as you believed.

I'd already tried hextoasciiing the p256r curve's seed, before ever commenting on it, no such joy. (I'd also hoped to find a similar answer to our generator, but no such question, as the message said though— the generator isn't a known cause for concern, as you can generally convert numbers relative to one generator relative to another trivially. I'd though perhaps the generator would result in low hamming weight in the multiplies, allowing some stems to be avoided but it seems not)

Four lines of code in pynode or whatever could be used to currently crash 86% of publicly reachable Bitcoin nodes— it was 100% before a month or so ago, for at least the last year. This is only a single known and fixed problem. Make the appropriate transaction first and the nodes won't come back up without upgrading their software. I could make more examples, but I'm somewhat wary of stuffing beans up my nose.

Why hasn't someone done it yet?


Because attacks aren't like random process failure. They're generally completely absent, until they're not. You cannot infer security from a lack of failure, only insecurity from the presence of them— it isn't symmetrical.

Absolutely, it's also the hardest to understand.  If you explain mining without explaining the rest of it, it gets misunderstood.

First you explain the whole idea of a scarce money like good created by a p2p system and how that can be socially useful.  Depending on the audience you explain the problem of achieving a distributed consensus.  Mining just solves the distributed consensus ("Security" for the less technical audience) while also solving the practical problem of getting the coins into circulation to begin with.

Once people understand the usefulness of Bitcoin and see that mining exists to solve important and necessary problems the result from the creation of the system, then it no longer sounds like some kind of scam.

You're just picking on the latest bugaboo there. There is nothing especially centeralizing about ASICs, in fact, when we were using GPU mining there was just a _single_ hardware vendor. We went months in 2011 with no 58xx gpus being available pretty much anywhere in the US.

All proof of work does effectively the same thing: It converts joules to cryptographic signatures that have verifiable scarcity. Differences in proof of work can only move around constant factors in the economics.

See section 7 of bitcoin.pdf

My prediction: People who don't understand bitcoin will continue to reinvent it poorly.

One of the most frustrating things about having concerns about Bitcoin's ongoing decentralization level is that half the other people complaining about it are simply confused.

Same way that pooled mining always works:  You attempt to mine a block, if you produce work which is less than some target set by the pool (which is a much easier bar than the network difficulty) you submit that work to the pool, and they decide if they like it or not, and then credit you based on how many of these shares you return. The shares constitute compelling evidence that you are working on work which is agreeable to the pool.

The pool could demand any level of disclosure and validation that it wants, but it really only needs to check that the coinbase transaction is correct. Any miner could always selectively throw away solutions which have hashes low enough to be valid blocks in order to attack the pool (this is called a withholding attack), so maliciously invalid blocks aren't an additional risk.

P2Pool goes all the way and replaces the pool with a decentralized system, but you don't have to go that far to still remove pools from the business of controlling the Bitcoin consensus algorithm.

Indeed, it's trivially possible. You don't change them after the fact, you change them before you mine. P2Pool enables this, and any pool that supports GBT (e.g. Eligius) could in theory support this. (I believe eligius actually does, but I don't think any miner software exists that lets you make use of it).

Selecting transactions is really not at all sufficient, as it would still let someone controlling a pool reverse transactions.  What you really want to do is separate "pooling for payment" from "control of the Bitcoin consensus".  This is trivially accomplished, from a technical perspective:  Do a GBT request to a pool to get a coinbase transaction that they'll accept, then query a local bitcoin daemon for your idea of the network consensus... merge the two and submit shares to the pool.  The pool then pays you if your shares are paying a suitable (e.g. winnings go to the pool) coinbase. ... but this requires non-existing miner software and, of course, pools which support pooling only for the payment.

You would think that these supposedly civic minded pool operators would have getting themselves out of the creators-of-systemic-risk business as a high priority, but apparently not, since the market apparently doesn't demand it.  (Eligius has done the most in this regard for centralized pools ... and it's 2.5% of the hashrate.  P2Pool is a decentralized system and it's about 1% of the hashrate).

Litecoin was originally marketed as GPU proof, as you can see— that didn't pan out so well. Many people believe that people were secretly GPU mining it all along while others druged along with CPUs.  Likewise, there may be people with FPGA or ASIC miners on LTC today. There is nothing fundamental that ltc is doing which makes it hard to get a large advantage... maybe not quite as much of an advantage, but a 10x advantage in a thin margin business might as well be infinite.

What you probably want to do is to take some python blockscanning tool, teach it the block hashes you already know, and ask people to run it on their own chain files and have it send you the blocks that you haven't seen.

There was an old blk000.dat that used to be hosted with the blockexplorer stuff that had a lot of fun reorgs in it.

I agree it would be good for someone to collect this data.

Astonishingly the PPS value of a difficulty 1 share is still above 1 bitcoin base unit.  I had previously tried to suggest that wizkid make the minimum at least 1 base unit PPS only to be surprised that it still was...

It may because you explained it using language that was suggestive of it being a scam. "If it sounds too good to be true!"

I've never had the problem you're describing.

I describe Bitcoin as a novel way for people to consensually interact without trusted third parties, instead of describing it as way to make money.  I am blunt about the risks, but also spend time contrasting them to the risks of alternative (dollars that inflate, banks that are really insolvent, gold notes that are backed by nothing, etc). I share funny stories about over exuberant bitcoiners and the crazy Bitcoin market.

The promise of Bitcoin is enough that people still find it compelling and fascinating even when knowing the real risks associated with it. It's hard, however, to tell someone that they're being scammed when they're being so frank about the risks.

See also this thread?

Presumably if you'd said something important enough to merit repetition you would have written it here?

"If you have to ask…"

Except it already has occurred. Anyone who hacks BTCGuild's systems or coerces its operator can happily reverse transactions that have reached six confirmations with a 21% success rate. 2 confirmations with a 53% success rate.

This is a direct result of the consolidation of hashpower which wouldn't exist absent it. It violates the security assumptions of the system.

We don't iterate MD5 more when its security assumptions were broken, we replace it.

See above.

We also have only about ~3000 stable inbound connection listening full nodes on the network according to the DNS seed crawlers.

We agree here (amazing) and I've had a similar experience to you. I am currently mining on P2Pool and I am a substantial fraction of its hashrate, not because I care for the variance reduction, but because I support P2pool and want miners who do not want the high variance of solo mining to have options which don't require delegating their mining authority over to centralized pools.

I have talked to easily a thousand people about Bitcoin. Hundreds of miners. I am a moderator in the mining subforum here.  It is my experience that your views are highly unrepresentative— not unique, but I could basically count the number of similar views I've heard on one hand if I exclude the developers who only have a few GH/s of toy mining.  If I thought your views were common I wouldn't be concerned.

Funny, responding to a pool behaving maliciously is not among those "modes". Luke's bfgminer stuff actually will detect a number of cases of bad pool behavior (like attempting to fork a chain it had previously mined on) and switch away. Con is completely uninterested in merging that or any comparable feature.

I'm curious what poolserver daemon you run.


I cannot think of a single feature in cgminer which is associated more with network health than short term hasher income.

The failover functionality also unfortunately means that if you compromise one large pool you can DDOS the others in order to drive the hashrate up on your compromised pool.

This is objectively false. For example, when P2SH went active on the network, 50BTC was asleep at the switch and for over a month almost every block they mined was orphaned. They lost no hashrate during this time and today are the second largest public pool.

BTCguild, before they went PPS, went through a months long period of "bad luck" which had one in a zillion chance of actually occurring based on chance. The cause was never explained. Today its the largest pool.

Some popular "gui" mining software botches its failover and has hundreds of gigahash of wrong usernames and passwords show up on other pools when their primary fails. It goes unfixed for months/years.  When a major pool goes down there is an observable loss in network hashrate, in spite of the really fantastic failover abilities in miner software— as you note, the pools are unreliable, and the miner software has great failover, and people don't avail themselves of it.

Pirate (and friends) ran an operation which was paying people to run their mining through them while concurrently running his ponzi operation and paid astronomic PPS rates as high as 150% PPS at times. He gave conflicting explanations of how the hashpower was being used, none of which could possibly have paid for those PPS rates.  He claimed to have a near majority of hashpower flowing through his systems at one point, the SEC reports over 23,000 BTC mined by his operation. Several other parties have also run large pay to hash operations and received large amounts of hashpower.

If a pool starts doing something evil will miners switch away from it — on the timescale of days, sure. Hours? No.  I don't believe anyone can say with confidence that a day-scale malicious reorg event would be survivable.


What am I wrong about?   BTCguild— months of 40% returns. #1 public pool.  50BTC, ~1 month of mostly orphaned blocks due to misconfiguration, second largest public pool.  Slush, hacked multiple times thousands of btc stolen, third largest public pool. Together they are a simple majority of the hashpower.

P2Pool plus solo mining (assuming we exclude the large mining corporations like asicminer) are _no more_ than about 4.3% of the total hashpower, and probably less.  The position you are expressing is, sadly, a demonstrably minority one.

As someone who was deeply involved in the recovery of that event I can't say I agree with your characterization of the situation at all.  A tiny minority of nodes had rapidly deployed new Bitcoin software, if not for the tremendous consolidation in hashpower— making that tiny minority have a large supermajority hashpower, the fork would have resolved naturally.  The miners who's blocks were orphaned in the change were paid for their loss.

You keep saying things that make me wish I could duplicate you, which is a very odd feeling because I have fairly low respect for you outside of your support for the network.  Still, I don't think that we can dispute that your experiences are unrepresentative: Solo mining is a tiny fraction of the hashpower.

At one point we had something like 20,000 stable reachable full nodes. At one point I knew a dozen people who solo mined. You are not talking to some newbie here who is repeating the same old uninformed concerns, I never complained that gpus or asics themselves were a centralization problem.

BC.i webwallet users out number all time downloads of the reference software by a significant multiple.  There are so many different ways that the Bitcoin economy and network has more single-point-of-failure risk than it did in the past now— and only a few ways that it appears to have less (more working client software, and viable exchanges are things I'd call out as having improved).

I am not saying that Bitcoin is doomed or that things will not improved. If I believed that I wouldn't waste my time working on it or discussing it with you here.  But I think we need to frank and clear about the risks and concerns we have with the system if any correction is to happen prior to a devastating event which we may or may not survive.

Evidence in the altcoins and in other security systems suggests its not. One alternative, indeed, is to "correct",  but correcting has great expense— one which is borne exclusively by the correctors but which confers benefits primarily to the general public, a failure to support decentralization is largely an externality.  Additionally, the need for correction is not obvious to most users of the system until there is a massive failure— this kind of security is brittle—, I could argue that this thread is evidence that people are not completely unaware of these concerns, but here you deny them. There are low/no cost changes participants in the system could make (move off of centralized mining pools to P2Pool, run full nodes for wallets if you can, SPV instead of webwallet where you can't, run additional full nodes for the network even where you don't run a wallet, refuse to provide funding to centralized mining datacenters) which few people appear to be taking. The massive failures required to trigger correction would underscore that the core security premises of the system are not currently or automatically true, eroding confidence.  Without confidence Bitcoin has no value.  And everyone has another alternative: don't use Bitcoin.

Some of the most popular mining pools have been hacked over and over and over again, three and four times. Their reputation is fine. A large portion of hashers do not know or care.  Someone attacking the system would be interested in shutting it down completely and/or profiting off shorting it. They don't necessarily have to be those "trusted" parties, they may instead be someone who has hacked or coerced them.    Your argument with respect to reputation could just as easily apply to the FED or Paypal, and yet they continue to stay in operation and continue to behave in ways which people find to be unethical or untrustworthy.

Bitcoin is supposed to be based on stronger stuff than that.

This also ignores that a sufficiently large reorg is unfixable without leaving some people robbed. You can end up with two chains with loads of mutually exclusive transactions and absolutely no way to determine who are the honest owners and who are the thieves: it's one persons word against another.  The actual miners causing the reorg don't even need to be parties to all the theft, it can simply be opportunistic theft that happens during the consensus failure.

The majority of the users are not participating in the Bitcoin protocol, they use thin clients and hosted wallet services which do not enforce the rules.  As usage grows it is a distinct possibility that operating a rule enforcing node will become very expensive— requiring multiple gigabits per second of bandwidth in the "scales to visa" examples given by some— so it's not at all clear that they even could respond to such a threat by changing their behavior due to economic constraints.

steal your coins. Because creating counter-party risk where none is required is absolutely what Bitcoin is about.

Wrong subforum. I tolerate the latest gambling schemes talk when they have some intersection with the actual Bitcoin protocol, software, or technology.  But when you respond telling people not to use technology and to just send you coin, I say— go try the service discussions subforum.

Do not confuse delta-t with the amount of waste heat. Ability to operate at high delta-t is limited by semiconductor technology.  Indeed, if we really did have high speed logic that worked with high delta-t then your options for making productive use of the waste heat would be broadened beyond low level heating applications, and the argument that hashing is more efficient decentralized wouldn't fly, but we don't currently (and this is something which is very much desired even outside of bitcoin mining).

Depending on how you define "Bitcoin"— if you mean the thing that most Bitcoin users use, ... most Bitcoin users use a couple webwallets and SPV clients. SPV clients cannot prevent inflation in our current blockchain protocol, and webwallets may not— at their own preference and whim. I believe that most Bitcoin users are trusting the behavior of a half dozen people or so to prevent inflation.  No _one_ perhaps, but six people? That is another question.

There is currently such an option, but with mining under the control of just a couple entities it could go away. They could happily only mine transactions created a certain way or obeying whatever new rules they wish to impose.

I think the thing we try to achieve with decentralization is not just freedom in practice but freedom which is infeasible to remove. It might not look likely that these freedoms will be removed in the short term, but I think we cannot say that it is currently infeasible.