lock_time уже есть и работает, правда без возможности управления через RPC (если только в новейших версиях не появилось, давно не следил за темой). Если хотите манипулировать lock_time'ом, можете воспользоваться моим скриптом: https://bitcointalk.org/index.php?topic=439210.0 — там, правда, bitcoind на bitcoin-cli поменять надо для новых версий Bitcoin Core.

Сам метод я уже как-то раз описывал:

Вы неправильно понимаете смысл транзакции. Транзакция — это единый перевод монет с произвольного списка адресов (точнее, входов) на произвольный список адресов (выходов). Т.е. транзакцию лучше представлять так (пример):

Разумеется. Банальные sendtoaddress/sendmany. Это для того, чтобы указать адреса списания, нужны более нетривиальные действия.

Есть блокчейн, который цепочка блоков (БД, копия которой есть у всех полновесных кошельков), а есть блокчейн, который https://blockchain.info. apxu имел в виду первый вариант, а вы, подозреваю, второй.

Один sendmany — одна транзакция (с несколькими выходами; обычно (sendfrom/sendtoaddress) их два). Соответственно, первый вопрос смысла не имеет.

walletconflicts — это список хэшей malleable транзакций. Например, отправили вы куда-то энную сумму и получили один хэш, а в блокчейн попал другой хэш той же по сути транзакции. Оба этих хэша будут выдаваться listtransactions, а в walletconflicts они будут ссылаться друг на друга. У меня такое было один раз. При приёме монет скорее всего будет то же самое, если до кошелька аналогично дойдут разные хэши одной транзакции.

1. Математик != программист
2. Программист != хакер
3. Хакер != скрипткидди

1. Создают ПО типа OpenSSL в первую очередь математики, хорошо разбирающиеся в предметной области (криптографии). Прикажете им не писать код? Ну-ну. Весело будет смотреть на уязвимый, но архитектурно вылизанный код. Debian OpenSSL bug помните?
2. Умение программировать (под этим я понимаю в первую очередь создание архитектуры системы и старания по поддержанию её при воплощении идеи в код) ещё не означает умения находить потенциальные бэкдоры в своём коде. Да и требования к безопасности у разного софта разные.
3. Умение пользоваться метасплойтом или подобными инструментами само по себе не делает человека хакером. Т.е. это ещё не означает, что он сможет сам найти уязвимость в коде.

Отчасти верно, но сможет проверить и проверит — разные вещи. У больших одноранговых команд есть одна проблема — большинство ждёт, что задачу решит (сделает код-ревью в нашем случае) кто-нибудь другой. Вдобавок, удерживать в голове при чтении все взаимосвязи проекта смогут только глубоко в него погрузившиеся люди. У многих ли возникнет желание тратить на это своё время (много времени), да ещё и бесплатно?

Для всех? В этом случае команды разработчиков любого ПО рискуют быстро превратиться в бесплатные обучающие центры. Делом когда заниматься?

Ошибки в ПО будут всегда. С этим следует смириться. Помочь может разве что формальная верификация, но она даже для космических проектов не делается (не всегда, не полностью, не для новых условий — нужное подчеркнуть), что уж говорить о рядовом софте. Почитайте, интересная статья. Кстати, использовалась Ада

Собственно, в шапке форума новость появилась. Для тех, кто не очень в ладах с английским, краткий пересказ стартового поста из "More info":

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

https://blockchain.info/tx/ce015217fca74854fe13e8ca6e5286d1af52aaedb3d1942c45a1c987f6fa688a
Или она проходит по категории собственных?

Поднятие комиссии не в интересах пулов. Как вы правильно заметили, это ведёт к меньшей привлекательности койнов и падению их стоимости. А вот асики пулам (обычно) оплачивать не надо — они лишь собирают мощности, владеют этими самыми мощностями рядовые майнеры. Кроме того, если какой-нибудь пул решит ввести минимальную планку для комиссий, ничто не помешает майнерам перейти к другому пулу.

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

** — возведение в степень.
По-русски: старший байт bits — порядок (256-ричный), остальные три байта — мантисса. Её старший бит в свою очередь является знаковым (по историческим причинам), поэтому допустимый диапазон мантиссы — от 2¹⁵ до 2²³-1.

