Аудиторские контракты | Биткоин форум

		Биткоин Форум > Разработка и Техническое Обсуждение
Аудиторские контракты

18 сентября 2012, 6:04:55 PM	# 1
titeuf_87 Сообщения: 112 Цитировать по имени цитировать ответ	Re: Assurance контрактов Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Всем привет, Осмотрев разговор Майк Хирн на конференции я хотел бы играть немного с некоторыми из этих вещей, так что я начал работать над контракты по обеспечению доказательство концепции. Использование Bitcoin 0.7 и сырьевая транзакции API я получил эту работу на testnet-в-коробке. Я не пробовал это на главной сети Bitcoin. Это небольшой питон скрипт, который делает три вещи: 1) Создание нового договора гарантии. Код: $ Питон pledge.py createcontract miA6bqrz9thieUpd5rZmHe1XpTmY6DLjot 7500000000 ТЙ контракт: Сумма: 75 To: miA6bqrz9thieUpd5rZmHe1XpTmY6DLjot 01000000000100eb08bf010000001976a9141cf69384eb6b27a8161b59577f41310a93b9c14388ac00000000 2) Добавление обязательства (это должно быть сделано с помощью различных людей, которые хотят закладывать некоторые биткойна): Код: $ Питон pledge.py залог 01000000000100eb08bf010000001976a9141cf69384eb6b27a8161b59577f41310a93b9c14388ac00000000 5000000000 Направлено 50BTC обратиться n21Nw4ikZrURVxaydZwYrPmdDyd8J8ZdQw (Закрытый ключ: cVNe9DSbZPe71pzwWpRbiR1n4NQ2Bdqi67g7HGiJCzARtX66nefY) TXID: 0ae14dc7c016d8bce090cfaa2eb88ce1e2818f24d3372c5682118ff5a68e8200 TXOut: 0ae14dc7c016d8bce090cfaa2eb88ce1e2818f24d3372c5682118ff5a68e8200: 0 Подписание сделки ... Подпись ввода: 00828ea6f58f1182562c37d3248f81e2e18cb82eaacf90e0bcd ... 3) Человек, который сделал этот контракт должен собрать все входы от всех и поместить их в один текстовый файл. Если есть достаточное количество объявленных взносов они могут быть объединены и окончательная транзакция посылается в сеть Bitcoin. Код: $ Питон pledge.py завершить 01000000000100eb08bf010000001976a9141cf69384eb6b27a8161b59577f41310a93b9c14388ac00000000 входы Отправка необработанный ТХ ... 010000000200828ea6f58f11 ... Это по-прежнему очень много доказательство концепции: приложения командной строки, имеющим разделить входы, большие строки, которые должны быть скопированы вокруг ... Но это работает Код на https://github.com/titeuf87/btcassurance Части него копируются из Bitcoin-питона, pynode и pywallet. Я думаю, что следующая вещь для этого, чтобы разделить его на сервер / клиент модель: сервер, который содержит контракты обеспечения и клиентом, что позволяет людям закладывать биткойны к одному из этих договора и отправить подписанный вход через.

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

19 сентября 2012, 1:17:52 PM	# 2
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: Assurance контрактов Получил 1806 Биткоинов Реальная история. Замечательно! Вот несколько мыслей. Я настоятельно рекомендую всем, кто хочет реализовать эти виды приложений, чтобы рассмотреть язык и рамки вы используете заранее. Python отлично подходит для создания прототипов и сценариев. Это плохой выбор для создания удобных настольных приложений, которые выполняют хорошо. C ++ приложения являются лучшими для этого, но и труднее писать. Java сидит где-то в середине. Все, что зависит от механизма Bitcoins RPC означает, что вам нужен полный ход узла, и это будет становиться все менее и менее распространены в будущем, особенно для конечных пользователей. Твердая часть внедрения этих систем на самом деле не крипта, это все вещи нужно наслаивать на вершине, чтобы создать гладкий и простой пользовательский опыт. Очевидно, начиная с командной строкой легко, но вы должны действительно думать о будущем, как вы можете позволить своим родителям использовать его. Если бы я был реализации этой системы, я написал бы начать с приложением GUI Java с помощью bitcoinj. Не только потому, что я написал это и так хорошо знаком с ним, а потому, что это может напрямую подключиться к сети P2P и синхронизировать бумажник цепи очень быстро по сравнению с полным узлом. Кроме того, поскольку интерфейсы должны сделать его легко настроить транзакции вам нужно. Наличие отдельного кошелька полезно, потому что это означает, что вы можете легко перемещать деньги и, и закладывать те же деньги на те же контракты (полезную возможность, когда есть несколько провайдеров, конкурирующих предоставить услугу, и вы не знаете, какой из них будет достижения цели первыми). Тогда я придумал набор буферов протоколов, описанных договор гарантии, как передать его на сервер и так далее. Я хотел бы использовать буфера протокола даже для очень простых протоколов, потому что, как вы получите простую расширяемость и протокол может быть легко описан, например, в стандартах документа. bitcoinj потребуется несколько незначительных расширений для изготовления правильный вид сделки, но если кто-нибудь серьезно о том, чтобы реальный продукт из этого, что должен был быть гладким и простым в использовании, я бы с удовольствием выполнять эти расширения и писать некоторые пример кода.

