Автоматический Escrow сервис

[Alex12]

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

 

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

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

 

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

 

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

 

Как считаете, будет ли интерес пользоваться таким сервисом?  

[br0nevik]

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

 

Технически это проще сделать через закрытые ключи. Скажем, покупатель генерирует пару ключей и переводит на неё требуемую сумму. После этого предоставляет файл кошелька третьей стороне. Продавец убеждается, что ключи у Эскроу, что на них действительно есть оговоренные деньги, и переводит свой товар.

Вроде бы просто, но так как это ещё никто не сделал, наверно есть технические засады.

[Alex12]

После этого предоставляет файл кошелька третьей стороне

У покупателя остается копия кошелька и при получении товара он снимает деньги сам. Продавец не защищен. Третья сторона будет дискредитирована.

[br0nevik]

У покупателя остается копия кошелька и при получении товара он снимает деньги сам. Продавец не защищен. Третья сторона будет дискредитирована.

Вот не уверен насчет этого, надо у более грамотных людей поспрашивать. Потому что если это действительно так, то у такой штуки как VanityGen Pool никакого смысла нет. А он существует.

[Alex12]

Другой вариант. Перевести деньги покупателя на счет Эскроу-сервиса и распоряжаться им единолично. Можно перечислить продавцу. А можно и смыться.

 

 

Технически это проще сделать через закрытые ключи.

 

Здесь тоже будет использоваться обмен ключами. Только открытыми. Имея такие ключи нельзя снять деньги. Только положить.

[Alex Mizrahi]

Да, это хорошая идея, я думаю давно уже назрела необходимость.

 

Я собственно тоже планировал делать что-то с multi-signature/escrow, возможно имеет смысл объединть усилия.

 

Я занимался вот такой штукой:  https://bitcointalk.org/index.php?topic=106373.0

 

Multi-signature там никак не используется, но p2p биржа работает через обмен фрагментами транзакций и поэтапное подписывание, так что есть что-то общее.

[polym0rph]

Потому что если это действительно так, то у такой штуки как VanityGen Pool никакого смысла нет. А он существует.

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

 

@Alex Mizrahi,

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

[Alex12]

Спасибо, Alex Mizrahi и polym0rph. 

 

Тогда давайте обсудим интерфейс.

Сервис будет поддерживать запросы HTTP GET https://54.235.114.198/help и SOAP https://54.235.114.198/wsdl. 

Пока пользоваться сервисом не рекомендую. Хотя некоторые функции точно работают https://54.235.114.198/settings.

 

Алгоритм работы следующий.

1. В первый раз, отправитель и получатель обмениваются открытыми ключами по своим каналам. Получают открытый ключ сервиса https://54.235.114.198/settings и создают multisig адрес командой 

 

addmultisigaddress 2 [<публичный ключ отправителя>, <публичный ключ сервиса>, <публичный ключ получателя>]

Адрес можно использовать многократно.

 

2. Отправитель переводит на адрес средства с учетом комиссии за будущую расходную транзакцию и одновременно комиссию сервису(если будет). Hash приходной транзакции передает по своим каналам получателю.

 

3. Отправитель и получатель после получения достаточного количества подтверждений приходной транзакции регистрируют на сервисе свои версии расходных транзакций https://54.235.114.198/save. Таким образом создается контракт с сервисом. Отправитель должен сделать это первым. В расходной транзакции необходимо указать время блокировки. В дальнейшем оно меняться не будет. Каждая версия транзакции должна содержать соответствующую подпись отправителя или получателя. Hex код расходной транзакции также должен быть подписан командой 

 

signmessage <адрес> <hex код расходной транзакции>

4. Таким же способом можно вносить изменения в свою версию расходной транзакции.

 

5. Получить информацию о зарегистрированной версии расходной транзакции партнера можно запросом https://54.235.114.198/get. При этом нужно указывать свою версию расходной транзакции и её подпись (как имя пользователя и пароль).

 

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

 

7. Если одна из сторон согласна с версией партнера и хочет разблокировать контракт нужно вызвать https://54.235.114.198/clear. При нахождении нового блока, единственная версия расходной транзакции подписывается и публикуется (конечно, если время блокировки истекло)

 

8. Контракт будет заблокирован, если приходная транзакция окажется истраченной. Это проверяется каждый раз при нахождении нового блока и при обработке запроса.

Edited 6 Feb 2013, 10:04 by Alex12

[Alex12]

Сервис полностью развернут по указанному выше адресу.

Во вложении находится описание способа взаимодействия с escrow-сервисом по протоколу HTTP GET, если у пользователя есть только браузер и bitcoin-qt. Этот способ больше годится для тестирования или на всякий аварийный случай.

http get.rtf

Edited 11 Feb 2013, 05:51 by Alex12

[Alex12]

Выкладываю программу EscrowClient, её описание и исходники на C#. Программа демонстрирует возможность взаимодействия с Escrow-сервисом по протоколу SOAP.

 

Буду рад предложениям и замечаниям.

EscrowClient.src.rar

EscrowClient.rar

EscrowClient.rtf

[polym0rph]

@Alex12,

Интересно, пытаюсь привязать к реальной жизни. Но пока мне не все понятно.

Пример:

 

Дано: Сервис - Гарант, Покупатель с деньгами, Продавец с товаром

Вопрос: как может Сервис помочь в следующей ситуации:

 

1. Покупатель и Продавец  обменялись открытыми ключами, получили открытый ключ Сервиса, сгенерировали multisig адрес.

2. Покупатель отправляет на этот адрес средства, Продавец это видит и отправляет товар.

3. Покупатель получает товар, но утверждает, что не получил, и требует возврат средств от Сервиса и Продавца.

[Alex12]

polym0rph, on 16 Feb 2013 - 19:21, said:

@Alex12,

Интересно, пытаюсь привязать к реальной жизни. Но пока мне не все понятно.

Пример:

 

Дано: Сервис - Гарант, Покупатель с деньгами, Продавец с товаром

Вопрос: как может Сервис помочь в следующей ситуации:

 

1. Покупатель и Продавец  обменялись открытыми ключами, получили открытый ключ Сервиса, сгенерировали multisig адрес.

2. Покупатель отправляет на этот адрес средства, Продавец это видит и отправляет товар.

3. Покупатель получает товар, но утверждает, что не получил, и требует возврат средств от Сервиса и Продавца.

 

 

 

Повторюсь. Урегулированием спора, если возникло противоречие, партнеры занимаются самостоятельно.

 

Сервис по сути устраняет только риск получения продавцом средств в случае ненадлежащего исполнения контракта. Использование механизма multisig устраняет риск присвоения оператором сервиса этих средств себе. Все остальные риски остаются.

[polym0rph]

@Alex12, Ок, а можно привести несколько сценариев, где такой сервис был бы полезен реальным пользователям пользователям в реальных задачах?

[Alex12]

polym0rph, on 17 Feb 2013 - 19:44, said:

 

@Alex12, Ок, а можно привести несколько сценариев, где такой сервис был бы полезен реальным пользователям пользователям в реальных задачах?

 

Сервис рассчитан на использование в схеме:

Заказчик(Покупатель) - Исполнитель(Продавец); 

Заказчик(Руководитель) - Эксперт(Клиент) - несколько исполнителей без права подписи(Работники).

Есть задумка реализовать схему:

Заказчик - несколько экспертов - несколько исполнителей без права подписи.

 

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