Доброго здоровья и удачи форумчанам! Пришел спецом всех поздравить с наступающим Новым Годом!

Думаю, что подытоживать прошедший год в посте будет нудно и долго, с большего должен отметить что был очень трудный год, но заканчивается он с большего в целом позитивно.

Но - из того что вижу сейчас - на следующий год потребуется еще больше удачи и здоровья, чтобы достойно пройти все новые задачи, которые будут возникать по его ходу. Самая сложная и важная из задач - показать миру прикладную полезность биткоина, потому как согласно боевым гадальным картам - ближе к концу следующего года, если реальных подвижек не будет - пойдет в СМИ волна относительно аферы 2009-2014 годов с криптовалютами, после чего будет попытка общественное мнение склонить именно в сторону того что от этих штук одни беды, опираясь на события которые были ранее, ну а после этого уже можно добивать инфраструктуру. Так вот - чтобы этого не произошло - самая большая сложность - это сделать на биткоинах реальную экономическую пользу в ИТ-секторе для начала - если этого не сделать - постигнет биткоин более изощренная атака, которая дискредитирует всю концепцию в целом - в том смысле как например сейчас относятся к изобретению вечных двигателей.

С большего все о главном - дополнительно к здоровью и удаче по жизни, желаю вам мощных майнеров, дешевого электричества, удачного майнинга, роста и здравия биткоина.

Приглашаю присоединиться к новогодним поздравлениям друг друга!

Дописать забыл совсем - все-же следующий 2014 год думаю будет годом биткоина ;-))))) Хотел дописать, разволновался и забыл :-) Дописал ;-)

Кому интересно, отпишите, пожалуйста, в топике - кто какую цену и на какое количество чипов считает справедливой. Цена на чипы по наличию (доставка в течении 1-2 дней) в сентябре (середина месяца). В формате - цена - количество которое хотел-бы взять - причина. Пожалуйста не устраивайте флеймов - все лишнее будет зачищаться. Пожалуйста также учитывайте - первое - цена возможно будет учтена в дальнейшем, и купить по ней сможете не только Вы, но и другие люди - это важный момент. Если есть желание написать более развернуто - то цена, количество и дата поставки с сентября по ноябрь скажем (т.к. это связанные параметры). Актуальность - до 30.08.2013 - потом залочу топик. Спасибо!

=== Дополнение ===

По поводу вопроса о количестве чипов - если интерес состоит в защите своих вложений, то возможны альтернативные схемы сотрудничества, как предложил ранее Анатолий Легкодымов, (которые тут тоже можно кстати описать) - мы даем чипы, вы вкладываете в сборку, размещение и обслуживание оборудования. Вместе майним, продаем либо гигахеши, либо железо, доход делим из оценки стоимости чипов, стоимости сборки и стоимость работ (менеджмента) сборки и установки. Расходы на обслуживание покрываем совместно. При этом В СЛУЧАЕ если конкурентные решения превышают наши ожидания - мы можем договориться либо двигать доли, либо не двигать доли, но в первую очередь окупить вашу инвестицию. Однако тут будут дополнительные требования с нашей стороны - в плане надежности решения, обслуживания и места где стоит железо. Варианты могут быть разные - от серверных до полезных функций - аля обогрев ваших объектов - однако - все должно быть сделано хорошо, и с расчетом стоять год-полтора. Если такой пункт нравится - прошу дополнительно прикинуть - сколько у вас есть не-проблемных киловатт мощности, которые можно освоить в удобном месте (чтобы обслуживание не стоило в итоге космических денег - например дача это не плохо, а датацентр с УПСами это уже труднее), по адекватной цене. По поводу безопасности - надо конечно думать - но если этот вариант партнерам тоже понравится - поможем тогда организовать.

ТАК ЧТО ПО ЭТОМУ ПУНКТУ - пишите / подредактируйте написанное дополнительными опциями (чтобы сохранить формат - один никнейм/одна позиция - я вместо ответа сейчас просто редактирую...) - сколько есть в наличии киловатт мощности, полезная-ли утилизация тепла (это как раз важно - например греть ГВС - это тоже интересно - круглый год ведь, отопление - уже чуть хуже), сложность/не сложность обеспечения безопасности долговременной площадки, стоимость киловатта ориентировочная, сколько чипов можете освоить под ключ итого и за один заход, какой желаемый % распила долей или-же оценачная стоимость чипа при такой схеме сотрудничества. Можно собственно часть выкуп/часть по такой схеме - тоже - рассмотрим (я в пятницу отчет буду готовить - так что есть время обдумать, поправить, дописать - редактирование норм - тут не дебаты, а высказывание позиции :-).