19 сентября 2012, 8:41:03 PM	# 3
titeuf_87 Сообщения: 112 Цитировать по имени цитировать ответ	Re: Assurance контрактов котировка Я настоятельно рекомендую всем, кто хочет реализовать эти виды приложений, чтобы рассмотреть язык и рамки вы используете заранее. Python отлично подходит для создания прототипов и сценариев. Это плохой выбор для создания удобных настольных приложений, которые выполняют хорошо. C ++ приложения являются лучшими для этого, но и труднее писать. Java сидит где-то в середине. Я не хочу, чтобы начать дебаты языка здесь, поскольку есть много аргументов сделано уже как в пользу и против Python. Как пользователь Ubuntu, хотя, много приложений я использую сделаны в Python, и они работают очень хорошо. Самым большим недостатком является то, вероятно, портативность GUI-структуры: GTK попало в Windows, и понятия не имею, если он даже работает на Mac OS X. Qt, вероятно, лучший вариант, но я не имеют никакого опыта с этим. C ++ будет лучшим вариантом здесь, в сочетании с Qt. Но я хорошо только с Python и .Net. котировка Все, что зависит от механизма Bitcoins RPC означает, что вам нужен полный ход узла, и это будет становиться все менее и менее распространены в будущем, особенно для конечных пользователей. Правда. В идеале вы бы просто иметь веб-сайт, где люди могут отправить биткойны на определенный адрес Bitcoin для залога, сколько Bitcoins они хотят, и это не будет работать иначе, чем отправка биткойны к обычному адресу Bitcoin. Но я сомневаюсь, что что-то подобное возможно. котировка Твердая часть внедрения этих систем на самом деле не крипта, это все вещи нужно наслаивать на вершине, чтобы создать гладкий и простой пользовательский опыт. Очевидно, начиная с командной строкой легко, но вы должны действительно думать о будущем, как вы можете позволить своим родителям использовать его. Я уже заметил, что делая это доказательство концепции было легко, но я думал о том, как развиваться и пока существуют различные способы, они не так легко. котировка Если бы я был реализации этой системы, я написал бы начать с приложением GUI Java с помощью bitcoinj. Не только потому, что я написал это и так хорошо знаком с ним, а потому, что это может напрямую подключиться к сети P2P и синхронизировать бумажник цепи очень быстро по сравнению с полным узлом. Кроме того, поскольку интерфейсы должны сделать его легко настроить транзакции вам нужно. Наличие отдельного кошелька полезно, потому что это означает, что вы можете легко перемещать деньги и, и закладывать те же деньги на те же контракты (полезную возможность, когда есть несколько провайдеров, конкурирующих предоставить услугу, и вы не знаете, какой из них будет достижения цели первыми). Тогда я придумал набор буферов протоколов, описанных договор гарантии, как передать его на сервер и так далее. Я хотел бы использовать буфера протокола даже для очень простых протоколов, потому что, как вы получите простую расширяемость и протокол может быть легко описан, например, в стандартах документа. Я думал о чем-то подобным, но без какой-либо blockchain вообще на стороне клиента. Поскольку должно быть центральным сервером, в любом случае, чтобы собрать все подписанные материалы, что центральный сервер может отслеживать blockchain тоже. Я полагаю, что-то вроде этого: веб-сервер, как Kickstarter, где люди могут увидеть все проекты, которые они могут ЗАЛОГ биткойны в. Если кто-то хочет, чтобы закладывать в проект они могут использовать клиентское приложение. Это клиентское приложение очень просто: 1) Он создает новый адрес Bitcoin и просит пользователя отправить биткойны к нему. 2) Он уведомляет сервер об этом адресе: когда Bitcoins направляется к нему, сервер позволит клиенту знать и клиент будет подписывать обязательство по договору гарантии и отправить его обратно на сервер. 3) Когда сервер получил достаточно обещает, что будет транслировать финальную транзакцию на сервер 4) Если не хватает обещаний, и пользователь хочет, чтобы их Bitcoins тогда клиент может создать новую транзакцию Bitcoin и отправить его на сервер, который будет транслировать его. Это, я думаю, по-прежнему безопасен, так как закрытый ключ к этому новому Bitcoin адрес хранится в клиентском приложении, и сервер не получает к нему доступ. Использование bitcoinj для прямого подключения к сети Bitcoin бы некоторые из этих шагов, ненужных, за счет клиента, имеющим обрабатывать blockchain. Я не совсем уверен, что дополнительные расходы стоит, даже если она идет гораздо быстрее, чем полный узел. Кроме того, с буферами протокола, вы имеете в виду использовать его для обмена данных между клиентом и сервером, не так ли? Если да, то почему бы просто не использовать сервер HTTP и JSON? Я не знаю много о буферах протоколов, за исключением глядя на примерах. Спасибо за ваши мысли

