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.

No, instead they prevent you from doing that in the first place.

E.g. in the blinded example: When you provide your inputs everyone sees your values, and you specify "this is a blinded X btc output" and they all sign that output with a key which corresponds to X btc, and obviously refuse to do so if your input isn't at least X.  Later you reveal your output, and they know its value by which keys signed it.

This isn't to say that implementing any of this is interesting. The state machine to achieve success in all cases ends up very complicated. (This is also why I think that blinded but quasi-centeralized e.g. where a semi trusted party coordinates are probably more interesting for initial deployment).

You are asserting it, (over and over again) but it doesn't make it true. It was explained in adequate detail previously enough for other people to understand it and implement tools that address it.

It's actually not, since it's not actually possible in the Bitcoin protocol to do what (it sounds like) you're describing, but more importantly performing the operation in that order defeats the anti-dos. If you lead with the inputs they provide a trivial anti-dos mechanism.

Because they fail to sign. There is no need to identify them beyond identifying their input coins to achieve rate limiting, and no need to identify the input/output correspondence.

I'll repeat it, since maybe other people are having problems following the link:

An example (using the blind signature approach, simplified for equal values) is that each participant cryptographically blinds their desired output, and then signs their blinded output using the keys from their intended inputs.  They then present to the group their inputs (and assuming those inputs are not black-listed) everyone in the group blind-signs each of the outputs. Then everyone connects again with new connections (e.g. a new circuit in tor) and presents their unblinded outputs and their signatures. Now everyone knows that all of the provided outputs were from authorized parties— but not the correspondence. The transaction is composed and— back on their original connections— they all sign. If someone doesn't sign, it means they're jamming the process, everyone blacklists theirs inputs and automatically restarts.  The network naturally rate limits them via the finite supply of available outputs.  (of course, if you want you can attack other valuable identities to the first step, like coin burning or what have you, if the natural network rate limit isn't enough).

This is just one example of a way to address this. There are several other ones possible— and discussed early on in this thread.  Other ones include publishing commitments and then if the process fails having everyone reveal their intended outputs (which they then discard and never use) in order to avoid being banned, or using an anonymous accumulator instead of blind signing to control access.

I boggle that they'd even sell a single unit.

Sold out?

While I am sad for the new bag holders, I'm happy because that means you'll be paying the refunds you owe people and shipping the months delayed products.

Right?

Sadly, XKCD's explanation is simple to the point of being deceptive— it's caused a lot of terrible misunderstanding.

True randomness is absolutely essential to password security. If there is enough, your key is secure— if there isn't it may not be.  It doesn't matter from a security perspective if that randomness is used to pick letters or whole words, so long as enough goes into it. If you'd find words easier to deal with— then great do that.

But there must be enough and, sadly, the example that XKCD gives is targeted around things like website passwords where very high speed attacks are infeasible, and where a multi-target speedup (e.g. from an unsalted password) is unavailable.  For an offline attack scenario where an attacker can have an effective attack speed of a billion attempts per second— or more— the strength discussed on XKCD would fail in a day or two.

A lot of people read the comic and completely miss the point of randomness being essential and just the form of its expression being irrelevant, and so they think any random human generated string is acceptable "'duck spatula stapler outlet', that's totally random!" when in fact it is in grave danger of being compromised by attackers with powerful statistical models for human generated passwords.

AnonMint, Every post you've made here has been error and confusion.

The very first post in the thread points out that decentralized versions take more work because of the anti-DOS proofing. A couple posts down I give some examples of how it can be done.

You're presuming a broken model that I don't believe anyone here has ever suggested. You'd always being the protocol by specifying the inputs in which you intend to sign. Signature authority over inputs is the principle scarcity that allows you to may the system dos-attack resistant. After the inputs are signed, outputs can be specified in a cheat proof way, and then the only avenue for disruption is refusing to sign which can be addressed by blacklisting your inputs (and other rate limiting tokens) and restarting.

Also keep in mind that when you post in the HF self-moderated thread it bumps it to the top again at least until they delete your post. Doing that keeps their distorted reality more visible than these other threads that are showing people whats missing.  If you're posting something critical in the HF thread: it _will_ be deleted, you might as well at least post it in parallel in the relevant other threads.

(Because of the high rate of deletions in that thread I recommend you post nothing in there at all— but if you feel you must, I don't see a reason to hold the duplication against you: most posts in that thread are deleted.. so just go ahead and simulpost when you post there.)

Also if you ignore hashfast-cl it will make their posts show up small and greyed out for you on the list, so it'll be less distracting. You can still click show to look at their posts at it if you want though... I recommend it if you find them irritating.

P2Pool is trivial to setup and just becomes solo mining if the pooling part doesn't work for some reason (like a broken escalator becomes stairs), and it's already what everyone should be using.

...Not that setting up solo mining is hard.

But really, if you're going to bump this discouragingly stupid thread, at least have a reason for it.

Just an update: HashFast has still not refunded the 97.95849881 they owe me after taking my funds and failing to deliver by the refund or die they which they chose, nor do I believe they've refunded or sent products to many other customers.

They have also still not responded to a single one of my certified letters. They have no confirmed with me if they will or won't make good on their explicit commitment to refund the full amount I paid— even though its now more than three months since they violated their agreement.

They also continue to aggressively delete all critical comments or concerned views from their self-moderated thread promoting their latest pre-order product. These deletions include deleting messages where they claim to have sent me a refund— which they have not— and where I respond pointing out that they have not done so.