It was also sent to me in email after my first purchase too, after a couple days delay. If they sent it to him at the same time they sent it to him it would have been a long time after his purchase. But I accepted the agreement and later— after HF had continued to say they were on-time for a few more weeks— made another purchase.  I could probably also make Morici's argument— that October 20th was the only relevant date— for my first purchase... but I'm really trying to give hashfast every bit of slack: Business is hard. But being screwed over even after giving them the benefit of doubt on ambiguity about which terms were actually in effect stinks.

Sadly, if HF is run as incompetently as they appear to be there likely will be nothing to recover. Getting a larger fraction of what they owe me at the expense of causing a complete loss for people making purchases now (under newer, even crapper terms) doesn't really strike me as the right thing to do, at least personally. I don't fault other people for forcing hashfash to comply with the agreement though. The fault rests exclusively on hashfast if they drafted a contract of adhesion that they couldn't live up to themselves.

It has absolutely nothing to do with the appreciation of Bitcoin. Your company advertised an October 20th delivery, and claimed to be "on time" until just before you missed that target— now it seems like you were just committing fraud at that point considering you didn't even have the chips until months later. I paid you roughly 5x per GH/s what your competition was charging specifically because you assured me that by doing business with you I wouldn't end up with substantially fewer coins than I started with as a result of delays or failure on your part. You assured this in several layered ways, including a promise of a full refund in the case that you had massively failed to deliver— which turned out to be the case. That promise required holding or hedging and was worth a premium. Because of these assurances I took a risk in doing business with you, and even if you do ultimately make good on your contract I will still be at a significant loss in terms of time, stress, exposure to fraud risk from you, and loss of use of those funds for seven months.

I'm perfectly happy with the actual purchase I made— with the ink on the paper and the terms of the agreement. My only regret is that paper is nearly worthless when the counterpart is a con-artist. To emphasize this further, I'd also be happy to receive the hardware plus the Bitcoin it would have mined had you delivered it on your advertised date. That I haven't been demanding that instead is because it's somewhat more than the full refund which was my "only recourse" according to our agreement, unlike you I'm willing to stick to the actual agreement even when it's a loss to me. Hell, I was prepared to accept— according to our agreement— the hardware plus full MPP and what it would have mined starting on your massively late deadline date of December 31st, though that would be a loss to me. In my first certified letter I proposed an alternative negotiation which would have allowed you to refund me in additional hardware (with a formula for the amount based on when you sent it), specifically because if you did something massive stupid and didn't hold/hedge I didn't want to put you out of business— for the same reason that you're getting forum posts from me and not a process server banging on your door. I'm willing to negotiate and even consider alternatives that leave me somewhat worse off than our agreed terms, because I think business should result in mutually beneficial results. Sadly, you've ignored my letters. What I will not accept is taking a complete bath while _you_ take a windfall, in violation of our contract, nor will I accept a "settlement" that leaves me defrauded while prohibiting me from telling others.

Sure. Everyone expected you to comply with your promises and to have held or hedged the Bitcoins you collected in order to do so, the talk about investors certainly created that impression, and the very reason we asked about the refunds was specifically because of that case and the reason that we still purchased your hardware at 4-5x the cost per GH of your competition at the time was because of assurances like that.

It's a very easy scam that others are believed to have performed in the past: Collect a bunch of pre-order money. If BTC goes up a lot 'refund' a bunch of people USD. If it goes down, either go ahead and ship a product to everyone or try to refund in BTC.

The fact that you also forcefully "refunded" fractional amounts in USD denominated terms in violation of the contract to many early customers without them ever asking for a refund makes a lot of people believe you are engaging in this fraudulently behavior and that perhaps you company intended to do so all along.

There is no windfall here. I started with X Bitcoin. You sold me a machine to mine Bitcoin for those X Bitcoin scheduled for late october whos value you would almost certainly rapidly decrease and would have been rather close to only breaking even— mining back just X Bitcoin— if you shipped on time and would become worthless if you were late. Your contract allowed you to be up to two months late with no recourse, which would have made my purchase into a substantial loss. To prevent a total loss your contract guaranteed a cancellation and full refund if you were later than that. You were— shipping to apparently a fraction of customers three months after your advertised date and almost one month after your own self-set deadline.

Few sane would spend X bitcoins to purchase hardware which would only ever mine 0.1*X bitcoins, they certainly wouldn't do so at 5x the cost of the competition. Your company was abundantly clear on this and because of it some of us purchased, because while we saw how other companies exploited ambiguity we didn't expect to get ripped off by someone overtly violating their agreement.