=== Краткие ответы на вопросы ===
>1. Причина опроса ? - мы хотим перейти на работу исключительно по наличию и завязать с предзаказами. Причин для этого несколько - в частности в том что контролировать даты поступления чипов НЕВОЗМОЖНО (от 2-х недель до 2-х месяцев - а это однако влияет существенно) - причем - предупреждаю - мы не идиоты и это не только нас касается - все поставки должны были идти не так как у нас они шли, а теперь думайте о других асик-предзаказах, вспоминайте историю за последние полгода и экстраполируйте на следующие... ;
>2. выгрузка метабанка, фана и европы (штаты не знаю) должна произойти в конце августа (конец этой недели) - начале сентября (до 6-7го) по моим данным - как у кого реально получится жизнь покажет - все обычно получается через одно место;
>3. сколько чипов будет продано - это возвращаюсь к пункту 1 - реально например мы должны были получить часть чипов в конце мая/начале июня, часть чипов в конце июня, часть чипов в конце июля - этого не получилось - вместо этого мы получили все практически комом, который трудно переваривать;
>4. Метабанк полностью поставит устройства (денех не будет)
Естественно;
>5. Вы укажите реальное количество чипов выпущенных в 0,1,2 батчах (а вдруг 1 млн чипов)
Количество чипов - на данный момент у нас информация закрытая и не для публикации. Я в одиночку не уполномочен ее разглашать - это раз. И два - не давать конкурентам возможность планировать свое производство - пусть догадываются, трудятся, анализируют, шпионят Думаю что правило можно будет расслабить на то, что есть в наличии и на то что скажем есть в горизонте в месяц, но не в горизонте 3-4 месяца.
>6. Будет доступна схема платы для самостоятельного изготовления или готовые варианты (по адекватной цене)
Будут - однако тут есть проблема - если доработаем схемотехнику с цепочками - будет легче - если нет - придется модифицировать каждый раз плату под источники - потому КАК ТОЛЬКО будет плата в open source с определенным видом источников питания - вы их не сможете купить по разным причинам - отчасти из-за того что их выметут те, кто собирают, отчасти от того что их выметут конкуренты/реселлеры и будут продавать дороже специально вам под  проект майнеров - очень многие в курсе сколько стоит ВРЕМЯ, и это совсем не значит, что вам будут помогать. Причем ребята довольно цепкие - если появится редкий компонент на плате - и вам казалось с 20 чиповым тестом что жизнь уже удалась и можно освоить например 2000, но про проект знает довольно много людей - пойдете покупать компонент, и его не будет По этой причине + ввиду нехватки времени платы сделанные так и НЕ ВЫЛОЖЕНЫ. И вот тут самый гадкий момент - в худшем случае под проект потребуется вносить изменения в плату, собирать разные комплектующие.

=== Дополнение по ГВС и режимам ===
1) как оказалось чип переживает перегрев до температуры отпаивания от печатной платы;
2) чип при работе на 100 градусах больше ест и на ~12% меньше решений дает
3) лучшая температура на чипе 40 - 55 градусов (причем холод тоже не хорошо !)
4) на 60-70 работает сносно - минус 3% где-то;
5) по водоблокам - дело в том что он довольно простой - один блок на две платы причем простой формы (низ платы, причем можно двуслойку);

OK, I have waited with great patience till http://bitbet.us/bet/450/bitfurys-asic-will-work-with-power-1/ went to pending resolution status. It gets more and more interesting.

Right now we had trouble with getting chips "in time" for tests (as we expected to get chips on 30th May and do the test earlier in June). So my friend went to Taiwan to get chips, meanwhile packaging factory tries to push delivery to 13th... We'll work hard to push it back to 10th or 11th as they promised second time. But it depends... More information will be available likely on monday.

So - to speedup testing and provide plausible and trustworthy confirmation of performance I have decided that we will send sample chips to 3-4 persons of this forums with following conditions:

