JSON-RPC метод идея: список транзакций новее данной TXID | Биткоин форум

		Биткоин Форум > Разработка и Техническое Обсуждение
JSON-RPC метод идея: список транзакций новее данной TXID

8 декабря 2010, 5:07:21 PM	# 1
davux Сообщения: 289 Цитировать по имени цитировать ответ	Re: JSON-RPC метод идея: список транзакций новее, чем в данной TXID Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Было бы здорово иметь метод JSON-RPC для включения новых сделок, которые новее, чем конкретный идентификатор транзакции. Это позволит developpers смотреть новые сделки легко, просто путем отслеживания последней известной TXID и опроса, что метод со скоростью их выбора. Возможный способ сделать это было бы расширить listttransactions так, что она принимает необязательный `TXID` аргумент: Код: listtransactions <Счет> [Число = 10] [TXID] Если `TXID` дается, не показывать, ни какая-либо операция старше него. (Как, может быть, заметка на полях listtransactions, с или без TXID, должны принимать фильтрацию по категориям сделки: создавать, отправлять, получать, движение). Я сожалею, что не могу предложить любой патч здесь, как я не могу сделать любой приличный C ++.

Как заработать Биткоины?
Без вложений. Не майнинг.

8 декабря 2010, 5:44:01 PM	# 2
nelisky Сообщения: 1554 Цитировать по имени цитировать ответ	Re: JSON-RPC метод идея: список транзакций новее, чем в данной TXID Получил 1806 Биткоинов Реальная история. +1 Я не получил мои руки грязные там еще, и предпочел бы провести какое время я нахожу, чтобы сделать импорт / экспорт ключей, но это то, что помогло бы некоторые из моих сценариев много.

8 декабря 2010, 7:01:02 PM	# 3
jgarzik Сообщения: 1484 Цитировать по имени цитировать ответ	Re: JSON-RPC метод идея: список транзакций новее, чем в данной TXID Цитата: davux от 08 декабря 2010 года, 5:07:21 PM Было бы здорово иметь метод JSON-RPC для включения новых сделок, которые новее, чем конкретный идентификатор транзакции. Это позволит developpers смотреть новые сделки легко, просто путем отслеживания последней известной TXID и опроса, что метод со скоростью их выбора. Если мы добавим код, чтобы следить за новые сделки, то мы должны быть в том числе монитора патчи Гэвины: https://github.com/gavinandresen/bitcoin-git/tree/monitorreceived

8 декабря 2010, 8:20:57 PM	# 4
genjix Сообщения: 1232 Цитировать по имени цитировать ответ	Re: JSON-RPC метод идея: список транзакций новее, чем в данной TXID Конечно, так как WalletTx добавляются последовательно в бумажнике, можно предположить, что старые TXID-х появляются раньше в кошельке? Тогда это просто тривиально сделать линейный поиск, а затем продолжить на выплевывая TXID после того. Может кто-нибудь подтвердить это?

8 декабря 2010, 8:21:49 PM	# 5
Satoshi Сообщения: 364 Цитировать по имени цитировать ответ	Re: JSON-RPC метод идея: список транзакций новее, чем в данной TXID Это не безопасно использовать listtransactions таким образом. Я знаю, что я подвергся критике за то, что не хотят о listtransactions. Позвольте мне объяснить свое нежелание. Сделки динамичны. Прошлые сделки могут стать неподтвержденными, уйти и вернуться, становятся недействительными и исчезают, или заменить на другой двойной потратить. Их дата может измениться, их порядок может измениться. Программисты, естественно, склонны хотеть использовать listtransactions как это: кормить меня новые сделки, так как я в последний раз спросил, и я буду держать свою собственную бирку или статическую запись о них. Это похоже на работу во все регулярном использовании, но если вы используете суммы за что-либо, весьма годный для использования: 1) Как вы знаете, если прошлая сделка становится недействительной и исчезает? 2) Когда есть блок-цепь REORG, было бы легко двойное количество сделок, когда они получают еще раз подтвердили. 3) Сделка может быть заменена двойными пакеты с другой TXID. Вы бы рассчитывать и тратит. Модель, в которой вы предполагаете, что вам нужно только увидеть новые сделки, потому что вы уже видели предыдущие транзакции не соответствует действительности. Старые транзакции могут измениться в любой момент. Каждый раз, когда вы берете действия на основе оплаты полученных суммах, вы всегда должны вернуться к Bitcoin и попросить текущий общий баланс (или использовать движение или sendfrom), и быть готовыми к тому, что он может пойти вниз. Теперь, когда мы имеем Accounts Функция делает его легче сделать это правильный путь, мы лучше подготовлены, чтобы иметь listtransactions.

