amaclin, большое спасибо! Вот теперь разобрался что к чему.

amaclin, спасибо! Вот теперь что-то более-менее понятное.

Насколько я еще понял, это скрипт scriptPubKey предыдущего выхода, который кто-то может использовать, для проверки берет и выполняет перед собой скрипт scriptSig того входа, который собирается использовать данный выход? Т.к. связка scriptSig+ScriptPubKey работают не в контексте одной транзакции, а именно в цепочке "выход предыдущей транзакции" - "вход следующей транзакции". Я правильно понял?

Ну так может кто-то пояснить откуда берутся исходящий адрес и адрес назначения в транзакции?

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

Извините, не понял.

Разбираю потроха bitcoin и наткнулся на совсем уж странную непонятку... Подозреваю что тут все очевидно для кого-то, но мне чтение доков не помогло.

В транзакции прописаны входы и выходы.

Во входе прописаны:
- предыдущий используемый выход;
- scriptSig;

В выходах прописаны:
- сумма;
- scriptPubKey;

Я так понимаю что в scriptSig и scriptPubKey могут быть прописаны любые скрипты, соответствующие синтаксису скриптов bitcoin. Однако возникает вопрос - откуда в таком случае брать информацию с какого адреса и на какой переводятся BTC?

Понял. Спасибо! Я примерно так и подозревал.

Спасибо за понятный ответ!

А пиры, как я понимаю, формируются через обмен пирами между разными клиентами и специальным IRC? А в каком порядке идут проверки? Сначала на IRC или сначала на 8 базовых (зашитых в клиенте) пиров?

Да... И еще - для чего используется локальный пул неподтвержденных транзакций? Я так понимаю, что если транзакция относится к текущему узлу, тут все ясно - показывается неподтвержденное перечисление. Если текущий узел занимается майнингом, он включает транзакции в свой блок (кстати, как он при этом выбирает какие именно транзакции включать в блок?). А что в этом пуле неподтвержденных транзакций происходит на обычном узле, к которому эти транзакции не относятся? Они все всегда на нем хранятся? Или хранятся только до момента подтверждения, а потом стираются?

Всем привет!

Недавно только заинтересовался внутренностями протокола биткоин и никак не могу найти ответ на вопрос - как распространяется неподтвержденная транзакция в сети биткоин? Т.е. с помощью какой технологии? Узлы просто скачивают списки адресов с других узлов и рассылают новые транзакции по ним?

Аналогично - как распространяются замайненные блоки? Через ту-же сеть или для них есть отдельная?

Такой вариант обсуждается в контексте произвольной личной информации. Минус метода - необходимость держать такую персональную информацию в открытом доступе.

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


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


Спасибо, посмеялся. :-/

На класс! Пришел новый человек, ни в чем не разобрался и теперь можно закрывать лавочку. Спасибо - столько времени нам сэкономили!

А теперь опишите, как вы привяжете биткоин адрес к одному конкретному человеку и что именно не позволит ему зарегистрировать на себя кучу других биткоин-адресов и "заверить" и их тоже? И в чем именно должно заключаться это ваше "заверение"?

Всем привет! Интересную тему вы затронули. Мы в своем проекте gplvote.org уже несколько лет ею занимаемся. Но с некоторыми оговорками.
Например, мы считаем, что решение должно быть "без особых людей". Не должно быть каких-то людей или центров, которые могут стать "единой точкой отказа" и которые могут повлиять на работу системы идентификации.

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

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

Кроме того, наша "сеть доверия" - это только база данных. Как ее обрабатывать - использующие ее проекты могут решать сами. Т.е. критерии допуска к голосованию на основании данных нашей сети доверия каждый проект может формулировать как ему вздумается.

Конечно, это решение - не панацея. Но, как нам кажется, это лучший вариант из того, что сейчас можно придумать.

PS. Кстати, мобильное приложение для Android для подписания любых документов, которое мы будем использовать, уже разработано и доступно - https://play.google.com/store/apps/details?id=org.gplvote.signdoc (естественно, с исходными кодами - https://github.com/UncleAndy/sign_doc. Открытость исходников - еще одно обязательное условие нашего проекта). Приложение делает только одно - подписывает документы. Сделано оно как универсальный модуль, так что может быть использовано любыми сайтами и мобильными приложениями (работа с сайтами в документации уже описана, работа с приложениями пока нет). Кстати, демо сайт, на котором можно покрутить приложение для подписания документов вот тут - http://signdoc-client.gplvote.org/

Приложение для реализации сети доверия сейчас находится в разработке (в варианте с распределенной сетью серверов). Так-же мы работаем над версией приложения SignDoc для iOS.