I didn't say anyone was 'evil' ... but there is a little something to that:   I've talked to parties with plans to build enormous private farms in the past and the discussion has gone a little like this  "Look, if there is a major consolidation of hashing power that undermines confidence in Bitcoin— the community _will_ change the POW to block it, making your chips worthless. All parties working on chips have included a vendor specific alternative POW, so parts can be denied on a case by case basis".  After contemplating this everyone else realized that the rewards of having private control of a substantial chunk of the total hashpower weren't worth the risk (or at least they had the good sense to be secretive about it and moderate their hashpower).   Someone gambling with other people's money— however— might be a little more prone to sociopathic behavior since the they don't have the same skin in it.

Some people believe that public investment creates evil. I think thats too simplistic... but gambling with other people's money certainly does encourage short term and excessively selfish thinking.

BFL responded to concerns at least in their own not very adept BFL way, ASICminer hasn't... take that for what you will.

Two other = three.

You mean 246 years, right?

There are two other companies building asic mining devices to sell to the public, with no plans to build majority hashpower farms under private control. BFL itself voluntarily implemented supply caps and shipment staging in order to reduce concerns about hash power consolidation. The people behind asicminer were cautioned in public and private about their plans to create a large amount of additional consoldaton and showed general indifference to the concerns. ::shrugs::

It may not be the end of the world, but don't confuse that with it being a good thing. To anyone who isn't an ASICminer shareholder them not existing would have been greatly preferable to putting ten to tens of TH under the control of a single party.  Though having additional competition for mining devices available to the public without the consolidation would have been even more preferable yet, but that wasn't an option the trustees of asicminer offered the community.

There is nothing magic about 50%, see the bitcoin paper for  the odds for successful reversals for various wait times and attacker powers... Though my understanding is that the asicminer first run was going to be 12TH/s, not 6TH/s.

In any case, I consider it concerning and the success in raising funds for such a large centralized mining farm certainly reduced _my_ confidence in Bitcoin (and did so completely independently of BFL). But opinions may vary.  The big centralized pools are concerning too, but at least there was always the argument that they depended on the goodwill of the people actually controlling the miners who could very easily "vote with their feet". This doesn't apply when you end up with similar consolidation of the actual hardware.

More like: the fact that their analysis didn't turn that up further confirms how shallow and ineffective the research was.  If only there were real research happening it might have been discovered more quickly!  (Of course, many other people did do things with the transaction graph without noticing this too— see for example blockchain.info's taint tracking service. So they were hardly alone in not noticing it)

Caught?  It's public and the history is available for everyone to see and he edited it with his normal account. I'm sure he fears your amazing sleuthing powers!

And ... "competitors"? In favor of BFL?  The aforementioned 'competitor' is building a centralized mining farm, not selling a hashing product to the public (at least not in the immediate future).  The page is about mining hardware for people building mining farms.  Asicminer doesn't obviously have any reason to be there.  (Frankly, none of the not-yet-shipping hardware really does, IMO, but that argument has been lost).

Please don't abuse your moderator status to create new drama sticky threads, especially when you've so recently berrated other people for spreading pro/anti- BFL drama outside of the BFL thread.

I wonder if the exchange rate is going to tank once people find out a single party has captured a substantial hunk of the hashrate?

Under that model miners and high value targets would need to run, say, 12 implementations at at least 12x the cost (and probably more because some implementations will be much less efficient).  ... and the effective feature set of the network would be degraded to whatever the most popular broken implementation runs.  …

There can be uses for running multiple nodes for comparison— I do today. It may become a regretful requirement in the future if broken node software becomes commonplace. But this is a _very_ bad answer to the fact that your software is broken while it is not widely used.  Please fix your software before spending time on this.

No.

Am I misreading this, or does this sound like they won't be at tape-out until 30 days from now?  (What careful checking of hand routed design will you be doing once the masks are being printed?).

They have— a great many FPGA products— but maybe that was just a "CYA" and not their actual policy.

