Рецензируемые Сделки | Биткоин форум

Будет ли текущая система скрипта позволяет условные сделки требует подписанного сертификата от арбитра третьей стороны?
Вероятно, это не представляется возможным, по тем же причинам, которые были disscussed в этой теме http://bitcointalk.org/index.php?topic=1786.0.

Хотя, это позволило бы очень интересно использование Bitcoins ...

Скажем, (Алиса) заинтересована в каком-то фантазии пункта (позволяет сказать fancynickname @ счетов-сайта) в настоящее время предоставляются В (Боб) по С (Freenode).
Так Алиса хотела бы купить Боб счет для 1BTC, но она не хочет, чтобы послать ему монету, потому что она не доверяет ему. Он не может отказаться от своего счета, даже если он получил компенсацию.
Конечно, Боб также хочет отказаться от своего счета, прежде чем он получил компенсацию.

Теперь, скажем, FreeNode (который владеет GPG ключ) соглашается подписывать сертификаты передачи счета.
Алиса хотела бы послать Бобу 1BTC условно к вопросу такого сертификата (в течение некоторого срока ...).

И это было бы так хорошо, если такие сделки можно было бы сделать!
а также В можно торговать, не зная друг друга, и оба должны только доверять судье С.

Есть предположения?

Конечно, с точки зрения пользовательского интерфейса может быть очень простой. Алиса просто спрашивает сайт FreeNode в то, что она должна положить в "состояние" поле в ней "Bitcoin отправить" окно.

Цитата: GIM 30 апреля 2011, 09:29:45 PM

И это было бы так хорошо, если такие сделки можно было бы сделать!
может торговать с В не зная друг друга, и оба должны только доверять судье С.

ClearCoin депозитный работало достаточно хорошо для моих целей:
http://www.clearcoin.com/

Цитата: sgornick 30 апреля 2011, 10:10:31 PM

ClearCoin депозитный работало достаточно хорошо для моих целей:
http://www.clearcoin.com/

Да! ClearCoin является своим родом арбитр, и может стать доверенным сертификатом эмитентом.
Но есть также много потенциальных судей, которые отказываются обращаться сами монеты.

Satoshi создал систему сценариев транзакции именно для целей, как это.

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

http://bitcointalk.org/index.php?topic=195.msg1611#msg1611

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

Будучи в состоянии так непосредственно манипулировать валюты на программном уровне позволяет обеспечить полную реализацию обещаний умных контрактов. Обеспечение исполнения контрактов через код без насилия. Децентрализация, добровольный арбитраж. Реализованный Cryptoanarchy. Представьте, насколько легче было бы вести бизнес в таких условиях. Это не часто упоминается здесь, но Bitcoin, в дополнение к резко изменяет денежную систему, действительно может революционизировать всю систему коммерческого права.

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

Цитата: хс 30 апреля 2011, 10:29:47 PM

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

Да, было бы здорово, если бы все эти функции могут быть добавлены быстро. Как сказал Satoshi, когда новые реализации клиента Bitcoin будет вокруг, все будет быстро установить в камне. Если что-то не движется прямо сейчас, я боюсь, что система сценарий никогда не будет использоваться, и будет оставаться эмбрион.
Вот почему я хотел бы видеть какое-то движение.

Посмотрите на SMTP, он имеет столько по умолчанию, и это, кажется, ничто не может быть сделано ... никто не перешел на [лучше] почте.
Если Bitcoin когда начинают идти магистраль (это?), Кто посмеет, чтобы перейти к [лучше] монеты? Не будет ли слишком поздно?

Цитата: theymos 30 апреля 2011, 10:51:41 PM

Есть ли у Вас пример сценария? Как вы справляетесь с крайним сроком?
Какие OP_s должны быть активированы в клиенте?

К сожалению, много вопросов

Вы можете сделать это на самом деле просто с помощью сценария, как это:

Код:

