Morici v Hashfast Technologies
Case5:14-cv-00087

http://198.27.67.106/hashfast.pdf

[quote author=dogjunior link=topic=392860.msg4370599#msg4370599 date=1389119660
It's called game theory. The more you can convince people not to buy miners with the genesis block the slower difficulty goes up. Those that have miners make more BTC and they tell you to buy BTC instead which then drives prices up.
[/quote]Thats certainly not my motivation, enough to the point that I put my money where my mouth is offering to sell the income stream from some of the overpriced hardware: https://bitcointalk.org/index.php?topic=395243.0

I might be willing to sell the income of an antminer for 3 BTC, though the ships-now is more attractive.

Making it expensive to create identities directly undermines the goal of having mining not controlled by particular parties. Moreover, any such scheme has some optimal strategy where the cost of identities vs exclusion are counter balanced, and in general complicated strategy favors larger parties (who can afford to figure out and implement the strategy). Also even if you had a perfect identity scheme (which could trivially be used to impose external control by ordering the identity holders to do things, but we'll ignore that) it wouldn't work because parties could permit others to use their identity.  (E.g. to mine at this pool you must obtain an identity and allow the pool to use it).

In any case, it's hard to comment with more than these sorts of arm-waving generalities against a proposal which is itself an arm-waving generality.

Please take the time to concretely work out how to intend to issue and manage these identities, and what effect(s) you have them to have before asking other people to spend time considering your idea. Otherwise any reviewers time investment is unboudned as you can continually reveal previously undisclosed features which patch over their concerns one by one.
 

Many people have spent large amounts of time looking at far more mining data than you have available. (e.g. hundreds of gigabytes of shares) and have not found anything terribly useful.

Because the distribution of input data is not believed to matter miners do all sorts of things which bias their inputs e.g. increment starting at zero or only sweep part of the nonce range, etc. which can serve to create apparent after the fact biases which aren't real and can be hard to sort out.

The fact early termination winnowing would be useful if available isn't lost on anyone— its an oft cited reason why $otherfunction wouldn't make a good POW. (E.g. you can rapidly tell trivial 3sat problems from potentially hard ones, so you grind the problem generator and then use a fast solver for trivial problems). Many (most?) miners make use of the fact that you can terminate sha256 a couple rounds early with the h==0 constraint.

If you've found something that lets you mine faster— congrats. I look forward to hearing about your major mining income or reading your paper.

Good luck.

Please don't bump many months old threads with new posts that are only partially related. The prior post was about using the fact that (rarely, sadly) the public key is not known, but only its hash to provide some recovery in the event of a serious advance in ECDSA.

You're asking how a Guy Fawkes signature would work generally.

By itself, this kind of scheme has significant problems with denial of service attacks. Potentially you could invoke POW to help, but doing so likely just shifts around the denial of service problems.

If you're actually just looking for hash based alternatives for signing, what you want is a lamport signature. Also note that if you mine a lamport signature but tree-structure the transaction so that you can prune the bulk of the signature the long term result left in the chain is the same as a Guy Fawkes signature... but you have instant verifiability, greatly simplifying the DOS situation.

Separately, it's possible to instead use a zero knoweldge signature of knowledge to prove you know the pre-image of a hash without revealing it. But all the schemes for this that I know of which have proof size competitive with a lamport signature also require asymmetric cryptographic constructs which might fall based on the same compromise as ECDSA.

The criteria to include a transaction?  It has to satisfy the rules specified in the scriptPubKeys in the coins that it is spending. There is no way for a past scriptpubkey to impose constraints on future script pubkeys (doing so can have some pretty negative results if used poorly), so I don't believe there is any straightforward way to implement a Guy Fawkes signature in Bitcoin without at least soft-forking changes to the protocol... but that no loss without a way to prevent DOS.

Except that, in practice, it has a lower empirical orphan rate. The design currently has a communications advantage.

The smallest mining device that I'm aware of that you can currently buy which is within a factor of ten of the best $/GH devices (e.g. remotely competitive at all) costs about $2000.  Why is a ~$2 bottom of the end cellphone/stb microprocessor your target device for controlling thousands of dollars of hardware? Doesn't this seem more than a little ridiculous?  Especially when the consequence is an abdication of control which undermines the security assumptions of the Bitcoin system and which— if exploited— could leave your hardware and the Bitcoin previously produced by it worthless?

 

Agreed.

While the buff shots are sure to get many hearts pounding— considering how quickly forum members seem to fixate on the personal lives of people they're irritated with, the only fucking this thread should be about should be the metaphorical fucking related to failed promises and non-shipped mining hardware.

Can the tabloid stuff move out of this thread unless it has a direct relevance to recovery for customers?  Being superficially interesting isn't enough. Knowing people's real names is but the rest, not so much.

Thanks.

It would be almost trivial to implement— just bundle it, if nothing else. But I suspect the ship has already sailed for this.

We now have miners with hundreds of thousands of dollars of equipment which run it off a raspberry pi. Who send their coins directly to coinbase to be sold. Who have never used a Bitcoin client of any kind (except for the coinbase webwallet), certainly not a full node, and they have no concept of why they'd want to.  The name they trust most in mining is operator of their chosen pool— who could be robbing them blind, but maybe isn't— who has a financial interest to the tune of— say— >$700,000/month in keeping miners on their pool, and who tells them they don't need to worry about things, and who is believed because far too many people— including you— overly fixate on "51%" and ignore the fact that someone who controls 25% hashpower can reorg 6 confirms with 5% success or 2 with 31% success.

Never mind that the question of parties with large hashpower using it to harm other Bitcoin users is not hypothetical, as its recently been done— achieved huge profits in the process— and seems to have resulted in no negative consequences for the involved pool, just a lot of victim blaming, and some months delayed promises that the responsible parties have been sacked.

Perhaps many miners could be moved to running something p2pool like if doing so was easy, but just running a Bitcoin node is no longer so easy that it can be treated as costless, with now gigabytes of space wasted by pointless dust-scale messaging transactions. Transactions that the Bitcoin users didn't care about because they weren't running nodes and because many people had a monetary interest in being able to wastefully use the systems resources in that manner.

In any case, I don't think the problems you're facing are technical. The problem is that participants in the system don't know or care. I think the problem is also that to some extent people who should know better are not paying attention to the mining ecosystem and don't realize what a mess things are, and some who do are tempering their statements because saying "Hey everyone, the Bitcoin security assumptions are basically invalid in the current environment" too loudly may be adverse to the value of their holdings.

If you can figure how to educate people on the subject in a world where people have multimillion dollar a year income streams that depend on hashers not being educated and while other people own hundreds of millions of dollars of Bitcoin whos value might be eroded if the concerns become too wide spread— then I think progress could be made. Otherwise?  ::shrugs::

[I don't even intend to suggest intentional misconduct due to the monetary interest, only: "It is difficult to get a man to understand something when his salary depends upon his not understanding it."]

Mod note: I removed a number of posts just repetitively ask "Where is our hardware?", and a number of posts contemplating the uselessness of these questions. Clearly asking it here isn't getting anywhere. I suggest you direct those questions directly to hashfast— and maybe just provide a weekly summary here on your (non-)progress, if that.

Posting multiple times purely to express your displeasure just makes the thread harder to follow for someone trying to extract useful information from it. If you're not going to add anything that other people would find useful in either evaluating the hardware or trying to not get screwed over their purchase of the hardware, at least confine yourself to a single post. Thanks.

But the pedantry doesn't extend to correcting $/GH? Or do your miners only perform a fixed number of hash operations during their lives?

My bet is based on an expected return on mining. The exchange rate only really matters here in that it changes how much you pay me. E.g. say I expect the device to produce 2 BTC if so obviously I'm not going to offer it to you on terms where you only give me 2BTC.   I solved it for the 8 BTC number, I need to go generalize my software to sweep the exchange rates, to come up with the other parameters. Gimme a day.

It doesn't need to be added to the protocol, thats part of the point.

If instead you mean the integrated Bitcoin-qt wallet, Wumpus and I have both commented that we'd like to see it there. I'd like to see more external implementation done first.  Inside the wallet is good for getting users, but it's not good for protocol R&D.

I also face-palm when I agree with someone and say 'yea right, and don't you also hate it when' and they think I'm saying they're doing it.  I'm not. The fact that bitfury is more efficient at 55nm is a concrete example of why bragging about 28nm is silly.

Alice participates in some web-of-trustish rating community (like #bitcoin-otc or the forum trust ratings) and would like to borrow money from people but generally wants to keep her trading practices private. People would like to loan her money, but don't want the _aggregate_ amount of loans  she has taken across all parties to exceed some risk tolerance threshold. The risk management could be solved by Alice publishing all her loans (and with the lenders making sure theirs show up in the list) but this isn't private.

I propose:

As Alice accepts loans she forms messages like "[lender_onetime_pubkey, nonce/H(terms), amount]" and stores it in a binary hash tree augmented with some of child amounts in the interior nodes, but with the total amount omitted from the root node.

At first the accumulator tree starts off empty, then Alice can add loans, and every time she adds a loan she executes the update inside a publicly verifiable zero-knowledge proof system.   She publishes in the public rating system the final root hash, along with the proof that it was a valid update according to the rules.

No one learns anything about Alices' loans except a upper bound on how many she has (and if batch updating is allowed, maybe not even an upper bound).

When someone wants to make a loan but is concerned that Alice is too risky, they ask Alice to create a proof that the balance of her accumulator tree is less than some amount (a fairly compact proof task, since it's only a test of part of preimage of a hash). They would learn nothing other than the binary result of the test.

When someone makes her a new loan, they ask her to provide a proof that she's updated her tree to include it. (This can be a side effect of the update process if it yields a list of H( added [lenderpubkey, nonce/H(terms), amount])).

When a loan is closed, she produces a proof of correctly removing the a loan, and the proof includes a list of pubkeys for which have been removed. The proof isn't considered valid by anyone, however, unless it comes with signatures by the pubkeys which have been removed. (this keeps ECDSA validation out of the zero knoweldge proof).

This kinda of system could be further extended to do things like track loan terms and dates.  E.g. "Prove you have no past due loans".  Though ideally queries that only touch log(n) nodes are going to result in more efficient proofs.

If loans can be satisfied by Bitcoin transactions, e.g. "payment of X to address Y; nonce" these terms could be hashed and included in the loan entry. This would allow Alice to remove loans from the list without the lender's help. Then after satisfying the loan Alice could produce a removal proof which reveals the hashed terms for the loan being removed, and along side it Alice could go collect a SPV proof from the bitcoin network,  "At least 6 blocks blockhash 0xdeadbeef the terms with hash X are satisfied"... and the peers in the reputation network will accept the pair of proofs so long as block 0xdeadbeef is in the current blockchain.

Something similar could be done to prevent fake lenders from tricking Alice into adding in loans they don't make good on. (e.g. put a specification for the loan payment in the entry, and allow alice to back out loans that were not paid by some deadline)... except that a compact proof of non-payment is not possible. So instead you'd want Alice to prove that a transaction spending a particular coin wasn't the right one agreed in the loan, or that the particular coin was unspent (which needs a utxo proof).

Since all of this requires proofs only over hashes, addition, and comparisons the proofs should be _feasible_ with currently described state of the art techniques, at least no less than any real application is.

Lately I've been assuming 2%/day hashrate growth, which is actually low compared to what we've seen over the last 6 months.

Yes, I did— or at least substantially. This is the norm in electronics manufacture, thats what investors are for, normally you don't have the customers funds before your design is done and manufactured. Pre-orders are unusual. Even in custom one off manufacture in the commercial market not only is payment normally provided _at delivery_ but goods are often invoiced net-30, so you won't get paid until sometime after delivery of the product.

Besides, you can factor out the exchange rate noise, just assume that the exchange rate was constant. In (some/most/all) states you are legally obligated to provide full refunds for pre-orders with fairly short notice on late delivery, and— obviously— in all states you are required to refund customers if you don't ship a product.  So they wouldn't have been able to meet even the most conventional of obligations, in the worst case (e.g. their design failed) if they'd been spending the pre-order funds to fund design and manufacturing.

In the mining space pre-order lets a maker lock in outsized prices and deny business to the competition by locking up the customers funds early. It might also be used to fund development and manufacture but if so, thats very risky, and may create all kind of adverse exposure for the business. Better to get investors with clearly established rights and obligations.

It's easier once you do the math and realize that at current prices most devices for sale are very likely to produce less BTC than they cost.

If you're looking to walk away with fewer BTC than you started with, I'm pretty sure I could sell you a little box with fans and blinkenlights for an amazing price.

I facepalm just a little bit every time I see someone brag that KNC was the first to 28nm. (hell, if you're going to be that liberal: there were people running on 28nm _FPGAs_ a LONG time before KNC shipped )

I believe(d) their employees and R&D were paid by funds from their investors.

HashFast's prices were far too high to have justified participation as a investomer if that had been what they had said they were doing. At announcement the devices were selling at prices below to what you would have expected their lifetime income would have been for an time delivery assuming 2%/day hashrate growth (actual: 2.3%/day since mid august), and they were only redeemed up to break even by the MPP.  For the customer deal had fairly little upside under likely assumptions, and was only worth taking because it also had only moderate little downside potential if they adhered to their contract.

(Worst case assuming they didn't break their agreement would have been delivering on Dec 31st with the high growth, as we had.)

Sure they could, they just needed a party to guarantee a floor value of their Bitcoin held, and they only needed enough of that to guarantee their parts costs and the minimum necessary margin (e.g. they didn't need to insure the whole amount). This is a service many large Bitcoin traders/holders would have been willing to provide for a fee. Also keep in mind that a refund still leaves them with the hardware and there is a tremendous demand for mining equipment. HashFast has been selling units for later delivery all through December.

Because the refunds were not payable until more than two months after their advertised target date— I'd personally assumed the reason for the mismatch between the target date and the guarantee date was to reduce the risk of revenue loss and a need to refill the order pipeline after a ordinarily late shipment triggered refunds.

AFAIK we don't issue them anymore.

Once negatively rated by people in the default trust list, hashfast's posts will have a red warning next to them by people using the default trust list. It should be there already, in fact— is it not?

They claimed that they wouldn't be using pre-orders to fund development, what they actually did is anyone's guess— much of the coin they'd been paid had apparently not been moved when people were investigating this a week ago.

It's certainly possible, even likely, that they spent some portion of it to cover the actual manufacturing— but we wouldn't know when. Though assuming their hardware works those costs should be amply recoverable.