Part of how you managed to gain sales originally was by convincing people your company understood the business of mining. It's ironic now how you insist on not understanding it— arguing that people should be happy to pay X bitcoin to buy hardware that earns a tiny fraction back when doing so is essential for your mindblowing claim that everyone's understanding all along was that you planned on refunding the full amount paid regardless of (and specifically due to) BTC price changes in the face of the fact that your founders and support staff clarified this point in the clearest possible terms several times in public and in private. Do you expect that people will want to buy your new mining boards from a company that now insists that it doesn't understand mining?

You sent me a check which was clearly labeled as a _settlement_ for about 10% of the value you owed me and contained a long list of burdensome conditions, such as that I couldn't tell other people how much you screwed me over. I don't believe I could ethical accept terms like that, nor should I especially for such an enormous loss.  You sold me a machine to mine bitcoin and then you failed to deliver. As a result I lost most of my purchase price— and at the moment all of my purchase price because you refuse to refund and instead  

You again prove that you're not actually reading the certified letters arriving, I have an attorney. I also have not complained to the state of California, though I suppose I probably should do that as well— especially now that you've made it clear with your consistent direct lying as you're doing here that you aren't operating your business in good faith.

I didn't unlock the thread. Your locking of it, however generated a number of moderator reports, so I presume someone did it.  SOP around here is that we do unlock threads when scamming vendors try to use locking to suppress people from discussing their fraud.

And please, you think I'm about to lift a finger to help you after you've fucked me over like this and behaved in such an unprofessional manner? The fact that I'm disinclined to apply the full power available to me against you should in no way be interpreted as suggesting that I think I owe you anything. I already gave you every kindness by attempting to resolve your default for three months in private before blasting you in public— attempts seem to have been completely ignored.  You always have the option of going away or convincing some other moderator who you haven't defrauded and deprived of 98 BTC. I've asked people to not repost the same stuff and to keep their posts related to their concerns that your new product (such as concerns that it will not be delivered or perform to specification based on your past and continuing dishonest and unethical business conduct), but beyond that as far as I'm concerned you can pound sand...

It was explained to you that it prevents shenanigans where the time is pushed against the rail and a trouble making minority makes the network unreliable. This is doubly true when you start to consider nlocktime.  Perhaps you don't care— people often don't care when it comes to other people's security— but at the same time it doesn't actually buy you anything either: If you want a monotonized timestamp just filter the existing one with max(current,last_filtered_value).

So, just to be completely clear— You are, in fact, refusing to refund my payment?

I want to be complete clear on this because you have ignored every certified letter I (and apparently other people have sent you) and you seem to also be saying that you already have— which is entirely untrue. You have not refunded me in any way shape or form, the only response I've received from you at all has been the taunting, insults, and deletion notices here— plus some crazy settlement for a fraction of what I'm out due to your incompetent or deceptive business practices: I am beginning to lean towards deceptive considering your apparent complete lack of interest in seeking a mutually agreeable resolution.

You continue to have an obligation according to our contract to refund my payment after your failure to deliver by the very lenient deadline which you specified. You have ignored all my private efforts to resolve the matter and not responded to any of my communication except here in public. Obviously very few people are going to do business with you with you screwing over people like this. You've claimed that your new pre-orders were flying off the virtual shelves— and maybe there really are enough suckers out there— but I'd guess if you actually were selling product you'd actually be able to make more deliveries and refund some of the people you've screwed over and left completely in the lurch.

Some of the most efficient constructions available now for proving arbitrary programs in zero-knowledge are only secure in the CRS model— in English: They require a trusted initialization step where someone has to generate some magical numbers and if they cheat (e.g. by keeping the initial randomness) they can produce false proofs.

Systems with these properties are found in some of the papers at http://www.scipr-lab.org/ and in http://research.microsoft.com/apps/pubs/default.aspx?id=180286, both of which are currently using systems based on the GGPR'12 cryptosystem. They have really awesome performance, though— fast enough to actually be feasible to use on the prover, and almost as verification in a couple milliseconds with a few hundred bytes for the proof regardless of the size of the program being proven or how long it takes to run. But the requirement of a trusted initialization is unacceptable for some applications.  Ultimately we'll want systems which do not depend on the trusted initialization but they're less far along in development and may never be quite as efficient.

Some things we'd like to use these proofs systems for is a more powerful and efficient replacement for Bitcoin script. Instead of every node verifying your fancy script, instead the party creating the transaction runs the script themselves and provides the network with an efficient proof that you ran it faithfully and that it accepted. This avoids network load as being a disincentive to using fancy scripts and also has privacy advantages.

For example, say I want to pay you conditional on you publishing a solution to a— say— Sudoku puzzle. A script running under an efficient proof of knowledge system could verify an encrypted solution, and because it's zero-knowledge miners couldn't come along and replace the outputs like in a plain hash-locked transaction. You could use a CRS snark here where the payer computes the trusted initialization and then the payee cannot cheat— but the fact that the payer initialized it means the payer could double-spend race the redemption and get both the solution and their coin back.

