Topic: [Announcement] Avalon ASIC Development Status [Batch #1] - page 9. (Read 155276 times)

BFL won't be testing anything until February based on their timeline.

I was looking at this set of graphs: http://bitcoin.sipa.be/index.html

and it seems like there was a bit of a spike just a little while ago which could have been testing.  Of course, it could be other things as well even testing by BFL (cough, cough) - and there is the DISTINCT possibility i am misinterpreting the graphs.

Yup. Very good product!

Blocks avg. per hour: 4.92
Difficulty:   3,249,550
Next Difficulty: in 947 blocks 3,035,068
Network Hashrate: 21.73 Terahashs/s

Bitsyncom, any sign of progress now?

Hey guys. 4 days left! The question is "4 days left for what?" Say somethething, show something?

I love google translate, i can totally hit on a chinese girl with that.

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...

http://translate.google.com/#auto/en/%E6%B6%88%E6%81%AF%E7%9A%84%E7%9C%9F%E7%A9%BA%0A%E6%81%B0%E5%A6%82%E9%BB%8E%E6%98%8E%E5%89%8D%E7%9A%84%E9%BB%91%E6%9A%97%0A%E5%8F%88%E4%BC%BC%E4%BB%A4%E4%BA%BA%E7%AA%92%E6%81%AF%E7%9A%84%E9%9D%99%E5%AF%82

... easy enough to understand what it means.

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?

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

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.

this is exact the pre-orders amount.

€300k x 1.30 = $390k