In hindsight... a better MPP would be to refund the miners any difference between the cost of the original system and what it would have mined in 90 days (in BTC of course). I think many would have preferred that to more hashpower later.
Absolutely. I suggested this to HF back in August but unfortunately they went with MPP instead. Remember the purpose of MPP was to protect against excessive hash rate increases, not delays. Orders are taken in BTC, in the unlikely event we get to refunds they will be given in BTC.
This is a step in the right direction. If you really want to do it right you should provide customer protection by providing refunds based on missed opportunity cost. For example: - HashFast promises to ship on October 30.
- Customer paid ~60 BTC for a pre-order unit.
- Customer registers a refund BTC address at the hashfast.com site.
- For every day HashFast misses their target shipping date, a partial automatic refund will be made based on what a 400 GH/s unit would have mined at the difficulty at that date.
- This would continue until either the refund is complete or the unit is delivered.
This would: - Prevent a BFL-type pitchfork scenario and alleviate worries that HashFast might be hashing with customer hardware at customers expense.
- Give customers peace of mind; At worst they would have provided a free BTC loan to HashFast. At best they get a unit that has already started making some ROI before delivery.
- Provide a strong incentive for HashFast to deliver on time.
(Note that I made this suggestion before they added the December 31 'guaranteed delivery date' to their ToS.) |
|
|
|
|
There is enough blame to pass around for everybody. Merry Xmas!
|
|
|
|
BFL was 6 months late, not 1 year, unless the calendar has changed in the past 2000 years or so? November - April = 6 months, not 12 months.
True, but the total wait for BFL customers was well over a year for many. I ordered my LS on 6/24/2012 and it was finally shipped to me on 7/9/2013. Needless to say, I have not even made 50% of my BTC back at this point. Now I mine little over 1 (bit)cent per day so I have accepted my losses. At this point my HF BJ is expected to do even worse. Needless to say, I'm done with pre-orders. |
|
|
|
We need some way to discourage overclockers from toasting their chips.
Especially since the chip runs @ 76 degrees *underclocked* according to HF. Combine that with their warranty statement on ambient operating temperature: Hashfast shall have no obligations for breach of warranty if the alleged defect or non-conformance is found to have occurred as a result of operation in an ambient temperature other than 5-22 degrees Celsius Also goes to show how much trust they put in their own thermal throttling system built into the chip: Die has built in thermal controls that allow the chip to pushed to the edge without damaging cores. |
|
|
|
The signal to noise ratio here is astounding  There is no signal at all, and it's not our fault. You and the trolls like you are the explicit example of who's fault it is. Nice job of 'blame the victim'. You can pat yourself on the back. HF put their customers in a Catch 22 situation. Eat an ~80% loss on your BTC with either a 1) USD refund or 2) hopelessly delayed HW. There is no happy ending here so customers are understandably frustrated. HF silence at this critical time is not helping, nor are their frequent TOS updates that shift risk & losses from HF to the customers. |
|
|
|
THIS: I personally will NOT accept delivery past december 31.. and will ask for my 210btc's back at Jan 01, 2014 0001H
So what will you do when instead they give you USD back at the BTC exchange rate (settled in USD) during the time of the purchase? This issue has been beat to death.... if paid directly to HF wallet for batch 1 customers.. refunds are in btc. I would not have ordered from them if this was not the case.. i learned all too well from the june2012 BFL order.. (or maybe i didn't learn so well  ) Can you please point me to the post where a HF representative explained that users that paid BTC to their direct wallet will be treated differently from customers that paid BTC to their BitPay wallet when it comes to refunds? I must have missed that. |
|
|
|
THIS: I personally will NOT accept delivery past december 31.. and will ask for my 210btc's back at Jan 01, 2014 0001H
So what will you do when instead they give you USD back at the BTC exchange rate (settled in USD) during the time of the purchase? |
|
|
|
What happens if the unit is shipped before the deadline but arrives after (Jan 1st). Can we decline delivery and request a full refund? What happens if we accept the delivery past the deadline? Would that automatically finalize the sale and waive our right to request a full refund? Is there clarity as to what a 'full refund' means to a Batch 1 customer at this point? I know that HF added a clause to their ToS recently that states they will only do refunds in USD and treat any BTC payment as paid in USD at the time of the transaction: REFUNDS. Any refunds due to Buyer will be made in United States Dollars, and for the purposes of calculating refunds, amounts paid in Bitcoin or other virtual currencies will be deemed paid in United States Dollars at the exchange rate given by Hashfast to its customers on the order date. However, this does not apply to Batch 1 customers, and it was stated earlier on this forum by HF that full refunds would be paid in BTC. Now since the only payment option is in BTC Will I get the same ammount of BTC back should you fail to deliver by December 31st?
Orders are taken in BTC, in the unlikely event we get to refunds they will be given in BTC. HF really owes their Batch1 customers some clarity after all these conflicting statements and retroactive ToS changes. It seems they thrive on ambiguity. |
|
|
|
Yes, they will ship saturday, that is just another way to say that they are gonna ship on monday, maybe.
The fact that they are now communicating with press releases is really interesting, btw.
I hope that they simply gave up and decided not to ship/refund.
I sent them an email to change my shipping address from office > home (as my office mailroom will be closed during the holidays) 2 days ago and they told me it is unlikely they will be able to change the shipping address at this point in time since they have already transmitted shipping addresses to Ciara for shipping. So shipping should be imminent. Saturday sounds reasonable. They should know the final specs by now (Power consumption at chip & wall level, GH/s/W, etc.) so I'd love to get some clarity on that. |
|
|
|
^^your order ack is garbage in case off a refund. do you have a order ack with the BTC price first as I have?
I ordered on Day 1. HashFast only accepted payment in Bitcoin though BitPay, there was no other option. (They did not accept USD or direct BTC until after their webstore broke). From the announcement post: Payments to be made in BTC with the help of BitPay A full refund is the return of exactly what I paid, in the currency I paid it in. BitPay allows the merchant to convert it to USD or keep it in BTC. What HF does with it after the transaction is up to them and does not concern me. We are customers. Not investors or backers. |
|
|
|
Note that while I'm writing software for them I'm just a contractor so I have no direct allegiance with them, so I'm trying to sift through all this information and I want to know if anyone has kept a copy, screenshot or whatever, to show that they promised to deliver by October 30th? I certainly remember it being implied when I first looked but wasn't really watching early on to see what was being advertised.
Hi Con! Thank you for all the work you're doing to ensure cgminer works flawlessly with HashFast ASICs. Per our ToS, Dec 31 is the guaranteed delivery date for Batch One. Best, -HF_CL That might be your ToS, but this one is mine: http://pastebin.com/EfS9vmRfThis is the announcement post on bitcoin talk: https://bitcointalk.org/index.php?topic=270384.0This is a screenshot of the product page at the time of my order: https://i.imgur.com/DDessZJ.pngThis is my order confirmation: https://i.imgur.com/mHjIYzy.pngThere was no ambiguity in the published statement "Shipments begin October 20-30" The original ToS did contain the following paragraph: Except for delivery dates explicitly guaranteed in the order confirmation, delivery dates communicated or acknowledged by Hashfast are approximate only, and Hashfast shall not be liable for, nor shall Hashfast be in breach of its obligations to Buyer because of any delivery made within a reasonable time before or after the stated delivery date. However a 'guaranteed delivery' date was not present, leaving it open to interpretation as to what 'reasonable time' means in the context of mining hardware purchases. 7 days after my purchase I received a 2nd 'order confirmation' by email with updated boilerplate: Your order is expected to ship between October 20 and October 30, 2013. Physical delivery of your order will take place within days, depending on the shipment method selected. HashFast guarantees that all "Baby Jet" units from our first production batch will be delivered by December 31, 2013. If Buyer ordered one or more Baby Jet units, and HashFast does not deliver such units by that date, then Buyer may at his or her discretion, cancel the undelivered portion and HashFast will issue a full refund the payment for the units that Buyer purchased but did not receive and cancelled. This cancellation and refund is Buyer's sole and exclusive remedy for HashFast failing to deliver by the December 31, 2013 guaranteed delivery date. Buyer must cancel the order and request a refund by January 15, 2014 to avail him or herself of this remedy. Buyer to pay all taxes, duties and shipping costs on units delivered. Also they had updated their ToS by that date (Aug 15) to include the guaranteed date (However they kept the revision the same at '1.B – Revised August 8, 2013', and now appear to have dropped revision number all together in their ToS so it is hard to know which one you are bound to unless you save a copy at the date of the sale). |
|
|
|
One quick question though, does the rasp pi image come with a fancy web gui as well ? Not that It's needed, but I'm just curious to know.
The RPi isn't powerful enough to run a 'fancy web gui' and cgminer is terminal-based. I'm trying to get DrHaribo and Tacotime development boards, so users who don't like cgiminer will have GUI-based options. Best, -HF_CL Not true. Look at bitfury's web interface, avalon (arguably an even weaker processor inside the tplink routers), custom pi mining firmwares, etc As far as cgminer being terminal based that's not a limitation as it has an API that can export all the necessary stats and info a gui might require. Like I said I really don't care if it comes with a gui option or not, but some more novice miners may. It should be possible to run minepeon as long as you use the updated cgminer with the HF driver. http://minepeon.com/index.php/Main_Page |
|
|
|
Why 400 we have 570 BJ in Batch one.
Mine is:
1491 8/29/2013 18:02:00 1 523
Consider yourself lucky. You might be able to get a full refund in January. What's funny is that they even look-a-like. InaTard and John(if john is the bluetooth guy)
The guy with the bluetooth headset is Eduardo. |
|
|
|
Hmm, well, for the record BFL got away with it, HF will likely too. It takes a rare kind of breed to actually do something. HF just have to wait it out, meanwhile their "creative pickaxing" (to borrow a phrase from Death&Taxes) will have paid off. No one really sued BFL, and our HF case is much stronger than BFL. We have proofs that they lied to us to sell an overpriced product. There is not even a lot to discuss about, what they did was illegal. I was about to ask about BFL but didn't want to hijack the thread. This is amazing for me. After all the drama not one single person sued them? I just can't believe this. Maybe HF already knew this and they just took the same route. That is certainly the impression I got after talking with John at the HF office back in October https://bitcointalk.org/index.php?topic=262052.msg3633785#msg3633785HF: good hardware team, sleazy sales & marketing team. |
|
|
|
Keep dreaming. They can't force hosting on customers. I would NEVER trust hosting of any of my miners. I prefer full control of absolute anything I purchased in HAND. Not F*ing hosting. I need to customize cooling, pools, miners, API, PSU, **ALL** as I always do. We purchased a physical product , not a stupid unit far in the cloud. We are the product owners. Not them.
Why is having the device that important? If you can check and confirm the hashrate of your hosted miner directly with your pool (e.g. btcguild) then what is the problem? I'd love free hosting if that means I can deploy my miner faster, don't have to deal with heat, noise, electricity costs, uptime maintenance or my house burning down. Just because someone hosts it does not mean you don't own it. Of course if they would use hosting merely as a way to get around their hard delivery deadline, that would be sneaky. |
|
|
|
they sure as hell had better ship a box with the upgrades. Otherwise the "upgrades" will be little more than more MPP that we'll have to buy empty boxes for. When I bought my upgrade, I was buying another *functional* 400 GH/s, and I won't accept any less...
You might be surprised at the things you'll accept once they have you fully bent over (i.e. right now). |
|
|
|
If depositors are reimbursed for pennies on the dollar (11 USD is only 1.5% of the current BTC USD value) while the rest (98.5%) goes to the 'owners' I would be really pissed considering that these people are responsible for this mess including: - Operating as a Limited Partnership before that partnership was fully formed (Unsigned docs)
- No backups of customer account data, No segregated accounts, No 2 factor on accounts (MtGox)
- Willfully leaked code including passwords to customer funds.
- Violating their own TOS
- Allowing a minor that was not an employee full access to funds and customer AML documentation (Zhou)
- No meaningful attempt to file reports for theft, backup recovery or fund recovery
- Never covering original thefts while lying to customers ('The thief stole from us, not you' & 'Previous thefts were covered by Tihan/investor') in order to attract new capital.
- etc.
I really hope the Liquidator will think this through and take steps that actually benefit the claimants. After all these are their funds that they trusted to Bitcoinica. Liquidating BTC @11 USD is almost legalized theft. Why is 30% of BTC off the table? What do you know that I don't?
I also don't see why this should be the case. The last 'official' number we got before Bitcoinica went into Liquidation was a 30% haircut. (Can't find Amir's thread but it is also echoed in this article: http://bitcoinmagazine.com/1805/bitcoinica-stolen-from-again/). In addition not every depositor filed a claim. So let's not give up that easily. Now that the Liquidator has access to the MtGox account we should get clarity as to how much is left. Of course the initial 30% haircut might have taken into account the promise of the investors to cover the previous (Linode & Rackspace) thefts. A promise they do not appear to have kept. |
|
|
|
|
It is time HF reached out to customers to confirm shipping dates and addresses.
I provided a work based shipping address but during the holidays it will be closed. If this is the case I will need to change the address to my home address. i.e. I need to know *when* my unit ships to determine where to receive it.
Also whatever happened to the managed hosting plans? HF will not be able to deliver all 550 units globally before the end of the year (Most postal services are overloaded around Xmas) and merely providing tracking numbers is *not* a substitute for delivery.
HF get your act together.
|
|
|
|
Why is there a chance we don't get our coins and our cash back? We should be made whole minus liquidator fees?
I think there is a chance we'd get the value in US dollars of the bitcoins at the time of liquidation. And that there will be a very large surplus amount of money which will go to the owners of the firm. And that the bitcoinica liquidation could be treated as the type of liquidation where the number of assets is greater than the liabilities. Think about what would happen if bitcoins went down to zero. It makes sense for a liquidator to value a highly variable asset at the value at the point of liquidation. On the other hand, if the liquidator doesn't ownership of the assets until much later - it could make sense to value them at the point of acquisition. Of course this is all speculation. We need to some solid kiwi (New Zealand) legal advice. Nice insolvency that would be. The people that f*cked up would be richly rewarded for their mistakes at the expense of all depositors. Bitcoinica liability needs to be defined as BTC based. The 3rd Liquidator report should be out any day now. So far I've been very disappointed in the performance of the liquidator. So I'm not very hopeful. |
|
|
|
|
Show Posts