[2] <Публичные EScrow в> <Публичных отправителя> <Публичных получателя> [3] OP_CHECKMULTISIG

Эскроу и одна из сторон или обе стороны, должны сотрудничать, чтобы отправить монету. Эскроу должен следить за соблюдением сроков, хотя. Я не думаю, что есть какой-нибудь способ, чтобы иметь безопасный срок в рамках сделок.

Цитата: theymos от 01 мая 2011, 12:24:32 AM

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

Это немного, где я рекламирую полезность OP_BLOCKNUMBER, несмотря на скромных осложнениях безопасного выполнение повлекло бы за собой. совсем недавно обсуждалось здесь http://bitcointalk.org/index.php?topic=6439.0

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

ByteCoin

Вы имеете в виду нажать текущее значение счетчика блока в стек? Это было бы удобно.
Какие проблемы с делать это? Я не вижу, что его уже обсуждалось.

Цитата: just_someguy от 01 мая 2011 года, 1:02:08 AM

В случае реорганизации блока цепи, в отсутствие двойной атаки расходов, все операции на короткой ветви можно ожидать, будут включены в более длинной цепи. Единственный "Деньги" что потерял это вознаграждение за нахождение блоков на короткой ветви - в coinbase сделки. Там причина, почему coinbase занимает такое долгое время, чтобы созреть, это потому, что при условии, чтобы быть исчезли в случае REORG. Мы предполагаем, что не может реорганизация; проходить на глубине 120 блоков так coinbase созревает после этого времени.
Проблема возникает с OP_BLOCKNUMBER сделок, которые участвуют в REORG, где они получают включены в блок, который изменяет функциональность скрипта из различных блоков числа. Любые операции, расходы монеты в зависимости от OP_BLOCKNUMBER сделки могут также получить аннулированные и это плохо. Таким образом, чтобы быть в безопасности там должен быть какой-то схема, которая обеспечивает столько уверенности, как это предусмотрено с coinbase созревания на 120 блоков. Я предполагаю, что coinbase созревает со скоростью 5BTC каждые 12 блоков таким образом, возможно, OP_BLOCKNUMBER сделка не должны созреть до макс (120, (value_in_bitcoins потолка / 5 * 12)) блоки прошли, чтобы обеспечить аналогичные гарантии.

Это не большое решение, как OP_BLOCKNUMBER операции трактуются по-разному к любым другим.

ByteCoin

Я бы не против OP_BLOCKNUMBER если операции с использованием его зрелости, как это.

Цитата: theymos от 01 мая 2011, 12:24:32 AM

Вы можете сделать это на самом деле просто с помощью сценария, как это:

Код:

[2] <Публичные EScrow в> <Публичных отправителя> <Публичных получателя> [3] OP_CHECKMULTISIG

Интересно! Странно, что эта собственность симметрична отправитель / получатель / эскроу.

Я думал, что арбитр должен быть оставлен в стороне от реальной сделки Bitcoin и подписать бы только "<В> дал <> его счет до <Дата>" сертификат. Но, может быть, это хороший способ справиться с проблемой крайнего срока? (Судья будет доверено правильно обрабатывать срок.)

Любой сценарий опкоды, импортирующие состояние снаружи могут быть использованы для раскошелиться блок цепи. Это не достаточно, чтобы иметь OP_BLOCKNUMBER только расходуемый после N блоков, как кто-то может написать скрипт, который действует вплоть до определенного времени, а затем становится недействительным, что позволяет произвольно Разветвляющуюся цепи даже при отсутствии в природе повторных Orgs.

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

Цитата: [микрофон] на 01 мая 2011 года, 2:35:41 PM

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

Я не совсем уверен, ваш аргумент является действительным, или, возможно, я не понимаю.
Боб поместить данные в цепи, когда он обеспечивает scriptSig (он ковкой с использованием документарного), чтобы выкупить его из-за.
Он должен сделать это до истечения срока, и Bitcoins замораживают до тех пор. Что вилка может вызвать что?