There are a couple of ways of solving this, but I wanted to mention another one which is especially general:

In a two-party trade, just have both parties compute their own trusted initiations, then require the script provide proofs under each of them. Then so long as one side isn't cheating the transaction will behave faithfully.

This can be further optimized by instead requiring Person_A_snark&&Person_B_ECDSA_sig || Person_B_snark&&Person_A_ECDSA_sig... Cross signing using ECDSA is more efficient since the snark proofs are larger (and much slower to compute) than ECDSA signature, and this equally achieves the goal of not allowing either party to take advantage of a trapdoor.  (in particular, if you use hash compression to avoid ever even bothering to publish the verifier public keys for the untaken branches).

The same approach can be extended to more than two parties though the efficiency becomes less impressive (e.g. the prover must run the proof N-1 times to handle any party possibly conspiring with them, or N/2 if you only want a honest majority security) and sadly, it doesn't really work for broadcast payment sorts of application.

Offered and paid out?  What are you talking about? You have absolutely not refunded me. I wish it were so, I certainly do not enjoy the current state of affairs.

The "Virus total" results mean less than nothing: They never report custom wallet stealers and couldn't be expected to do so. The fact that you keep pointing to them when you should know better yourself is very suspicious.

You should never run non open-source Bitcoin software, you should never run binaries of Bitcoin software that you or someone yourself can't verify matches the publicly audited source.

There is no particular need to use a wallet specific tool, there are many open steganography applications: http://freecode.com/search?q=steganography&submit=Search

There isn't a chance in hell that I'd run this.

We had an explicit contract. The contract specified how this would be handled. This understanding was also directly confirmed with your staff.  Had Bitcoin went to $1 I would join with you in telling people under that contract who were looking for the USD price to stuff it.   My appreciation for your concern about buyers remorse is why I found the Dec 31st deadline acceptable in light of the Oct 20th advertised ship date— you didn't want the risk of people selectively canceling hardware based on how the recent price movements went.

There is no "windfall" involved here. You committed to specific terms, ones which were necessary at the prices your were charging to make your products commercially interesting. As your own founders had pointed out: You were selling a device to mine Bitcoin. If it mines less bitcoin then it costs then it is not a good buy. The construction of your contract was the only way to assure that your product wouldn't be a _massive_ loss for its buyers in the event that you failed to live up to your delivery promises, as you did. It was furthermore reasonable in light of your claims of using investor funds to finance your operation, as you could secure yourself against the risk while locking in the sales by simply setting the funds aside.

You still have not answered my questions— Do you or do you not intend to honor your clearly established contract with me with requires you to refund the Bitcoin paid?   You have still not responded to any of my certified letters.

I, and many other people, did not pay you via Bitpay.  I specifically raised the issue of some past vendors apparently taking funds waiting for the price of Bitcoin to rise and then "refunding" the past USD value (or otherwise, if the price did not rise— acquiring product) and was assured that hashfast would protect against this, a commitment which was later supported in HF's contract, and public communications by your representatives here.

This and other now apparently empty commitments like an October delivery and actually useful MPP made HashFast's 4-5x high price per GH than CoinTerra's still seem remotely competitive.  Without these representations I (and I assume many others) would not have purchased at all and certainly not at your prices, so much so that people sought out to double and triple confirm them directly with your staff and founders.  Considering your claims (backed up by documents filed with the state) of being funded by investors and not pre-orders the prospect of you holding coins (or other methods of hedging) to make good on refund promises seemed completely realistic.

The specific coins I paid you ended up at https://blockchain.info/address/1KFrqkEGy6Yq7X4SYCbYoj8HEwfbWVUDJ9 which is not under Bitpay's control.

Not that I've observed. I don't have a power meter specifically on that unit, and guessing from my aggregate load it may have decreased it if anything. Probably better to ask someone with a big farm of them however.  As you can see in that graph, it didn't adversely impact latency at least (DOA rate of 1.2% pretty consistently).

Otherwise a minority of miners could trivially force the timestamps maximally far in the future... which then pushes everyone up against the local time limit, and would potentially require a centeralized source of time to avoid being constantly orphaned.

A public service announcement on the CT boxes: 

Make sure you're running the latest firmware. I don't think I need to point out where I installed the new firmware here:

No.  You author a transaction and move a partially completed transaction, which is just non-private data, around. You do not collect all the private data in one place as that would defeat the point.

You cannot sign without putting all your key parts in one place. If that one place is compromised they will be stolen or subverted to sign a different transaction. If that place is completely secure you can just put a single key there and dispense with the fancy footwork.