- We will send 10-30 chips (number of chips is that what you could select yourself depending on your custom issues - say if you sure that no problem to get 30 sample chips - we'll send 30). Preliminary specs - each chip would give roughly 5 GH/s performance.
- You will solder AS SOON AS YOU GET chip it using dead-bug style (for later chip make PCBs of course, however if you are eager to run it quicker - dead-bug might be right way) with bypass capacitors underneath and will try to run it, measure power consumption and performance with different voltage modes (sweep from 0.5 V to 0.9 V).
- You will post photos in any case - not depending whether chip works or not, it could be also interesting if you could scrub the top and post photo of its internals (if you could remove AL_RDL layer that would be great).
- You have to understand C programming language and boards like raspberrypi (if not you should team up with programmer) - but that's mandatory, and understand how to deal with quick power-hungry chip (i.e. capacitor bypass selection,  power impedance issues).
- It would be great, but not mandatory, if you have good web of trust to these persons who are running website bitbet.us: http://serajewelks.bitcoin-otc.com/trustgraph.php?source=kakobrekla&dest=mircea_popescu as they do not trust our results much, and it would be nice to give them bulletproof confirmations _IN_TIME_ for bet resolution.
- Reporting during some time how chips behave - whether they all alive and hash good or broke with time passed, and guesses why they break (maybe by sending chip to us so we could unpackage them and scan them to find out failure reason).

Additional requirements:

- Being hacker at least a bit... As we haven't enough time to write documentation, and you'll basically get C-code for raspberry that is capable to communicate, not well-tested. Some half-working miner code. Chip pinout. Maybe verilog code... It's a bonus if you could do debug - in case if chip will not work and you'll find bug - we'll likely just pay additional bonus for that. Don't expect good written documentation of any kind and don't expect that I will be able to spend many hours explaining how to make this job. Likely we'll open separate discussion thread and will discuss issues there.
- You would likely need lab power supply, if you don't have - then prepare 0.6 - 0.9 V power supply with current up to 6 amps, power supply of 1.8 V with current 100-200 mA
- raspberry-pi board or board like that (first software will be designed for it), if other board used - you should know what you do and do it yourself - SPI required.
- maybe you should have to use EXTERNAL clock generator giving 150 - 500 Mhz programmable frequency output.
- it would be great to have at hand 500 - 1000 Mhz oscilloscope, even better to have 10 Ghz oscilloscope to make clock jitter measurements, also it would be even greater to have spectrum analyzer with 4-10 Ghz bandwidth to measure power noise spectral content and debug in case if you have excessive pulsations in power network at certain frequencies by reworking capacitor bypass network to get good performance (however all of that can be skipped if we are lucky enough and have good margins in chip).
- handle chip carefully - as ESD-protection may underperform and may not give 2kV HBM protection for example. This should be met, but we don't know if it is met or not yet.

If candidates will be 3-4 or less - they will get chips, if more - I will collect in PM or in this thread requests to take opportunity with testing, make after 24 hours additional POLL topic, and those who will be elected will get chips. 48 hours after this message I hope everything will be known and settled.

Chips will be sent on 10-11th from Taiwan, if we'll find out how to help our packaging factory to make it happen, but it can be later as well. Anyway it is not only bet issue, but we would like to know about chips performance AS SOON AS POSSIBLE. I think that opportunity to get these hashes earliest would be excellent motivation to execute tests in shortest possible terms.

PS. I've read that someone here is reselling metabank.ru offers with our chips. I would like to clarify - first - neither me nor metabank.ru endorses these resellers. Second - metabank.ru is not taking 'prepayment', its just preorders with 100% refund  just to freeze funds - basically people can just show them bitcoins and keep on their OWN wallets (not moving them). Its mainly purpose is just preliminary evaluation of volumes for next production batch. With other sales, etc - that all will be discussed only AFTER testing. So my advice - don't be crazy and don't buy BS (Edited: this is what I meant - is those crazy sellers for $5k with prepayment and without guarantees, BitCentury seems to be legit and faithful).... But of course you may be lucky and that will happen as advertised - that's your win/loose.

PPS. About further distribution of chips - we have ideas (yet only ideas we'll see how that will happen in reality) - standard instrument "chip futures with real delivery with expiration date MM.YYYY", it would be traded online and actual delivery will be done by tytus (Leszek), and instead of direct contract there will be one single public contract. Then - for small to medium order amounts actual acquisition would be done to multiple locations using intermediaries who will do assembly, certification and will have end-user support for the devices. For bigger quantities it will be possible to get chips directly. I think some of delivery locations will convert "bulk" into smaller amounts for chip deliveries as well. But to grasp overall idea - we'll not multiply headache, but actually spread headache among many many heads, so each will have much less headache to pass and grow to higher volumes. Also there's some technical issues that we're discussing - how to organize it... I would like to deploy fully-featured peer-to-peer real-time exchange as open-source project and invite current web-sites to distribute tickers and handle cash-in/cash-out issues (that's not limited to these futures, but are open for many participating parties as well), but being objected that it's quite complex and not trivial to do in limited time. I hope that if we have enough of luck and chip will work, I'll have enough time to make this actually happen.

SO PLEASE, DON'T BOMBARD ME WITH REQUESTS TO BUY CHIPS, ETC. JUST BE PATIENT.

Hello All!

I've based some of my research on topic, basically used previous work of ngzhang
where he have identified chip: https://bitcointalk.org/index.php?topic=79825.0

Unfortunately I do not know exact speed grade of used devices.

In Quartus using my "prototype" code that I used for Hardcopy IV evaluation,
and other Stratix and Cyclone V devices (I would remember that for Cyclone V
it is possible to get 320 Mh/s performance per chip @ 160 Mhz @ 6 W approx).

The same code on EP3SL150F780C4 gave highest clock 220 Mhz, and on
EP3SL150F780C3 gave highest clock 250 Mhz. It is exactly unrolled round calculation.
And clock is based on "Slow 110mV 85C Model Fmax Summary" so if some overvolt
practice done it would run a bit (probably like 10%) faster.

Fitter report:

Fitter status: Successful - Sun Jul 01 10:22:07 2012
Quartis II 64-Bit Version: 11.1 Build 173 11/01/2011 SJ Full Version
Revision Name: ALAdder
Top-level Entity Name: sha_s4_test
Family: Stratix III
Device: EP3SL150F780C4
Logic utilization: 86%
  Combinational ALUTs: 86,417 / 113,600 (76%)
  Memory ALUTs: 0 / 56,800 (0%)
  Dedicated logic registers: 85,360 / 113,600 (75%)
Total registers: 85360
Total pins: 7/488 (1%)
Total block memory bits: 198,080 / 5,630,976 (4%)

As you see - one of improvements for Stratix / Cyclone design is to use RAMs...I use them with altsyncram primitive as
it gives me ability to implement shift registers with read_during_write_mode_mixed_ports => "DONT_CARE" mode, which
is important or otherwise memory will be slower (consider this as a HINT to BFL - to not use altshift_taps or automated synthesis of shift registers).

PowerPlay gives estimation of about 26214.26 mW and average toggle rate 249.704 millions transitions / sec (for 250 Mhz clock setup).

So what this means for BFL single device:

1) Without any overdriving practices device with C4 could deliver 220*4 = 880 Mh/s and with C3 250*4 = 1000 Mh/s
2) Power consumption would be (let's assume that PowerPlay lied and it is 30 W @ 250 Mhz @ 1.1 V) ~ 50W for C4 chip and 65 W for C3 chip;
3) in case of overdriving chip to 1.2 V C4 chip would deliver about 960 Mh/s and C3 chip about 1090 Mh/s, power consumption would be about 60 W and 76W correspondingly;

But because they already have about 80W power consumption, that leads me to conclusion, that C3 chip is used, but top-level logics and round maths is inferior and suboptimal.  As basically you could get _lower_ performance just by doing operations in wrong order.

I've already tried to contact BFL in PM - regarding my development and ASIC future deployments, but no answer. Maybe this topic would add some heat.

But I have few questions here:
1. What chip speed grade exactly there ?

2. What voltage is used there (this can be probably measured by many owners of BFL singles) ? Is it standard 1.1 V or something like 1.2 V ?

It would be nice, if BFL would do full disclosure here about their previous product art, as their ASIC initiative seems to make them obsolete already.

Also 2 BFL - if you use same top-level for your ASIC development, don't you think you may end up with product "obsolete-on-arrival" ? Because this is not "custom IC cell design", this is just math, and not complex part of it - as this "test sha_s4_test.vhd" is actually pretty small file mostly using RTL-style code and not using low-level primitives etc. I've run fitter and synthesis without optimization settings. But - if you can't deliver best in top-level optimization, why would I believe, that you would in low-level, where things are more complex and you'd likely have to do full-wave simulations of your custom cells, and still have several re-spins ? Or in layout - because layout could be done in a way by automatic tools, that will destroy all harvested performance. (2 DiabloD3 and those who think that custom IC is always that difficult - NO - I've studied more - if you don't try to harvest performance, and would do reliable cell and don't care about performance much, it is _likely_ that your cell would work, you may even implement cell that would work on different fabs... "portable" one but it would be quite inefficient... actually custom IC may be even cheaper - because basically it is just the same as PCB but on silicon, so if you do design in a way where you accept wide tolerance of your transistors - you get good manufacturability, good portability but poor performance... surprising, but tools for custom IC design without extensive modelling are actually cheaper - say for example www.tannereda.com - pretty nice tool to go from schematic to layout of chip - you even can get evaluation there for free and try to layout several transistors yourself, testing their performance in SPICE... that would be however likely far from specs you get from silicon... ).

I would be sorry, if you have worked on ASIC for quite long period and already have layout, because it seems that you'll have to re-do it if my estimations about your top-level is right.

Regards,
BitFury.

PS. 2 BFL fans - please do not turn BFL into religion :-) There's mining speculation subforum for exactly that purpose.

PPS. As you see _only_ 75% of chip is used... In extra space there could be fitted approx 2 times bigger serial hashers as addition, as design using automated placement would fit into 90% of a chip. Leaving about 10%. In these 10% it is possible to place about 8 serial hashers running at same or faster (LIKELY FASTER) clock. Each hasher outputting additional 3.5 Mh/s - so +25-28 Mh/s per chip and +50-56 Mh/s per BFL single. Setting best theoretical output as 1140 Mh/s per BFL single.

[SECURED LOAN]

As I am person who have long-term interests to have BitCoin alive and safe (mainly because I have invested into massive mining operations, and plan to deploy further projects using BitCoin) I propose following to happen:

As you see system with codes - like Mt.Gox codes, CryptoXChange codes, BTC-E codes works rather well, and these actually represents something like promissory note (debt note, i.e. that finally Mt.Gox would pay to owners of these codes) of Mt. Gox for some USD for example. This already works, but it has multiple dangers - first - you ABSOLUTELY HAVE to trust exchange, as in cases when they get in trouble, all of their obligations to pay against holding of USD / BTC will be troubled. This would result in massive panic on market, exchange rate drop, etc. So this approach would definitely produce problems.

So what is proposed:
1) either embed into current block-chain or add supplementary USDchain block-chain.
2) add ability (or check if that is already available with scripts) to bitcoin code that would allow to lock some BTC for SECURED LOAN of USDcoins - you see - unlike BTC "mining" production, USDcoins produced in the same conventional way - as debt.

