[Announcement] Avalon ASIC Development Status [Batch #1]

[lucif]

I am glad Avalon helping me to dance on Josh bones.

But I should warn all of you about Avalon itself.

No demo, no tests, no bitcoin hashrate increase so far. Only pics with unnamed chips. And 5 days to delivery.

Lets see, lets see...

[1714989429]

1714989429

[1714989429]

1714989429

[nathanrees19]

No demo

Yeah, they still haven't given a solid answer on this (unless I missed it?). It's a bit odd.

[lucif]

Very interesting what is estimated summary pre-orders amount in Avalon...

[Gyrsur]

Very interesting what is estimated summary pre-orders amount in Avalon...

300 pre-orders in first batch.

300 x 60 GH/s = 18,000 GH/s

increase of hashrate by 18,000 GH/s until next month.

[lucif]

So, $400k.

Not enough, not enough... Okay lets see.

[Gyrsur]

So, $400k.

Not enough, not enough... Okay lets see.

right, $400k.

300 x $1,299.99 = $389,997.00

not enough for ASIC production but maybe they have own or foreign capital involved.

[aTg]

So, $400k.

Not enough, not enough... Okay lets see.

right, $400k.

300 x $1,299.99 = $389,997.00

not enough for ASIC production but maybe they have own or foreign capital involved.

 A structured ASIC costs 300k €

[Gyrsur]

So, $400k.

Not enough, not enough... Okay lets see.

right, $400k.

300 x $1,299.99 = $389,997.00

not enough for ASIC production but maybe they have own or foreign capital involved.

 A structured ASIC costs 300k €

this is exact the pre-orders amount.

€300k x 1.30 = $390k

[anti76]

I used to send scanned documents to pay warrants 200,000,846.
Status of the order has not changed, the letters from the scans or who did not reply, sent to the address: info@avalon-asic.com, yifu.guo @ avalon-asic.com

Order #    Date    Ship To    Order Total    Status    
200000846    11/24/12    ---------   $8,159.94    Pending Wire    View Order

The wire came in on the 11th of this month, a month plus late... I'm aware of this order, but due to it's nature being two wire transfers it did not complete automatically. This matter will be addressed.

until now the status has not changed.

[MrTeal]

Very interesting what is estimated summary pre-orders amount in Avalon...

300 pre-orders in first batch.

300 x 60 GH/s = 18,000 GH/s

increase of hashrate by 18,000 GH/s until next month.

It's 66GH/s now, is it not?

[420]

Very interesting what is estimated summary pre-orders amount in Avalon...

300 pre-orders in first batch.

300 x 60 GH/s = 18,000 GH/s

increase of hashrate by 18,000 GH/s until next month.

It's 66GH/s now, is it not?

ASIC Bitcoin Miner
Done right
~60GH/s starting at $1,299. Avalon, a world first, coming to your doorsteps Q1 of 2013.

4
DAYS
17
HOUR

[MrTeal]

From the original post of this thread.

Intro. Avalon launched with a challenge to our competitors: a over 50% dollar per GHash gain. Our competitors since then has also increased their specifications in order to stay competitive. Deviated from their original plan the competition managed to even the playing field, yet we simply proceeded with our original design goals and have reached 64Gh/s, and now 66Gh/s! Once again taking the lead in $/Ghash. While the competition promised early delivery dates but kept pushing them back. Avalon instead gave an very conservative estimate but now is scheduled to ship even earlier at Jan. 20th 2013.
...
$1,299? Yep, to stay with the spirit of the competition. $1,299 for 66Gh/s.

[tvbcof]

I have a suggestion for future 'pre-order' funds management.

This suggestion only works of the vendor does not need to use the funds prior to shipping for operating expenses (and if they do, I would argue that pre-orders and are inappropriate source of funding anyway.)

I suggest that an entity who wishes to queue up in the delivery line simply transfers a particular value to an address that _they_ retain control of.  The address list would be public domain.  When their turn comes up in the queue, they can optionally take delivery.  If at some point prior to delivery they wish to de-queue, they just transfer the funds back out.

Any terms involving exchage rate adjustments (and the like) could be drawn up.  As long as it's clear that the vendor had an option to capitalize on favorable exchange rate moves up front, I'd be totally fine with that.  To clarify:

 - if the BTC values go up, the original outlay is taken
 - if the BTC values go down, additional funds are needed to exercise delivery.

In vendor-favorable scheme like the above example, the customer may still choose to take delivery or not.  If not, the next guy in the queue gets the option.

Lots of permutations are possible.  It is the case that people with excess funds could queue up as a speculative move planning to potentially sell their spots (which is why I used a vendor-favorable example above.)  At the end of the day, though, who cares?  Accounting and management of funds should be trivial and mechanical.  Most importantly, it should leave the customer in control.  Bitcoin offers some pretty unique opportunities because of it's transparency and it would be cool to seem them leveraged by vendors in efforts to demonstrate good intentions.

[Gyrsur]

any sign from Avalon? if they will start to ship next monday they should start to assembly and test the units.

countdown: avalon-asics.com

[SolarSilver]

A structured ASIC costs 300k €

this is exact the pre-orders amount.

€300k x 1.30 = $390k

and producing 300 units with a PCB, CPU, ethernet, case and power supply is free?

[julz]

I have a suggestion for future 'pre-order' funds management.

This suggestion only works of the vendor does not need to use the funds prior to shipping for operating expenses (and if they do, I would argue that pre-orders and are inappropriate source of funding anyway.)

I suggest that an entity who wishes to queue up in the delivery line simply transfers a particular value to an address that _they_ retain control of.  The address list would be public domain.  When their turn comes up in the queue, they can optionally take delivery.  If at some point prior to delivery they wish to de-queue, they just transfer the funds back out.

Any terms involving exchage rate adjustments (and the like) could be drawn up.  As long as it's clear that the vendor had an option to capitalize on favorable exchange rate moves up front, I'd be totally fine with that.  To clarify:

 - if the BTC values go up, the original outlay is taken
 - if the BTC values go down, additional funds are needed to exercise delivery.

In vendor-favorable scheme like the above example, the customer may still choose to take delivery or not.  If not, the next guy in the queue gets the option.

Lots of permutations are possible.  It is the case that people with excess funds could queue up as a speculative move planning to potentially sell their spots (which is why I used a vendor-favorable example above.)  At the end of the day, though, who cares?  Accounting and management of funds should be trivial and mechanical.  Most importantly, it should leave the customer in control.  Bitcoin offers some pretty unique opportunities because of it's transparency and it would be cool to seem them leveraged by vendors in efforts to demonstrate good intentions.

I really love this idea.
Presumably people would prove they own the address, and agree to the particular terms by signing those terms using a Bitcoin 'sign message' facility.

More generally - this seems like a form of 'layaway' (or lay-by as it's known here in Australia)

I'd like to see a little lay-by management tool for merchants & customers to view their agreement terms and balances.
..but how could we prevent someone using the same funds as part of deals with multiple merchants where the amounts happen to match?
(some people may just reserve way more resources than they are ever going to be able to pay - negatively affecting the utility of the system for merchants)
I like the simplicity of your proposal.. but some further script magic would seem to be required?

[tbcoin]

Finally... how it is the Avalon hardware ? It is a complete PC with integrated ASIC? used Raspberry Pi? tablet?

[Bogart]

Finally... how it is the Avalon hardware ? It is a complete PC with integrated ASIC? used Raspberry Pi? tablet?

The high level controller is to be a small Atheros MIPS board similar to a TL-WR703N running a linux based on OpenWRT.

Like a Raspberry Pi, but even smaller/cheaper/lower-powered, and with no video output.

http://wiki.openwrt.org/toh/tp-link/tl-wr703n

[tvbcof]

I have a suggestion for future 'pre-order' funds management. <snip>

I really love this idea.
Presumably people would prove they own the address, and agree to the particular terms by signing those terms using a Bitcoin 'sign message' facility.

More generally - this seems like a form of 'layaway' (or lay-by as it's known here in Australia)

I'd like to see a little lay-by management tool for merchants & customers to view their agreement terms and balances.
..but how could we prevent someone using the same funds as part of deals with multiple merchants where the amounts happen to match?
(some people may just reserve way more resources than they are ever going to be able to pay - negatively affecting the utility of the system for merchants)
I like the simplicity of your proposal.. but some further script magic would seem to be required?

I guess I would say 'so what' if people did multiple pre-orders from the same addy?  For one, the address is public so if the merchant decided to give a shit he might be able to detect doubled-up pre-orders, but why should he care, for one, and more importantly...

The idea would be that the merchant only honors the queue position from the documented address.  If that gets spent it automatically drops out of the queue and the next guy in line gets his chance.

If merchants start using such a mechanism (which I doubt since pre-orders generally are a bit corner-case) it is unlikely that two merchants would have exactly the same notional value for a pre-ordered item, and if they did, they could avoid a collision...unless one of them wanted a collision for some reason I suppose...

---

An interesting artifact would be that being #500 in a queue of 300 ASIC chips (for instance) still gives one a decent chance of getting the item anyway.

An interesting fallout from the above in monetary science terms would be that a fair amount of money could be tied up in queues and not used in circulation.  Most mainstream economists would think this is not such a great thing.  I'm not so sure.  In any event, again, pre-orders are likely to be an unusual thing generally.

But as you allude to in your post, the general idea could probably be used for similar sorts of problems with a bit of scripting and perhaps a tool provided by someone for managing such a thing.

[leiyplane]

Bitsyncom, any sign of progress now?