8 декабря 2010, 8:22:42 PM	# 6
jgarzik Сообщения: 1484 Цитировать по имени цитировать ответ	Re: JSON-RPC метод идея: список транзакций новее, чем в данной TXID Цитата: genjix от 08 декабря 2010 года, 8:20:57 PM Конечно, так как WalletTx добавляются последовательно в бумажнике, можно предположить, что старые TXID-х появляются раньше в кошельке? Тогда это просто тривиально сделать линейный поиск, а затем продолжить на выплевывая TXID после того. Бумажник база данных db4 ключ / значение (и карта ключ / значение в ОЗУ). Ни структура данных упорядочены по времени.

8 декабря 2010, 8:41:41 PM	# 7
mikegogulski Сообщения: 358 Цитировать по имени цитировать ответ	Re: JSON-RPC метод идея: список транзакций новее, чем в данной TXID Я могу видеть мотивацию для запроса davux в. При разработке плагинов для электронной коммерции я выпустил, я задавался вопросом о жизнеспособности долгосрочной перспективе использования "свалка" метод против бумажника, так как с течением времени возвращаемые данные просто будет расти и расти. То, что я предпочитаю быть в состоянии приложить обратный вызов URL JSON-RPC на счет или адрес, может быть вызвано каждый раз, когда подтверждение или любое другое изменение статуса на этот счет или адрес приходит, пока обратный вызов не будет сброшен. Это позволит исключить необходимость опроса бумажника полностью. Я бросил "запрос функции" сообщения в о том, что где-нибудь.

8 декабря 2010, 8:46:03 PM	# 8
jgarzik Сообщения: 1484 Цитировать по имени цитировать ответ	Re: JSON-RPC метод идея: список транзакций новее, чем в данной TXID Цитата: Satoshi от 08 декабря 2010 года, 8:21:49 PM Я знаю, что я подвергся критике за то, что не хотят о listtransactions. Позвольте мне объяснить свое нежелание. Сделки динамичны. Прошлые сделки могут стать неподтвержденными, уйти и вернуться, становятся недействительными и исчезают, или заменить на другой двойной потратить. Их дата может измениться, их порядок может измениться. Программисты, естественно, склонны хотеть использовать listtransactions как это: кормить меня новые сделки, так как я в последний раз спросил, и я буду держать свою собственную бирку или статическую запись о них. Это похоже на работу во все регулярном использовании, но если вы используете суммы за что-либо, весьма годный для использования: 1) Как вы знаете, если прошлая сделка становится недействительной и исчезает? 2) Когда есть блок-цепь REORG, было бы легко двойное количество сделок, когда они получают еще раз подтвердили. 3) Сделка может быть заменена двойными пакеты с другой TXID. Вы бы рассчитывать и тратит. В какой-то момент, веб-сайт или лицо, которое принимает сделку должен этот риск. Это неизбежно, используете ли вы listreceivedbyaddress или listtransactions. Поэтому listtransactions нежелание кажется настолько необычным. Почти каждый обмен или веб-сайт, принимающий Bitcoins достигает двоичный decisionpoint, когда сделка будет принята, и товары отгружены или обмен денег. После этого бинарного decisionpoint, даже если блок цепь reorg'd или операции исчезают, нет ничего на сайте можно сделать, но принять потерю (или продолжить возврат за пределами Bitcoin). С точки зрения веб-сайта зрения, существует нулевая эффективная разница между «listtransactions 6» и «listreceivedbyaddress 6», потому что конечный результат к оператору сайта является тот же: товар был отправлен / принятый заказ / деньги обменены.

8 декабря 2010, 10:36:45 PM	# 9
Satoshi Сообщения: 364 Цитировать по имени цитировать ответ	Re: JSON-RPC метод идея: список транзакций новее, чем в данной TXID Тогда как же справиться с проблемами, которые я перечислил в сообщении вы процитировали?