----- How it works:

Alice has 50 BTC and would like to sell them for some 5.0 USD, Jane has 30 BTC and would like to sell them for 5.2 USD.

So Alice takes 250 USDcoins (please note that is not US dollar note!) for her 50 BTC being LOCKED and available to anyone to PULL at specified exchange rate by her. Jane takes 156 USDcoins and 30 BTC is LOCKED as well. That way 406 USDcoins created from thin air as secured loan against BTC.

Then Alice finds some exchanger that would exchange to paypal for 2%, and sells to that exchanger her USD coins and gets 245 USD on her paypal account (please note that it is again not US dollars, but paypal obligation to have enough reserves...).

Jane in other way finds Bob who want to buy BitCoins and offer him her 156 USDCoins and gets paid with cash.

Bob goes to market and buys 31.2 BitCoins from Alice, liquidating 156 USDCoins in circulation. Market is p2p as well - cross-chain trading!.

So now we have on market 250 USDcoins and 48.8 BTC available.

Then John buys 250 USDcoins from exchanger for his 255 USD available on dwolla and buys the rest 48.8 BTC available on market.

----- Problems:

1)

Main problem is inflation of USDcoins, as if such basic schema as written above implemented. Nothing stops Rob to go into market and put 50 BTC for 1'000'000 USDcoins . This should be LIMITED and it is the most tricky part of this play,
as this limit must be well understood math and research.

