Получение всех транзакций с данной TXID

Привет, народ,

Я бы очень хотел, чтобы поддержать Bitcoin на веб-сайте я разрабатываю. Я играл вокруг с JSON API, и по большей части она удовлетворяет мои потребности. Там в один вопиющее упущение, однако: с настоящим API я не вижу способа получения всех сделок (либо связанно с учетной записью или все из них), которые произошли с момента неподвижной точки в прошлом (с заданным идентификатором транзакции, например, ).

Я понимаю, что «listtransactions» даст мне список последних N сделок, но нет никакого способа узнать заранее, что это значение N сделок, которые произошли с момента последней опрошены сервера Bitcoin. Кроме того, «listtransactions» требует обязательного имени учетной записи; было бы полезно, если команда гипотетического «listtransactionssince» могут также возвращать все операции, независимо от счета.

Твои мысли?

Спасибо!
Джон

0.3.20 будет поддерживать listtransactions «*» для всех операций.

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

Я могу представить себе тонкий bugs-- вы запрашиваете сделок с момента но TXID оказывается транзакция сиротской (дважды провести на проигравшей стороне блока цепи повторного орга) так Bitcoin возвращается ... что?

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

Здравствуй,

Спасибо за быстрый ответ! Очевидно, что я не имею никакого намерения копировать всю цепочку дезинфицирующее что Bitcoin демон выполняет. Моя идея состояла в том, чтобы получить все подтвержденные / действительные / кошерные сделки, так как определенный момент в прошлом. Там больше чем один способ указать, что эта неподвижная точка должна быть, но если предположить, что TXID уникален, это было бы хорошим кандидатом. Timestamps, конечно, может также использоваться, до тех пор, как дела, связанные с угловыми нескольких сделок с одной и той же временной меткой ухаживает.

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

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

Ура,
Джон

Цитата: jon_smark от 01 февраля 2011 года, 8:42:17 PM

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

Две мысли:

listaccounts [minconfirmations] (также нового в 0.3.20, если я помню правильно) даст вам все счета и их остатки. Если остаток по аккаунту не меняется, вы знаете, он не получил монету.

А зачем вам это нужно периодически обновлять учетную запись пользователя / активы? Не могли бы вы просто запросить bitcoind для их текущего баланса, когда они получать их «статус счета» страницы (или там, где вы показать пользователю, сколько Bitcoins они есть)? Вы делаете что-то с полученным Bitcoins без явного действия со стороны пользователя, и делаете что-то заботиться об общем балансе или отдельных операциях?

Здравствуй,

котировка

listaccounts [minconfirmations] (также нового в 0.3.20, если я помню правильно) даст вам все счета и их остатки. Если остаток по аккаунту не меняется, вы знаете, он не получил монету.

Если нет другого решения не имеется, что может работать. Однако, ради прозрачности, я бы очень хотел, чтобы предоставить пользователю полный список подтвержденных операций, связанных с их счета. Кроме того, я немного обеспокоен погона «listaccounts». Предположим, что есть тысячи счетов, но лишь немногие изменили свой баланс с момента моего последнего запроса. Это кажется немного глупым, чтобы пройти через все их вычисление дельты в балансе счета.

котировка

А зачем вам это нужно периодически обновлять учетную запись пользователя / активы? Не могли бы вы просто запросить bitcoind для их текущего баланса, когда они получать их «статус счета» страницы (или там, где вы показать пользователю, сколько Bitcoins они есть)? Вы делаете что-то с полученным Bitcoins без явного действия со стороны пользователя, и делаете что-то заботиться об общем балансе или отдельных операциях?

Да это так "за кулисами" действия, которые должны иметь место независимо от вмешательства пользователя. Предположим, что пользователь купил что-то; Я хочу, чтобы иметь возможность поставлять товар, как только сделка Bitcoin подтверждается. Конечно, я мог бы иметь список невыполненных заказов и сделать проверку всех связанные счетов за изменившийся баланс периодического опроса, но это кажется гораздо более эффективным, если бы я мог попросить Bitcoin демона "смотрите, последняя сделка я уже TXID из XXYYZZ. Пожалуйста, дайте мне список всех подтвержденных сделок, которые произошли с тех пор",

Еще раз спасибо за ваше внимание, это очень ценится!
Джон

