Неподтвержденные транзакции - ГДЕ они

[nusuth]

Сделал транзакцию руками. Без включения комиссии (потому что в порядке эксперимента, да и вся транзакция - 300 мкБиткоин).
Киент (официальный v0.8.1.0-g34d62a8-beta) транзакцию принял. Теперь она висит в неподтвержденных - то есть висит в клиенте, а в сетевых сервисах информации о ней по ID не обнаруживается.
Соответственно, вопрос знатокам на уровне кишков системы - ГДЕ находится эта транзакция сейчас? Перефразируя вопрос - знает ли о ней только мой клиент, или существует некое виртуальное "место" в общей сети биткоин, где кучкуются такие вот транзакции, ожидающие включения в блок?
Следующий вопрос практический: Что с данной транзакцией произойдет дальше?
Перелопачивая инфу, пришел к выводу, что транзакции, при создании которых пожадничали включить комиссию - все-таки включаются в блок, но с задержкой. Но не уверен, что это актуально к настоящему времени. Плюс, не совсем ясен механизм такого отложенного включения - ведь если транзакции с включенной комиссией имеют приоритет - они, образно говоря, при появлении вклиниваются в середину всей очереди на обработку, отодвигая нищебродов назад. При достаточной активности появления новых транзакций нахождение бесплатных транзакций в конце очереди - практически бесконечно.
У меня два варианта развития событий - либо эта транзакция будет "бесконечно" висеть в неподтвержденных, в надежде, что когда-то и до нее дойдет очередь, либо существует некий временной лимит, после которого "заявка на обработку" транзакции будет отменена.
Есть вариант с попыткой повторной траты этих же самых денег - с включением комиссии, чтобы повторная трата получила высокий приоритет и "обогнала" первоначальную зависшую(правда, подозреваю, что тут мне понадобится другой экземпляр клиента - этот запрещает повторную трату уже на этапе создания транзакции). Но тут я тоже не совсем понимаю кишки - ведь конкурентная борьба между двумя тратами одних и тех же денег имеет смысл только в том случае, если обе траты включаются в разные варианты блоков - а здесь, вроде как, никакого включения в блок нет.
В общем, растолкуйте, пожалуйста.
ЗЫ.
ID транзакции (из клиента)
abcdd48f7dbdc355ee917fa5edaec54ce7ecb925282696709d299f736321790e

ЗЗЫ
а заголовок темы убойный вышел :-D

[1714877740]

1714877740

[1714877740]

1714877740

[1714877740]

1714877740

[LuciferUA]

а заголовок темы убойный вышел :-D

Ага, вопрос без вопросительного знака - самое то...

[nusuth]

А с другой стороны, если в конце концов ответят - то все правильно будет. Будет тема, растолковывающая про то,"где они нах"

[rPman]

Если никто о транзакции не знает, значит либо она слишком долго висела у 'этих других' в mempry pool и выкинута как 'попытка флуда', либо по каким то иным причинам она не принята сетью (ошибочные/потраченные входы например).

Алгоритм передачи данных по mesh сети мне не известен, но скорее всего он избыточен, т.е. каждый клиент получив транзакцию:
1. проверяет ее на непротиворечивость в соответствии со своими данными (в т.ч. проверяет, не принял ли он ее от кого то еще)
 - сюда добавляются какие то алгоритмы с оценками, для выявления флудеров и лже-кошельков, которые набирают оценку клиентам и банят их по условию.
2. помещает в свой memory pool
3. и транслирует эту транзакцию всем остальным клиентам, к которым он на данный момент подключен (кошельки за NAT-ом обычно подключены максимум к 8-рым,.. а кошельки соло и пулов майниинга стараются подключиться к сотням клиентам и по возможности ко всем другим пулам)
 - этот момент трансляции для меня под вопросом... рассылается ли транзакция повторно (скорее всего нет), но ничто не мешает иннициировать эту расссылку самостоятельно.
