Update 28.03.2013
Портированы изменения из официального клиента 0.8.1
Бинарники собраны с поддержкой QR-кодов.

бесплатный хостинг в i2p
http://open4you.i2p/index.html

P.S. мопед не мой

Тут меня в личке попросили пошагово описать. Повторим кое-что из первого поста.

1) качаем дистрибутив i2p только с официального сайта http://www.i2p2.de/download
2) если не установлена Java, установщик i2p сообщит об этом. Java надо скачать тоже с официального сайта http://java.com/download/
3) ставим сначала Java, потом I2P
4) идем Панель управления - Администрирование - Службы. В списке находим I2P, проверяем, что он запущен (если нет - запускаем).


5) в браузере открываем странцу http://127.0.0.1:7657/configclients. Если страница не открывается, это значит, что i2p не запущен (возможно возникли какие-то ошибки). После того, как страница открылась возле пункта SAM application bridge необходимо нажать кнопку Start, после этого поставить галочку в столбце Run at Startup?, потом нажать кнопку Save Client Configuration.

6) если i2p настроен можно запускать биткоин. Открываем командную строку. В винде: Win+R, набрать cmd, нажать Enter. В линуксе, и так понятно))
7) в консоли переходим в директорию, в которую распаковали архив с моими исполняемыми файлами (например, C:\bitcoin)
8 ) запускаем пропатченный клиент с параметром -generatei2pdestination

9) в появившемся окне видим три поля. И три кнопки для копирования содержимого в буфер обмена. Копируем весь текст из первого поля (можно соответствующей кнопкой).
10) открываем или создаем конфиг-файл для биткоина по адресу указанному здесь же в окне. пишем в него такое содержимое:
11) копируем текст из второго и третьего мне в pm, или постим сюда.
12) закрываем биткоин. запускаем снова уже безо всяких параметров. он загружается как обычно.

Готово.
Upd. Тесты показывают, что и с закрытыми портами работает нормально, поэтому убрал лишние картинки и описание того, как открыть порты для i2p.

Вчера отправил 1 бтц без комиссии - запечатали в первый же блок. Монеты были не старые ~80 подтверждений

Для развития проекта необходимы публичные сиды, т.е. кошельки запущенные в режиме гейта и с постоянным I2P-адресом (IP-адрес при этом может быть динамическим, порт 8333 наружу открывать необязательно, но желательно открыть порт, на котором висит i2p). Если у вас есть возможность держать i2p и пропатченный клиент запущенными, вы окажете огромную помощь проекту, опубликовав здесь или прислав мне в pm ваш i2p-адрес, я его добавлю как сид-ноду в исходниках готовящегося нового релиза. Сумма на запущенном кошельке совершенно не важна! Там может быть даже 0. Главное условие - это запущенный i2p (желательно с открытым портом), и запущенный клиент с постоянным i2p-адресом. Если вы не доверяете моей программе, можете запускать ее в виртуалке или на отдельной машине. Инструкции по настройке и ссылки на исходники и бинарники в первом посте.

Если это вас забанили, то сейчас заработало, потому что сменился i2p-адрес на новый незабаненный. Проверить легко: открываете файл debug.log (он лежит в той же директории, что и wallet.dat), ищите там строку

3-4 - нормально (в i2p пока мало людей).

Если вы собирали моими скриптами, то логично, что у вас получился такой же бинарник как у меня, т.е. без QR-кодов. В исходниках QR-коды уже есть, просто я собирал свои бинарники без библиотеки для работы с ними. awoland правильно все сказал, только если вы для винды собираете, то компилить  библиотеку нужно не g++, а mingw32. Ну и менять мои скрипты для сборки биткоина, или собирать вручную.

Прогресс бар я вообще не трогал. Ни одного символа не менял в том коде. Так что поведение отличаться не должно. У меня никаких проблем с прогресс баром нет. Я даже не представляю, как он может отображаться по-другому. Так что вам лучше сделать скриншот - я посмотрю. Также учтите, что если у кошелька мало подключений (1-2), прогресс бар может вообще не отображаться, хотя синхронизация будет идти - это нормальное поведение.

