Pull to refresh

Comments 32

Была та же проблема, когда пересылал кварки на криптси… Просто удалил все файлы в директории \AppData\Roaming\Quarkcoin\chainstate, запустил кошель. Он закачал по новой базу данных транзакций и монетки вернулись. Это куда быстрее, чем описанные выше пункты).

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

Я так понимаю, информация о транзакции хранится в wallet.dat. Вероятно, есть зависимость от клиента.
Плохо, что нет в апи метода resendtransaction. Этот ручной метод совсем не подходит для автоматизированных систем.

Как раз вчера в одной из криптовалют скрипт отправил несколько переводов, 1 дошел, 4 висят в мемори пуле на клиенте. Каждый раз вручную так проталкивать — сумасшествие.
Насколько я понял, эту роль выполняет связка getrawtransaction <txid> / sendrawtransaction <hex>. Но это лишь в теории, мне оно не помогло. Возможно, просто очень «повезло».
Мне тоже не помогло, TX rejected.
Странно. Конкретно при данной операции у меня TX rejected вылезал только когда я полученный HEX случайно прогнал через signrawtransaction, а уже результат кинул в sendrawtransaction. Если переотправлять результат в чистом виде, должен быть возвращен либо номер транзакции, либо «transaction already in block».
Факт того, что на локальном компьютере мы «забыли» о транзакции (импортировали приватный ключ в девственный валлет) ничего не говорит о том, что об этой транзакции забыли наши пиры и вообще вся биткоин-сеть. Я нигде не нашел данных о том, сколько времени в мемори-пулах на узлах сети хранится низкоприоритетная транзакция, которую никто не хочет включать в блок. Но, как правило, речь идет о таких копейках, которые не стоят того, чтобы о них задумываться.
Фактически же, если новая транзакция, отсылающая «зависшие» средства, попала в блок, то даже если вдруг проблемная транзакция отвиснет, она просто отмениться должна.
Велик и могуч русский язык (впрочем, в данном случае я думаю и в английском такая же ситуация).
Словосочетание «если транзакция попала в блок» можно понять как «транзакция заблокирована, застопорена, посажена в тюрьму», так и «транзакция подтверждена, проведена, закреплена в блокчейне».
Правильное толкование в данном случае — второе.
Вопрос мой в том, что «вторая транзакция» может попросту не дойти до майнеров, потому что ее не будут распространять узлы сети, имеющие в мемори-пулах первую транзакцию. А первая транзакция не будет попадать в блокчейн, потому что она низкоприоритетная.
Полагаю, что в контексте криптовалют попадание в блок всегда должно подразумевать именно положительное явление.

Вопрос интересный и хотелось бы получить разъяснение его от компетентных лиц. Мнения встречал противоречивые по этому поводу. Где-то говорили, что достаточно просто отправить транзакцию, которая потратит зависшие деньги, якобы она нормально уйдет, а зависшая будет отменена. С другой стороны, описание схем даблспенда подразумевало наличие своих значительных мощностей, что говорит об ошибочности слухов о простой отмене.
Эта тема регулярно всплывает в разных местах. Например, вот тут bitcointalk.org/index.php?topic=232979.0
Честно говоря, шерстить код и проверять сложно, тем более, что на обычных узлах сети и у майнеров софт может отличаться.
Да и со временем логика работы с низкоприоритетными транзакциями может меняться.
Повторю: проблема с зависшими транзакциями на сегодняшний день возникает только в случае экстра-малых переводов и не стоит того, чтобы тратить на это время.
Что вы подразумеваете под экстра малыми переводами? В моем случае завис перевод на 113к, что в рублях порядка 7к. Все-таки экстра-малые, в моем понимании, это несколько рублей. Или хотя бы в пределах сотни.

Что послужило причиной зависания в данном случае — не знаю. Средства лежали на счете не первый день и обросли подтверждениями. Была ли это ошибка сети, ошибка клиента или неизвестные параметры в формуле приоритета — не знаю. Но факт остается фактом.
UFO just landed and posted this here
Конечно, интересно. Структуру файла сами изучали? Не встречал толковой спецификации по содержимому. Выпилить из кошелька информацию — это была первая идея, но до нее так и не дошло.
UFO just landed and posted this here
Нельзя сразу подозревать плохое :) Поставил плюсик.
UFO just landed and posted this here
Была обратная проблема. При маленьком платеже стандартный биткоин клиент требует комиссию.
Погуглил — понял что это как раз чтобы избежать проблемы как у автора поста, и кстати другие клиенты могут не требовать комиссию.
Получается для микроплатежей биткоин счас не очень то подходит. Скажем в моём случае при платеже $2 или $5 комиссия $0.1 (5+ процентов).
Переводимая сумма должна быть больше некоего порога.

Такое ограничение выступает в качестве средства борьбы с транзакционным спамом.

На микроплатежи якобы был ориентирован лайткойн. Но слышал, что у него порой комиссия выходит еще больше.
Хм. Я всегда думал, что в кошельке хранятся только приватные ключи, а все остальное — в цепочке блоков. Оказывается, что там хранится немного больше информации:

keypairs for each of your addresses
transactions done from/to your addresses
user preferences
default key
reserve keys
accounts
a version number
Key pool
Since 0.3.21: information about the current best chain, to be able to rescan automatically when restoring from a backup.

Я думаю, что хранение транзакций в кошельке — это, своего рода, оптимизация. Т.к. мы можем в новый пустой кошелек импортировать только ключи и баланс «найдется», т.е. будет получен из цепочки блоков.

А к Вам у меня вопрос. Вы пишете:

Теперь нужно получить приватный ключ от нужного счета. dumpprivkey <address>. Вместо <address> нужно подставить публичный номер счета, на котором лежат заблокированные средства.

Как Вы узнали нужный адрес? Опять же, насколько я знаю, при отправке средств у транзакции может быть несколько входов — т.е. Ваши деньги будут идти с нескольких счетов.
Я думаю, что хранение транзакций в кошельке — это, своего рода, оптимизация. Т.к. мы можем в новый пустой кошелек импортировать только ключи и баланс «найдется», т.е. будет получен из цепочки блоков.

Получается, что так и есть. Именно поэтому в некоторых случаях достаточно обновить цепочку блоков на актуальную.

Как Вы узнали нужный адрес? Опять же, насколько я знаю, при отправке средств у транзакции может быть несколько входов — т.е. Ваши деньги будут идти с нескольких счетов.

У меня всего пара счетов, и я знал, на каком были средства. Для надежности проверил в блок эксплорере, что средства именно там, где я думаю.

Но вообще, определить счет возможно. Входами транзакции являются не счета, а другие транзакции. Если счетов много, и неизвестно, какой надо импортировать, можно сделать следующее:
  1. Получить «расшифрованную» транзакцию. Варианта два:
    • getrawtransaction <txid> 1.
    • Результат getrawtransaction <txid> передать в decoderawtransaction.
  2. Взять txid всех транзакций, являющихся входами для проблемной транзакции и пройтись по ним командой gettransaction <txid>. В поле address содержится счет, на который переводились средства в данной транзакции. Соответственно, полученные счета и являются нужными.
  3. ???????
  4. PROFIT
У меня всего пара счетов, и я знал, на каком были средства.

Вы при приеме денег используете один и тот же адрес? И как же быть со сдачей, ведь она приходит на новый адрес?

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

Я задал вопрос потому, что способ который Вы описали в статье, подходит не всем. Например, если человек пользуется обычным клиентом и особо не вникает в детали, то у него будет 100500 адресов по которым размазан его баланс. И тут простое «Теперь нужно получить приватный ключ от нужного счета...» не пройдет.
В данном случае все средства были на одном счете.

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

Пока что использовать криптовалюты, не вникая в детали, — не лучшая затея. Это все еще довольно специфичная штука.
Вы даете очень плохой совет в общем случае.