Solution could be to implement limitation for such operations - say first - Alice sells 50 BTC for 5.0, but actually get not 250 USDcoins, but only 125 USDcoins, and could get another 125 USDcoins, when her previous 125 USDcoins were destroyed in market. This actually requires research and financial experiments.

Second part - 50 BTC for 1'000'000 USDcoins - actually secure loan algorithm should prevent this kind of deal totally.

As you see - USDcoins would be as secure, as would be smarter algorithm that controls emission of them. If emission is too high, then USDcoins worth would drop against US dollar. If emission is too low, then it would be pain to trade on this market, and USDcoins would worth more than true US dollar. So multiple market parameters should be taken into account, and USDcoins could stick then to actual USD supply-demand for BitCoin transaction.

Long term problem - it may happen that transaction rates in BTC would drop, while in USDcoin increase, as some people would prefer to stick more with USD equivalent of worth. Then - overall worth of BTCs that were put to secure USDcoin emission would decrease, and USDcoin would become unsecured bubble.

Solution to this problem could be seen for example as adding demurrage on USDcoin, so if you HOLD USDcoin on your account, value of it decreases 0.1% - 0.2% per single day. This could be also payment to miners.

http://en.wikipedia.org/wiki/Demurrage_%28currency%29

Adding demurrage rule would prevent of using such USDcoin for asset accumulation purposes. But again - building correct model, taking in account actual economic behavior of people is not easy task here. Looking forward for some help.

2)

Mining. If BitCoin could be mined, USDcoin cannot be mined in the same way. So probably only fees like 0.2% per transaction could fund mining, and that would be pennies today.

------ Solutions (roadmap):

1) Find out algorithm that can calculate correctly secured loan value;

2) Implement necessary additions to bitcoin protocol, and deploy some prototype on servers in non-p2p way, but more like carthel with some exchanges;

3) Invite users into this experiment;

4) If everything goes good - deploy it for wider usage as p2p software, possibly integrating into existing BitCoin software;

Dear BitCoin developers and mining pool owners,

Looking @ work of http://www.tricone-mining.com/limp.html and having experience with high performance stuff, I would like to point that overall many of these ways to deliver shares are highly suboptimal. As basically getwork/shares submission do not require such facilities of TCP like ORDER of packets sent/received from miner to bitcoind or pool. So individual packet acknowledgement would work better, especially when miner is behind of poor internet connectivity like myself.

So - I have proposal to stop re-inventing wheel all of the time and make this once and for many years. Also light-weight protocol would make burdens of ddos mitigation much easier. Basically unlike implementing HTTP protocol, this protocol when implemented even by not very skilled programmer could easily withstand gigabits of incoming bandwidth, just throw-in better network card into your server.

So - lightweight getwork protocol.

Single UDP packet may contain multiple messages, building up to 1400 bytes in size. 1400 choosen because mostly when you get access with several VPNs, your MTU would be cut down from 1500. So 1400 is safe compromise value. But mining client could correct this value to one of his choice. And even more - server shall not reply with more messages in single UDP packet, than client requested! So one could get 8 works to getwork requests only if client requested 8 getworks at once.

So - UDP packet is basically concatenation of several messages of following format:
struct msg_header {
  unsigned char msg_size;
  unsigned char msg_opcode;
  unsigned char msg_context_uuid[16];
};

struct msg_work {
  struct msg_header hdr; /* This is basically C-way of inheritation... in C++ this would be msg_work : msg_header */
  unsigned char work[80]; /* last 32-bit is nonce, but can contain bitstream unlock sequence (special for EldenTyrell) */
};

Opcodes:
REQUESTING WORK:
msg_opcode == 1  - getwork request, typically answer is 10, 11 or 12
msg_opcode == 10 - structure with msg_work returned, miner shall process that work
msg_opcode == 11 - getwork negative acknowledgement - too many requests, this opcode may be sent to friendly nodes
                             in case of too many getwork requests, so miner would not ambush server more;
msg_opcode == 12 - work is invalidated (when new block calculations started);

GETTING ANSWERS:
msg_opcode == 20 - answer message type is msg_work;
msg_opcode == 30 - successfully accepted msg_work;
msg_opcode == 31 - share rejected - stale;
msg_opcode == 32 - share rejected - invalid;
msg_opcode == 33 - share rejected - unknown;
msg_opcode == 34 - share rejected - duplicate;

FEDERATION OF SERVERS INTERNAL COMMUNICATION:
msg_opcode == 40 - I want to posses right to process this getwork request;
msg_opcode == 50 - I have no objection, proceed with that getwork;
msg_opcode == 51 - I have already processed that getwork, drop it;

TYPICAL MINER <--> BITCOIND OR POOL COMMUNICATION:
msg_opcode == 1  - sent from miner to bitcoind taking about 46 bytes to request work;
msg_opcode == 10 - 126 bytes (just 126! not 2 KB!) returned from pool to miner msg_work;
msg_opcode == 20 - msg_work with found nonce returned from miner to bitcoind;
msg_opcode == 30 - share is good - returned from bitcoind to miner;