С соединениями - да, это особенность i2p. Дело в том, что при установке соединения к i2p-адресу, кошелек соединяется не с удаленным хостом (т.к. он просто не знает где тот находится), а с локальным i2p-сервисом. Т.е. сокет открывается на адрес 127.0.0.1. Естественно, при отваливании внешнего интернета соединения с 127.0.0.1 не рвутся, и кошелек будет отображать, что соединения есть. НО! Спустя некоторое время, либо i2p-сервис, видя, что инет отвалился, либо сам кошелек, не получая данные с этих сокетов в течение 60 сек, закроет эти сокеты. Так что при отваливании внешнего инета кошелек будет отображать наличие соединений еще максимум 1 минуту. После этого они все равно закроются. Если интернета нет меньше минуты, нужно просто подождать, пока соединения переустановятся. Это может занять ~10 минут: пока i2p или кошелек поймут, что соедиение уже не актуально, пока переустановят новые и т.д. Если интернета нет больше минуты, соедиения в кошельке не должны отображаться, т.к. кошелек должен сам их закрыть. После появления интернета, кошелек должен сам переподключится, но опять-таки не сразу, а в течение ~10 минут.

В SAM есть неприятный баг, иногда клиент больше не может открыть соединение http://trac.i2p2.i2p/ticket/492. В таком случае требуется перезапуск i2p-сервиса. Но этот баг проявляется крайне редко, у меня за несколько месяцев, он был всего один раз. Возможно, вы столкнулись с ним. Вообще, я обратил внимание, что i2p плохо или не всегда восстанавливает связь после долгого отсутствия интернета или при выходе из спящего режима. Перезапуск i2p-сервиса помогает. Кошелек при этом перезапускать необязательно. Перезапускать сервис лучше из браузера, на странице консоли i2p-роутера слева есть кнопка рестарт. При таком способе перезапуска, переинтеграция с сетью происходит за несколько секунд.

Еще одна особенность I2P, как и всех p2p-технологий, что качество связи сильно зависит от количества узлов, с которыми вы соединены. Поэтому лучше открыть входящие порты для i2p. На странице консоли i2p-роутера слева отображается количество пиров. Если пиров меньше 100 (обычно 10-20), значит ваш i2p-роутер не принимает входящие соединения (порты закрыты). При открытых портах количество пиров быстро становится больше 1000. Качество связи при этом улучшается значительно.

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

Если это ваш i2p-адрес,
то ваш адрес был забанен за Misbehaving, поэтому вы не можете больше соединиться.

Мне интересно сколько реджектов будет, и будет ли пул успевать раздавать задания, потому что задержки в I2P на порядок больше, чем в инете.
А вот биржа в I2P - это было бы прикольно.

сегодня в irc-чате на канале #i2p был интересный диалог

Однако интересна причина появления таких сообщений.

Забавный факт. С самого момента публикации моих i2p-адресов для коннекта. Кто-то пытается соединится по этим адресам, но посылает заведомо неверные данные. А после этого молчит. По истечении 60 секунд молчания мой кошелек автоматически закрывает соединение. Потом все повторяется опять. Адреса иногда меняются. В логе кошелька это выглядит так

Да, спасибо. Теперь нормально отображаются.
Я сначала подумал, что их сняли с торгов, поэтому они исчезли. Кстати, что-нибудь известно о дальнейших планах по этим бондам?

Тогда после установки линукса, ставь mingw32 командой
1 и 2 скрипт нужно запускать только при первой компиляции, все последующие (пере)сборки можно делать только скриптом 3.
1 и 2 скрипт пойдут без изменений, а 3 придется немного допилить, или повторять мою структуру каталогов.
Мои скрипты ищут исходники в ${WORKSPACE}/bitcoin-qt/src, где ${WORKSPACE} - это директория, где лежат скрипты.
Результаты работы первых двух скриптов кладутся в ${WORKSPACE}/dependencies.
Результаты 3-его (т.е. сами bitcoin-qt.exe и bitcoind.exe) кладутся в ${WORKSPACE}/release.
Еще в 3 скрипте можно использовать многопоточную компиляцию, что сильно ускоряет сборку на многоядерных процессорах
где n - количество потоков (обычно = числу ядер). Но многопоточная компиляция жрет много памяти, так что используй осторожно.

Спасибо

alpet
Расскажи нубу, как выглядит процесс покупки акций на бирже (например, btct.co). Откуда они узнают куда платить дивиденды? Как вообще выглядят эти акции, и где они хранятся? Каким образом осуществляется передача акций от одного человека к другому (раз их так легко прям на форуме продают)?

Если владеешь линуксом, собирай кросскомпиляцией под линуксом - это реально проще. У меня есть скрипты для кросскомпиляции https://github.com/VirtualDestructor/bitcoin-qt-i2p. Файлы 1.env-setup.sh, 2.build-deps.sh, 3.build-linux-mingw.sh.

У них была 0.8, это разрабы биткоина попросили их перейти на 0.7. Они владели более чем половиной мощности в 0.8 ветке, и ветка 0.8 побеждала, после их перехода на 0.7, ветка 0.7 стала сильнее. http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/12

Upd
Вообще ветка 0.8 была изначально сильнее и побеждала. Гэвин был за то, чтобы оставить все как есть
Но все остальные были против, после перехода гильдии на 0.7, ветка 0.7 победила.

Оно задется опцией командной строки.
Эта опция нужна для размера генерируемого именно этим кошельком блока. Вполне логично, что майнеры сами могут решать какие блоки им генерировать. Но если они уже сгенерировали блок, и он соответствует всем правилам, то остальные кошельки обязаны его принять, независимо от их настроек. А кошелек версии 0.7 отбросил правильный блок, просто потому что не смог записать его в базу.

Именно. Считаю, что в протоколе ограничения, не обусловненные какими-то фундаментальными причинами (например, разрядностью соответствующего поля), не нужны. Считаю, что ситуация, когда блок с 1700 (например) транзакциями верен, а с 1701 транзакией - нет, является бредовой. Клиент должен обрабатывать любое количество. Как он будет это делать - это уже работа программистов. И то, что они не справились - действительно фейл. Но фейл именно в клиенте, а не в протоколе. В конце концов, сатоши-клиент - не последняя инстанция, и в сети теоретически может быть куча разных клиентов, которые будут хранить свои данные, как им вздумается. Поэтому ставить какое-то ограничение на протокол только потому что 0.7 версия сатоши-клиента не может чего-то там обработать, т.к. кому-то было лень прочитать документацию на BDB во время проектирования - считаю глупостью. Надо фиксить баг и заставлять всех переходить на новый клиент, а старый выкинуть, как несоответствующий протоколу. А тесты - понятно, что нужны, в том числе и на соответствие протоколу. И понятно, что 0.7 не просто должна была отбросить этот блок, а кричать "ай-ай-ай не могу сохранить в базу, ахтунг!!! голактеко опасносте!!!!11!11".

Ситуация довольно проста.
Есть описанный протокол. В нем нет ограничений на количество и размер транзакций. Все клиенты должны придерживаться этого протокола. Но выясняется, что в версии 0.7 было скрытое ограничение на количество транзакций в блоке, о котором даже не знали сами разработчики. Оно было связано с каким-то внутренним ограничением BDB. Налицо несоответствие протокола и клиента. Если бы это был сторонний клиент, все бы сказали: "сами виноваты, что пользовались клиентом, не соответствующим протоколу", но ведь это "официальный" клиент. Выхода ровно два: подогнать протокол под кривой клиент или пофиксить клиент. Вы предлагаете подогнать протокол. Думаю, найдутся люди, которые с вами не согласятся. Лично я против внесения в протокол каких-то магических констант и непонятных ограничений. Я считаю, что правильный путь - это пофиксить клиент, т.е. заставить всех обновится до 0.8. Кстати, Гэвин предлагал именно этот путь. http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/12