19 сентября 2012, 8:45:06 PM	# 4
Северьян Сообщения: 476 Цитировать по имени цитировать ответ	Re: Assurance контрактов Пожертвование послал. Assurance контракты будут одна из основ принятия Bitcoin путем большего мира. Выступая в качестве неразвивающейся LUSER, пожалуйста, продолжать эту линию работы.

20 сентября 2012, 12:33:42 AM	# 5
kjj Сообщения: 1302 Цитировать по имени цитировать ответ	Re: Assurance контрактов Круто! Вы следуете BIP10?

20 сентября 2012, 8:16:35 AM	# 6
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: Assurance контрактов Цитата: titeuf_87 19 сентября 2012 года, 8:41:03 PM Как пользователь Ubuntu, хотя, много приложений я использую сделаны в Python, и они работают очень хорошо. Да. Python очень хорошо работает на Linux, так как он поставляется из коробки, имеет хорошие привязки к родному инструментарии и т.д. Но большинство людей не используют Linux. Цитата: titeuf_87 19 сентября 2012 года, 8:41:03 PM Я думал о чем-то подобным, но без какой-либо blockchain вообще на стороне клиента. Поскольку должно быть центральным сервером, в любом случае, чтобы собрать все подписанные материалы, что центральный сервер может отслеживать blockchain тоже. Да, он может сделать это. Это усложняет протокол клиент / сервер, хотя, и в будущем я надеюсь увидеть поддержку договора гарантии интегрирована в бумажнике программного обеспечения. Как это уже делает отслеживание блока цепи, было бы легче для тех клиентов, просто представить сделку непосредственно. Вы можете настроить основные приложения GUI бумажник в bitcoinj лишь несколько строк кода, это не очень сложно. Цитата: titeuf_87 19 сентября 2012 года, 8:41:03 PM 2) Он уведомляет сервер об этом адресе: когда Bitcoins направляется к нему, сервер позволит клиенту знать и клиент будет подписывать обязательство по договору гарантии и отправить его обратно на сервер. Сервер имеет не действительно отслеживать блок цепи независимо от того, чтобы она могла передать транзакции обратно клиенту для подписания. Но уже есть протокол, который позволяет клиенту найти транзакции, данные некоторые ключи / адрес - регулярный протокол Bitcoin P2P. Это странно, что переописать. Имейте в виду, если вы не заботитесь об обработке повторных Orgs, протокол P2P по умолчанию является довольно проста в использовании. Но вы, вероятно, заботиться о ре-Оргам, в противном случае вы будете в конечном итоге с странные края случае ошибки. Вот почему я рекомендую только с использованием предварительно составленной библиотеки Bitcoin. Переключение вне Bitcoin P2P сетей для чего-того HTTP + JSON на основе не меняют основные правил системы, она не позволяет игнорировать повторные Orgs и другие детали цепи вследствие свободном. Цитата: titeuf_87 19 сентября 2012 года, 8:41:03 PM 3) Когда сервер получил достаточно обещает, что будет транслировать финальную транзакцию на сервер 4) Если не хватает обещаний, и пользователь хочет, чтобы их Bitcoins тогда клиент может создать новую транзакцию Bitcoin и отправить его на сервер, который будет транслировать его. Почему клиент должен зависеть от сервера, чтобы помочь им отменить свое обещание? Это похоже неотъемлемый конфликт интересов. Опять же, разговаривая с P2P-сети, когда можно решить эту проблему. Цитата: titeuf_87 19 сентября 2012 года, 8:41:03 PM Кроме того, с буферами протокола, вы имеете в виду использовать его для обмена данных между клиентом и сервером, не так ли? Если да, то почему бы просто не использовать сервер HTTP и JSON? Вы можете использовать HTTP, если вам нравится. Почему protobufs? Потому что я думаю, что они лучше, чем JSON. Во-первых, есть простой язык схемы, который легко читать. Большую часть времени, когда я вижу примеры JSON они катятся свой собственный способ описания протокола и в значительной степени опираться на примеры. Во-вторых есть Protobuf компиляторы, которые генерируют код обертки для вас на основе языке схемы, практически для любого языка программирования можно назвать. Таким образом, вы можете работать со структурами данных непосредственно вместо неудобных типов данных в формате JSON. В-третьих, это эффективный и надежный, особенно при передаче двоичных данных (который является общим в протоколах Bitcoin), нет никаких странных причуд кодирования, который может укусить вас, как с помощью JSON. Короче говоря, я не вижу никаких причин, чтобы использовать JSON для чего-нибудь, если вы не общаетесь с веб-браузером и исправны только с Eval () ИНГ ответ. Но даже тогда, иногда это небезопасно. Также protobufs набирает довольно хорошее принятие, есть много библиотек и вещей, которые интегрируются с ними. Например, библиотека Нетти асинхронной IO в Java может обрабатывать Protobuf + HTTP изначально, так что практически нет кода требуется. Я предполагаю, что протокол может выглядеть Код: // Сохранение в файл и загрузить с некоторых веб-сервера / электронной почты вложения / и т.д.. сообщение ContractDescription { требуемые байты output_script = 1; требуется UInt64 target_value = 2; // HTTP- или HTTPS место, где сообщение Залогом может быть POSTd. // Может отсутствовать в вариантах протокола, где это предусмотрено контекстом. Необязательная строка pledge_submit_url = 3; // для восприятия человеком описание того, что договор о. Необязательное описание строки = 4; // 600x300 PNG, которые могут быть отображены в графическом интерфейсе рядом с описанием. дополнительный байт LOGO_IMAGE = 5; } сообщение Pledge { // Посылает target_value средства на output_script требуемые байты serialized_tx = 1; // У человека считываемого сообщения (возможно, поощрение) к предпринимателю Необязательная строка сообщения = 2; }

