И то и то работает.

Индексация всех транзакций сделана по умолчанию - https://github.com/neiros/old_work/blob/TTC-all-Lyra2REv2/src/util.cpp#L552 (txindex=1)
Без этого полноценная работа клиента невозможна.

В данном случае не при чём.

Информация gettransaction бесполезна.
getrawtransaction показывает входы и выходы транзакции. Вот эти inы и outы проблемной транзакции и нужно узнать.

Сами-то поняли, что написали и где ошиблись?




Вот эта строчка делает тоже самое.
Ничего дополнительно декодировать ненужно.

  Транзакция в кошельке? В кошельке. В wallet.dat`е? В wallet.dat`е.
В мемпуле этого кошелька, на обратной стороне Луны или в ваших фантазиях?
Я практически уверен что в мемпуле этого кошелька.

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

Либо же это был банальных орфан блок и он, при перезагрузке кошелька, уже сам давно испарился. Без wallet.dat я могу пока только предполагать.

 

Есть. Не вводите в заблуждение. И в Bitcoin раньше был и сейчас есть и должен быть.
Где же ему быть-то, как не в кошельке(клиенте).


К кошельку Bitcoin Core для обычных пользователей уже, можно сказать, не имеет, а к кошельку TDC это имеет самое прямое и непосредственное отношение. Поэтому не стоит мешать одно с другим. TDC это не нынешняя фигня ввиде Bitcoin Core и его однообразных форков.


Для меня же Bitcoin не чёрная коробка. Я же его изъездил и изучил на уровне кода вдоль и поперёк(старую версию конечно, а не ту хрень, что уже расплодилась). Неужели вы думаете, что я не смогу, при желании, из клиента, который сам сделал, достать из wallet.dat транзакцию, если она там действительно есть?



Спасибо конечно, но по-моему с каждой новой версией Bitcoin Core вы, да наверное и не только вы, становитесь всё большим дилетантом в ключевых вопросах. На мой взгляд, конечно.

Ладно, проехали.
У меня сейчас других дел и проблем выше крыши - https://bt.irlbtc.com/view/5134288.msg50902507#msg50902507

я правильно понимаю, что тут https://bt.irlbtc.com/view/5043605.0 обсуждают то, что уже реализовано в TDC?

_оффтопик_

Чем в последнее время я занимался. Сделал геотермальный контур: 8 скважин (2*4), 285 метров пнд труб 25-ого диаметра. Кому надо пробурить дырку в земле, обращайтесь. Пол дня делов, без учета подготовительных работ. Тепловой насос - кондиционер MSS-12R08 с минимальными "косметическими" переделками наружного блока. Установил один ветрогенератор. Плюс к этому ещё один, нежданчик, бонусный, почти бесплатный(спасибо китайцам) установил на мачту которую пришлось сварить из металлолома, что под рукой был. А также заборы, ворота, калитки и т.п. мелочи. Всё вполне нормально и выглядит и работает. Так что переход на использование только энергии солнца и ветра для отопления(?) и электроснабжения в сибирских условиях вполне реален и даже относительно мало затратен как по материалам, так и по времени. Конечно для тех у кого руки из нужного места растут. Как-нибудь про это дело отдельную статью надо будет написать. Ведь налоги за солнечный свет, за ветер, за воздух и т.п. пока ещё ни одно централизованное хуйло в законе не догадалось ввести.

---

Всё-таки обрабатывать какую-нибудь деревяшку, железку или чинить/латать какую-угодно фиговину мне больше нравиться, чем пилить какой-нибудь программный код.


Но сейчас уже руки дошли до возможного решения этой проблемы - https://bt.irlbtc.com/view/2254304.msg51666221#msg51666221
Самый простой вариант примерно такой:

1. Не создавать, а соответственно и не отправлять, транзакцию если нет соединения хотя бы с одной нодой.
2. Если есть соединение, узнаём текущую высоту блокчейна.
3. Создаём и отправляем транзакцию только из тех выходов, глубина которых не ниже рабочей длины блокчейна минус некоторая константа по времени, определяемая через количество блоков для относительно гарантированного попадания транзакции в блокчейн из расчета одни сутки это ~ 24 * 12 блоков в час. Думаю круглой цифры в 1000 блоков будет достаточно. Это почти 3 с половиной дня. Так как при создании транзакции наибольший приоритет у самых древних непотраченных выходов - https://github.com/neiros/TDC/blob/TDC/src/wallet.cpp#L1038 , то если глубина таких выходов будет больше 105000, то не имеет смысла включать эти выходы в транзакцию, так как они уже будут пустыми, т.е. потраченными коинтрансфер транзакцией.

По-моему этого пока будет вполне достаточно.
Осталось собраться, освежить подзабытые навыки и знания, и сделать и добавить что-то примерно подобное, а может и более навороченное. Тут уж как получится.

Это дело AcceptToMemoryPool(false) ведёт нас сюда - https://github.com/neiros/TDC/blob/TDC/src/main.cpp#L1078
А это accept(state, *this, fLimitFree, NULL) сюда - https://github.com/neiros/TDC/blob/TDC/src/main.cpp#L803
где находится ещё довольно много стандартных проверок, которые и не пускают даблспенд транзакции.

В общем то это правильно. Как я и предполагал.

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

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

Вне всяких сомнений.

Так точно, сэр! Есть, сэр! Слушаюсь, сэр! Разрешите исполнять, сэр?!

Есть только один небольшой момент консенсуса данного коина: транзакция может быть абсолютно валидной в некий конкретный момент времени, но уже через секунду сталь совершенно невалидной. Я вместо 1 секунды сделаю временной лаг в 3 с половиной дня и если после этого никаких подобных проблем не всплывёт, значит проблема, можно сказать, будет решённой. Хотя по хорошему здесь нужен гораздо более основательный подход, с учётом всех возможных и не возможных вариантов. Но на данное время этот коин не настолько популярен, чтобы уделять такой незначительной мелочи уж очень пристальное внимание.