Наблюдаю интересную картину:
Если верить графикам с bitcoincharts.com, то сегодня ночью (незадолго до 4-х по Грнинвичу) была сделка с покупкой/продажей BTC по $12.5 за BTC!
При этом, у меня уже несколько недель болтается ордер на продажу 48BTC по $11 за штуку. И этот ордер висит до сих пор.

Вопрос: каким образом кому-то удалось продать по цене $12.5 до того, как сработал мой ордер?
Я чего-то не допонимаю?

Для испытаний софта необходимо начать с нуля ветку (т. е. запустить генерацию первого блока) в локальной сети, состоящей из 2-х машин. Зацепиться клиентами удалось, но как приступить к генерации, если ни одного блока пока не существует? Похоже, клиент просто не выдаёт задание для майнера...

А что, сабж больше не работает?
На "btcguild help" выдаёт список команд, а на остальные команды никакой реакции!

Итак, 5 минут до обещанного старта торгов на Mt. Gox...
Делаем ставки, куда рванёт BTC в момент старта. Вверх или вниз?

Читаю-читаю форум, да так и не пойму: чтобы майнить на 2-х GPU одновременно, мне нужно 2 майнера запускать, или существуют нормальные майнеры, которые умеют сразу на нескольких GPU считать?

Наконец-то нашёл время ознакомиться с документом.
Обнаружил много интересного.
1. Там написано, что "рассосавшиеся" транзакции (дословно: "похороненные под достаточным числом блоков") можно выкидывать, оставляя лишь дерево хешей. Мало того, далее говорится, что от старых блоки можно вообще, оставлять только хеши, так что блоки будут длиной всего 80 байт! Вопрос: это уже реализовано? Если да, то мне вообще, не понятен кипиш с ростом истории (а точнее, размера блоков). Какая разница, насколько большим вырастет блок, если рано или поздно от него останется всего 80 байт хеша?

2. Там же написано, что простому клиенту (который лишь получает и отправляет деньги и не занимается генерацией блоков, а значит и проверкой транзакций) вообще,  нет нужды хранить у себя историю. Ведь он доверяет сети, а значит, критерием достоверности транзакции для него служит количество подтверждений (длина цепочки блоков начиная с блока, содержащего транзакцию). Т. е. нам достаточно хранить на диске лишь список своих транзакций (id транзакции, номер блока, в который она вошла и хеш этого блока), а также, номер и хеш последнего полученного блока. Каждый раз, когда клиент выходит в онлайн, ему достаточно скачать блоки, которые пришли после последнего полученного, чтобы убедиться, что цепочка не была забракована. Опять же вопрос: реализовано ли такое поведение клиента? Пока я почему-то не наблюдаю такой опции и судя по размерам файлов blkindex.dat и blk001.dat, клиент хранит всю историю локально.

3. Поскольку полноценного широковещательного запроса в интернете сделать нельзя, то слабое место у сети вовсе не вычислительные мощности, а узлы, к которым можно цепляться. Достаточно загасить irc.lfnet.org и узлы из списка "seed nodes" и вновь подключающиеся просто не смогут подключиться к сети! По-моему, работы не так уж и много.

Прочитал тему http://forum.bitcoin.org/index.php?topic=3512.0 и пришёл к выводу, что это действительно, является серьёзной проблемой. В самом деле, если кто-то начнёт заваливать систему тупыми транзакциями, забивая ими блоки и заставляя "хорошие" транзакции висеть в очереди, то в системе не предусмотрено механизма для защиты от этого. Мало того, с ростом сети будет расти и количество транзакций в единицу времени. Однако, в систему заложен механизм саморегулирования, "благодаря" которому с ростом вычислительной мощности сети её "пропускная способность" остаётся неизменной: размер блока ограничен, а количество генерируемых блоков в единицу времени остаётся неизменным. Фактически, все ресурсы системы уходят на пустую бессмысленную работу. Таким образом, может настать момент, когда сеть перестанет справляться с потоком транзакций и стараясь ускорить прохождение (подтверждение) своей транзакции, пользователям придётся тратить огромные деньги в качестве комиссий.
Мм-да-сс... Не самая лучшая перспектива для "свободной" валюты.

Я предлагаю механизм для борьбы с "трафиком транзакций". Его можно назвать "Временное снижение сложности" или "Блоки с продолжением".
Идея такая: если при генерации очередного блока выясняется, что остаются лишние транзакции, которые существовали ещё до начала генерации этого блока, но так и "не поместились" в нём, в блок добавляется специальная запись о том, что данный блок будет иметь продолжение. Данная запись будет означать, что на время генерации следующего блока, сложность будет снижена в 2 раза. Встретив такую запись, клиенты начнут генерировать блок-продолжение, для которого сложность будет считаться сниженной в 2 раза. Соответственно, и сгенерирован он будет примерно в 2 раза быстрее, чем остальные блоки. Если и при генерации данного блока остались "транзакции за бортом", то в конце данного блока опять же, будет пометка о том, что у него есть продолжение. И для следующего блока сложность снизится ещё в 2 раза. Естественно, бонус за такие блоки тоже, будет начисляться во столько раз меньше, во сколько раз была занижена сложность при генерации блока, чтобы нельзя было спамить систему левыми транзакциями, ускоряя тем самым эмиссию биткойнов. Как только будет сгенерирован блок, в который вошли все транзакции, он уже не будет содержать пометку о продолжении. Это и будет сигналом о том, что сложность генерации возвращается к исходному значению.

При использовании данного механизма, злоумышленнику удастся лишь временно (на время атаки) немного увеличить частоту генерации блоков. И не более. Это сделает атаки бессмысленными, а сеть более надёжной и быстрой.