20 сентября 2012, 6:50:04 PM	# 7
titeuf_87 Сообщения: 112 Цитировать по имени цитировать ответ	Re: Assurance контрактов Цитата: Северьян от 19 сентября 2012 года, 8:45:06 PM Пожертвование послал. Assurance контракты будут одна из основ принятия Bitcoin путем большего мира. Выступая в качестве неразвивающейся LUSER, пожалуйста, продолжать эту линию работы. Спасибо, это понятно, Цитата: kjj 20 сентября 2012, 12:33:42 AM Круто! Вы следуете BIP10? Я не знал об этом BIP. Я смотрел на нее и на первый взгляд, кажется, хорошо: есть сделка, которая должна быть подписана. Но я не думаю, что он будет работать для этого случая использования: каждый пользователь хочет добавить входы транзакций в этом, а не только их подписать. И они должны быть подписаны с помощью "anyonecanpay", Цитата: Майк Херн на 20 сентября 2012 года, 8:16:35 AM длинный пост ... Благодаря Вы убедили меня использовать Bitcoin p2p самой сети. Мне нравится идея договора страхования является просто файл, который вы можете скачать (который также является то, что Kjj предложил в своем посте). Ваш пример protobuffer сделал это очень ясно, как она может работать. Это делает клиентское приложение / залог сможет работать независимо друг от друга и не привязаны к одному конкретному серверу. Я играл немного с bitcoinj ранее сегодня (в то же время отрабатывает свои знания Java, это было в то время). Из беглого взгляда на источнике, кажется, что создание сделки по контракту уже будет возможно, но подписание данных с использованием anyonecanpay пока не представляется возможным?