2. Аккаунты не обязаны быть номерами, это просто строки. Они в точности соответствуют меткам адресов в bitcoin-qt. Создание нового аккаунта с адресом: «getaccountaddress "ID 102325"» или «getnewaddress "ID 102325"».
3. Отдельной операции создания аккаунта не существует, есть только добавление адреса к аккаунту.
4. Я бы сказал, метка адреса. Одному аккаунту может соответствовать несколько адресов.
5. Да, но новые адреса берутся из пула предварительно сгенерированных адресов. Вот когда он исчерпается относительно предыдущего бэкапа, новый бэкап становится строго обязательным.
6. Ничего специфического по сравнению с просто ценными данными. Сохранить на разные носители и разнести географически (чтобы пожар не уничтожил сразу все бэкапы). Ну, разве что файл кошелька дополнительно в криптоконтейнер положить.
8. Не на запуск, а на любые операции, требующие закрытых ключей (подпись транзакций, дамп этих самых ключей). Как и в bitcoin-qt.
9. Приватные ключи/публичные ключи/адреса, транзакции с участием этих адресов, аккаунты. Комментарии к транзакциям вроде тоже. В зашифрованном, кстати, зашифрованы только приватные ключи, всё остальное в открытом виде.
10. Примерно так, только я бы сказал не доступ к сети, а доступ к средствам на счёте (адресе). Дабы не путать с доступом к сети Интернет.
11. 0.00001 (10^-5) btc вроде; правда, есть некоторая разница между paytxfee и relayfee. При соблюдении некоторых правил комиссию можно вообще не платить.
12. Ну, вносить в базу транзакции можно не в момент распространения по сети, а в момент включения её в блок. Впрочем, блок тоже может заорфаниться, так что исключения транзакций из базы также регулярно будут происходить. Кстати, в сторону abe смотрели?

Небольшой практический нюанс: bitcoind не отправит вторую транзакцию в сеть, ибо выходы он будет считать уже потраченными. Эксперимент нужно проводить так: готовим две malleable транзакции с помощью createrawtransaction/signrawtransaction, одну отправляем через https://blockchain.info/pushtx, одновременно вторую из кошелька посредством sendrawtransaction. Чем одновременнее, тем лучше.

Вдогонку: метка адреса в bitcoin-qt — то же самое, что и аккаунт. Можете проверить в консоли gui-кошелька командой getaddressesbyaccount. В частности, можно разным адресам назначать одинаковые метки.

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

Вообще говоря, непохоже. В публичном отчёте о последних сделках указана именно цена исполнения, вряд ли покупатели у себя внезапно обнаружат, что реально купили по более высокой цене.

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

Неожиданно обнаружилась одна вещь - на местной бирже заявки исполняются не по цене предложения в стакане, а по цене, указанной в самой заявке. Например, есть несколько заявок на покупку битков:
Допустим, мы хотим удовлетворить все указанные заявки, продав 3 битка. Указываем цену с запасом - 18195 р. Обычно на биржах мы получаем
здесь же заявки исполнятся по цене 18195, и мы получим 18195*3, потеряв на некорректных ожиданиях 9.5 р.
Будьте внимательны.

Я так понимаю, что TapLogin просто по другому каналу с сайтом соединяется (по другому зашифрованному соединению общается)? Тогда, если нужно обойтись без QR-кода, можно присылать эту транзакцию клиенту на смартфоне в онлайне аналогично TapLogin'у.

Я был бы обеими руками за Необязательно даже именно этот алгоритм, главное открытость.

По поводу TapLogin — он опенсорсный? Мой внутренний параноик отказывается использовать проприетарный код для подобных целей Если нет, могу предложить такой вариант в духе Google Authenticator:
1. https://www.ietf.org/rfc/rfc2104.txt
HS = HMAC-SHA1(K, text)
K — ключ
text — авторизуемая транзакция в человекочитаемом текстовом виде.
2. https://www.ietf.org/rfc/rfc4226.txt
OTP = Truncate(HS)
На RFC 4226 непосредственно ссылается Google Authenticator (RFC 6238).

Соответственно, можно текст транзакции отображать хоть на сайте QR-кодом, пользователь считает его телефоном, проверит корректность транзакции на телефоне, после чего введёт одноразовый код.

UPD. В text очень рекомендую записывать также время формирования транзакции и не разрешать переводы, подтверждающий код на которые приходит очень поздно. Иначе взломщик сможет тупо последовательно перебрать все комбинации OTP для своей транзакции.

Двойная трата случится, если транзакцию готовить вручную (createrawtransaction / signrawtransaction), используя одни и те же входы. А вот при обычной отправке (sendtoaddress / sendfrom / через GUI) вторая транзакция вполне может пройти — просто другие входы расходоваться будут. Впрочем, это не наш случай:

Для dunup на будущее. Вручную транзакцию пнуть можно так (txid — идентификатор зависшей транзакции):
1. getrawtransaction
2. Берём полученный кусок данных (транзакцию в сыром виде), вставляем его сюда и нажимаем "Submit transaction".
Естественно, проверять добросовестность менялы нужно самостоятельно, кошелёк за вас этого не сделает.

Ничего фантастического — почитайте эту историю (кстати, обратите внимание — автор разбирается в теме, но ему это не помогло). dunup'у советую перепроверить комп, а то и начисто переставить систему.