Кошелек в bitcoin и форках устроен так, что он одновременно хранит пул из 100 секретных ключей, с каждым из которых связан свой адрес и своя сумма денег (например, сдача с каждой тразакции всегда идет на новый неиспользованный адрес). Командой dumpprivkey вы получаете ОДИН приватный ключ и, удаляя wallet.dat, теряете информацию об остальных. Создав новый wallet.dat, вы получите 100 ДРУГИХ ключей и, импортировав один старый, восстановите средства только с него.

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

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

Тоже плохо. Во-первых, «вернуться» — это значит снова просканировать весь блокчейн, чтобы кошелек был синхронизирован с блоками и транзакциями. Во-вторых, когда вы отправите с нового wallet.dat транзакцию, сдача пойдетна новый адрес, которого нет в старом файле. Придется возиться с импортом и этого ключа. Или постоянно переключаться и пересинхронизироваться между кошельками.

Собственно, проблема в том, что оригинальный клиент не рассчитан на использование одних и тех же ключей в разных местах, поэтому любые манипуляции с wallet.dat чреваты неожиданными проблемами. Следует избегать их всегда, когда можно.

Ключ -salvagewallet также упомянут в посте.

Сорри, не заметил той строчки. Впрочем, она все равно неинформативна =) («Запустите клиент с каким-нибудь волшебным ключом (-rescan / -reindex / -salvagewallet»). Этот ключ, кстати, реализован больше года назад
В целом да. Проблема со сдачей решается отсылкой ее на один из своих счетов.

Я понимаю, что описанное решение неидеально. Но, допустим, зависла транзакция. Информация о ней в кошельке, скачивание новой цепочки блоков ничего не дает. Ключ -salwagewallet в клиенте не реализован. Инструмента для выпиливания из кошелька информации под рукой нет. Как поступить?

И есть вопрос насчет пула из 100 ключей в кошельке. 100 штук — это ограничение? Допустим, при создании кошелька в нем имеется 100 ключей. При импортировании в него нового ключа их там станет 100 или 101? Просто интересно, можно ли полноценно имитировать -salwagewallet, вытащив все ключи из старого кошелька.
Инструмента для выпиливания из кошелька информации под рукой нет. Как поступить?

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

Кстати, Ваш способ я бы исправил так: на шаге 8 отправить ВСЕ доступные на адресе монеты сначала на один из своих адресов (можно даже на этот же). И после подтверждения транзакции вернуться к старому wallet.dat и пересканировать блокчейн. Потеряем только сумму комиссии.

Вообще, суть моего недовольства не в самом способе или его отсутствиии, а в том, что на любых рецептах всегда должна находиться информация о побочных эффектах. Потеря денег иногда приводит к потере здоровья =)

100 штук — это ограничение?

Нет, это не лимит, а именно пул «неиспользованных адресов», генерируемый при создании wallet.dat. Они задействуются по мере необходимости (обычно — для получения сдачи). Как только не останется ни одного «чистого» адреса — будет сгенерировано еще 100. При этом старые ключи никуда не удаляются, даже если на соответствующих адресах пусто. Salvagewallet испортирует вообще все ключи, что есть.
Можно этот инструмент скачать: по времени это сравнимо с пересканированием блокчейна

А можно подробнее? Первый и единственный на данный момент инструмент я встретил в комментарии к этому же посту. Не там искал? Или не то?

Информацию об избежании проблем в пост добавил.
Ну, не знаю. Первый ответ по запросу «bitcoin delete transaction» — это bitcointalk.org/index.php?topic=35214.0 — наверное, самое сложное там — это установка python. Я знаю, что есть еще утилиты для работы напрямую с wallet.dat, уверен, что их можно найти по схожему запросу (еще ключевое слово — «unconfirmed tx»)
Хм, этот топик я видел, но почему-то упорно пропускал его. Видимо решил, что решение сугубо для биткойна.
А, ну, конечно, в самом скрипте все пути прописаны для биткоина. Но удобство всех его незамысловатых форков в том, что достаточно сделать замену «bitcoin» -> «anycoin» в коде
Sign up to leave a comment.

Articles