8 декабря 2010, 11:07:22 PM	# 10
jgarzik Сообщения: 1484 Цитировать по имени цитировать ответ	Re: JSON-RPC метод идея: список транзакций новее, чем в данной TXID Я считаю, что важным моментом является то, что эти вещи неизбежны небезопасным после определенной точки, даже для listreceivedbyaddress. Так что я думаю, что это полезно сравнить текущее поведение сайта под магистральным Bitcoin, с listtransactions. Будем называть это точка подтверждения. Решение ваших запросов ... Цитата: Satoshi от 08 декабря 2010, 10:36:45 PM 1) Как вы знаете, если прошлая сделка становится недействительной и исчезает? bitcoinmarket и mtgox и другие сайты, похоже, считают 6 подтверждений их "точка подтверждения", В тот момент, при котором транзакция может рассматриваться "безопасно." Если прошлая сделка становится недействительной и исчезает, веб-сайт не может избежать потенциальных потерь, потому что пользователь уже получил свой PayPal-USD или LR-USD или Pecunix ГАУ и исчез. То же самое для веб-магазина или кирпича и минометных магазине. Существует точка подтверждения, при которой клиент получает товар. Если TX становится недействительным после того, магазин берет неизбежную потерю, потому что клиент уже ушел с покупными товарами. Цитата: Satoshi от 08 декабря 2010, 10:36:45 PM 2) Когда есть блок-цепь REORG, было бы легко двойное количество сделок, когда они получают еще раз подтвердили. Будем считать, что граф подтверждения для TXID 0x1234 прыгающий дико от 0 до 10 до 0 и назад и вперед, из-за большого количества блоков реорганизацию;. Будь то listreceivedbyaddress или listtransactions, вы по-прежнему есть точка бинарного подтверждение, момент времени, в котором транзакция пересекает "утвержден магазин" уровень доверия. В этот момент подтверждения, клиент уходит с покупных товаров, а также магазин берет потери независимо от дальнейшей блочной цепи или поведения TX. Я согласен, программист может сделать ошибку, и предположим, что количество подтверждений всегда будет увеличиваться. Но это человеческая ошибка, тоже будет вызывать опасность при использовании listreceivedbyaddress. Цитата: Satoshi от 08 декабря 2010, 10:36:45 PM 3) Сделка может быть заменена двойными пакеты с другой TXID. Вы бы рассчитывать и тратит. На это точка, я согласен, что listtransactions представляет дополнительную опасность здесь, в связи с изменением TXID, если и только если новая двойные израсходуют соответствует целевому Bitcoin адреса разыскиваются пользователем JSON-RPC. Тем не менее, в этом случае тоже, безопасность пользователя полностью зависит от их уровня доверия: если ТЙ заменить до 6 подтверждений, программное обеспечение, скорее всего, не заметит ничего. Если TX заменен после 6 подтверждения, клиент уже ушел с покупными товарами, а пользователь Bitcoin беретом потери. Это просто присуще Bitcoin себя. Блок цепь REORG мог бы произойдет после того, как 50 блоков. Но веб-сайты не хотят, чтобы их пользователи ждать 50 блоков до получения товара. Это хорошо известная проблема, снэк машина. listtransactions ничего не добавляет к этой проблеме, помимо тех, которые уже уязвимы через listreceivedbyaddress. Сделки могут и будут заменены после двоичной "пункт подтверждение." Все пользователи Bitcoin должны понять это в их бизнес-планы, так же, как они составляют кредитных карты риски платежа или кражи в магазине и риск.

8 декабря 2010, 11:40:59 PM	# 11
davux Сообщения: 289 Цитировать по имени цитировать ответ	Re: JSON-RPC метод идея: список транзакций новее, чем в данной TXID Цитата: Satoshi от 08 декабря 2010 года, 8:21:49 PM Каждый раз, когда вы берете действия на основе оплаты полученных суммах, вы всегда должны вернуться к Bitcoin и попросить текущий общий баланс (или использовать движение или sendfrom), и быть готовыми к тому, что он может пойти вниз. Так что это будет проблемой дизайна в приложении в developper, а не проблема, присущая listtransactions. Что вы говорите: если listtransactions используется без ухода, это может быть опасно. Хорошо, но многие программные инструменты имеют ловушки тоже. Например, программирование с потоками полон дизайнерских ловушек. Это вовсе не означает, что этот инструмент не должен быть доступен для developpers, но что документация должна сильно предупредить об этих ловушках. Моя точка зрения: давайте listtransactions доступны, но документально это точно, как и любой API, и объяснить конструктивные ошибки, которые не должны быть сделаны при его использовании.