First, lets be completely clear about this before you start slandering me:  I _offered_ but also said I think it would be best to find it via testing, because we have no other way of knowing if the testing is sufficient. It is utterly essential that the complete rules of the system be faithfully executed. It is very hard to get this right. It's no insult to anyone if it's not quite right at first, but it is very essential that its well tested so that the test turn up every short coming.

Just as a reminder of what I said:

A problem is that even with good testing it is hard to have confidence that the testing is good, and so the software remains untrustworthy even if its perfect. In fact, the more perfect the software is the more doubtful the tests become— They always pass!

Because of this, the fact that someone knows about an issue is a significant opportunity: If the tests find it then there is some actual evidence that the tests are sufficient. Not complete evidence, but some.  And right now the software is new and pre-production, so there is no harm created by some rules issues persisting for a bit, no risk to the Bitcoin network of someone exploiting the differences, etc. So finding something like this is an opportunity to build confidence in the software quality which would be destroyed by me just throwing out specifics about what is broken.

(And, of course, the tests are far from sufficient in the reference client— otherwise I'd just be saying "run the reference client's tests against your software". But the reference client's behavior is normative, so the bar is higher for alternatives: They have to emulate the rules related 'bugs' in the reference client: All (rules) bugs are features. This is one reason why Satoshi didn't support alternative clients).


I think it looked mostly complete, that is why I asked though— I wasn't sure if you believed it to be complete already or if you were still working on it. The issue I'm aware of is a part of script validation— though I'd encourage you to not over optimize on what I'm aware of, simply because there may be other useful things you find while testing.

If you're syncing from the network even if your own connection is fast you're subject to luck of the draw on which peers you pull from. This is one reason Pieter was suggesting loadblock runs above.

Okay. You're missing at least one important rule, but I don't know what else is missing that I missed in review.

Unless you object, I'm contemplating keeping this missing rule to myself for now so that it can function as a test of the testing. E.g. if the test don't find it, they're incomplete.  Obviously I don't want to withhold information which could undermine the network, but absent better testing the software shouldn't be in production use anyways... and there are scarcely few good ways of testing the tests.   Does this sound reasonable to you?

Whats the current timeframe for enforcing all of the script rules so that mining on this code isn't a forking risk? (if there is one?)

Were you already synced with 0.8 before attempting that reindex?  If so that was horribly slow.

Not just miners.  It's needed to protect the relaying network from floods of spam transactions which would never get mined. But sure— as the fee marketplace becomes a real thing I can see the anti-spam fees for relaying becoming something that no one practically has to worry about because if it exists at all (it could be potentially replaced by priority queues for that purpose) it would end up smaller than the amount required to realistic get a transaction into a block.
 

Setting up a private testing network is trivial.

You start two copies, in two datadir, of bitcoin in testnet mode on separate ports and -connect them to each other.
Lets say the directories are /home/me/node1 and /home/me/node2

The configurations are, /home/me/node1/bitcoin.conf:

and /home/me/node2/bitcoin.conf:

You'll need one to have the testnet blockchain first. So start one without the connect and irc=0 config options first... as it won't mine until it has one peer and has reached the last checkpoint (block 500 for testnet)

start  bitcoin with  bitcoind -datadir=/home/me/node1   and bitcoind -datadir=/home/me/node2

Then just point a GBT miner (like BFGminer) to 127.0.0.1:3111 user:node1 password:ewiorweiprowi  or start a stratum proxy pointed to the same place and you'll be mining.

Not only that, Bitcoin testnet is a public testing network (though the above puts you on an isolated private fork, because you're using connect and you're on a non-standard port. But to be doubly sure, you may want to explicitly firewall off inbound to 3111/3112 if thats not already blocked)— I'd strongly recommend vendors test on the public testnet. Testing on a public network (but not _the_ public network) would create a slightly more realistic test (long pools from remotely created blocks) and also increase your customer's confidence that your products are real.

If you run public testnet you don't need to run two nodes, and don't need to connect= them, one node is adequate as you'll get remote peers.

e.g. the config would be, /home/me/node1/bitcoin.conf:

If any of the ASIC product manufacturers needs help with a testing setup please feel free to drop me a line, and I'd be glad to help you get one setup. Likewise, if any ASIC purchasers with more than a couple units needs help setting up solo mining or p2pool once the products ship, I'll be glad to help out.

This isn't one of the rules that can't be changed— like the block validation rules— and it has been changed before— the base fee was lowered from 0.01 to 0.0005 about a year ago.

What happens is that your peers (well, practically all nodes on the network) will just drop transactions that don't meet the rules and because your client knows this it will decline to generate any transactions that do.  To change the rule an new version that has a lower limit is released and then after that version is widely deployed (so that it's likely that everyone has at least one or two peers running it) the next new version comes out that imposes the lower limit locally too.