Packet loss is ALWAYS handled on miner's side - if no reply received, request is re-tried with some delay,
with exponential backoff.

Bitcoind / pool NEVER retransmits packets on its own.

For miners behind firewall, special proxy can be launched that converts messages from TCP to UDP protocol. However
such proxies will be subject to DDOS attacks due to TCP itself... beware...

THEN - how DDOS mitigation can be implemented in this protocol (don't know whether this good for pool or for bitcoind):

Server collects frame of requests for say 100 milliseconds. On 1 Gbps internet that can be as many as 6'000'000 incoming messages for getwork. Then server should get only 100 to 1000 best getworks in his opinion from that buffer and silently drop rest of requests. How then server may choose ? Quite simply - by priority sorting - first server would rank higher those, who sent more shares within last 60 seconds, then sort by ip address, where ip that requested less getworks would rank higher to cut off botnets. Then drop all of the rest 5'999'000 requests. But well... if such protocol used through all stages, it can easily process 10'000 getworks per second on simple VPS!

Then - why UDP ?! Is it more complex ?

Actually not ... because in UDP it is EASY to setup replication of communication... Say you add up to your mining rig connected to ADSL additionally GSM or 3G internet... And you can transmit same getwork request over 2 channels simultaneously, and to 3 servers of your beloved pool.... That would increase traffic, but also would increase reliability by MAGNITUDE... So while pools are fighting 1% more or 1% less, many of miners loose about 2-3% for internet outages, some with bad internet connectivity loose about 10-12% (like me).

For TCP on other side you would always have hassle with maintaining connection state, etc. While in UDP you would have to remember _multiple_ miner "return addresses" for about 60 seconds, while getting packets from him is actual. And you would broadcast answers to all of these addresses.

I am going to implement this protocol soon for own purposes, but it ridiculous when finally I convert all of that into HTTP-JSON based getwork.

So I wanted to ask:

1. Who also would support such initiative/have similar problems ?

2. How code to bitcoind should be submitted/approved ? Is this addition subject to be added to existing bitcoind ? As maintenance of separate patch-set could be quite boring... Also there may be questions on how this would be implemented in best way (say bitcoind mainly relies on boost::asio).

Kind regards,
V. // BitFury :-)

Dear BitCoiners, BitCoin talk users!

First of all I would like to thank to other developers of Spartan-6 based works, especially those who contacted me soon - shalab.si, fpgamining.com team, Greg and all those who understand how hard that work is. Also I would like to thank all those who supported me during development of these mining racks and invested money, so I haven't went into "preorder"
fall like offering more Mh/s power than hardware actually could deliver.

I am actually in love with bitcoins, because this is exactly the thing I lacked in 2006 year, and tried hard to invent... Unfortunately I were not smart enough to find out proof-of-work based blockchain. And this solution actually useful even in wider range of applications than money transfer themselves, as it can limit or remove human factor in distributed database consistency. It is interesting how this will evolve.

Second, I was surprised by reaction about comparision with ButterFly Labs with 'Estimated price'. People, that's $90k is with 20% VAT, which is not paid in US for example and with having in mind that it would have single hot air outlet and that's all about it... but to get mini-rig we would pay +20% on customs VAT, so it would be not $15'295 but $18'354 + shipment costs, so it is $0,728 per Mh/s. We've spent on boards production about $0,50 per Mh/s and on installation about $0,12 per Mh/s, totalling $0,62 per Mh/s. Count bitstream offer (it will be later in this topic) - it would be $0,69 per Mh/s. SO IT IS $0,03 LESS THAN THAN BFL Mini-Rig and it really works for almost 2 month, so we are sure now that it does not fry chips etc. We have not even managed to fry chip, when fed it with 1.5 V VCCINT core voltage. But, price would be definately higher (near estimated production cost), if counted other issues, like climate control, getting specialized area for them, getting power (as it consumes 20 kW together with chiller). All of these costs were already paid, because it is installed in basement of household with already existing heat pump.

Third, 300 Mh/s is not limit of this bitstream, it can give even more rounds, if you count that almost all DSPs are not used in left part of design, and some free space in topmost part. So it could definitely give 8% at least better performance, it would then cost to us $0,57 per Mh/s, which is even less than BFL Mini-Rig.

I've been asked by email and skype about smaller editions. And I would say that in my opinion best solution would be standard 4-U chassis, 0.5 meter long, with 14-15 boards with 6 chips on board installed (that is 84 - 90 chips), like with shalab.si original ideas, but a bit different layout to prevent overheating chips. Withing this chassis single Intel Atom D525 motherboard is installed. Boards with 6 spartans can be even without microcontrollers and flash, everything could be programmed right via LPT-port. Bandwith required to communicate with every chip is quite low - about 300 bps. So with all chips it would be about 27 kbps. Bitstream loading over LPT port however will be slow. For smaller scale RS-485 is overkill. Why to bother about it and not implement using USB - simply because flashing chip or flashing controller
adds up cost of controller and also costs of programming and testing them, also when something should be updated, and you have to reprogram every controller - that rises service cost. I would like to say, that current design of BitFury rack, where controller only translates RS-485 to SPI bus with Spartan and back requires almost zero maintenance.

Cost of such chassis with power supply and Intel ATOM motherboard could vary in $400 - $600 range. Cost of Spartan6 chips when purchased in bulk quantities (WITHOUT VAT) would vary in $70 - $95 range, depending on shipment location and quantity of chips ordered. Cost of other components (using numbers from our current design):

motherboard 4-layer $111 ($24,5 PCB and $8,53 soldering), daugthercard 6-layer $18.39 ($2,2 PCB and $5,5 soldering). these are costs with components with VAT and connectors. If connectors will be removed and VAT will be removed, then cost would be like $77,7 for motherboard for 6 chips and daugthercard $12,83 . Totalling $154,68 per board .

So server with 14-15 boards could cost in range $8'445 to $11'470. More likely that actual manufacturing cost plus work will be somewhere about $10'000 to $10'500. Then, say it would have 90 chips. I would point out how important Mh/s  are:

BFL Mining rig quite comparative product promised to be sold at $15'295 for 25,2 Gh/s - that is $0.607 per Mh/s

200 Mh/s bitstream - would produce 18 Gh/s - it would be compared to 71% of Mini-Rig and so product price could be $10'859.
250 Mh/s bitstream - would produce 22.5 Gh/s - it would be compared to 89,2% of Mini-Rig and so product price could be $13'643.
300 MH/s bitstream - would produce 27 Gh/s - it would be compared to 107% of Mini-Rig and so product price could be $16'365.
325 MH/s bitstream - would produce 29.2 Gh/s - it would be compared to 116% of Mini-Rig and so product price could be $17'722.

So at 200 Mh/s - there's almost no difference between bulk order and product price. At 250 Mh/s there's $3'143 income.
At 300 Mh/s there's $5'865 income. And at 325 Mh/s there's $7'222 income. Additional 50 Mh/s per chip gives 86%  income increase if prices are set at BFL levels of $0.607 per Mh/s. Additional 75 Mh/s per chips gives +129% income.

Calculating these costs and also costs handling sales, manufacturing etc. lead me to following licensing targets for about 1000 chips per month installed:

$20 - $25 per chip (depending on chip price and costs incurred by AES-key programming) for current bitstream and
$5 - $7.5 for future upgrade (separately), which can be opted when such update actually done.

From our side most important point is bitstream protection. This incurs costs of AES-key programming by moving trusted person to assembly plant from time-to time, powering on boards and fusing chips with AES-key. For simplicity it would be great to have 6 spartans on single board tied on JTAG line via buffers. Then encrypted bitstream could be available without any additional protection to it. Of course if quantities will be small and location distant, it would be difficult to execute programming. We are already planning to program chips with AES key in Hong-Kong, and we have good access to EU, because we are located in Ukraine. Existing boards could be upgraded as well.

Also - why I am insisting that 4U design one of the best sizes:
1) it would consume 1.3 - 1.5 kW per 4U, and that fits into envelope 350W per 1U heat production, which is not difficult
to implement in either datacenter or homebrew setup;
2) Chassis itself could be sold with minimal margin, so people could build mining power within nice chassis step by step;
3) When local price to electricity would be unaffordable, people can send what they built to Iceland for $0.04 per kw*h
special setup, so compatibility with datacenters is nice feature;
4) It gives $1'800-$1'900 "entry-level" price and board-by-board upgrade possibility;
5) "special single board" can be available as well - with USB, and it would be nice option that it can be put into server,
basically I expect to lower costs to have boards with pads for USB-related components, just they will not be soldered for
items that will be put into servers;
6) also it would be nice to have some DRAM on board for other purposes, but again - this would be not soldered at all, but later, if boards will be re-used for other tasks such DRAM capability and at least 1G ethernet external connectivity would make difference for long-term product life. At stage of PCB design it adds only NRE costs of designing PCB itself, and no cost at manufacturing.