При использовании офф. клиента можно восстановить кошелек из бакапа (копия до создания транзакции) либо отредактировать wallet.dat утилитами вида pywallet и повторно сгерерировать транзакцию.

[nusuth]

моя беда в том, что я не особо еще уяснил себе понятия "сеть знает о транзакции" и "сеть обрабатывает транзкцию".
С учетом того, как я понял предыдущее сообщение, попробую описать процесс таким образом:
1. Я создаю транзакцию и даю клиенту команду сообщить о ней.
Как следствие, мой клиент об этой транзакции "знает". Так же он оповещает тех клиентов, с которыми связан непосредственно, те оповещают своих соседей и т.д. Рано или поздно о транзакции узнаёт клиент, который умеет генерить блоки и может зафиксировать транзакцию.
Первый этап окончен. Опустив промежуточные звенья, можно сказать так: о транзакции знают клиент-инициатор и клиент-генератор (пул).
2. Пул принимает решение не обрабатывать транзакцию. Вот здесь первый вопрос - означает ли это, что в этом случае пул "забывает" мою транзакцию? Собщает ли он о том, что транзакция им отвергнута и забыта? И кстати, как поступают промежуточные клиенты (не пулы), которые использовались только для ретрансляции транзакции от моего клиента в сеть - забывают и молчат?
У меня аж несколько гипотез:
а) либо какого-то механизма обратной связи нет - и в этом случае возникает ситуация, когда спустя какое то время лишь только мой клиент знает об отвергнутой транзакции и она действительно будет висеть вечно - ведь остальные клиенты и пулы о ней забыли. Но этот вариант какой то некрасивый - клиент считает средства заблокированными и разблокировать их штатно не получится.
б) либо существует механизм оповещения об отказе, а транзакция висит долго потому, что не все еще пулы узнали о транзакции и, соответственно, не сообщили об отказе/принятии к обработке.
в) либо все-таки существует какая-то отложенная очередь и транзакция принята к обработке в принципе, но помещена в "дальний ящик".

[rPman]

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

Работа пулов заключается в том что они каждый момент времени (как майнер запросит работу getwork, это в конце концов происходит ежесекундно ну или как майнер настроит майнер или прокси) выбирают из СВОЕГО memory pool транзакции, собирают из них блок и пытаются для него решить задачу (найти nonce или extraNonce перебирая хеши).

Логика выбора транзакций из memory pool (а так же удаление их от туда) - у каждого может быть своя, с другой стороны обычно майнеры стараются оперативно обновлять клиент своего кошелька, т.е. фактически этим алгоритмом рулит ведущий программист Гэвин (он конечно работает с оглядкой на других программистов и мнение майнеров, точнее топовых пулов майнинга).

Это значит если какой то пул решит сделать логику выбора другой (более неудобной для клиентов, например повысив требование к комиссии) то транзакции, не подходящие под эти требования будут обрабатываться другими пулами... поэтому говорят, транзакция висит в memory pool и ждет (правда в текущий алгоритм всех пулов уже встроен алгоритм игнорирования дешевых или бесплатных транзакций, пока они не наберут некоторый вес.. не вылежатся некоторое время, кажется сейчас реализуется какой то иной алгоритм, что то про аукцион, не изучал пока)

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

[Xtc]

Транзакции с суммой перевода меньше какого-то  значения(0.1 биткойн вроде) и не имеющие комиссии отбрасываются другими клиентами и не передаются по сети, до пула они даже не дойдут.
Можно отправлять бОльшие суммы без комиссии, они дойдут в течение суток обычно.
Эта транзакция зависла и уже никогда не обработается, монеты можно повторно включить в другую транзакцию с комиссией.

[nusuth]

