Bitcoin Forum
September 25, 2017, 10:27:13 PM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 [33] 34 35 36 37 38 39 40 41 42 »
  Print  
Author Topic: [Announcement] Avalon ASIC Development Status [Batch #1]  (Read 151598 times)
lucif
Sr. Member
****
Offline Offline

Activity: 448


Clown prophet


View Profile
January 15, 2013, 09:38:24 AM
 #641

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...
1506378433
Hero Member
*
Offline Offline

Posts: 1506378433

View Profile Personal Message (Offline)

Ignore
1506378433
Reply with quote  #2

1506378433
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1506378433
Hero Member
*
Offline Offline

Posts: 1506378433

View Profile Personal Message (Offline)

Ignore
1506378433
Reply with quote  #2

1506378433
Report to moderator
nathanrees19
Full Member
***
Offline Offline

Activity: 196



View Profile
January 15, 2013, 09:42:53 AM
 #642

No demo

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

Activity: 448


Clown prophet


View Profile
January 15, 2013, 09:45:18 AM
 #643

Very interesting what is estimated summary pre-orders amount in Avalon...
Gyrsur
Legendary
*
Offline Offline

Activity: 1764


#BEL+++


View Profile WWW
January 15, 2013, 10:06:53 AM
 #644

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
Sr. Member
****
Offline Offline

Activity: 448


Clown prophet


View Profile
January 15, 2013, 10:12:12 AM
 #645

So, $400k.

Not enough, not enough... Okay lets see.
Gyrsur
Legendary
*
Offline Offline

Activity: 1764


#BEL+++


View Profile WWW
January 15, 2013, 10:45:52 AM
 #646

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
Legendary
*
Offline Offline

Activity: 1358



View Profile
January 15, 2013, 10:51:43 AM
 #647

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
Legendary
*
Offline Offline

Activity: 1764


#BEL+++


View Profile WWW
January 15, 2013, 10:58:15 AM
 #648

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
Sr. Member
****
Offline Offline

Activity: 342


View Profile
January 15, 2013, 12:26:08 PM
 #649


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
Legendary
*
Offline Offline

Activity: 1274


View Profile
January 15, 2013, 07:45:01 PM
 #650

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
Hero Member
*****
Offline Offline

Activity: 756



View Profile
January 15, 2013, 07:54:47 PM
 #651

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

Donations: 1JVhKjUKSjBd7fPXQJsBs5P3Yphk38AqPr - TIPS
the hacks, the hacks, secure your bits!
MrTeal
Legendary
*
Offline Offline

Activity: 1274


View Profile
January 15, 2013, 08:00:12 PM
 #652

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
Legendary
*
Offline Offline

Activity: 2268


View Profile
January 15, 2013, 08:08:04 PM
 #653


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
Legendary
*
Offline Offline

Activity: 1764


#BEL+++


View Profile WWW
January 15, 2013, 08:53:50 PM
 #654

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
Legendary
*
Offline Offline

Activity: 1118


View Profile
January 15, 2013, 10:52:40 PM
 #655

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
Legendary
*
Offline Offline

Activity: 1092



View Profile
January 15, 2013, 11:07:49 PM
 #656


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?




@electricwings   BM-GtyD5exuDJ2kvEbr41XchkC8x9hPxdFd
tbcoin
Legendary
*
Offline Offline

Activity: 980



View Profile WWW
January 15, 2013, 11:27:30 PM
 #657

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

Sorry for my bad english Wink
Bitcoin card for deposit and payment + Little POS
Donations:1N65efiNUhH6sEQg7Z6oUC76kJS9Yhevyf
Bogart
Legendary
*
Offline Offline

Activity: 938


View Profile
January 16, 2013, 12:02:24 AM
 #658

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

"All safe deposit boxes in banks or financial institutions have been sealed... and may only be opened in the presence of an agent of the I.R.S." - President F.D. Roosevelt, 1933
tvbcof
Legendary
*
Offline Offline

Activity: 2268


View Profile
January 16, 2013, 12:14:23 AM
 #659


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
Jr. Member
*
Offline Offline

Activity: 42


View Profile
January 16, 2013, 05:20:55 AM
 #660

Bitsyncom, any sign of progress now?
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 [33] 34 35 36 37 38 39 40 41 42 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!