9 декабря 2010, 12:12:17 AM	# 12
Satoshi Сообщения: 364 Цитировать по имени цитировать ответ	Re: JSON-RPC метод идея: список транзакций новее, чем в данной TXID Я не говорю о нормальном риске для данного уровня minconf, я говорю о дополнительных подводных камнях из listtransactions при использовании этого способа. Цитата: Satoshi от 08 декабря 2010, 10:36:45 PM 2) Когда есть блок-цепь REORG, было бы легко двойное количество сделок, когда они получают еще раз подтвердили. Пример Ор по listtransactions <Счет> [Число = 10] [TXID], кажется, подразумевает, и было бы очень легко для программистов предположить, что, если они проходят в последнем TXID предыдущего вызова listtransactions, они никогда не будут видеть эту же операцию несколько раз, что не является случай. Было бы очень легко двойное количество платежей, если вы не поддерживаете свою собственную постоянную карту или словарь, чтобы отслеживать, какой TXID ты уже принял. Это не похоже, права иметь функцию, которая кажется портной сделал для использования определенного очевидного пути, и таким образом является неочевидной ловушкой. Цитата: jgarzik от 08 декабря 2010, 11:07:22 PM Цитата: Satoshi от 08 декабря 2010, 10:36:45 PM 3) Сделка может быть заменена двойными пакеты с другой TXID. Вы бы рассчитывать и тратит. listtransactions ничего не добавляет к этой проблеме, помимо тех, которые уже уязвимы через listreceivedbyaddress. Предположим, что и проводит это к тому же адресу. getreceivedbyaddress всегда будет рассчитывать только на одну или другие израсходуют в любой момент времени, никогда оба. Использование listtransactions, было бы очень легко подсчитать обоих. Вы видите первый израсходуете, то считать. Вы видите, вторые расходы, считать его. Тотал двойной учет.

9 декабря 2010, 12:41:44 AM	# 13
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: JSON-RPC метод идея: список транзакций новее, чем в данной TXID Я буду и добавить еще одну причину, чтобы не иметь "Список операций, которые произошли после того, как " : переехать "операции" не имеет идентификатора транзакции, но они не влияют на баланс счета (и перечислены в listtransactions). Ваш код будет получить действительно грязными, если вы ожидаете, чтобы позвонить listtransactions, а затем запастись на TXID последнего пункта вернулся. Если бы это было "категория":"переехать", Там не будет TXID ... RE: исключая опрос: в какой-то момент довольно скоро, я планирую уборку мой "monitorreceived" патч, чтобы POST к URL, когда операции приходят или блоки принимаются ... но мне нужно сделать некоторые глубокого мышления перепроектировать на основе уроков, извлеченных из «счетов». Это может превратиться в очень минимальный API, если уведомление "Эй, TXID <123ae4221 ...> только что получил N подтверждений, вы можете позвонить gettransaction и getbalance получить уточненный."

9 декабря 2010, 12:58:05 AM	# 14
jgarzik Сообщения: 1484 Цитировать по имени цитировать ответ	Re: JSON-RPC метод идея: список транзакций новее, чем в данной TXID Цитата: Гэвин Андресен 09 декабря 2010, 12:41:44 AM Я буду и добавить еще одну причину, чтобы не иметь "Список операций, которые произошли после того, как " : Я согласен с вами, и Satoshi о "TXS после ", Мои listtransactions (сейчас xlisttransactions) патч многозначительно не имеет такой функции, и никогда не имеет.

9 декабря 2010, 11:48:56 AM	# 15
ribuck Сообщения: 826 Цитировать по имени цитировать ответ	Re: JSON-RPC метод идея: список транзакций новее, чем в данной TXID Цитата: jgarzik от 08 декабря 2010, 11:07:22 PM Если прошлая сделка становится недействительной и исчезает, веб-сайт не может избежать потенциальных потерь, потому что пользователь уже получил свой PayPal-USD или LR-USD или Pecunix ГАУ и исчез. Это не всегда так. Иногда клиент будет иметь баланс на сайте. Оператор веб-сайта, безусловно, хочет знать, если прошлые сделки становятся недействительными и исчезают.

9 декабря 2010, 4:13:50 PM	# 16
jgarzik Сообщения: 1484 Цитировать по имени цитировать ответ	Re: JSON-RPC метод идея: список транзакций новее, чем в данной TXID Цитата: ribuck 09 декабря 2010, 11:48:56 AM Цитата: jgarzik от 08 декабря 2010, 11:07:22 PM Если прошлая сделка становится недействительной и исчезает, веб-сайт не может избежать потенциальных потерь, потому что пользователь уже получил свой PayPal-USD или LR-USD или Pecunix ГАУ и исчез. Это не всегда так. Иногда клиент будет иметь баланс на сайте. Оператор веб-сайта, безусловно, хочет знать, если прошлые сделки становятся недействительными и исчезают. Конечно, и это достаточно легко отслеживать с помощью операций.