Я понял так:
С одной стороны, если транзакция признана подходящей, то она попадает в мемори-пулы клиентов и майнеров в сети, то есть, проще говоря - "запоминается сетью", существует в ней и ждет своей очереди на обработку - следовательно, будет обработана в течение пусть и долгого, но разумного времени.
С другой стороны, получается, что подходящей признается не каждая валидная транзакция. Причем, фундаментально в сети биткоин существует только проверка на валидность, а вот оценка подходит/не подходит - происходит по неким дополнительным правилам.
Таким образом, все-таки возникает та "некрасивая" ситуация, которую я предполагал: технически правильные и, в общем, незапрещенные действия пользователя приводят к отказу в обработке, причем об отказе внятно никак не сообщается, и откатить непризнанную транзакцию штатным образом нельзя (или я ошибаюсь насчет шатных способов?).
Насчет исправления.
Из рекомендации "восстановить wallet.dat из бэкапа или править его утилитой" я прихожу к выводу, что инфа об отправленной, но зависшей транзакции хранится в самом wallet.dat?
Я вообще надеялся на то, что где-то в другом месте - на уровне служебных файлов клиента, - и хотел попробовать запустить конкурентную транзакцию с этим же кошельком, но с другого клиента. Хотя, как крайний вариант еще существует возможность выгрузить-импортировать ключи для адреса.

[[Tycho]]

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

Транзакция, имеющая хотя бы один выход менее чем на 0.01 BTC должна иметь комиссию. Да, владелец пула может разрешить приём и таких транзакций, но это вряд ли случается часто. Кроме того, если, допустим, минимальный размер комиссии обычно составляет 0.0005 BTC, то многие узлы откажутся просто распространять такую транзакцию, если комиссия будет менее 0.0001 BTC и она может просто не доехать до того пула, который принял бы её без комиссии.

[nusuth]

То, что пул имеет полный произвол не обрабатывать невыгодные ему транзакции - это его святое право. Размеры комиссий и их оправданность, справедливость и т.п. не обсуждаются.
Но с другой стороны и пользователь имеет полное право подсовывать сети любые валидные транзакции - как сознательно, так и неосознанно.
Вопрос плавно перемещается к тому, а предусмотрен ли какой-то механизм для нормального отсеивания непринятых/неподходящих транзакций - то есть однозначно и с какой-то информацией о причинах отсеивания?
В системах с централизованным процессингом попытка отправить неподходящую транзакцию останавливается на уровне приема к исполнению - строго говоря, в таких системах собюдение минимальных сумм платежа и размеров комиссий входят в понятие валидации. В биткоин мы имеем распределенный процессинг, в котором потенциально существуют майнеры, готовые обработать любую транзакцию. Однако получается, что согласно каким-то дополнительным правилам (кстати, где они возникают и проверяются - "вкладываются" в очередную версию клиента?) клиент-ретранслятор (или даже клиент-инициатор) отклоняет транзакцию (не сообщает о ней далее по сети), при этом никак не уведомляет о том, что транзакция отклонена. Разве это невозможно по каким-то фундаментальным причинам?
Как-то непонятно все еще.

[nusuth]

вот что нашел на blockchain.info в разделе "Не подтвержденные транзакции":
https://blockchain.info/ru/tx/c9dbf14695e423488a8702adc7afdf53cd1428f5bbf88da6b1d7987e3def9d18

транзакция без адресов отправителя и получателя (другой способ?) на 0 BTC. Без комиссий :-D.
Торчит в очереди с расчетным временем на обработку.

Моей транзакции в этом списке вроде нет.
Все страньше и страньше.

[rPman]

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

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

Да, в сети есть только простое правило - непротиворечивость (чтобы небыло двойной траты), все остальное - пожелания пулов майнинга. Поэтому и говорят, что пулы майнинга создают большую опасность централизации валюты и чем их больше (и чем меньше их отдельные мощности) тем лучше для сети в целом, так как это не позволит им легко договариваться друг с другом против всех пользователей сети (например если сейчас 5-6 основных крупных пулов манинга и солистов договорятся и сделают комиссию в 0.1 btc, то никуда народ не денется, будет платить либо ждать свои транзакции сутками, пока не согласные с политикой этого соглашения майнеры, коих останется очень мало, не обработают вашу транзакцию).