20 сентября 2012, 7:22:03 PM	# 8
kjj Сообщения: 1302 Цитировать по имени цитировать ответ	Re: Assurance контрактов Цитата: titeuf_87 от 20 сентября 2012 года, 6:50:04 PM Цитата: kjj 20 сентября 2012, 12:33:42 AM Круто! Вы следуете BIP10? Я не знал об этом BIP. Я смотрел на нее и на первый взгляд, кажется, хорошо: есть сделка, которая должна быть подписана. Но я не думаю, что он будет работать для этого случая использования: каждый пользователь хочет добавить входы транзакций в этом, а не только их подписать. И они должны быть подписаны с помощью "anyonecanpay", Я хотел бы поговорить с etotheipi об этом, и попытаться использовать по существу один и тот же формат. Детали немного отличаются, но идея очень похожа: вы собираете подписи для последующего объединения.

20 сентября 2012, 10:02:22 PM	# 9
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: Assurance контрактов Цитата: titeuf_87 от 20 сентября 2012 года, 6:50:04 PM Я играл немного с bitcoinj ранее сегодня (в то же время отрабатывает свои знания Java, это было в то время). Из беглого взгляда на источнике, кажется, что создание сделки по контракту уже будет возможно, но подписание данных с использованием anyonecanpay пока не представляется возможным? Если вы посмотрите на Transaction.signInputs () есть логический зашит ложный называются anyoneCanPay. Там также утверждают в верхней проверки вы используете SIGHASH_ALL, так как я никогда не испытывал другие флаги. Я думаю, что было бы некоторые довольно простые модификации, чтобы добавить поддержку. В основном вы продлите Wallet.SendRequest иметь новый параметр, как "InputValue", По умолчанию было бы снята с охраны / устанавливается на фиктивное значение как -1, а затем, очевидно, входное значение будет >= Выходное значение, как сейчас. Если явно установлен, то wallet.completeTx () будет добавить достаточное количество входов для достижения целевого значения, а затем вызвать tx.signInputs (SigHash.ALL, это, правда); где последние логические пары будут тот, который вы добавить, что бы установить anyoneCanPay. Одна вещь, которая требует тщательной мысли, что происходит, если вы не можете сделать целевое значение входного сигнала точно. Добавление выходов изменения не будут работать должным образом, так что вам нужно сначала построить транзакцию, которая дает вам выход точно правильное значение, а затем другую сделку закладывать его. Это усложнило бы API несколько, если все сделано автоматически, поэтому я предлагаю просто бросать исключение в этом случае и ожидает приложение, чтобы справиться с этим на более высоком уровне. Если вы хотите, чтобы обсудить его дальше, давайте дизайн разговор в список рассылки bitcoinj.

3 октября 2012, 4:46:13 PM	# 10
titeuf_87 Сообщения: 112 Цитировать по имени цитировать ответ	Re: Assurance контрактов Я не был в состоянии работать много на это: всего лишь несколько часов в выходные дни. Bitcoinj, кажется, отлично работает для клиента (с некоторыми изменениями), но я думал о сервере Сейчас: Я не думаю, что либо bitcoinj или Satoshi клиента есть простой способ узнать, если определенный выход сделки проводится? Это необходимо для того, что при наличии достаточного количества объявленных взносов окончательная сделка может быть сделано только с действительным, а не уже израсходованы, входы и транслируются в сети Bitcoin.