Thinking where equipment will be placed - in small quantities - probably in homes, but when it will get larger - I have already found location and discussed this issue with Andreas Fink (Skype: andreasfink ) from datacell.com

[5/22/2012 10:24:36 AM] Andreas Fink: Our datacenter is designed for 20kW cooling per rack
[5/22/2012 10:24:37 AM] bitfury.org: but if air inlet drops 10 degrees Celsius, performance can be increased. and optimal temperature is about 0 degrees Celsius if we use industrial chips. that gives 20% performance increase.
[5/22/2012 10:24:44 AM] Andreas Fink: we use hot aisle concept
[5/22/2012 10:25:17 AM] bitfury.org: buyers of these devices actually concentrate on pure performance and cost of electricity, cooling etc. many of them installing such installations right at home, because it is cheaper.
[5/22/2012 10:25:27 AM] bitfury.org: you can google for "bitcoin mining"
[5/22/2012 10:25:40 AM] Andreas Fink: Well we operate our datacenter in iceland. energy is cheap there and coolign is easy.
[5/22/2012 10:27:05 AM] Andreas Fink: We could build a custom datacenter just for that if there's enough demand.
[5/22/2012 10:28:05 AM] Andreas Fink: what is the potential of your installation if it produces bitcoins?
[5/22/2012 10:29:38 AM] bitfury.org: very difficult to say, because we have just started to announce our solution.
[5/22/2012 10:29:54 AM] Andreas Fink: a rough estimate to get an idea.
[5/22/2012 10:29:54 AM] bitfury.org: current bitcoin network hashpower is 10'000 Gh/s, single bitfury produces 110 Gh/s
[5/22/2012 10:30:03 AM] bitfury.org: so estimation is about 30-40 racks
[5/22/2012 10:30:28 AM] bitfury.org: that's potential for FPGA bitcoin mining.
...
[5/22/2012 11:37:42 AM] Andreas Fink: the electricity company charges like 3-4 eurocents per kWh
...

