The last mining chip scam was significantly less sophisticated and still obviously bilked quite a few people. YMMV.


I'd take a non-trivial bet that if this is real it's some SASIC (hardcopy FPGA) process and not a FPGA (the numbers just don't make sense for any of the FPGAs currently available).   If so, under the suggested assumption that bitcoin blows up, depreciation to zero is a completely reasonable assumption.

Because $580/380 is $1.52.  380 is the speed we should expect from two of the the -3 parts, because thats the speed that the currently best available open source code typically gets on them.

It would be surprising if the X6500 is unable to reach the same speed ZTEX is getting with _the same part_ after adopting the same double stage pipeline design spending the couple hours brute-forcing the optimizer settings to get it to route for 200mhz. It might be the case that the -2 part also ends up just as fast due to the vulgarities of binning, but I know of no reason to expect it to be to be faster.

(and keep in mind, of these three the ztex is the only one you can click-and-buy for immediate shipment right _now_ so if you want to talk about dollars per MH _this moment_ rather than what we can reasonably expect— then Icarus and X6500 are both ~$∞/mh. )

And yes, agreed. It's all good work. And regardless of how the $/mh ultimately works out when the boards are generally available. The Icarus boards look like they'll be an excellent value due to their increase flexibility.

This is a misleading description.  You're happily waving away the _cost_ of a particular attack.

Take bitcoin as it is.... if you'd like to buy computing time to mine a six block fork you should pay 300 BTC (plus some premium to get it all at once, I suppose). Under the 2.5/minute 12.5 BTC model, the cost would be 75.5 BTC.

(Before you protest that burst computing capacity in excess of bitcoin violates the security model— realize that is effectively an argument that honest bitcoin mining must consume a majority of all fungible computing power in the universe,  as compared to the far more limited requirement that the majority sustained hash power applied to bitcoin be honest.    It's also important to keep in mind that not all the attacks we guard against are races against the public network. It's pretty easy to isolate single nodes via sibyl attacks then slowly feed them blocks which have no chance of surviving on the main network)

The assumptions also require that blocks are not frequently found under the network latency. The 1s number being thrown around is nuts and obviously and observably not true today. Keep in mind that forwarding nodes also check the validity of the blocks before propagating them some of our larger recent blocks are hitting a second of validation (computation/disk IO) alone. This is why it takes several hours to syncup a new client now.

Then there is the point which I made in my first post which seems to have been ignored— part of why we _wait_ is not just to gain confirmations, but to reduce the risk that there was a network partition with considerable hash power on both sides.  E.g. If EU and the US lose internet connectivity people can spend on both sides. In order to be secure you must wait long enough that such a split is unlikely and/or long enough that if a split were to happen people would have an opportunity to detect it intervene (e.g. miners could stop processing new txn, sites could switch to higher confirmation limits— but only if they've detected the partition, which takes time if you are to avoid false positives).  Both criteria require absolute time, the distribution of blocks is irrelevant.

Perhaps I missed it, but I haven't really seen anyone address the point I made that this kind of change (10->2.5minutes) is a change in value but not in character. It doesn't suddenly make the system suitable for direct POS usage. There is a fairly narrow range of use cases where that would constitute an improvement and I suspect almost all of those uses could be adequately addressed by the solutions employed for POS processing.  (I assume everyone agrees that switching to _two second_ blocks needed for comfortable direct POS processing (keeping in mind the variance) most certainly would break it, even if you care to debate my arguments against decreases in general)   (Oh, I see maaku's edit now— oh well, this is worth repeating)

It won't be better (from a purely myopic $/MH basis) unless it's equal to or lower than the x6500 unless he undercuts the x6500 price. Which is kinda sad because it looks like a much nicer board (for reasons unrelated to $/MH).

Or would you like to take a bet that a board with the _lower_ speed grade version of the same part is going to deliver higher performance?   I might take the opposite of that bet.

250 and not 200: https://bitcointalk.org/index.php?topic=40058.msg584606#msg584606

The X6500 is only at that speed due to not very well optimized mining code which hasn't been touched for sometime.  They were saying in #bitcoin-fpga that now that the board production was all sorted some time was going to get spent on the mining code. It's using the same -3 grade parts which ZTEX gets 190MH/s per FPGA on (and ZTEX's code is OSS).  While it's possible that they flubbed the power design or the clock signal quality and can't actually get it to that speed, I think thats unlikely.

It appears that Icarus is using the "slower" -2 speed grade part— which is probably the best part to use in terms of $/MH from a parts cost perspective.  But the parts cost only matter if they're passed on to the buyer.

Too much more that his costs and it's going to lose attractiveness vs the X6500 — yes, it's a more flexible board (it looks beautiful and deserves a good price) but for people who are primarily interested in mining the amount of premium they'd pay for that over a more minimal design probably isn't great.  (the idea of increased resale value is good, but it's pretty theoretical... and probably not worth that much in present day dollars)

Fortunately it looks like all the boards out there already have pretty healthy margins— they have to because of the small quantities we're talking about... so there should hopefully be room to take some of the increased parts costs without making it uncompetitive.

So, you're volunteering to come staff IRC and help people recover their unspendable funds when the priortization leaves their txn unprocessed for weeks, thus locking the inputs?

This isn't speculative, every once in a while some poor sod takes some bad advice given on this form and confuses it for an opinion by someone competent— they get away with it for a few weeks (after all, the overwhelming majority of txn don't get asked to pay any fees) but inevitably they show up on IRC asking for help recovering their wallet and we get to play the hex editing game.  Perhaps you're stitting on a stock pile of old inputs which have enough age that it's completely inconsequential for you. Great for you, but you'd also be unaffected by the fees.

This has absolutely nothing to do with miner's fee policy and everything to do with providing software which doesn't invisibly fuck over it's users.  Yes, better handling of stuck transactions is important and will reduce the need for the fee safety net, but it's not very clear how to do this without creating other kinds of traps and confusion— thus why no one has submitted patches to handle it yet. But if fees which are applied only rarely and only to TXN which look objectively like DOS attacks and which are less than the rounding error of a typical USD transaction (due to truncation to cents) are a problem for your bitcoin business dealings, then I don't think anyone can help you.

This is a perennially bad proposal.   The security of an N block bury comes largely from the amount of hash power used to bury it but also from the unlikelyhood of non-trivial internet splits lasting a given amount of time.   If you half the hash power required to get N blocks, then you double the number of blocks you need for the same security. Obviously there is a non-linearity at the one block boundary, but you're not talking about a one confirmation transaction.

Reducing the inter-block time further reduces security by creating additional hash power dilution:  When many blocks are found faster than the global communication time of the network (which, if you observe LP skews between pools, can already be up to a minute) then the network there will be may more short term forks and attackers can gain additional advantage by allowing their target to land in one fork, while applying their own power to another fork. The dilution also generally gives single large (good or bad) miners an additional advantage because of their improved power concentration.

A faster block time still is far too slow for "instant transactions" of the POS kind. So we have no less need for solutions for that, and when we have mature solutions for that then your whole concern is mostly moot.

Faster time between blocks would also be burdensome on low trust light clients— which don't need to know much but they do need to know the block headers.  Requiring 4x the storage on mobile phones is not nice.

The increase block rate also increases exposure to DOS attacks marginally.

Finally, and perhaps most importantly:  Any fundamental change in the distributed protocol will not be accepted by rational bitcoin users (unless its some bugfix essential for bitcoin's survival).   If we were willing to change this— whats next? The subsidy? The geometric decline?  Start skimming 5% off to send to a Glorious Leader?    Changes to the immutable bitcoin distributed algorithm would _seriously_ undermine trust and rightfully so.  We may be stupid, we're not that stupid.

Just set your maximum scan time to 1 second. This means you'll lose a maximum of ~144 seconds of mining a day or 0.166%. You'll usually lose  more effort than that from pools due to other issues (stales, bugs, network latency).

Pools can't do this because all the users would slam them. But it's a perfectly reasonable thing when running on your own. (not that running pushpool with LP locally is much of an issue).

Your request for a pony is being processed. You are #6182382813 in line. Please stand by.

Altcoin style would be to bet like gentlemen then set the building on fire to ensure outcomes.

An OT tangent really, but this is ridiculously and stupidly conservative.  FPGAs are quite neat— but in terms of silicon and power they are enormously wasteful. It's trivial and expected to get >>10x better on both fronts going from FPGA to a proper ASIC.   Without the inefficiency of the FPGA in the way the circuit for a miner is rather small so a mining ASIC on modern process would be thermally limited.  Even in cheap packaging you're going to easily do better than 2GH/s.

It occurred to me that with this daughter-board design you could bolt a large number of the daughterboards directly to a large monolithic heatsink then attach the host board, allowing the gold fingers to eat any of the placement error.    That should eliminate the interface problems that often come up with using a single heatsink with multiple chips. (Perhaps you were planning this already?)

I prefer the kind of evidence where the margins get down to 20% over COGS.

Space was set aside so that it could be switched to scrypt, it only didn't start out that way because of some reasonable conservatism in selecting the functions in use and scrypt is unproven though conceptually better for the reason you gave.

(The wallet encryption currently uses SHA-512 inside the iterated strengthening function now,  one reason this was done instead of SHA-256 is because even if we weren't going to switch to something costly to accelerate using the exact same algorithm that the bitcoin community has spent so much effort GPU optimizing seemed unwise)

Huh? So they reused some case photographs. Thats hardly indicative of deception.  Is newegg a scammer because they use manufacturer provided shots of some products?

I thought Luke had said they answer their phones. Call 'em up and ask when you can swing by.  I think it would be reasonable to say that if you confirm their legitimacy lots of people will order  (so be sure to ask for a good cut :-P ). 

JTR does not support the algorithm we're using, though you could use it as a wordlist generating front end on your own implementation of it.

But you still won't get very far— Bitcoin's key strengthening takes 100ms per attempt on whatever computer you last changed the wallet pass-phrase on, with a minimum of 25,000 iterations (which was 100ms on 1.86 GHz pentium M).

Ten passwords per second per core is only attackable if you already basically know the password.

Hey, be careful.  You're spreading misinformation: The FSF still takes bitcoin https://my.fsf.org/donate/other/

I think this is a better point... make testnet self-reset once a month.  This will also reduce some of the incentives that people had for doing a lot of mining on it... e.g. amassing a lot of testcoin to sell to people.

Here is how I might do it... create a new genesis, include in it a bunch of testnet btc (10 million?) transferred to the fountain.

Have an extra testnet-only rule for the second block— which says that its timestamp can't be more than a month old. (obviously the normal 2 hour future check still applies).  Add a little code to punt the blocks and transactions when the expiration happens. (instead of trying to restore them to the chain)

(the fountain should mine a block every cycle and merge the input from that block before paying out any fountain coin in order to prevent people from replaying old fountain payouts on the reset— e.g. the fountain's initial bounty should only ever be spent combined with an input which will be lost on reset)

So then once a month, all on its own.. all of testnet would fork and begin again from block 1.

If this was done along with adjusting the target time from two weeks to two days (7x faster than bitcoin, who cares if there are lot of splits)... testnet would be a pretty good target for testing without being gratuitously different from bitcoin or attractive as an alt-chain for non-testing purposes.

This would also helpfully trigger deep deconfirmations of transactions— allowing people to test behavior which is otherwise tricky to test.