9 декабря 2010, 6:08:08 PM	# 17
Satoshi Сообщения: 364 Цитировать по имени цитировать ответ	Re: JSON-RPC метод идея: список транзакций новее, чем в данной TXID Цитата: jgarzik 09 декабря 2010, 12:58:05 AM Я согласен с вами, и Satoshi о "TXS после ", Мои listtransactions (сейчас xlisttransactions) патч многозначительно не имеет такой функции, и никогда не имеет. Пока интерфейс предназначен для таких вещей, как показывает пользователю последней N истории транзакций, это хорошо, теперь, когда мы имеем Accounts Функции делает его легче сделать-определение ОПЛАТЫ правильного пути. Gavin, может listtransactions иметь возможность перечислить операции по всем счетам? Я не уверен, что интерфейс может быть, может быть: listtransactions [Число] Было бы трудно сделать это из командной строки, хотя. Я не могу думать о хорошем решении для интерфейса, это проблема. Может быть "" особый случай, как "" является. Каждый должен будет убедиться, что ни один пользователь не может создать имя учетной записи "", Цитата: jgarzik 09 декабря 2010, 4:13:50 PM Конечно, и это достаточно легко отслеживать с помощью операций. Я не понимаю, как это "легко" отслеживать с помощью операций.

9 декабря 2010, 7:23:52 PM	# 18
davux Сообщения: 289 Цитировать по имени цитировать ответ	Re: JSON-RPC метод идея: список транзакций новее, чем в данной TXID Цитата: Satoshi 09 декабря 2010, 6:08:08 PM Gavin, может listtransactions иметь возможность перечислить операции по всем счетам? Это было бы прекрасно! Цитата: Satoshi 09 декабря 2010, 6:08:08 PM Я не уверен, что интерфейс может быть, может быть: listtransactions [Число] Было бы трудно сделать это из командной строки, хотя. Как насчет пустой строки? Это легко использовать в программном контексте (например, в Python), а также в контексте оболочки: Код: bitcoind listtransactions '' Кроме того, он будет соответствовать текущей API, так как пустая строка уже означает "любой счет", Например, при использовании с "Отправлено из" (И, возможно, в других ситуациях). Давайте не будем использовать несколько специальных случаев, которые являются специальными тонкими, различными способами. Чем проще, тем лучше.

9 декабря 2010, 7:41:33 PM	# 19
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: JSON-RPC метод идея: список транзакций новее, чем в данной TXID Цитата: Satoshi 09 декабря 2010, 6:08:08 PM Gavin, может listtransactions иметь возможность перечислить операции по всем счетам? Я не уверен, что интерфейс может быть, может быть: listtransactions [Число] Было бы трудно сделать это из командной строки, хотя. Я не могу думать о хорошем решении для интерфейса, это проблема. Может быть "" особый случай, как "" является. Каждый должен будет убедиться, что ни один пользователь не может создать имя учетной записи "", Да, listtransactions "" <подсчитывать> возможно. Остальные процедуры счета могут вернуть новую "неверное имя учетной записи" Ошибка, если дано "", У меня есть две проблемы с этим, хотя: 1. listtransactions "" придется перебирать каждую сделку в бумажнике (сделки не индексируется по времени), который будет медленным для больших кошельков и будут получать медленнее, в течение долгого времени. И индексирование сделки просто так, что listtransactions быстро нарушает "дополнительная функция не должна стоить ничего, если она не используется" принцип. 2. Что такое использование случае "список последних N операций по всем счетам" ? Только один я могу придумать разрабатывает альтернативный графический интерфейс, который взаимодействует с bitcoind через JSON-RPC, но для поддержки, что, по крайней мере несколько других функций, должен быть добавлен в то же время (например, listtransactions бы нужно добавить счета и Bitcoin информации обратитесь к объектам, которые он возвращает ....)

31 июля 2013, 8:18:06 PM	# 20
abourget Сообщения: 8 Цитировать по имени цитировать ответ	Re: JSON-RPC метод идея: список транзакций новее, чем в данной TXID Что такое новое положение дел в отношении этого вопроса, после 3-х лет? Есть ли способ для опроса или получить уведомление, когда все происходит в сети? благодаря

« Предыдущая тема | Следующая тема »

Как заработать Биткоины?

Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包

bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW