Киловатт-часы - это как раз и есть энергия. И не в час, а именно киловатт-час. Потому что "киловатт в час" - это киловатт разделить на час, а "киловатт-час" - это киловатт умножить на час. Энергия (и работа) - таки в Джоулях. А в Ваттах (и киловаттах) измеряется мощность. Мощность - это производная работы по времени. Физический смысл мощности - это работа произведенная в единицу времени. Т.е. 1 Ватт = 1 Джоуль / 1 секунду.
В киловаттах меряется мощность, а не энергия. Энергия имеет ту же размерность, что и работа, т.е. джоуль или, что тоже самое, 1 ватт х 1 секунду. Отсюда 1 кВт*ч = 1000 Вт * 3600 с = 3,6*10^6 Дж.
Если вы прочитаете квитанции внимательно, то увидите, что оплачиваем мы именно энергию, т.е. кВт*ч. И счетчики наши измеряют энергию, т.е. как раз кВт*ч, о чем на них недвусмысленно написано.
Путаница связана с тем, что в быту неудобно произносить "киловатт-час", вот и произносят "заплатить за киловатт", хотя с физической точки зрения - это грубейшая ошибка.

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

Очень странно. Собирал на многих платформах - везде было нормально. Почему-то не может найти объявление функции close.
Попробуйте в i2psam.cpp добавить еще один инклуд  unistd.h

продайте его гоксу, может хоть лагать перестанет

Если б сразу не переводили в доллары, интересно, как бы они мне зафиксировали курс >230? Из своего кармана что ли доплачивать будут?
Несколько раз переводил - все четко было. Со сроками - да, нужно что-то делать. А в остальном претензий нет, только комиссию бы поменьше. Помнится когда-то 3% была.

Exactly. That's why I made smallest changes as I could. And that's why there is i2p-patch only, not general "long-address" patch. Because it's too complex for this moment.

Sorry, I didn't understand you. What do you mean "ban blockchain"?

Yes, I thought about making it more abstract.
In general case there must be a method to negotiate a length of address and type of net. Different nets may have equal length of address.
Also current bitcoin code is hard to add new protocols. So adding general NODE_LONG_ADDRESS service is much more harder than add i2p protocol only. Probably adding a general long address support will cause a huge refactoring of the current bitcoin code.
I considered a "boost::asio" library as a base for this refactoring, but it's just in my thoughts yet.

IBM сама довольно серьезно поддерживает линукс. Поэтому дрова уже есть в ядре. Список оборудования из этого ящика поддерживаемого ядром 3.3 тут http://www.ibm.com/developerworks/linux/linux390/development_technical.html

Пруф на поддержку в дебиане: http://www.debian.org/releases/stable/s390/ch02s01.html.en#id381758

It's true. I've been beating my brains out trying to solve the problem. And my solution is...
Instead of thousand words:

I added a new service NODE_I2P to bitcoin protocol.
And I added a new serialization flag SER_IPADDRONLY. By default my client serialize both of ip-address and i2p-address. But if my client interacts with a node which is not support NODE_I2P service (vanila clients), I do serialize an ip-address only.

So, if my client connected to a node with NODE_I2P service it will send and receive full ip and i2p-addresses. If my client connected to a standard client it will send and receive only IPs. It's fully backward compatible with standard clients, except of "peers.dat" file.

With my patch you can run your wallet using i2p only ("-onlynet=native_i2p" option) or in a mixed mode. If you run the client in the mixed mode, your wallet will be like a gate between i2p bitcoin subnet and the rest net. If you run the client using i2p only, you have to communicate with the gates run in the mixed mode (maybe indirectly). Otherwise, your wallet will be separated from the rest net.

Let's say wallet1 and wallet3 running in i2p-only mode. And wallet2 running in mixed mode (gate).
In this case wallet1, wallet2 and wallet3 will communicate only through I2P. Wallet1 and wallet3 cannot communicate with the rest bitcoin net directly. But wallet2 will retranslate their transactions to the rest net. If wallet2 is down, wallet1 and wallet3 will be separated from the rest network. Some people help me and run their clients in the mixed mode with a static I2P-address. I add their I2P-addresses to source files as seed-nodes. That allows other people use the "i2p only" mode and do not fear to be separated from main bitcoin network.

As I know, blockchain shows IP-address of a node which first retranslate a transction. So I guess it will be an IP of a gate-node. Anyway no one can to know you real IP if you use "i2p only" mode. Moreover, you can firewall all your network connections except i2p-connections and your wallet will work.

Перевод:
Новый мейнфрейм z10 [здесь имеется ввиду именно мейнфрейм, а не процессор] эквивалентен примерно 1 500 х86 серверам [серверам(!), а не ядрам и не процессорам] по производительности.

[Меня терзают смутные сомнения, что производительность они мерили именно в майнинге.]

[из этой фразы становится понятно, что под 'the z10' они имеют ввиду именно мейнфрейм в целом]
Перевод:
Мейнфрейм z10 использует 64 4х-ядерных процессора специального назначения

Итого.
Ядра там не х86, и вряд ли ими когда-то будут, т.к. на этом основан многомиллиардный бизнес IBM.
По каким-то синтетическим, выдуманным самой IBM, тестам 64*4 z/ ядра эквивалентно 1500 х86 серверам (сколько ядер в этих серверах они в статье умалчивают). Частота z/ ядер 4,4 ГГц. Частота х86 ядер, с которыми они сранивают,  - неизвестна.
z/Архитектура родом из 60х-70х, когда x86 еще даже в проекте не было. z/Архитектура до сих пор сохраняет АБСОЛЮТНУЮ обратную совместимость со всеми своими предыдущими поколениями. Поэтому сравнивать в лоб частоты z/ ядер и х86 ядер нельзя в силу совершенно разной архитектуры.

Upd.
Кстати, из википедии
Так что эта железка стоит минимум миллион долларов.

Железка не такая уж и старая - максимум года два-три. По меркам мейнфреймов - совсем новая. Такие девайсы любят госкорпорации, финансовые учреждения, государственные структуры и прочий "серьезный бизнес". Даже средний бизнес просто финансово не потянет такую игрушку. А уж софт для нее стоит совсем заоблачных денег (десятки $млн. за одну софтину - это нормальная цена).

Ядра там абсолютно точно не х86.
На z/OS есть POSIX, хоть и примотанный на изоленту и подпертый костылями. Поэтому есть ненулевая вероятность собрать под нее cgminer, например. Ну или допилить его в крайнем случае.
Еще на этой железке можно запустить дебиан. Он поддерживает эту архитектуру. Под дебианом собрать майнер должно быть проще.
Однако, как уже сказали, администрировать эту железку КРАЙНЕ нетривиально. Да и быстродействие в майнинге вызывает у меня большие сомнения.

No. It's a service inside i2p, that allows applications to interact with i2p using simple (berkley) socket.
www.i2p2.de/samv3.html
Applications must be written with SAM support. You cannot run usual apps with SAM.

OK. I've got the bitcoins. Thank you.

Это понятно. Дело в том, что, похоже, в дебиане/убунте в пакетах нет статической qrencode, только so.

Подключайте тестинг репозитарий. Дебиан без тестинг репозитария иногда бывает уныл. Можно основные пакеты оставить стабильными (если это важно), а нужные подтягивать из тестинга или даже из анстейбла.
Или убунту ставить - по сути, тот же тестинг дебиан.

Спасибо, что откликнулись.
"Address + private key" отправлять никому не нужно, нужно держать в секрете.
Мне нужно отправить "Address (you can make it public)" и "Short base32-address".

Сообщения "Send:" и "Reply:" являются отладочными, их можно игнорировать. Пока я их вывожу в консоль (stdout). Со временем буду писать в лог-файл. Если они вас отвлекают, можно перенаправить вывод в файл

Чтобы статически слинковаться с библиотекой, она должна быть собрана как статическая библиотека, а не динамическая. Как я понял, в репозитриях дебиана/убунты статически собранной qrencode нет. Если вы уж так сильно хотите слинковаться с ней статически, вам нужно выкачать ее исходники и скомпилировать ее как статическую библиотеку, после этого линковать ее. Но я не понимаю для чего вам статически линковаться с библиотекой, которая по умолчанию есть в репозитариях - это не linux-way. Если этой библиотеки нет на целевой машине, то нужно просто ее поставить.

cannot find -lqrencode
т.е. библиотека просто не установлена

Надо установить саму библиотеку и девелоперский пакет для нее. В убунте так:

Update 28 Mar 2013
Merged with 0.8.1