Цитата: GIM от 01 мая 2011, 03:25:56 PM

Он должен сделать это до истечения срока, и Bitcoins замораживают до тех пор. Что вилка может вызвать что?

Я имею в виду .. единственный реальный вопрос я вижу, это против временных меток проблемы цепи Reorg.

Цитата: [микрофон] на 01 мая 2011 года, 2:35:41 PM

Вы правы - это невозможно сделать безопасно. Злоумышленник может сделать что-то вроде:

Код:

OP_BLOCKNUMBER [120000] OP_LESSTHAN

Dunno о OP_BLOCKNUMBER, но если эта команда возвращает номер блока, в котором сценарий (или даже scriptSig) предназначается для включения в, я не вижу проблемы ... для цепи реорганизации, за исключением.
Конечно, она не должна возвращать номер текущего блока, как в "сегодня последний blocknumber" в случае проверяется позже.

Я хотел бы знать, если я что-то не хватает.

Блок, в котором подразумевается скрипт для включения в не могут быть известны люди проверочных сделки.

30 апреля 2011, 9:29:45 PM	# 1
гИМ Сообщений: 90 Цитировать по имени цитировать ответ	Re: реферативный сделок Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Будет ли текущая система скрипта позволяет условные сделки требует подписанного сертификата от арбитра третьей стороны? Вероятно, это не представляется возможным, по тем же причинам, которые были disscussed в этой теме http://bitcointalk.org/index.php?topic=1786.0. Хотя, это позволило бы очень интересно использование Bitcoins ... Скажем, (Алиса) заинтересована в каком-то фантазии пункта (позволяет сказать fancynickname @ счетов-сайта) в настоящее время предоставляются В (Боб) по С (Freenode). Так Алиса хотела бы купить Боб счет для 1BTC, но она не хочет, чтобы послать ему монету, потому что она не доверяет ему. Он не может отказаться от своего счета, даже если он получил компенсацию. Конечно, Боб также хочет отказаться от своего счета, прежде чем он получил компенсацию. Теперь, скажем, FreeNode (который владеет GPG ключ) соглашается подписывать сертификаты передачи счета. Алиса хотела бы послать Бобу 1BTC условно к вопросу такого сертификата (в течение некоторого срока ...). И это было бы так хорошо, если такие сделки можно было бы сделать! а также В можно торговать, не зная друг друга, и оба должны только доверять судье С. Есть предположения?

30 апреля 2011, 9:44:04 PM	# 2
гИМ Сообщений: 90 Цитировать по имени цитировать ответ	Re: реферативный сделок Получил 1806 Биткоинов Реальная история. Конечно, с точки зрения пользовательского интерфейса может быть очень простой. Алиса просто спрашивает сайт FreeNode в то, что она должна положить в "состояние" поле в ней "Bitcoin отправить" окно.

30 апреля 2011, 10:10:31 PM	# 3
Стивен Gornick Сообщения: 2352 Цитировать по имени цитировать ответ	Re: реферативный сделок Цитата: GIM 30 апреля 2011, 09:29:45 PM И это было бы так хорошо, если такие сделки можно было бы сделать! может торговать с В не зная друг друга, и оба должны только доверять судье С. ClearCoin депозитный работало достаточно хорошо для моих целей: http://www.clearcoin.com/

30 апреля 2011, 10:25:02 PM	# 4
гИМ Сообщений: 90 Цитировать по имени цитировать ответ	Re: реферативный сделок Цитата: sgornick 30 апреля 2011, 10:10:31 PM ClearCoin депозитный работало достаточно хорошо для моих целей: http://www.clearcoin.com/ Да! ClearCoin является своим родом арбитр, и может стать доверенным сертификатом эмитентом. Но есть также много потенциальных судей, которые отказываются обращаться сами монеты.

30 апреля 2011, 10:29:47 PM	# 5
хс Сообщений: 40 Цитировать по имени цитировать ответ	Re: реферативный сделок Satoshi создал систему сценариев транзакции именно для целей, как это. "Конструкция поддерживает огромное разнообразие возможных типов транзакций, которые я разработал года назад. Escrow сделки, скрепленные договора, арбитражную третья сторона, многопартийная подписи и т.д. Если Bitcoin улавливает в большом пути, это вещи, которые мы хотим исследовать в будущем, но все они должны были быть разработаны в начале до убедитесь, что они будут возможно позже." -Satoshi http://bitcointalk.org/index.php?topic=195.msg1611#msg1611 Он сказал, что он работал над ней два сторонних escrows, но теперь, когда он ушел это может быть что-то для нынешних разработчиков, чтобы рассмотреть приоритеты. Будучи в состоянии так непосредственно манипулировать валюты на программном уровне позволяет обеспечить полную реализацию обещаний умных контрактов. Обеспечение исполнения контрактов через код без насилия. Децентрализация, добровольный арбитраж. Реализованный Cryptoanarchy. Представьте, насколько легче было бы вести бизнес в таких условиях. Это не часто упоминается здесь, но Bitcoin, в дополнение к резко изменяет денежную систему, действительно может революционизировать всю систему коммерческого права.

30 апреля 2011, 10:51:41 PM	# 6
theymos Сообщения: 2870 Цитировать по имени цитировать ответ	Re: реферативный сделок Это возможно, хотя я думаю, что вам нужно некоторое из внеполосных системы, чтобы получить эскроу агента подписать вашу сделку.

30 апреля 2011, 11:28:24 PM	# 7
гИМ Сообщений: 90 Цитировать по имени цитировать ответ	Re: реферативный сделок Цитата: хс 30 апреля 2011, 10:29:47 PM Он сказал, что он работал над ней два сторонних escrows, но теперь, когда он ушел это может быть что-то для нынешних разработчиков, чтобы рассмотреть приоритеты. Да, было бы здорово, если бы все эти функции могут быть добавлены быстро. Как сказал Satoshi, когда новые реализации клиента Bitcoin будет вокруг, все будет быстро установить в камне. Если что-то не движется прямо сейчас, я боюсь, что система сценарий никогда не будет использоваться, и будет оставаться эмбрион. Вот почему я хотел бы видеть какое-то движение. Посмотрите на SMTP, он имеет столько по умолчанию, и это, кажется, ничто не может быть сделано ... никто не перешел на [лучше] почте. Если Bitcoin когда начинают идти магистраль (это?), Кто посмеет, чтобы перейти к [лучше] монеты? Не будет ли слишком поздно?

30 апреля 2011, 11:30:50 PM	# 8
гИМ Сообщений: 90 Цитировать по имени цитировать ответ	Re: реферативный сделок Цитата: theymos 30 апреля 2011, 10:51:41 PM Это возможно, хотя я думаю, что вам нужно некоторое из внеполосных системы, чтобы получить эскроу агента подписать вашу сделку. Есть ли у Вас пример сценария? Как вы справляетесь с крайним сроком? Какие OP_s должны быть активированы в клиенте? К сожалению, много вопросов

1 мая 2011, 12:24:32 AM	# 9
theymos Сообщения: 2870 Цитировать по имени цитировать ответ	Re: реферативный сделок Вы можете сделать это на самом деле просто с помощью сценария, как это: Код: [2] <Публичные EScrow в> <Публичных отправителя> <Публичных получателя> [3] OP_CHECKMULTISIG Эскроу и одна из сторон или обе стороны, должны сотрудничать, чтобы отправить монету. Эскроу должен следить за соблюдением сроков, хотя. Я не думаю, что есть какой-нибудь способ, чтобы иметь безопасный срок в рамках сделок.

1 мая 2011, 12:43:11 AM	# 10
ByteCoin Сообщения: 416 Цитировать по имени цитировать ответ	Re: реферативный сделок Цитата: theymos от 01 мая 2011, 12:24:32 AM Я не думаю, что есть какой-нибудь способ, чтобы иметь безопасный срок в рамках сделок. Это немного, где я рекламирую полезность OP_BLOCKNUMBER, несмотря на скромных осложнениях безопасного выполнение повлекло бы за собой. совсем недавно обсуждалось здесь http://bitcointalk.org/index.php?topic=6439.0 Многое, как я думаю, что скриптовый лучший бит работы Satoshi, я буду Сомнительно, что когда-нибудь будет возрожден. Тот факт, что Bitcoin является более ценным с помощью сценариев отключенных означает, что сценарии не является существенными. Включение сценариев, хотя я большой поклонник, нарушило бы правило о том, что успешный продукт должен сделать одну вещь хорошо. ByteCoin

1 мая 2011, 1:02:08 AM	# 11
just_someguy Сообщения: 125 Цитировать по имени цитировать ответ	Re: реферативный сделок Вы имеете в виду нажать текущее значение счетчика блока в стек? Это было бы удобно. Какие проблемы с делать это? Я не вижу, что его уже обсуждалось.

1 мая 2011, 1:27:28 AM	# 12
ByteCoin Сообщения: 416 Цитировать по имени цитировать ответ	Re: реферативный сделок Цитата: just_someguy от 01 мая 2011 года, 1:02:08 AM Вы имеете в виду нажать текущее значение счетчика блока в стек? Это было бы удобно. Какие проблемы с делать это? Я не вижу, что его уже обсуждалось. В случае реорганизации блока цепи, в отсутствие двойной атаки расходов, все операции на короткой ветви можно ожидать, будут включены в более длинной цепи. Единственный "Деньги" что потерял это вознаграждение за нахождение блоков на короткой ветви - в coinbase сделки. Там причина, почему coinbase занимает такое долгое время, чтобы созреть, это потому, что при условии, чтобы быть исчезли в случае REORG. Мы предполагаем, что не может реорганизация; проходить на глубине 120 блоков так coinbase созревает после этого времени. Проблема возникает с OP_BLOCKNUMBER сделок, которые участвуют в REORG, где они получают включены в блок, который изменяет функциональность скрипта из различных блоков числа. Любые операции, расходы монеты в зависимости от OP_BLOCKNUMBER сделки могут также получить аннулированные и это плохо. Таким образом, чтобы быть в безопасности там должен быть какой-то схема, которая обеспечивает столько уверенности, как это предусмотрено с coinbase созревания на 120 блоков. Я предполагаю, что coinbase созревает со скоростью 5BTC каждые 12 блоков таким образом, возможно, OP_BLOCKNUMBER сделка не должны созреть до макс (120, (value_in_bitcoins потолка / 5 * 12)) блоки прошли, чтобы обеспечить аналогичные гарантии. Это не большое решение, как OP_BLOCKNUMBER операции трактуются по-разному к любым другим. ByteCoin

1 мая 2011, 1:35:38 AM	# 13
theymos Сообщения: 2870 Цитировать по имени цитировать ответ	Re: реферативный сделок Я бы не против OP_BLOCKNUMBER если операции с использованием его зрелости, как это.

1 мая 2011, 1:35:02 PM	# 14
гИМ Сообщений: 90 Цитировать по имени цитировать ответ	Re: реферативный сделок Цитата: theymos от 01 мая 2011, 12:24:32 AM Вы можете сделать это на самом деле просто с помощью сценария, как это: Код: [2] <Публичные EScrow в> <Публичных отправителя> <Публичных получателя> [3] OP_CHECKMULTISIG Эскроу и одна из сторон или обе стороны, должны сотрудничать, чтобы отправить монету. Эскроу должен следить за соблюдением сроков, хотя. Я не думаю, что есть какой-нибудь способ, чтобы иметь безопасный срок в рамках сделок. Интересно! Странно, что эта собственность симметрична отправитель / получатель / эскроу. Я думал, что арбитр должен быть оставлен в стороне от реальной сделки Bitcoin и подписать бы только "<В> дал <> его счет до <Дата>" сертификат. Но, может быть, это хороший способ справиться с проблемой крайнего срока? (Судья будет доверено правильно обрабатывать срок.)

1 мая 2011, 2:35:41 PM	# 15
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: реферативный сделок Любой сценарий опкоды, импортирующие состояние снаружи могут быть использованы для раскошелиться блок цепи. Это не достаточно, чтобы иметь OP_BLOCKNUMBER только расходуемый после N блоков, как кто-то может написать скрипт, который действует вплоть до определенного времени, а затем становится недействительным, что позволяет произвольно Разветвляющуюся цепи даже при отсутствии в природе повторных Orgs. Сделки, "зрелый" по истечении определенного времени возможны nLockTime, хотя и без замены это не то, что полезно. Кроме сценарии не отключаются. Вы просто должны получить новый сценарий в белый список, а затем убедить некоторые шахтер обновить. Все клиенты будут понимать, что новый тип сценария впоследствии.

1 мая 2011, 3:25:56 PM	# 16
гИМ Сообщений: 90 Цитировать по имени цитировать ответ	Re: реферативный сделок Цитата: [микрофон] на 01 мая 2011 года, 2:35:41 PM Любой сценарий опкоды, импортирующие состояние снаружи могут быть использованы для раскошелиться блок цепи. Я не совсем уверен, ваш аргумент является действительным, или, возможно, я не понимаю. Боб поместить данные в цепи, когда он обеспечивает scriptSig (он ковкой с использованием документарного), чтобы выкупить его из-за. Он должен сделать это до истечения срока, и Bitcoins замораживают до тех пор. Что вилка может вызвать что?

1 мая 2011, 3:36:32 PM	# 17
гИМ Сообщений: 90 Цитировать по имени цитировать ответ	Re: реферативный сделок Цитата: GIM от 01 мая 2011, 03:25:56 PM Он должен сделать это до истечения срока, и Bitcoins замораживают до тех пор. Что вилка может вызвать что? Я имею в виду .. единственный реальный вопрос я вижу, это против временных меток проблемы цепи Reorg.

1 мая 2011, 8:04:51 PM	# 18
theymos Сообщения: 2870 Цитировать по имени цитировать ответ	Re: реферативный сделок Цитата: [микрофон] на 01 мая 2011 года, 2:35:41 PM Любой сценарий опкоды, импортирующие состояние снаружи могут быть использованы для раскошелиться блок цепи. Это не достаточно, чтобы иметь OP_BLOCKNUMBER только расходуемый после N блоков, как кто-то может написать скрипт, который действует вплоть до определенного времени, а затем становится недействительным, что позволяет произвольно Разветвляющуюся цепи даже при отсутствии в природе повторных Orgs. Вы правы - это невозможно сделать безопасно. Злоумышленник может сделать что-то вроде: Код: OP_BLOCKNUMBER [120000] OP_LESSTHAN

1 мая 2011, 9:22:17 PM	# 19
гИМ Сообщений: 90 Цитировать по имени цитировать ответ	Re: реферативный сделок Dunno о OP_BLOCKNUMBER, но если эта команда возвращает номер блока, в котором сценарий (или даже scriptSig) предназначается для включения в, я не вижу проблемы ... для цепи реорганизации, за исключением. Конечно, она не должна возвращать номер текущего блока, как в "сегодня последний blocknumber" в случае проверяется позже. Я хотел бы знать, если я что-то не хватает.

1 мая 2011, 9:35:16 PM	# 20
theymos Сообщения: 2870 Цитировать по имени цитировать ответ	Re: реферативный сделок Блок, в котором подразумевается скрипт для включения в не могут быть известны люди проверочных сделки.

Заголовок