Huh? No. I'm saying the list was missing them (thus also 'at a minimum' since I don't know if there are other subforum specific badges)— I got asked by someone what the (B) symbol meant, and I had no where to point them because they're not included in the list here.

Wait.  I can get paid for our communities inability to keep from getting itself ripped off???

GPUs are dead for Bitcoin mining, they may be dead for scrypt in the not so distant future, but they're certainly dead for Bitcoin. Non-bitcoin threads are moved into the altcoin subforum already. I believe this is non-negotiable.

There is relatively little FPGA discussion these days. I'm not aware of any projects doing interesting miners on the latest generation (28nm) FPGAs. Regardless, I don't believe there is enough traffic for it.

I do think there is perhaps a point in having a subforum for experimentation, hardware design, etc. But we can create one later.

I've asked theymos to manually update the database to move all the threads here to hardware, and close the custom hardware form. I haven't heard back yet.

E.g.


and


In addition to the invoices in BTC that people received with the full refund text, which was only revised months after the sale to indicate that refunds would be of the USD amount at the time of the purchase.

Well, it's not a _ton_ but, I think it goes along with the WU/m being more consistent with 700GH/s than 400GH/s. It's probably doing dynamic clock control and it jumped up to 700GH/s at start but had a wad of errors and clocked itself back. At least thats my best guess.

Saved. So much for 700GH/s, 1.2TH/s or whatever numbers people were hoping for.

439.72GH/s  with 450watts at the wall.

Sadly, even ignoring all the unspecified details, this sort of scheme can't work simply because its too easy to pay fees via a backdoor.

E.g. I give the miner a transaction with zero fee, but a txout paying a key owned by the miner.  I give a different version to each miner.  Now they are not subject to your fee punishment.

I thought about doing something like that too. But then I did the math, and realized that it's basically no better than what antminers cost, and antminer's don't have the risk of doubling down on hashfast delays.

It's not a question of courage. It's a question of expected return.

A positive return from suing may seem unlikely to some, especially if you account for a non-trivial time and effort it would take to get there.

Consider:  If HashFast successfully retains the batch 1 Bitcoins the gain for them is approximately 15 million dollars (assuming 400 batch 1 units, I don't know the actual count) over being forced to refund.  This means that if spending 1.5 million dollars on defense gave them just a 10% chance of success, they'd come out ahead in spending it.

It's actually somewhat worse since they might as well spend up to the full amount fighting it, since it's probably already a fair multiple of the liquidation value of the company... it seems like that if they lose they'll have spent every cent they have on their way there, and so you'd get nothing but their intellectual property rights— which aren't worth _that_ much, as evidenced by the fact of there being quite a few other chipmakers.

You— a one or two or whatever device customer— are standing on the opposite side of that equation. If you win you're likely to get nothing because they'll have spent it all on defense, if you lose you'll lock in a >80% loss plus your legal expenses and time. At _best_ you break even, since they almost certainly couldn't afford a defense, and making batch 1 whole, and punatives.

Effectively, what you're asking for people to do is to double down on their losses for a small chance of recovery and a somewhat greater chance of making a point (and perhaps liberating an image ready design which is rapidly aging).

I think thats a lot to ask for, and I think hashfast is doing the same calculation too.  It's not that no one has any cojones, it's that HashFast has their customers by the cojones and HashFast knows it, otherwise they'd be trying to offer some olive branch at least. I assume the delay in making the statement that they were intending to renig on their original deal was because they hoped they could ship in time and avoid ever disclosing that they weren't going to make good on it, due to the resulting loss of goodwill.

HashFast has now announced they'll be missing their "guarantee date", and are attempting to renig on the above. Now customers must choose to lock in an 86% loss or lose all potential of refund:

I'm especially concerned about the 15 day refund window:


It sounds like they're saying you can choose— within 15 days— to lock in an 86% loss, or endure potentially perpetual additional delays or failures to deliver.

(WRT the trust ratings: Any of you can leave them ratings... I don't get why I'm the only one whos done it so far.)

The forum trust stuff has largely replaced the scammer tag.

I've gone ahead and and put in a negative rating for Simon Barber, and Hashfast itself.

Am I missing any other parties which acted as agents for hashfast and concretely promoted the belief that if hashfast failed to deliver they would refund the full amount paid?

[Edit: I've removed Cypherdoc because he claims to be a victim too. If I were going to down-rate everyone who in honest ignorance promoted something that turned out badly, I'd need to be down-rating a lot of people.  If the trust system had a softer way of making notes on traders I'd still whine, perhaps, but the full distrust is quite forceful]

There are tradeoffs here.

All of these deterministic wallets are based on schemes I originally promoted in one form or another, so I'm certainly no enemy to them. I mounted an unsuccessful effort in early 2011 to get buy in for changing. A lot of people were— and some still are— suspicious about deterministic schemes.

At the same time, key management is an essential part of the safe use of cryptographic systems.  Losing control of an old system or an old backup— say, after it ends up on ebay— should not result in you losing funds, and certainly not all your funds.  The use of non-deterministic keys automatically has some good key management properties. The problem is that it doesn't mesh well with backups.  Swinging 100% the other way to deterministic keys does well with backups, but so far the implementations I've seen have completely neglected key management. They effectively put all the eggs in one basket, which isn't good— especially systems which use the type-2 homomorphism exclusively as compromise of a single key potentially compromises all of them.

As with most things in engineering a middle path is probably best.... as also with most things in engineering, the first try is seldom the best.

In Bitcoin-Qt you can adjust the keypool size to better match your usage and backup patterns. This is— in my opinion— too much to ask of many users, so I'm not defending it as a good setup, but it's perhaps not quite as bad as you're thinking.

In my opinion an ideal system would support multiple independent master keys, precomputing the next one, and doing controlled transactions triggered by backups, according to user configurable retention policies... e.g. An example policy: once a month it adds a new master key which is initially unused, then after at least one month and four backups have passed it switches to using it (so the key has made it into at least four backups), funds which remain on keys which are over a year old are periodically swept onto new keys.  I think an ideal system would would also include things like an emergency key compromise panic buttons which would generate new keys, walk you through creating a new set of backups, and then migrate all the funds.

Yes, invented long ago by the Bitcoin core development team, and eagerly rushed to market by alternative implementations — potentially heedless of security considerations, design fragility, quality of specification, full spectrum of use cases, performance, implications of key management, compatibility, etc.

I'm super happy that people went out and built new and interesting things— and I intentionally decided to allow the patentablity window on the homorphic derivation scheme to close, because I concluded that paranoia over the patent would to more harm than the good that could be done by defensive licensing.

Your own software implements BIP32 as well, now— and while I cannot say you rushed... but please, if you're going to brag about some feature you have that Bitcoin-QT lacks, please don't pick one that Bitcoin-QT lacks because instead we were spending time building the feature for everyone else— including you— too. Your patches are welcome to Bitcoin-QT as well. Or does the collaboration only flow in one direction?

Is 50 BTC paying miners again? Have they generally made good on the funds they owe miners?

I'm asking because someone changed back https://en.bitcoin.it/wiki/Comparison_of_mining_pools  so that it no longer says all income is kept by the pool.

I couldn't figure out what this was. After someone else reported it I moved it out of the thread.

People have been successfully reversed and respent— many times in the case of unconfirmed transactions, but also in the cases of incidental reorgs and other events. Reports of bitcoin's demise may be exaggerated.

The new firmware works fantastically on P2Pool BTW.  The cpu load is still strangely high, but its no longer adversely increasing the mining latency.

I described a notion in #bitcoin-wizards a while back that I called "fail inflationary":

<@gmaxwell> So cryptocurrencies which "fail inflationary"... which is a property that things like USD has, if you print really good fake USD .. well everyone takes the cost. Not the person that accepted the fake USD, at least not if its sufficiently good.
<@gmaxwell> It would be totally plausable to make it so that if you get tricked by a recentl valid looking bitcoin fork, that both parties get paid. Thus moving the cost of such an attack to everyone holding bitcoin and not just the guy accepting it.

You could obviously do things like limit the amount of inflation created this way— perhaps in a first come first server exponentially declining way so that the ability to get compensated never runs out but is still finite...

The tricky part is how this could be constructed in a way where miners wouldn't just intentionally create forks in order to collect inflated coins.

If the parties immediately before and after you in the loop are conspiring (or sibyls) then they can always tell which inputs/outputs you added, so this is less private than some of the schemes proposed, in which N-2 malicious parties in an N way join cannot tell the 2 honest parties apart, for all N>2 (assuming you have underlying anonymous communication).

Your protocol sounds somewhat similar to a reencryption mix, except a reencryption mix doesn't need the chaff because the values are encrypted. A problem with using them for CJ is that protocols to prove faithful operation (e.g. to catch a party trying to break it) are computation and bandwidth intensive. One of their upsides (also— somewhat the case for yours) is that they are not so dependent on an underlying anonymity network (also the case for a MPC sort).

I think another potential issue in your protocol is that someone can just keep changing inputs/outputs forever to jam it, and you can't tell who is doing it (well, not anymore than you can tell who is who absent a jammer).

Interesting, it appears to me to be edited from the original version.