3 октября 2012, 5:26:22 PM	# 11
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: Assurance контрактов Если транзакция в бумажнике и "в ожидании", То это будет проверяться каждый раз, когда новый блок найден, чтобы увидеть, если какие-либо операции в блоке дважды провести ввод любых сделок, которые находятся на рассмотрении. Я думаю, что есть еще несколько отверстий в этом (например, несколько отложенных сделок, которые зависят друг от друга), но я думаю, что если вы добавите взносы в ожидании бассейна в кошельке, то вы можете слушать на WalletEventListener.onTransactionConfidenceChanged () событие, или TransactionConfidence.Listener событие, чтобы увидеть, если ТЕ идет DEAD. Если это DEAD, то это означает, что был дважды провел в Лету. В случае договоров гарантии это не обязательно является проблемой, пользователь может обещали те же деньги на несколько проектов на первый пришел-первый обслужен.

3 октября 2012, 7:55:36 PM	# 12
titeuf_87 Сообщения: 112 Цитировать по имени цитировать ответ	Re: Assurance контрактов Спасибо, что вы полезны, как всегда Mike Это, казалось, работали, я никогда не думал о добавлении взносов в кошелек человека заключением договора о гарантии, так как они не являются на самом деле действительными сделками (ввода < вывод).

3 октября 2012, 9:01:07 PM	# 13
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: Assurance контрактов Да, очевидно, просто положить обязательства в кошельке недостаточно. Рассматриваемые операции будут проверяться на наличии двойного тратит, и вы можете узнать о них с помощью слушателей событий, но вы до сих пор не знаете, что входные значений, так что вы не можете на самом деле построить израсходуете с таким бумажником. Я думаю, что мы должны были бы следующие изменения: Класс TransactionInput нужно будет поддерживать кэширование значений подключенных выходов. Когда транзакция извлекаются из цепочки обычно входные значения не имеют значения, вы заботитесь только о выходных значениях. Для залога вы уход. Protobuf сериализация должна быть модернизирована, так что вы можете записать, что хорошо. У нас еще есть проблемы, как вы заявили, зная, что выход. Во-первых, bitcoind может получить новый JSON-RPC, чтобы проверить множество неизрасходованных выходов. Это означает, что некоторые C ++ взлома. Другие проекты могут принести пользу тоже. С другой стороны, Мэтты Corrallo повысила bitcoinj быть полностью проверка. Я рассматриваю и слияние своего кода в данный момент. После того, как эта работа объединена, все это может быть сделано в Java. Я думаю, что такой подход, вероятно, выше, как у вас есть достаточный контроль, чтобы избежать некоторых сложных условиях гонки. Класс Бумажник должен понимать, что делать с обещаний. Я предполагаю, что бумажник может содержать как обычные действительные сделки и обязательства. Когда вы пытаетесь построить расходы, было бы собрать все предметы, которые совместно идентичную производительность и увидеть, если договор гарантии может быть завершен. Если да, то это засчитывается ваш баланс и будет использоваться для построения израсходует. Если нет, то нет. Я думаю, что TransactionConfidence может потребоваться расширение, чтобы отразить, что залог ТХ полностью недействительным. Вопрос состоит в том, что если у вас есть кошелек с регулярными фондами и некоторыми обязательствами, и вы строите расходы, что хочет ценность их всех? Вы можете объединить обязательства вместе, но вы не можете объединить этот заполненный договор вместе с другой произвольной сделкой. Я думаю, что кошелек API должен быть обновлен для поддержки создания нескольких операций в рамках расходов. Он не играет так хорошо с текущим дизайном В качестве альтернативы вы можете просто ввести некоторые основные ограничения на данный момент, как и о том, кошельке может содержать обязательства XOR регулярных денежных средств. Это, вероятно, не является проблемой на практике.