Важно, чтобы не пропустить сделку, becouse listtransactions не сообщают количество сделок - это дает только список последней из них.

Цитата: bitcoinex от 02 февраля 2011, 12:43:50 AM

Да, именно поэтому я думаю, что «listtransactions» имеет очень мало пользы для надежной системы электронной коммерции, и очень бы предпочел метод API, который будет возвращать все подтвержденные транзакции с момента фиксированной TXID в прошлом ...

Какой язык / рамки вы собираетесь разрабатывать приложение с?

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

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

Как вы думаете, что код должен иметь дело с проблемой "фиксированный TXID может больше не действителен" ? Или сделки, которые вы имели МЫСЛЬ N подтверждений и были в блоке с отметкой времени T повторно организованы, чтобы иметь М подтверждений и в блоке с отметкой времени T2?

tcatm и я болтали в IRC об этом problem-- он имеет проблему, как сохранить Javascript GUI (который показывает вам когда-либо сделки) уточненный.

Похоже, вы действительно хотите эффективный способ задавания "Я знаю, что ли о точно такой же набор операций, как bitcoind" (Либо в течение всего бумажника или для учетной записи). Это предполагает, что данные транзакции не могут изменить (кто-то перепроверить это предположение для me-- при изменении данных транзакции, то изменения TXID ... я думаю).

Это привело к некоторому мозговому штурму вычисления хэша всех идентификаторов транзакциев (возможно, просто XOR их все вместе). Или, может быть что-то более сложным, как Merkle дерево ... но это кажется излишним.

Есть хорошее, простое решение для синхронизации "У меня есть этот набор вещей, дать мне все, что у меня нет" ?

Цитата: Гэвин Андресен 02 февраля 2011 года, 4:10:24 PM

Есть хорошее, простое решение для синхронизации "У меня есть этот набор вещей, дать мне все, что у меня нет" ?

Не то, что я знаю из.
Ответ я нашел unelegant опрос.

Также IIRC был консенсус в отношении того, что должен быть точка, в которой вы решили, что сделка не будет отменено, и рассматривать компенсацию как действительный.

Что-то я должен выполнять в Британской Колумбии, это проверить, что Подтверждения продолжать идти вверх по каждой сделке. Если количество подтверждений для данного ТХ перестает восходя, даже если блок COUNT увеличился означает, что сделка получила недействительным и должен позаботиться специально.

* Дав открывает вопрос GIT

Цитата: jon_smark 01 февраля 2011, 10:32:49 PM

Операции подтверждаются, когда новые блоки принимаются; это идея моей 95% -finished «monitorreceived» коды. Это будет POST к URL, когда новые Транзакции и блоки принимаются. Информационный блок включает в себя все идентификаторы транзакций (и ссылку на предыдущий блок).

Как вы заметили, у вас еще есть вопрос о том, что делать, если ваш код пропускает POST. Это не должно быть большой проблемой, хотя, потому что вы будете ресинхронизаций в следующий раз, когда блок найден. В худшем случае, вы будете грузить к блоку клиента 1 (10 минут) позже, чем является оптимальным, если подключение к bitcoind теряется.

Цитата: Гэвин Андресен 02 февраля 2011 года, 4:10:24 PM

Вот как я думаю, что проблема должна быть решена:

После первоначального вызова, клиент запрашивает список все Операции с минимальным числом N подтверждений.
Демон Bitcoind прилежно обязывает.
Клиент сохраняет TXID последней сделки на вершине стека.
Теперь клиент запрашивает список всех сделок, по крайней мере, N подтверждений, которые произошли с TXID на вершине стека.
Демон Bitcoind прилежно обязывает.
Клиент снова хранит TXID последней сделки на вершине стека. Стек теперь два элемента.
Какое-то время проходит, и клиент запрашивает еще раз все операции, которые произошли с TXID, что теперь на вершине стека.
Там проблема, однако, поскольку запрошенная TXID была признана недействительной. Bitcoind демон возвращает ошибку отчетности этой ситуации.
Теперь клиент знает, что все операции, которые имели место между двумя верхними элементами в стеке должны быть признаны недействительными. Он удаляет верхний элемент из стека и пробует новый запрос от "Последний известный хороший момент",
Демон Bitcoind либо обязует или возвращает ошибку (принуждая клиент к попам еще один элемента из стека и аннулирования кучи сделок).