[nusuth]

ага.
вроде как въехал.
Что ж, в целом все ожидаемо и логично, единственная нелогичная вещь - сохранение данных об отправленных транзакциях в wallet.dat официальным клиентом. В самом деле, не место им там . Исходя из идеологии сети - думаю, кошелек должен хранить только ключи, остальная инфа должна либо выцепляться из сети, либо (если нужна только локально) - храниться в служебных файлах. Ну да это ладно. Как уже говорил - есть экспорт/импорт ключей.

[yurm]

Однако получается, что согласно каким-то дополнительным правилам (кстати, где они возникают и проверяются - "вкладываются" в очередную версию клиента?) клиент-ретранслятор (или даже клиент-инициатор) отклоняет транзакцию (не сообщает о ней далее по сети), при этом никак не уведомляет о том, что транзакция отклонена. Разве это невозможно по каким-то фундаментальным причинам?

В уведомлениях нет особого смысла. В транзакции не записано, какой узел является её инициатором (т.е. даже соседние с инициатором узлы не будут знать, принимают они транзакцию от инициатора или ретранслятора), а ретранслятору такое пришедшее уведомление нафиг не сдалось, он уже включил транзу в memory pool (не удалять же её оттуда только из-за того, что у соседа другая политика ретрансляции). Получается только лишний трафик. Проверка на допустимость сборов возложена на узел-инициатор, и при обычном использовании оф. клиента он не даст создать перевод со слишком малой комиссией (вроде; переспросит-то уж обязательно). А по поводу raw transactions явно сказано:

You must be careful to include an appropriate transaction fee, or the sendrawtransaction method is likely to fail (either immediately or, worse, the transaction will never confirm).

[nusuth]

Так все-таки, как вы думаете (или точно знаете) - какое описание более всего подходит для данной ситуации?
:
- Транзакция вообще не ушла дальше моего клиента (т.е., это именно он принял решение не ретранслировать ее дальше). Тем не менее, транзакцию клиент "придерживает" - видимо, на случай изменения соглашения о минимальной комиссии, в результате чего транзакция может оказаться подходящей и ее можно будет повторно ретранслировать. (Кстати, где-то вычитал, не помню, про то, что клиент (официальный) все-таки делает повторные оповещения о ранее принятых, но еще не подтвержденных подходящих транзакциях).
Сам я склоняюсь к этой версии. Раз уж минимальная сумма "допуска" (та, которая сейчас 0,0001, в отличие от рекомендуемой 0,0005) зашита в код, ничто не мешает клиенту юзать ее не только при ГУИшном создании транзакции, но и при обрабтке консольной команды отправки.

- Транзакция ушла в сеть и болтается в мемори-пулах [некоторых] клиентов и майнеров. Только не обрабатывается. Тут две подситуации:
-- Транзакция остается в мемори-пулах, но постоянно игнорится майнерами при запросе текущей очереди. (Маловероятно. Тогда получается, что мемори-пулы попросту забиты таким мусором)
-- Транзакция уничтожается при извлечении ее из пула. То есть, вначале в пул попадает все подряд, затем все же и извлекается, но вот обрабатывается только часть, остальное исчезает.

[yurm]

Посмотрел исходники текущей trunk версии оф. клиента.

- Клиент не придерживает транзакцию в случае её некорректности, например, при вызове sendrawtransaction генерирует исключение (файл rpcrawtransaction.cpp, функция sendrawtransaction):

Code:

        if (!fHave) {
            // push to local node
            CValidationState state;
            if (!mempool.accept(state, tx, false, NULL))
                throw JSONRPCError(RPC_DESERIALIZATION_ERROR, "TX rejected"); // TODO: report validation state
        }
    ...
    RelayTransaction(tx, hashTx);

Судя по всему, где-то выше по стеку исключение перехватывается и выводится сообщение об ошибке. Однако mempool.accept не проверяет минимальность комиссий, если третий параметр fLimitFree == false. В случае корректности транзакция передаётся соседям (RelayTransaction).

- При приёме транзакции от соседа mempool.accept проверяет допустимость комиссий (main.cpp, ProcessMessage, fLimitFree == true):

Code:

    else if (strCommand == "tx")
    {
        ...
        bool fMissingInputs = false;
        CValidationState state;
        if (mempool.accept(state, tx, true, &fMissingInputs))
        {
            RelayTransaction(tx, inv.hash, vMsg);
            ...
        }
        else if (fMissingInputs)
        {
            AddOrphanTx(vMsg);

            // DoS prevention: do not allow mapOrphanTransactions to grow unbounded
            unsigned int nEvicted = LimitOrphanTxSize(MAX_ORPHAN_TRANSACTIONS);
            if (nEvicted > 0)
                printf("mapOrphan overflow, removed %u tx\n", nEvicted);
        }
        int nDoS;
        if (state.IsInvalid(nDoS))
            pfrom->Misbehaving(nDoS);
    }

Никаких ответных сообщений не отсылается, просто если транзакция не принята в mempool, то сосед, её приславший, увеличивает свою "негативную карму" (pfrom->Misbehaving(nDoS)) и при превышении последней порогового значения отправляется во временный бан.

- Из mempool'а корректные транзакции, похоже, не удаляются вообще до принятия их в блок. По крайней мере "grep -n mempool.remove *" выдал только случай получения нового блока (main.cpp, функция SetBestChain). Т.е. транзакции в memory-пуле ждут до победного. Единственное исключение - orphan-транзакции, т.е. такие, чьи входы клиенту ещё не полностью известны (либо транзакции, чьи выходы тратит orphanная, ещё не получены, либо вообще ещё не отправлены в сеть - есть такая фича у оф. клиента). Для таких транзакций буфер ограничен (LimitOrphanTxSize) и отделён от mempool'а.

- Свои транзакции периодически перепосылаются соседям (wallet.cpp, CWallet::ResendWalletTransactions).

Хотя это довольно поверхностное копание в исходниках. Например, я пока не выяснил, перепосылаются ли периодически чужие корректные транзакции соседям, что такое фильтры (межклиентские команды filterload/filteradd/filterclear), не углублялся в вопрос, что такое inventory (CInv). Да и политики могут отличаться от версии к версии и даже от узла к узлу (наложением своих патчей). Но на первый взгляд так.

[A-Bolt]

Из mempool'а корректные транзакции, похоже, не удаляются вообще до принятия их в блок.

В Bitcoin-Qt список транзакций в mempool можно посмотреть командой getrawmempool.

Кошелёк с аптаймом двое суток выдал количество транзакций в mempool примерно 2500.
Свежезапущенный кошелёк выдал 7 транзакций.

Получается, клиент при каждом перезапуске очищает mempool.

[VESA2]

Ребят, подскажите пожалуйста как повторно отправлять монеты из не подтвержденных транзакций

[icreator]

Ребят, подскажите пожалуйста как повторно отправлять монеты из не подтвержденных транзакций

их кошелек сам отправляет - подожди 2 дня

[Spiritus Sanctus]

Приветствую, может кто подскажет, сколько максимально долго может не подтверждаться транзакция Биткойн, уже прошло более 10 суток, а она висит в неподтвержденных до сих пор, была отправлена с биржи с комиссией 0.0004 BTC. Может быть биткойны уже вернулись отправителю? Если так, то меняется ли статус транзакции в публичном блокчейне? в данный момент она имеет статус как неподтвержденная. До этого сталкивался с задержкой подтверждения в трое суток, но более 10 дней мне кажется это слишком долго уже