6 октября 2012, 3:23:19 PM	# 14
titeuf_87 Сообщения: 112 Цитировать по имени цитировать ответ	Re: Assurance контрактов Раньше я просто думал об обнаружении двойной тратит, и я не думаю, что в дальнейшем о том на самом деле знать, сколько уже обещаны. Можно выполнить договор гарантии, даже если вы не знаете, сколько каждый вход стоит, но это не дорога, я хочу взять с собой: она включает в себя привлечение всех обязательств вместе в одной транзакции, представив его в узел Bitcoin и если она каким-то образом попадает в блок, то мы знаем, что у нас было достаточно обещаний. Но это имеет так много недостатков, что я не буду пытаться это. котировка Класс TransactionInput нужно будет поддерживать кэширование значений подключенных выходов. Когда транзакция извлекаются из цепочки обычно входные значения не имеют значения, вы заботитесь только о выходных значениях. Для залога вы уход. Protobuf сериализация должна быть модернизирована, так что вы можете записать, что хорошо. Согласитесь, это будет необходимо здесь. котировка У нас еще есть проблемы, как вы заявили, зная, что выход. Во-первых, bitcoind может получить новый JSON-RPC, чтобы проверить множество неизрасходованных выходов. Это означает, что некоторые C ++ взлома. Другие проекты могут принести пользу тоже. С другой стороны, Мэтты Corrallo повысила bitcoinj быть полностью проверка. Я рассматриваю и слияние своего кода в данный момент. После того, как эта работа объединена, все это может быть сделано в Java. Я думаю, что такой подход, вероятно, выше, как у вас есть достаточный контроль, чтобы избежать некоторых сложных условиях гонки. Я буду ждать, пока это реализуется в bitcoinj, особенно если код уже написан котировка Класс Бумажник должен понимать, что делать с обещаний. Я предполагаю, что бумажник может содержать как обычные действительные сделки и обязательства. Когда вы пытаетесь построить расходы, было бы собрать все предметы, которые совместно идентичную производительность и увидеть, если договор гарантии может быть завершен. Если да, то это засчитывается ваш баланс и будет использоваться для построения израсходует. Если нет, то нет. Я думаю, что TransactionConfidence может потребоваться расширение, чтобы отразить, что залог ТХ полностью недействительным. Там также должно быть различие, чтобы знать, если договор гарантии отправляет биткоен на адрес принадлежащего этого кошельком или нет. Как мне представляется, это то, что люди могут создавать контракты обеспечения на веб-сайте в течение определенного количества Bitcoins для отправки в определенный Bitcoin адрес, что они выбирают. Сервер управляет сбором взносов и создает реальную сделку, когда есть достаточно. Ни в какой момент он сможет провести любой из Bitcoins, которые я думаю, это большой плюс, как если сервер получает трещины в то никто не теряет никаких биткойны. котировка Вопрос состоит в том, что если у вас есть кошелек с регулярными фондами и некоторыми обязательствами, и вы строите расходы, что хочет ценность их всех? Вы можете объединить обязательства вместе, но вы не можете объединить этот заполненный договор вместе с другой произвольной сделкой. Я думаю, что кошелек API должен быть обновлен для поддержки создания нескольких операций в рамках расходов. Он не играет так хорошо с текущим дизайном Sad Или же вы можете просто ввести некоторые основные ограничения на данный момент, как и о том, кошельке может содержать обязательства XOR регулярных денежных средств. Это, вероятно, не является проблемой на практике. Создание более одной сделки в рамках расходов также будет слишком хорошо, когда пользователь не имеет правильные выходные значения в залог (для пользователя экземпляра имеет BTC сделок 20 и 30, но хочет в залог 25 BTC) Но я не буду беспокоиться об этом сейчас, как это на самом деле не нужны, просто хороший бонус

7 декабря 2012, 1:48:40 PM	# 15
ffcitatos Сообщений: 71 Цитировать по имени цитировать ответ	Re: Assurance контрактов Я сожалею, чтобы вторгнуться в дискуссию с чем-то не имеет отношения к вышеупомянутому реализации, но все же: вы не учитывать тот факт, что контракты обеспечения являются легко воспользоваться, чтобы сделать их использование весьма ограничено? То, что я имею в виду, что (на языке https://en.bitcoin.it/wiki/Contracts пример 3) после начала сбора средств на 1000 БТД, и, заметив, что только 100 BTC будет поднята сроком, (мошенник) предприниматель может подписать обязательство на 900 BTC / ее сами, и, следовательно, получить 100 BTC, в отличии от них монеты возвращаются жертвователям. Любые комментарии приветствуются.

7 декабря 2012, 2:43:32 PM	# 16
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: Assurance контрактов Вы можете объединить контракты обеспечения при посредничестве, если вы не доверяете предпринимателю честно выполнять условия (выходной порог подпись).

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

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

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

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

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW