For example, if you want to pay BitVOIP for some nice VoIP services*, the only thing that matters for that transaction is what Bitcoin protocol they are willing to accept. Inevitably, for Bitcoin to work at any scale, it is the merchants people want to do business with the most who matter.

* No, I don't know anything about BitVOIP or anything like that. I just quickly peeked at the Trade wiki page for a quick example I'm not biased on.

I'm assuming that if SHA256 gets broken, any backup variation of it automatically is also broken. The algorithm might need to change anyway, but it would break all ASICs.

Um, no. I want ASICMINER to be as profitable as it can be. I think reconsidering the hoarding plan can help that significantly.

But with ASICMINER having a (near?) majority forces the entire Bitcoin currency to depend on trusting us. I'm okay with that - it's only 1-2 months until consumers have ASICs themselves. But I don't think all Bitcoin is as trusting, and that could have a negative impact on price as well as future profitability even assuming the mining is never abused.

Probably just once. But by that point, consumer ASICs are almost guaranteed to be online. Obviously if there are still sufficient concerns, the algorithm could be changed again at the expense of all ASICs.

Yes, that's one reason why the barrier required to do so is high.

Please, actually read what I've said before posting an "analysis" of it...

I am also invested in ASICMINER, and hope it is a success. I think that all things considered, our risk is greater by taking the ASIC hoarding approach, even temporarily.

I'm on your side, no need for ad hominem!

ASIC hoarding cannot be considered to be equal with "honest mining", no matter who does it, since it forces the community to trust the person controlling them.

All ASIC vendors, not just BFL, are advised to implement an alternative algorithm in case of emergency. Just having such an algorithm doesn't provide anything that can be "played". Only the Bitcoin economic majority (the final "authority" for Bitcoin) can choose to make use of it or not.

Since consumer ASICs would be online the new algorithm(s) first (as in, immediately), it won't be so simple to 51% attack at that point. If you could, however, I'm not sure any way for Bitcoin to ever really recover - any reason to justify switching to new algorithm(s) is extreme enough that it would never make sense to switch back by force.

P.S. Ignoring kano's nonsense troll attempt

ASIC hoarding before consumer ASICs are available is generally not considered to be in the "honest moners" category.
I'm sure midnightmagic only brought up the risk of the algorithm being changed (not by any one person, but by the whole community together) because such action is (with good reason) generally considered to be hostile.

That's an improvement, but why the 10 BTC limit? If you need a new hash to gamble on, just take SHA256(txid) for each subsequent bet.

It does no such thing. It's a (hackish) workaround for the limitations of ASIC compared to GPUs/FPGAs (which don't have this limitation at all).

No. In such a scenario, all the benevolent ASICs need to be supported (to the extent possible), or the community won't let it through.

There are other projects like ASICMINER, though it is up to them to make their own annoucements.

What? Nobody is dictating anything. The advice to support an alternative hashing algorithm is simply to overcome the limitations of ASICs should an algorithm change be forced by circumstance.

Gavin cannot change the Bitcoin hash algorithm. Only the economic majority can.

FPGAs/ASICs often need to have "wasted" space due to contraints of their designs. That space can be used for trivial tweaks. For example, one simple possibility would be to change a bit in one of the SHA256 constants for the 2nd round of hashing, only if a certain flag is set.

... what?

I don't think economic majority is equivalent to mining majority anymore, and certainly won't be after this ASIC upgrade. Even with GPUs and FPGAs, a lot of the bigger miners have had to sell most of their profits for fiat currency. I expect the biggest influence for such a change would be MtGox: who's going to use an algorithm they don't support these days? And I think MtGox's integrity is such that they would not go along with such a change merely to satisfy greedy miners.

Edit: For an example, note that some big GPU miners have been trying to push for an algorithm change, but they're not getting anywhere because it's based only on greed.

Mining majority cannot change the algorithm, only an economic majority can. I don't think anyone would be able to get most BFL miners to switch without a good reason, anyway - it's simply too risky since "greed" won't fly with the non-BFL miners.

There are no licenses or issued secrets. Each ASIC vendor is expected to come up with their own reasonable "secret alternative algorithm" and not tell anyone else (including developers) until such an emergency occurs. When/if that happens, Bitcoin would be made to accept any of these alternatives.

That is not necessarily true. ASIC vendors are advised to implement an alternative algorithm they can switch to in case of emergency like this. If the community felt it necessary to block out ASICMINER (or some other hostile ASIC hoarder), the other ASIC vendors would then publish their secret alternative algorithms, and Bitcoin could be made to support those.

Edit: There is no single "secret alternative algorithm" being issued/given to ASIC vendors. They are all expected to come up with their own and not share it outside the company except in an emergency.

0.00001% transaction volume from 0.0000000000000001% of usage is a DDoS attack, yes. And "stress tests" don't make the network more mature, development and adoption does that.

It's not ready. Nobody (involved in development) pretends it is. People merely abusing it doesn't help at all.

I'm not suggesting it be done, just concerned about the risk that it might be considered necessary by the community (no one man can do it).

I was asked here. The same "problem" applies to BFL ASICs and any other super-high speed mining device. I assume anyone making ASICs (and I know for sure including BFL) has given thought to the problem by now, and it's not like there isn't a solution developed already.

BFL says they are selling 100% (or close to it?) of their ASICs immediately, and a bunch at the same time to prevent any one person from having a chance to abuse it. ASICMINER has announced they plan to hoard their first batch and mine with it before anyone else has ASICs, thus centrally controlling a Bitcoin-threatening amount of hashrate. See the difference? As for "BFL lobbying"... while I do stand with BFL, I also stand with ASICMINER - I want them to succeed, and am even a shareholder; but that doesn't make these risks/concerns just disappear either.

All that being said, I'd like to note the following for anyone considering changing the algorithm:

• It sounds like ASICMINER's total will be under the 50% required to do anything evil, even accounting for some variance.
• With BFL (and other vendors) shipping ASICs to consumers within 2 months, any opportunity time for abuse is very limited.
• Most 51% attacks can be dealt with after the fact; that is, the algorithm change would be more or less just as effective if it is only IF abused. So there is no need to cut it off just for holding (near) 51% short-term.
• While the "time travel" attack remains a risk that cannot easily be dealt with after the fact, the practical reality is that it takes much longer or much more percent of hashrate to pull off, which ASICMINER probably won't have (less than 2 months and not much more than 50% if that)
• Changing the algorithm breaks all old clients and miners, requiring more work for developers and forcing every miner to update.

Added this use case to the notes for the planned event system.

It should work under Windows. If you want more details in your log, you can also try the --debuglog option. Note that 2>log.txt must come after ALL options, since it is a redirection and not an option itself.

100 times worse than if you let people send 1 BTC to make 100 bets instead of flooding the network with 100x 0.01 BTC transactions.

That only solves the share/result side of the problem. You still need to getwork for every 4 GH/s.

Even if DiabloMiner is so inefficient that it uses 12 GH/s worth of work per GPU, it's still a far cry from the hashrates ASICs really do perform.

Not pooled mining in general, just centralized pooled mining where the pool is providing you with blind work. A standard getwork request can only sustain 4 GH. With rollntime, that becomes 4 GH/s. ASICs can easily do huge speeds of TH/s, and keeping getworks going fast enough to sustain them can be very troublesome.

Decentralized mining allows miners to cooperate in a pool while still making their own blocks. Once a minute or two (and on new network blocks aka longpolls), the miner will get a new set of rules for valid shares, and then make as many blocks as they need/want for shares. Eligius supports this with the BIP 22 and BIP 23 standards; P2Pool and BitPenny use their own proprietary protocols. I expect we'll see more pools upgrade as we get closer to ASICs becoming a consumer reality (of the open source poolserver software, Eloipool only just finished basic BIP 22/23 support yesterday, and ecoinpool has it planned).

Please stop creating DDoS attacks on the Bitcoin network.

Centralized pooled mining is incompatible with ASICs, and decentralized pooled mining ultimately moves control of blocks back to the miner - that is, ASICMINING alone controls the full 12-16 TH/s. Spreading it over decentralized pools (of which there are only 3-4 right now) doesn't change that.

Mining will yield ZERO income if the Bitcoin community decides ASICMINING is a threat and changes the hashing algorithm so our ASICs don't mine valid blocks.

As a shareholder in ASICMINING, this risk concerns me. I also don't think the mining income from hoarding the first batch would offset the potential income from selling them immediately to the highest bidders (especially since they will no doubt require software development and burn-in testing, which would obviously be mining Bitcoins).

I'd like to hear Friedcat's thoughts on all this.