Обратите внимание, что мое предложение ставит бремя решения этих волосатых обстоятельств на клиенте электронной коммерции, а не на демоне Bitcoind. Хотя я понимаю, что некоторые ленивые программисты могут в настоящее время удосужились реализовать этот алгоритм в своем клиентском приложении, даже они могут избежать возможностей катастрофы просто установив число N минимальных подтверждений быть довольно высоким. Это мое понимание того, что шансы цепи быть признаны недействительными умаляют экспоненциально с ростом N. Поэтому, если вы не можете быть обеспокоены, чтобы справиться с волосатыми ситуациями вы можете просто установить N = 100 и утешение в том, что Вселенная будет страдать от тепловая смерть, прежде чем есть шанс, что вы когда-нибудь столкнетесь с проблемами ...

Как вы думаете?

С наилучшими пожеланиями,
Джон

Хороший, мне нравится ваше предложение.

Как вы знаете, C ++?

Цитата: jon_smark от 02 февраля 2011 года, 5:20:07 PM

ОТЕ, что мое предложение ставит бремя решения этих волосатых обстоятельств на клиенте электронной коммерции, а не на демоне Bitcoind.

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

Цитата: Гэвин Андресен 02 февраля 2011 года, 5:35:48 PM

Хороший, мне нравится ваше предложение.

Как вы знаете, C ++?

На самом деле, я надеялся, что поставив на клиенте бремя борьбы с волосатой вещью (и клиентом я имею в виду в зависимости от того приложения отправляют запросы JSON-RPC), мое предложение было бы сделать этот метод API относительно просто реализовать на демоне Bitcoin , Это звучит не слишком отличается от уже существующего метода «listtransactions», или же это?

Я использовал C ++ в предыдущей жизни, но ничего серьезного с ним не сделано почти 10 лет. Почти все мои программирования в эти дни делается в OCaml. В любом случае, я не знаю достаточно о внутренней работе Bitcoin даже думать реализации этого себя с какой-либо степенью уверенности не знаю.

Ура,
Джон

Hallo снова,