It depends - if we manage to start with 4U working with them and without using diesel/ups-backed power which is  expensive and climate control equipment - it would be cheapest collocation for mining available in world.

[5/22/2012 11:02:04 AM] Andreas Fink: http://www.sgi.com/products/data_center/ice_cube_air/
[5/22/2012 11:02:17 AM] Andreas Fink: put them in such a shelter, we provide power and internet and put it into the green field

I suppose that shelter should be designed as well as SGI could be expensive, but generally you've got the point. And that is why I am sticking with rackmount design. It will be big pain to move devices that are non-compliant with datacenters, putting Mini-Rig there for example. I suppose this is the moment, when buyers of BFL should start thinking twice, what they would do with their rigs, when income will be about the same as consumed power. For myself that problem is solved - mining equipment is integral part of house heating now. For cold countries this can be as well solution - integrating house / DHW heating with mining. Today you will probably say that it is absolutely crazy, but 5 years in the future things would change, and those who make useful use of excessive heat will save on electricity bills, while those who will pay additionally for air conditioning would loose, as they could not compete.

So finally, I would welcome everyone interested to join efforts. First - design chassis and PCB with more-or-less interexchangable parts. Getting for example with-USB and without-USB version, with-flash and without-flash version, etc. so actual board can be customized by needs of our partner who provide product, but in general they all are near the same, and could be fitted inside 4U chassis. This way we can save on designing this thing, build product in which our customers will be confident, that even if one supplier stops selling boards, he can possibly with higher costs order elsewhere, but still finish his 4U box. More important is different metal pieces like holders of boards, etc. Which would depend on supplier of these chassis solution.

I am going to provide soon draft of 4U box, as I see it in 3D with airflow calculations. For those who asked about current interface, I am attaching right into this message .vhd source code of bitstream side, current .ucf file (but please, it can change - we used 1 mm FGG484C, and it could be possibly better to use CSG 0.8 mm steps), only important point that communication enters BOTTOM of chip. And communication part in dsPIC33F firmware. As you probably would see - same communication can be performed over LPT port without bothering with production of additional conversion boards.

Here are links to download:
http://www.bitfury.org/bfdetails/sha_top.ucf
http://www.bitfury.org/bfdetails/sha_top.vhd
http://www.bitfury.org/bfdetails/shaspi.vhd
http://www.bitfury.org/bfdetails/jobs.c

Meanwhile - we used FGG484 because we though to put more bypass capacitors below chip for overclocking purpose, as with CSG there
will be difficult to place such numbers of capacitors. However we've aimed for 320 Mhz that makes too much errors, with 240 Mhz
it would be fine to place less capacitance, and also get industrial CSG chip, as this would remove any possible overheating problems.
CSG chips have about 1.5 times (!) lower junction-case thermal resistance according to datasheet. However this would be great to be
confirmed by someone who used CSG chips - I saw ZTEX used them.

So - how we shall proceed ? I suppose best way will be to:
1) Write to this topic, if you are in (possibly after getting in touch in skype: bitfury.org );
2) Writing estimated quantities per month, assembly plant location (place where chips can be turned on);
3) Writing your final destination where you are going to ship these boards for further packaging;
4) Writing number of chips you already use - because if there's many already - then possibly re-work on IR station could cost
   significantly less than buying new chips;
5) Writing your requirements to board - specifying way of Spartan programming, currently used interfaces (i.e. USB with USB chip name),
   so we can get common specification for board interfaces and chips that shall be on board. Probably for overclockers it would be nice
   to have ability of voltage setting.

Then next iteration will be to approve specification and doing PCB schematic design, and then doing layout, and
doing similar way with chassis. Hopefully there's people who like working 24 hours + night

Kind regards,
Mr. V // Skype: BitFury.org

PS. Special note for those who know me personally. I dislike indexing of personal information via google, etc, so please, do not write here - "oh I know this guy"... Write it in skype in personal communication (it will be visible at least for
special services and not to general johny hacker who mines information and would like to get some cash), not on public forums  or public web pages. And I discourage everyone from doing so with their information. Imagine that it is possible to enter your name to google not only to your friends and partners, but also to your foes, those who you even do not know...

PPS. I've also uploaded stats file http://www.bitfury.org/bfdetails/bitfury_status.txt with current number of working cores, you may see that some cores are not working, error rates.... There were no special handling with them - we've just put cores "as is" into motherboards, and there are no visible defects. We've not bothered replacing these cores. Just to those who say that it is not real thing

EDITED - also forgot part of conversation with Andreas Fink about Iceland VAT there is 25.5% but for collocated servers it is returned. So it is like having 0% VAT compared to 18-20% VAT in EU countries.