Actually I think they're fine for this without the UFOs, I only brought them up because you were insisting things that were add odds with their e
Appears you are saying that as a participant when I provide my input, I also specify the amount of my output?

Derp. Your output is equal to your input. Privacy comes from equalizing amounts.

It's relatively easy to do with schnorr signatures.  It would be a major advance to be able to do this with ECDSA.

I've not worked through the protocol presented here yet... but if it is indeed secure it will also be a major advance.  In CoinSwap there is shown a method where any two party fancy scripted transaction can be made indistinguishable from a 2-of-2 multisig, assuming the transacting parties are honest (if someone cheats the transaction loses its indistinguishably). So the anonymity set of these transactions is the set of 2-of-2 multisig transactions. I'd previously lamented that in schorr signatures single key 2-of-2 is utterly trivial, and these could have an anonymity set of all transactions.

Though it's too early to deploy, I recommend coming up with a patch for libsecp256k1 to do these 2-of-2 key agreement and signing.

Eventually, after the transaction is formed according to the blind signatures.
At the point they sign the transaction they know the outputs (or else the transaction wouldn't yet exist).

Zerocoin itself was already not realistic inside Bitcoin due (among other reasons) to the large transaction that you have to put into the blockchain. UFOs make them larger by a small multiple. Sending a few extra tens of KB outside of Bitcoin probably isn't an issue.
WTF?! Like in everything else you use a cryptographically strong PRNG which holds as long as some underlying hash function holds, and if the hash function is distinguishable with unknown inputs from a random oracle you're already hosed in every other protocol (including your DSA signatures).
Yes? and so what? First— I note that you're continuing to waste time discussing the more complicated ZC thing when that wasn't what I was speaking about and do not recommend people implement (I noted it as a possibility for those were excited about ZC to find a potential application for the technology). Secondly— who cares if maybe someone kept a trapdoor and could just DOS attack? If you were really worried about that case you can just keep around a couple parameter sets, track how often you fail in each case and prefer ones where you've never been dos attacked (with the users taking a majority decision or something like that).

I did no such thing. Your frequent misrepresentation in discussion makes it very difficult to justify continuing to respond to you.

Great. If the DOS attack occurs during the blind signing of the output tokens then everything is totally trivial then. Since every inputting user is required to blind sign everyone else output token, if they don't— you know who's jamming the process and you ban them.

Here is an overview of all the places a user could refuse to participate further:

(0) If a user refuses to sign an initial introduction message that specifies their input and their blinded output (and other parameters like blind signing keys to be used), then they're just not participating as producing that message is how they join in.

(1) If a user refuses to sign the blinded outputs of all the other users their inputs are blacklisted as the blind signing of everyone's output tokens is not anonymous (relative to inputs).

(2) If a user (now reconnected anonymously relative to inputs) refuses to reveal their unblinded outputs, this attempt is aborted, all honest users reveal their blinding factors and withholder is deanonymized and their inputs banned.

If we've made it this far we have a set of outputs which were provably created by the people who created the inputs, though we don't know the correspondence. We can form a transaction and know that the transaction matches their wishes. So we do.

(3) If any input does not sign for the resulting transaction we blacklist them because we know the transaction is accurate at this point.

I really cannot understand why you find this difficult to understand.

The input is identified by the fact that it fails to sign a provably valid transaction.

...by the fact that they fail to sign.

You're now quoting from a different approach. I listed several. The one which I specifically identified in our discussion here used plain chaum blinded signature. (The others should work fine too— but if you mix things up its hard to have a coherent discussion)

ZC initialized with an RSA UFO has no trusted initialization, in fact— they make the updates much larger but thats harmless for data not going in the blockchain. Additionally if you do use the efficient trusted initialization the ZC accumulator approach still has perfect zero knoweldge. Compromise of the state allows someone to make false proofs (dos attacks in this context).   Though these points are not terribly relevant because I wasn't talking about the ZC approach.

Because they refuse to sign the transaction. Everyone knows that all the outputs provided in the transaction were the unique outputs provided by the inputting parties (because they have been signed by all participants). So they all know the transaction is valid.

(of course, if it fails before you finish the unblinding, — you explain below how thats handled)

You've apparently not done much research at all, as you are not aware of RSA UFOs (which are described in some of the very first papers about those sorts of accumulators), you are not aware of non-trapdoor NIZK (e.g. fiat-shamir/random oracle only), and ... apparently you're not aware of anything as simple as a blind signature.

I'm glad you agree that the case where the protocol fails before all the blind signatures are collected is easily resolved. If it fails after transaction signing has begun, then—because the blind signatures assure everyone that the transaction was correct— you know the non-signer is the adversary.