Хорошо, я принял беглый взгляд на код в rpc.cpp (из https://github.com/bitcoin/bitcoin/blob/master/rpc.cpp), И кажется, listtransactionssince особенность, которую я просил не отличается от кода, который уже на месте.

В функции listtransactions, уже существует цикл реверсирования назад от последней сделки до заданного количества сделок не будет достигнуто. В гипотетической listtransactionssince Функция, условие окончания для этого цикла должна быть вместо того, чтобы открытие сделки, чей TXID соответствует заданному параметру.

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

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

Твои мысли?

С наилучшими пожеланиями,
Джон

Если дополнительное время пары необходимы, может избавиться от "поскольку " Понятие и просто сделать это "дайте мне все получить сделки по [счет] с [minconfirmations], которые имеют время больше, чем [время]",

Цитата: Гэвин Андресен февраля 03, 2011, 6:03:12 PM

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

Цитата: jon_smark от 03 февраля 2011 года, 6:24:35 PM

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

А? Я не вижу, как проходит делает эту проблему лучше.

Допустим, у вас есть сделки A B C D (в таком порядке). С времени T1, T1, T2 и T2 (A&B произошло 2 блока назад, вы получили C&D в последнем блоке).

Теперь представьте блок-цепь повторно орг, так и B C теперь недействительны.

Спросите все сделки после D, и вы получите nothing-- же, как если бы вы попросили все сделки с течением времени больше, чем Т2.

котировка

Допустим, у вас есть сделки A B C D (в таком порядке). С времени T1, T1, T2 и T2 (A&B произошло 2 блока назад, вы получили C&D в последнем блоке).
Теперь представьте блок-цепь повторно орг, так и B C теперь недействительны.

Хорошо, давайте рассмотрим этот сценарий. Шаг за шагом, просто чтобы убедиться, что мы находимся на той же странице:

Демон Bitcoind знает сделок [А, В, С, D] с временными метками [Т1, Т1, Т2, Т2].
При первом вызове, клиент запрашивает список всех сделок. Он получает [A, B, C, D] (и временные метки) в качестве ответа.
Там в блок-цепь повторно орг недействительными [С, D].
Четыре новые сделки [Е, F, G, Н] с временными метками [Т2, Т2, Т3, Т3] стало известно демона. Согласно демону, ток цепи [А, В, Е, F, G, H].
Если теперь клиент запрашивает все транзакции с Т2, он будет получать только [G, H] и не условие ошибки, став поэтому не обращая внимания к аннулированию [C, D] и существование [E, F]. Если же, с другой стороны, клиент должны были попросить всех сделок, начиная с D, демон вернулся бы (правильно) ошибка.

Я что-то упускаю?

Приветствия, (и спасибо за внимание!)
Джон

1 февраля 2011, 5:47:13 PM	# 1
jon_smark Сообщений: 90 Цитировать по имени цитировать ответ	Re: Получение всех транзакций с данной TXID Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Привет, народ, Я бы очень хотел, чтобы поддержать Bitcoin на веб-сайте я разрабатываю. Я играл вокруг с JSON API, и по большей части она удовлетворяет мои потребности. Там в один вопиющее упущение, однако: с настоящим API я не вижу способа получения всех сделок (либо связанно с учетной записью или все из них), которые произошли с момента неподвижной точки в прошлом (с заданным идентификатором транзакции, например, ). Я понимаю, что «listtransactions» даст мне список последних N сделок, но нет никакого способа узнать заранее, что это значение N сделок, которые произошли с момента последней опрошены сервера Bitcoin. Кроме того, «listtransactions» требует обязательного имени учетной записи; было бы полезно, если команда гипотетического «listtransactionssince» могут также возвращать все операции, независимо от счета. Твои мысли? Спасибо! Джон

1 февраля 2011, 6:00:39 PM	# 2
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: Получение всех транзакций с данной TXID Получил 1806 Биткоинов Реальная история. 0.3.20 будет поддерживать listtransactions «*» для всех операций. Сделки с тех пор .... звучит опасно. Вы пытаетесь отразить базу данных транзакций, что Bitcoin держит? Если вы, вы уверены, что вы будете иметь дело с должным образом (редко) блок цепи реорганизаций, где операции, которые вы думали, имели одно подтверждение оказываются недействительными в новой вилке цепи? Я могу представить себе тонкий bugs-- вы запрашиваете сделок с момента но TXID оказывается транзакция сиротской (дважды провести на проигравшей стороне блока цепи повторного орга) так Bitcoin возвращается ... что? Все не бесхозные операции со временем операций, равные или больше, чем заданные метки времени могут work--, но то, что ваш случай использование?

1 февраля 2011, 8:42:17 PM	# 3
jon_smark Сообщений: 90 Цитировать по имени цитировать ответ	Re: Получение всех транзакций с данной TXID Здравствуй, Спасибо за быстрый ответ! Очевидно, что я не имею никакого намерения копировать всю цепочку дезинфицирующее что Bitcoin демон выполняет. Моя идея состояла в том, чтобы получить все подтвержденные / действительные / кошерные сделки, так как определенный момент в прошлом. Там больше чем один способ указать, что эта неподвижная точка должна быть, но если предположить, что TXID уникален, это было бы хорошим кандидатом. Timestamps, конечно, может также использоваться, до тех пор, как дела, связанные с угловыми нескольких сделок с одной и той же временной меткой ухаживает. Вот мой случай использования: предположим, у меня есть потенциально большое количество пользователей, делающих переводы, направленные на меня (каждый из которых использует отдельный счет). Мое приложению нужно будет периодически опрашивать Bitcoin демон, чтобы узнать, какие новые переводы были подтверждены, поэтому он может обновить учетную запись пользователя / активы на стороне приложения. Я понимаю, что механизм PUSH также может быть использован, то есть Bitcoin демон может быть дан обратный вызов для вызова каждый раз, когда транзакция подтверждается. Тем не менее, есть несколько вещей, которые могут пойти не так в этом сценарии, по которому у меня есть небольшой контроль (бы для экземпляра Bitcoin демон достаточно умен, чтобы выпустить повторную попытку, если другой конец не ответил?). Поэтому я предпочитаю механизм периодического опроса, так как я нахожусь в контроле ситуации ошибок. Ура, Джон

1 февраля 2011, 8:50:05 PM	# 4
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: Получение всех транзакций с данной TXID Цитата: jon_smark от 01 февраля 2011 года, 8:42:17 PM Вот мой случай использования: предположим, у меня есть потенциально большое количество пользователей, делающих переводы, направленные на меня (каждый из которых использует отдельный счет). Мое приложению нужно будет периодически опрашивать Bitcoin демон, чтобы узнать, какие новые переводы были подтверждены, поэтому он может обновить учетную запись пользователя / активы на стороне приложения. Две мысли: listaccounts [minconfirmations] (также нового в 0.3.20, если я помню правильно) даст вам все счета и их остатки. Если остаток по аккаунту не меняется, вы знаете, он не получил монету. А зачем вам это нужно периодически обновлять учетную запись пользователя / активы? Не могли бы вы просто запросить bitcoind для их текущего баланса, когда они получать их «статус счета» страницы (или там, где вы показать пользователю, сколько Bitcoins они есть)? Вы делаете что-то с полученным Bitcoins без явного действия со стороны пользователя, и делаете что-то заботиться об общем балансе или отдельных операциях?

1 февраля 2011, 10:32:49 PM	# 5
jon_smark Сообщений: 90 Цитировать по имени цитировать ответ	Re: Получение всех транзакций с данной TXID Здравствуй, котировка listaccounts [minconfirmations] (также нового в 0.3.20, если я помню правильно) даст вам все счета и их остатки. Если остаток по аккаунту не меняется, вы знаете, он не получил монету. Если нет другого решения не имеется, что может работать. Однако, ради прозрачности, я бы очень хотел, чтобы предоставить пользователю полный список подтвержденных операций, связанных с их счета. Кроме того, я немного обеспокоен погона «listaccounts». Предположим, что есть тысячи счетов, но лишь немногие изменили свой баланс с момента моего последнего запроса. Это кажется немного глупым, чтобы пройти через все их вычисление дельты в балансе счета. котировка А зачем вам это нужно периодически обновлять учетную запись пользователя / активы? Не могли бы вы просто запросить bitcoind для их текущего баланса, когда они получать их «статус счета» страницы (или там, где вы показать пользователю, сколько Bitcoins они есть)? Вы делаете что-то с полученным Bitcoins без явного действия со стороны пользователя, и делаете что-то заботиться об общем балансе или отдельных операциях? Да это так "за кулисами" действия, которые должны иметь место независимо от вмешательства пользователя. Предположим, что пользователь купил что-то; Я хочу, чтобы иметь возможность поставлять товар, как только сделка Bitcoin подтверждается. Конечно, я мог бы иметь список невыполненных заказов и сделать проверку всех связанные счетов за изменившийся баланс периодического опроса, но это кажется гораздо более эффективным, если бы я мог попросить Bitcoin демона "смотрите, последняя сделка я уже TXID из XXYYZZ. Пожалуйста, дайте мне список всех подтвержденных сделок, которые произошли с тех пор", Еще раз спасибо за ваше внимание, это очень ценится! Джон

2 февраля 2011, 12:43:50 AM	# 6
bitcoinex Сообщения: 350 Цитировать по имени цитировать ответ	Re: Получение всех транзакций с данной TXID Важно, чтобы не пропустить сделку, becouse listtransactions не сообщают количество сделок - это дает только список последней из них.

2 февраля 2011, 3:49:48 PM	# 7
jon_smark Сообщений: 90 Цитировать по имени цитировать ответ	Re: Получение всех транзакций с данной TXID Цитата: bitcoinex от 02 февраля 2011, 12:43:50 AM Важно, чтобы не пропустить сделку, becouse listtransactions не сообщают количество сделок - это дает только список последней из них. Да, именно поэтому я думаю, что «listtransactions» имеет очень мало пользы для надежной системы электронной коммерции, и очень бы предпочел метод API, который будет возвращать все подтвержденные транзакции с момента фиксированной TXID в прошлом ...

2 февраля 2011, 4:03:40 PM	# 8
Дав Сообщения: 1372 Цитировать по имени цитировать ответ	Re: Получение всех транзакций с данной TXID Какой язык / рамки вы собираетесь разрабатывать приложение с? Кроме того, следует помнить, что счета отслеживание ненадежно, как сейчас, так как он будет отбрасывать subcent суммы, что произошел на Bitcoin центрального, люди имели сообщили баланс, который отличался при запросе к БД и к клиенту. Bitcoin центральный код является открытым исходным кодом, вы можете изучить его, чтобы увидеть, как это удалось.

2 февраля 2011, 4:10:24 PM	# 9
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: Получение всех транзакций с данной TXID Как вы думаете, что код должен иметь дело с проблемой "фиксированный TXID может больше не действителен" ? Или сделки, которые вы имели МЫСЛЬ N подтверждений и были в блоке с отметкой времени T повторно организованы, чтобы иметь М подтверждений и в блоке с отметкой времени T2? tcatm и я болтали в IRC об этом problem-- он имеет проблему, как сохранить Javascript GUI (который показывает вам когда-либо сделки) уточненный. Похоже, вы действительно хотите эффективный способ задавания "Я знаю, что ли о точно такой же набор операций, как bitcoind" (Либо в течение всего бумажника или для учетной записи). Это предполагает, что данные транзакции не могут изменить (кто-то перепроверить это предположение для me-- при изменении данных транзакции, то изменения TXID ... я думаю). Это привело к некоторому мозговому штурму вычисления хэша всех идентификаторов транзакциев (возможно, просто XOR их все вместе). Или, может быть что-то более сложным, как Merkle дерево ... но это кажется излишним. Есть хорошее, простое решение для синхронизации "У меня есть этот набор вещей, дать мне все, что у меня нет" ?

2 февраля 2011, 4:44:21 PM	# 10
Дав Сообщения: 1372 Цитировать по имени цитировать ответ	Re: Получение всех транзакций с данной TXID Цитата: Гэвин Андресен 02 февраля 2011 года, 4:10:24 PM Есть хорошее, простое решение для синхронизации "У меня есть этот набор вещей, дать мне все, что у меня нет" ? Не то, что я знаю из. Ответ я нашел unelegant опрос. Также IIRC был консенсус в отношении того, что должен быть точка, в которой вы решили, что сделка не будет отменено, и рассматривать компенсацию как действительный. Что-то я должен выполнять в Британской Колумбии, это проверить, что Подтверждения продолжать идти вверх по каждой сделке. Если количество подтверждений для данного ТХ перестает восходя, даже если блок COUNT увеличился означает, что сделка получила недействительным и должен позаботиться специально. * Дав открывает вопрос GIT

2 февраля 2011, 5:07:40 PM	# 11
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: Получение всех транзакций с данной TXID Цитата: jon_smark 01 февраля 2011, 10:32:49 PM Да это так "за кулисами" действия, которые должны иметь место независимо от вмешательства пользователя. Предположим, что пользователь купил что-то; Я хочу, чтобы иметь возможность поставлять товар, как только сделка Bitcoin подтверждается. Операции подтверждаются, когда новые блоки принимаются; это идея моей 95% -finished «monitorreceived» коды. Это будет POST к URL, когда новые Транзакции и блоки принимаются. Информационный блок включает в себя все идентификаторы транзакций (и ссылку на предыдущий блок). Как вы заметили, у вас еще есть вопрос о том, что делать, если ваш код пропускает POST. Это не должно быть большой проблемой, хотя, потому что вы будете ресинхронизаций в следующий раз, когда блок найден. В худшем случае, вы будете грузить к блоку клиента 1 (10 минут) позже, чем является оптимальным, если подключение к bitcoind теряется.

2 февраля 2011, 5:20:07 PM	# 12
jon_smark Сообщений: 90 Цитировать по имени цитировать ответ	Re: Получение всех транзакций с данной TXID Цитата: Гэвин Андресен 02 февраля 2011 года, 4:10:24 PM Как вы думаете, что код должен иметь дело с проблемой "фиксированный TXID может больше не действителен" ? Или сделки, которые вы имели МЫСЛЬ N подтверждений и были в блоке с отметкой времени T повторно организованы, чтобы иметь М подтверждений и в блоке с отметкой времени T2? Вот как я думаю, что проблема должна быть решена: После первоначального вызова, клиент запрашивает список все Операции с минимальным числом N подтверждений. Демон Bitcoind прилежно обязывает. Клиент сохраняет TXID последней сделки на вершине стека. Теперь клиент запрашивает список всех сделок, по крайней мере, N подтверждений, которые произошли с TXID на вершине стека. Демон Bitcoind прилежно обязывает. Клиент снова хранит TXID последней сделки на вершине стека. Стек теперь два элемента. Какое-то время проходит, и клиент запрашивает еще раз все операции, которые произошли с TXID, что теперь на вершине стека. Там проблема, однако, поскольку запрошенная TXID была признана недействительной. Bitcoind демон возвращает ошибку отчетности этой ситуации. Теперь клиент знает, что все операции, которые имели место между двумя верхними элементами в стеке должны быть признаны недействительными. Он удаляет верхний элемент из стека и пробует новый запрос от "Последний известный хороший момент", Демон Bitcoind либо обязует или возвращает ошибку (принуждая клиент к попам еще один элемента из стека и аннулирования кучи сделок). Обратите внимание, что мое предложение ставит бремя решения этих волосатых обстоятельств на клиенте электронной коммерции, а не на демоне Bitcoind. Хотя я понимаю, что некоторые ленивые программисты могут в настоящее время удосужились реализовать этот алгоритм в своем клиентском приложении, даже они могут избежать возможностей катастрофы просто установив число N минимальных подтверждений быть довольно высоким. Это мое понимание того, что шансы цепи быть признаны недействительными умаляют экспоненциально с ростом N. Поэтому, если вы не можете быть обеспокоены, чтобы справиться с волосатыми ситуациями вы можете просто установить N = 100 и утешение в том, что Вселенная будет страдать от тепловая смерть, прежде чем есть шанс, что вы когда-нибудь столкнетесь с проблемами ... Как вы думаете? С наилучшими пожеланиями, Джон

2 февраля 2011, 5:35:48 PM	# 13
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: Получение всех транзакций с данной TXID Хороший, мне нравится ваше предложение. Как вы знаете, C ++?

2 февраля 2011, 5:41:11 PM	# 14
ribuck Сообщения: 826 Цитировать по имени цитировать ответ	Re: Получение всех транзакций с данной TXID Цитата: jon_smark от 02 февраля 2011 года, 5:20:07 PM ОТЕ, что мое предложение ставит бремя решения этих волосатых обстоятельств на клиенте электронной коммерции, а не на демоне Bitcoind. Это единственный способ, которым это будет работать в реальном мире. Это бизнес-решение, когда рассматривать сделку как завершенные, и как (и нужно ли) для обработки недействительных сделок. Различные предприятия будут иметь различные политики и процедуры.

2 февраля 2011, 6:06:42 PM	# 15
jon_smark Сообщений: 90 Цитировать по имени цитировать ответ	Re: Получение всех транзакций с данной TXID Цитата: Гэвин Андресен 02 февраля 2011 года, 5:35:48 PM Хороший, мне нравится ваше предложение. Как вы знаете, C ++? На самом деле, я надеялся, что поставив на клиенте бремя борьбы с волосатой вещью (и клиентом я имею в виду в зависимости от того приложения отправляют запросы JSON-RPC), мое предложение было бы сделать этот метод API относительно просто реализовать на демоне Bitcoin , Это звучит не слишком отличается от уже существующего метода «listtransactions», или же это? Я использовал C ++ в предыдущей жизни, но ничего серьезного с ним не сделано почти 10 лет. Почти все мои программирования в эти дни делается в OCaml. В любом случае, я не знаю достаточно о внутренней работе Bitcoin даже думать реализации этого себя с какой-либо степенью уверенности не знаю. Ура, Джон

3 февраля 2011, 5:26:48 PM	# 16
jon_smark Сообщений: 90 Цитировать по имени цитировать ответ	Re: Получение всех транзакций с данной TXID Hallo снова, Хорошо, я принял беглый взгляд на код в `rpc.cpp` (из https://github.com/bitcoin/bitcoin/blob/master/rpc.cpp), И кажется, `listtransactionssince` особенность, которую я просил не отличается от кода, который уже на месте. В функции `listtransactions`, уже существует цикл реверсирования назад от последней сделки до заданного количества сделок не будет достигнуто. В гипотетической `listtransactionssince` Функция, условие окончания для этого цикла должна быть вместо того, чтобы открытие сделки, чей TXID соответствует заданному параметру. Что касается вопроса о том, как мы должны иметь дело с ситуацией, когда была аннулирована прошлое сделки, я полагаю, что, что данная TXID никогда не будет найдена, и функция найдет сама перекручивание всего пути до конца. Таким образом, один простая реализация просто возвращает ошибку, если мы достигаем конец никогда не находя данную TXID. Однако, по соображениям производительности, имеет смысл вырваться из цикла и возвращает ошибку гораздо раньше, чем это. Итак, почему бы не предоставить функцию с дополнительным дополнительным параметром (отметка о времени), который указывает на последний раз в прошлом, до которого мы должны еще искать TXID. Если цикл находит сам тестирует сделку, временные метки старше этого обрезания, чем мы можем выйти из цикла раньше и сообщить состояние ошибки. Опять же, обратите внимание, что это ставит на клиенте бремя предоставления метки времени, которая имеет смысл. Твои мысли? С наилучшими пожеланиями, Джон

3 февраля 2011, 6:03:12 PM	# 17
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: Получение всех транзакций с данной TXID Если дополнительное время пары необходимы, может избавиться от "поскольку " Понятие и просто сделать это "дайте мне все получить сделки по [счет] с [minconfirmations], которые имеют время больше, чем [время]",

3 февраля 2011, 6:24:35 PM	# 18
jon_smark Сообщений: 90 Цитировать по имени цитировать ответ	Re: Получение всех транзакций с данной TXID Цитата: Гэвин Андресен февраля 03, 2011, 6:03:12 PM Если дополнительное время пары необходимы, может избавиться от "поскольку " Понятие и просто сделать это "дайте мне все получить сделки по [счет] с [minconfirmations], которые имеют время больше, чем [время]", Я подумал о том, что, как хорошо, но как бы клиент знать, если полученный ранее перечень сделок был признан недействительным? Кроме того, TXID можно считать уникальным, даже если мы рассмотрим множество всех операций, в том числе в недействительных отраслях. Имеет ли это свойство также и для транзакционных меток времени в Bitcoin? Я думаю, нет, что делает полагаться исключительно на временные метки плохая идея.

3 февраля 2011, 7:01:27 PM	# 19
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: Получение всех транзакций с данной TXID Цитата: jon_smark от 03 февраля 2011 года, 6:24:35 PM Я подумал о том, что, как хорошо, но как бы клиент знать, если полученный ранее перечень сделок был признан недействительным? А? Я не вижу, как проходит делает эту проблему лучше. Допустим, у вас есть сделки A B C D (в таком порядке). С времени T1, T1, T2 и T2 (A&B произошло 2 блока назад, вы получили C&D в последнем блоке). Теперь представьте блок-цепь повторно орг, так и B C теперь недействительны. Спросите все сделки после D, и вы получите nothing-- же, как если бы вы попросили все сделки с течением времени больше, чем Т2.

3 февраля 2011, 7:52:18 PM	# 20
jon_smark Сообщений: 90 Цитировать по имени цитировать ответ	Re: Получение всех транзакций с данной TXID котировка Допустим, у вас есть сделки A B C D (в таком порядке). С времени T1, T1, T2 и T2 (A&B произошло 2 блока назад, вы получили C&D в последнем блоке). Теперь представьте блок-цепь повторно орг, так и B C теперь недействительны. Хорошо, давайте рассмотрим этот сценарий. Шаг за шагом, просто чтобы убедиться, что мы находимся на той же странице: Демон Bitcoind знает сделок [А, В, С, D] с временными метками [Т1, Т1, Т2, Т2]. При первом вызове, клиент запрашивает список всех сделок. Он получает [A, B, C, D] (и временные метки) в качестве ответа. Там в блок-цепь повторно орг недействительными [С, D]. Четыре новые сделки [Е, F, G, Н] с временными метками [Т2, Т2, Т3, Т3] стало известно демона. Согласно демону, ток цепи [А, В, Е, F, G, H]. Если теперь клиент запрашивает все транзакции с Т2, он будет получать только [G, H] и не условие ошибки, став поэтому не обращая внимания к аннулированию [C, D] и существование [E, F]. Если же, с другой стороны, клиент должны были попросить всех сделок, начиная с D, демон вернулся бы (правильно) ошибка. Я что-то упускаю? Приветствия, (и спасибо за внимание!) Джон

Заголовок