Видимо придется ждать, когда разработчики запустят заложенную в протокол функцию отложенных транзакций lock_time, если это вообще произойдет  lock_time уже есть и работает, правда без возможности управления через RPC (если только в новейших версиях не появилось, давно не следил за темой). Если хотите манипулировать lock_time'ом, можете воспользоваться моим скриптом: https://bitcointalk.org/index.php?topic=439210.0 — там, правда, bitcoind на bitcoin-cli поменять надо для новых версий Bitcoin Core. Сам метод я уже как-то раз описывал: возможно ли какой-то специальной командой в консоли временно(!) выключить определенный адрес из биткоин-сети?
А цель? Заблокировать средства до определённого момента времени, и чтобы их нельзя было перевести куда-либо кроме in? Тогда так: создаём временный кошелёк, переводим на один из его адресов (intermediate) средства, после перевода создаём транзакцию intermediate→in с требуемым временем разблокирования (locktime), транзакцию сохраняем, временный кошелёк уничтожаем. После locktime публикуем сохранённую транзакцию. |
|
|
|
{ my_adress_1: 1.BTC -> to_adress, my_adress_2: 1.BTC -> to_adress, my_adress_3: 1.BTC -> to_adress ... } ?
Вы неправильно понимаете смысл транзакции. Транзакция — это единый перевод монет с произвольного списка адресов (точнее, входов) на произвольный список адресов (выходов). Т.е. транзакцию лучше представлять так (пример): { (my_address_1: 1.BTC, my_address_2: 1.BTC, my_address_3: 1.BTC) -> (to_address_1: 0.8 BTC, to_address_2: 2.2 BTC) }
или в bitcoind есть команда отправить 20 BTC на адрес без указания адресов списания?
Разумеется. Банальные sendtoaddress/sendmany. Это для того, чтобы указать адреса списания, нужны более нетривиальные действия. |
|
|
|
2) ВСЕ клиенты используют блокчейн тем или иным образом. Без блокчейна ни один клиент работать не сможет
почему все используют блокчейн? почему нельзя самому сделать решение не хуже блокчейна? что особенного в блокчейне? Есть блокчейн, который цепочка блоков (БД, копия которой есть у всех полновесных кошельков), а есть блокчейн, который https://blockchain.info. apxu имел в виду первый вариант, а вы, подозреваю, второй. |
|
|
|
При использовании sendmany как рассчитывается комиссия?
одна на все транзакции или на каждую?
и еще вопрос, сколько за раз может быть транзакций за один sendmany?
Один sendmany — одна транзакция (с несколькими выходами; обычно (sendfrom/sendtoaddress) их два). Соответственно, первый вопрос смысла не имеет. |
|
|
|
еще вопрос, что за массив walletconflicts в транзакции ? какие там данные могут быть?
walletconflicts — это список хэшей malleable транзакций. Например, отправили вы куда-то энную сумму и получили один хэш, а в блокчейн попал другой хэш той же по сути транзакции. Оба этих хэша будут выдаваться listtransactions, а в walletconflicts они будут ссылаться друг на друга. У меня такое было один раз. При приёме монет скорее всего будет то же самое, если до кошелька аналогично дойдут разные хэши одной транзакции. |
|
|
|
Если хакеры оказываются умнее программистов - то во-первых таким программистам не место в программировании,
а во-вторых такие поделки должны быть выкинуты и заменены на надежный софт...
1. Математик != программист 2. Программист != хакер 3. Хакер != скрипткидди 1. Создают ПО типа OpenSSL в первую очередь математики, хорошо разбирающиеся в предметной области (криптографии). Прикажете им не писать код? Ну-ну. Весело будет смотреть на уязвимый, но архитектурно вылизанный код. Debian OpenSSL bug помните? 2. Умение программировать (под этим я понимаю в первую очередь создание архитектуры системы и старания по поддержанию её при воплощении идеи в код) ещё не означает умения находить потенциальные бэкдоры в своём коде. Да и требования к безопасности у разного софта разные. 3. Умение пользоваться метасплойтом или подобными инструментами само по себе не делает человека хакером. Т.е. это ещё не означает, что он сможет сам найти уязвимость в коде. А чем больше народу сможет проверить исходники - тем больше ошибок будет найдено.
Отчасти верно, но сможет проверить и проверит — разные вещи. У больших одноранговых команд есть одна проблема — большинство ждёт, что задачу решит (сделает код-ревью в нашем случае) кто-нибудь другой. Вдобавок, удерживать в голове при чтении все взаимосвязи проекта смогут только глубоко в него погрузившиеся люди. У многих ли возникнет желание тратить на это своё время (много времени), да ещё и бесплатно? вот для этого и надо сделать сертификацию и опросы/голосования, если иходники не понятен для всех то его надо срочно начинать переписывать, пока не хакнули
Для всех? В этом случае команды разработчиков любого ПО рискуют быстро превратиться в бесплатные обучающие центры. Делом когда заниматься? Ошибки в ПО будут всегда. С этим следует смириться. Помочь может разве что формальная верификация, но она даже для космических проектов не делается (не всегда, не полностью, не для новых условий — нужное подчеркнуть), что уж говорить о рядовом софте. Почитайте, интересная статья. Кстати, использовалась Ада |
|
|
|
Собственно, в шапке форума новость появилась. Для тех, кто не очень в ладах с английским, краткий пересказ стартового поста из "More info": Если вы пользовались графической версией 0.9.0 на любой платформе, вы должны обновиться немедленно. Если это пока невозможно, остановите клиент. Если вы когда-либо использовали payment protocol (при отправке платежей обрабатывали кошельком ссылки вида "bitcoin:"), то считайте, что ваш кошелёк скомпрометирован. Сгенерируйте новый кошелёк (не просто новый адрес) и перешлите на него все ваши биткойны. Старый кошелёк не удаляйте. Если вы используете другую версию клиента или консольную 0.9.0, уязвимость вас затронет только при использовании command-line опций rpcssl. Если вы запускали клиент с ними, и атакующий мог достучаться до RPC порта, следует считать кошелёк скомпрометированным. В противном случае немедленных действий не требуется. Если вы используете бинарный кошелёк, скачанный с bitcoin.org или SourceForge, обновление одной только системной библиотеки OpenSSL не поможет. Download 0.9.1AnnouncementДругое ПО (включая другие кошельки) также может быть затронуто багом. OpenSSL очень распространена. |
|
|
|
Уязвимые на данный момент версии: 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1, 1.0.2-beta1.
Эта уязвимость затрагивает множество программ, не только Tor — каждый, кто запускает https-сервер или клиент может быть потенциальным противником или жертвой: возможна утечка памяти всех процессов, использующих OpenSSL (например веб-сервера, VPN и др). Если вам нужна стойкая анонимность и приватность в интернете, то стоит подумать о прекращении использования интернета на ближайшие несколько дней до исправления уязвимости. Как сообщают разработчики OpenSSL, им удалось обнаружить и устранить критическую уязвимость в популярной криптографической библиотеке. Согласно опубликованному экспертами бюллетеню безопасности , причиной появления бреши послужило отсутствие проверки границ данных в компоненте Heartbeat , который используется протоколом TLS/DTLS.
Стоит отметить, что уязвимость позволяет потенциальному злоумышленнику удаленно получить неограниченный доступ к оперативной памяти системы, использующей OpenSSL. Атакующий может раскрыть любую информацию, которая должна передаваться в зашифрованном виде, не оставляя при этом никаких следов компрометации.
Исследователи также отмечают, что данная брешь присутствовала в OpenSSL с марта 2012 года, когда была выпущена версия 1.0.1. В связи с этим разработчики настоятельно рекомендуют не только обновить библиотеку до актуальной версии 1.0.1g, но и обновить используемые в настоящий момент секретные ключи и сертификаты. Пока не разобрался, влияет ли эта уязвимость на кошельки (OpenSSL большинством из них используется), однако рекомендую быть готовым к срочному переводу своих койнов на свежесгенерированные адреса (причём не из пула заранее сгенерированных адресов, лучше создать полностью новый кошелёк). |
|
|
|
Второй вопрос. Бунт пулов. Сложность растет - асики стоят дорого и будут стоить дорого. Количество асиков увеличивается. Выручка падает. А покупку асиков нужно оплачивать. У пулов нет другого пути как объявить бунт и прекратить обработку транзакций без комиссий за перевод, а в будущем и прекращение обработки с маленькой комиссией. И никто им ничего не скажет. Сложность растет - закупаются новые асики - сложность еще вырастает - выручка падает, а асики уже куплены - повышается минимальная плата за транзакцию - цена одной транзакции увеличивается - оборот коинов падает, уже не выгодно оплачивать мелкие покупки в магазинах и осуществлять мелкие переводы - цена за биткоин вслед за оборотом падает - выручка за майнинг падает - минимальная комиссия за транзакцию возрастает - и так до краха.
Поднятие комиссии не в интересах пулов. Как вы правильно заметили, это ведёт к меньшей привлекательности койнов и падению их стоимости. А вот асики пулам (обычно) оплачивать не надо — они лишь собирают мощности, владеют этими самыми мощностями рядовые майнеры. Кроме того, если какой-нибудь пул решит ввести минимальную планку для комиссий, ничто не помешает майнерам перейти к другому пулу. Вопрос третий. Раздавленные яйца. Манить соло уже не выгодно - все собираются в пулы. А пулы - это узкие горлышки всей защиты криптосистемы. Со временем находятся люди (их немного), которые организуют работу пулов. А может быть они изначально были известны. Им наступают на яйца и заинтересованные лица получают доступ к узким горлышкам всей защиты сети. Небольшое изменение ПО и атаку 51 можно провести с помощью сил пула, пулов.
Атаку 51 с помощью пула можно провести один раз. Как только какой-нибудь пул или группа пулов будут в этом замечены, свою долю в суммарном хэшрейте они резко потеряют из-за оттока майнеров. Для полноценной атаки 51 нужно владеть мощностями, а не просто привлекать их. |
|
|
|
target = (bits & 0xFFFFFF) * (256 ** (bits >> 24)) ** — возведение в степень. По-русски: старший байт bits — порядок (256-ричный), остальные три байта — мантисса. Её старший бит в свою очередь является знаковым (по историческим причинам), поэтому допустимый диапазон мантиссы — от 2 15 до 2 23-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. В частности, можно разным адресам назначать одинаковые метки.
|
|
|
|
UPD. Да, и неплохо бы ограничители на цену ввести. А то так легко можно на порядок ошибиться Имеется в виду при вводе суммы заявки? При вводе курса, хотя бы предупреждение показывать при выходе за некоторые границы. На паре LTC/BTC такой треш творится И ещё — хотелось бы, чтобы сообщения были отсортированы от более новых к более старым, а то пролистывать каждый раз неудобно. А если ещё можно было бы выделять сразу несколько (чтобы помечать прочитанными или удалять сразу группой), то было бы совсем хорошо. |
|
|
|
Доход, надо полагать, идёт в карман биржи, а не покупателям (которые в данном случае могли бы купить дешевле, если по-честному)... Ай-яй-яй!  Вообще говоря, непохоже. В публичном отчёте о последних сделках указана именно цена исполнения, вряд ли покупатели у себя внезапно обнаружат, что реально купили по более высокой цене. UPD. Да, и неплохо бы ограничители на цену ввести. А то так легко можно на порядок ошибиться |
|
|
|
Неожиданно обнаружилась одна вещь - на местной бирже заявки исполняются не по цене предложения в стакане, а по цене, указанной в самой заявке. Например, есть несколько заявок на покупку битков: | Rate | Quantity | | 18199 | 1 | | 18198 | 1.5 | | 18197 | 0.5 |
Допустим, мы хотим удовлетворить все указанные заявки, продав 3 битка. Указываем цену с запасом - 18195 р. Обычно на биржах мы получаем 18199*1 + 18198*1.5 + 18197*0.5 здесь же заявки исполнятся по цене 18195, и мы получим 18195*3, потеряв на некорректных ожиданиях 9.5 р. Будьте внимательны. |
|
|
|
Но пользователям прийдется обязательно всегда читать QR-код с экрана для проверки подлинности каждой транзакции и потом еще код вводить. То есть этот способ будет работать только для смартфонов с нормальными камерами. И это, очевидно менее удобно, чем в онлайне одной кнопкой подтвердить.
Я так понимаю, что TapLogin просто по другому каналу с сайтом соединяется (по другому зашифрованному соединению общается)? Тогда, если нужно обойтись без QR-кода, можно присылать эту транзакцию клиенту на смартфоне в онлайне аналогично TapLogin'у. Но можно сделать такой способ опциональным. То есть, чтобы его можно было установить вместо Таплогина, тем, кто желает.
Я был бы обеими руками за Необязательно даже именно этот алгоритм, главное открытость. |
|
|
|
По поводу TapLogin — он опенсорсный? Мой внутренний параноик отказывается использовать проприетарный код для подобных целей Если нет, могу предложить такой вариант в духе Google Authenticator: 1. https://www.ietf.org/rfc/rfc2104.txtHS = HMAC-SHA1(K, text) K — ключ text — авторизуемая транзакция в человекочитаемом текстовом виде. 2. https://www.ietf.org/rfc/rfc4226.txtOTP = Truncate(HS) На RFC 4226 непосредственно ссылается Google Authenticator ( RFC 6238). Соответственно, можно текст транзакции отображать хоть на сайте QR-кодом, пользователь считает его телефоном, проверит корректность транзакции на телефоне, после чего введёт одноразовый код. UPD. В text очень рекомендую записывать также время формирования транзакции и не разрешать переводы, подтверждающий код на которые приходит очень поздно. Иначе взломщик сможет тупо последовательно перебрать все комбинации OTP для своей транзакции. |
|
|
|
То, что вторая попытка отправки прошла, говорит и о том, что не было применено transaction malleability, иначе это была бы двойная трата.
Двойная трата случится, если транзакцию готовить вручную (createrawtransaction / signrawtransaction), используя одни и те же входы. А вот при обычной отправке (sendtoaddress / sendfrom / через GUI) вторая транзакция вполне может пройти — просто другие входы расходоваться будут. Впрочем, это не наш случай: transaction malleability, видимо, не получился бы по той причине, что я опустошал кошелек подчистую на тот момент. Т.е. для двойной траты не было необходимых условий, как минимум Для dunup на будущее. Вручную транзакцию пнуть можно так ( txid — идентификатор зависшей транзакции): 1. getrawtransaction <txid>2. Берём полученный кусок данных (транзакцию в сыром виде), вставляем его сюда и нажимаем "Submit transaction". Естественно, проверять добросовестность менялы нужно самостоятельно, кошелёк за вас этого не сделает. Вы перегружаете комп, достаете бэкапы, вводите пароли - в общем делаете то, что мошеннику нужно - он записывает.
Повторюсь, мои выводы скорее всего неправильные - слишком уж фантастически.
Ничего фантастического — почитайте эту историю (кстати, обратите внимание — автор разбирается в теме, но ему это не помогло). dunup'у советую перепроверить комп, а то и начисто переставить систему. |
|
|
|
|
Show Posts