It is categorically different.   I can tell you my wallet encryption key but that does you no good unless you've also compromised my system or my paper backups to steal the wallet / seed (in the case of electrum).  This is two factor security.

What third party sources? It's not your fault that they don't practically exist, but it's still the case.

A major point I was making is that the theoretical security of a pragmatic user does not reduce the _systemic_ risk of a widely used service.  The fact that if users jump through some hoops that almost no users do they can personally be secure doesn't prevent the shared fate that we get from many people using a single point of failure.

I think it's quite trivial to profit from false payments though perhaps harder to profit from them on a wide scale.  In the context of Mywallet I'd probably use the mixer service to skim off users funds. People making regular transactions are prompted to participate in the mixer, and I'd simply have that skim off their inputs and repay them with fake ones.

I'd looked at the security page— It's platitudes and standard practices. While I'm glad that you have better security practices than some Bitcoin sites. Nowhere are the "these" concerns— the specific architectural limitations— discussed on it.  The stack exchange answer is much better, and some of that should make its way into the security page.

Hm. Did the email backup behavior change at some point? It makes me much happier to know it's a default.

Again, wrt your comparison with other clients my concern is what does individual things better (and indeed, your site does many things quite nicely!) but what creates systemic risk.  If a single person loses their wallet it is unfortunate but it is not catastrophic for the system. If a service depended on by tens of thousands of people merely goes _offline_ for an extended period thats terrible and if data is lost its catastrophic.  This is the cost of centralization: it creates failure modes which _must not happen_ and so defending against them is much more important.


Sadly, this is a worthless assurance. If your systems are compromised you wouldn't know about the logging.  It seems inevitable that you will be subject to law enforcement order to log some things (with or without due process, or whatever mockery of it you have in your location) and those orders will likely order you not to disclose this fact.   You could also be lying— you are, in fact— the best know enemy to casual privacy in bitcoin with the "first relayed" method; though I trust you are not but trust is what creates fiasco like mybitcoin, pirate, and bitcoinica. Plenty of people mine and do OTC exchanges.  Again, my concern is primarily systemic risk— and yes, the bitcoin exchanges are a systemic risk.  But one bad does not make a second bad irrelevant.

Please understand that I have great respect for the work you've done. Your service is very well constructed and well loved for good reason.  While some of the things I've brought up might be improved with some tweaks here and there, much of it is simply the structural consequences of centralized services, trusted parties, web clients, etc.   Those limitations don't reflect on your character or capability.   And they aren't flaws that exist in a vacuum: distributed solutions are harder to develop, harder to test, harder to add features to, often slower, often less reliable on average (though far more reliable in the worst case),  and darn near impossible to monetize in order to fund the maintenance and development.

There are plenty of reasons to use your service in spite of its limitations, but the benefits and limitations should be understood in context... and I don't think our community should take any actions which promote centralization or consolidation due to systemic risk if nothing else— so just like Bitcoin.org doesn't link to MTGOX (though it's also a widely love, well maintained, and very widely used service) I don't believe it should promote your wallet service either.