Мульти-сиг транзакции

[suppp]

Интересно почему до сих пор не запустили мульти-сиг транзакции? Эта фича обсуждалась год назад или больше

[1714022346]

1714022346

[1714022346]

1714022346

[1714022346]

1714022346

[Balthazar]

Как не запустили?

[killerstorm]

Интересно почему до сих пор не запустили мульти-сиг транзакции? Эта фича обсуждалась год назад или больше

Насколько я понимаю, проблема только в том чтобы сделать нормальный user interface.

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

А так, ну скажем интерфейс и какой-то протокол можно прикрутить за пару дней, а толку, если никто пользоваться не будет?

[naima53]

Интересно почему до сих пор не запустили мульти-сиг транзакции? Эта фича обсуждалась год назад или больше

Насколько я понимаю, проблема только в том чтобы сделать нормальный user interface.

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

А так, ну скажем интерфейс и какой-то протокол можно прикрутить за пару дней, а толку, если никто пользоваться не будет?

Гуру, подскажите, вот мне о-очень надо что бы у меня так работало: (из трех человек)
Пусть Я=нащальника, Вася=строитель, Алиса=клиент. Строитель (Вася) делает ремонт у Алисы.

1. Я перевожу Васе, он видит что деньги у него, но заморожены, пока Алиса не подтвердит
2. Алиса видит в своем клиенте мой перевод Васе, когда Вася, например, закончит ремонт у Алисы, Алиса одобряет мой перевод Васе за работу, и Вася может уже пользоваться этими монетами.
3. Если Вася нах...вертил там у Алисы и она никогда не одобрит мой перевод Васе - то по истечении заданного мной срока, деньги должны вернуться МНЕ обратно.

Все 3 клиента должны иметь граф. оболочку и быть одинаковыми + иметь возможность отправлять "обычные" транзакции, совместимые с "обычным" клиетном Сатоши.  (можно даже голову не ломать: пусть выглядит как кнопка "одобрить перевод c 1guygu5hog5lkkvhj2vkfdDRttrry6 на 1fhchghjkllhhjgyoiKJGdgfghgfdhGF87)

Куда мне смотреть? Сколько может стоить такая доработка? Я бы рад тему создать в анг. ветке, да меня помидорами закидают за googletranslatorish  

Спасибо.

[killerstorm]

1. Я перевожу Васе, он видит что деньги у него, но заморожены, пока Алиса не подтвердит
2. Алиса видит в своем клиенте мой перевод Васе, когда Вася, например, закончит ремонт у Алисы, Алиса одобряет мой перевод Васе за работу, и Вася может уже пользоваться этими монетами.

Это обычный 2-of-2 multisig.

3. Если Вася нах...вертил там у Алисы и она никогда не одобрит мой перевод Васе - то по истечении заданного мной срока, деньги должны вернуться МНЕ обратно.

Вот с этой частью проблема, логика которая позволяет нормально организовать возврат денег отключена "на всякий случай".

Вообще предполагается делать это спомощью nLockTime: перед тем как подписать транзакцию, отправляющую деньги в 2-of-2 multisig, подписывается транзакция которая возвращает деньги "начальнику". Но он не может ей воспользоваться из-за nLockTime.

Проблема состоит в том, что если "начальник" передаст транзакцию в сеть, то он заблокирует платёж Васе т.к. будет висать в mempool. Логика которая позволила бы заменить транзакцию "начальнику" на транзакцию "Васе" отключена.

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

Эту проблему мог бы решить майнер который пропустит платёж Васе, ему это выгодно =)

Все 3 клиента должны иметь граф. оболочку и быть одинаковыми + иметь возможность отправлять "обычные" транзакции, совместимые с "обычным" клиетном Сатоши.  (можно даже голову не ломать: пусть выглядит как кнопка "одобрить перевод c 1guygu5hog5lkkvhj2vkfdDRttrry6 на 1fhchghjkllhhjgyoiKJGdgfghgfdhGF87)

Мне лично удобнее всего работать с Armory. Пользователям, наверное, не очень, т.к. он кушает много памяти.

Куда мне смотреть? Сколько может стоить такая доработка?

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

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

Но я думаю есть возможность как-то организоваться и скинуться т.к. многим бы такая функциональность не помешала бы.

Я бы рад тему создать в анг. ветке, да меня помидорами закидают за googletranslatorish  

ОК, я попробую поднять эту тему... Мне самому оно бы могло пригодиться.

[naima53]

1. Я перевожу Васе, он видит что деньги у него, но заморожены, пока Алиса не подтвердит
2. Алиса видит в своем клиенте мой перевод Васе, когда Вася, например, закончит ремонт у Алисы, Алиса одобряет мой перевод Васе за работу, и Вася может уже пользоваться этими монетами.

Это обычный 2-of-2 multisig.

3. Если Вася нах...вертил там у Алисы и она никогда не одобрит мой перевод Васе - то по истечении заданного мной срока, деньги должны вернуться МНЕ обратно.

Вот с этой частью проблема, логика которая позволяет нормально организовать возврат денег отключена "на всякий случай".

Вообще предполагается делать это спомощью nLockTime: перед тем как подписать транзакцию, отправляющую деньги в 2-of-2 multisig, подписывается транзакция которая возвращает деньги "начальнику". Но он не может ей воспользоваться из-за nLockTime.

Проблема состоит в том, что если "начальник" передаст транзакцию в сеть, то он заблокирует платёж Васе т.к. будет висать в mempool. Логика которая позволила бы заменить транзакцию "начальнику" на транзакцию "Васе" отключена.

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

Эту проблему мог бы решить майнер который пропустит платёж Васе, ему это выгодно =)

Все 3 клиента должны иметь граф. оболочку и быть одинаковыми + иметь возможность отправлять "обычные" транзакции, совместимые с "обычным" клиетном Сатоши.  (можно даже голову не ломать: пусть выглядит как кнопка "одобрить перевод c 1guygu5hog5lkkvhj2vkfdDRttrry6 на 1fhchghjkllhhjgyoiKJGdgfghgfdhGF87)

Мне лично удобнее всего работать с Armory. Пользователям, наверное, не очень, т.к. он кушает много памяти.

Куда мне смотреть? Сколько может стоить такая доработка?

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

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

Но я думаю есть возможность как-то организоваться и скинуться т.к. многим бы такая функциональность не помешала бы.

Я бы рад тему создать в анг. ветке, да меня помидорами закидают за googletranslatorish  

ОК, я попробую поднять эту тему... Мне самому оно бы могло пригодиться.

Спасибо! Тот случай, когда Алиса не одобрит платеж Васе (т.к. тот на..вертил) и не одобрит возврат мне (т.к. Алиса разгневалась "на всю контору") довольно редок, на данном этапе этим можно пренебречь. Я правильно понимаю, что описанное мной реализуемо, если Алиса подпишет транзакцию так, что деньги я получу обратно? (разумеется, после согласования меня и алисы)

[killerstorm]

Я правильно понимаю, что описанное мной реализуемо, если Алиса подпишет транзакцию так, что деньги я получу обратно? (разумеется, после согласования меня и алисы)

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

Насчёт сложностей реализации, они не столько в создании кнопки, сколько в коммуникации между клиентами, т.к. нужна передача неполных биткоин транзакций.

Можно, конечно, их посылать копи-пейстом, в файликах или ещё как. Но это гемор для пользователей.

Можно использовать какую-то среду обмена сообщений. К примеру, в ArmoryX p2ptrade мы использовали что-то вроде веб чата. Кто-то запускает HTTP сервер обмена сообщений, к нему подсоединяются участники и торгуют. Это не совсем хорошо с точки зрения отсутствия децентрализации, но поскольку сервер может запустить кто угодно какая-то децентрализация всё-таки есть.

Наконец, можно использовать какой-то p2p способ коммуникации, но это существенно сложнее.

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

[viv]

Созвучная тема https://forum.btcsec.com/index.php?/topic/791-avtomaticheskii-escrow-servis/

[Yurock]

Немного обобщаю задачу.

Есть плательщик S, арбитр A и множество адресов получателей R. S предоставляет деньги, A решает, на какой адрес из R они отправляются. S теряет контроль над деньгами. A не может отправить деньги на адрес не из R без согласия S. Есть возможность продемонстрировать факт условного депонирования заинтересованным сторонам.

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

Применительно к задаче Наймы.
S – начальник.
A – заказчик.
Испольнитель – заинтересованная сторона.
В R входят 2 адреса: адрес начальника и адрес исполнителя.

Наиболее реальным на сегодня вариантом реализации я считаю веб-сервис. Сайт будет автоматизировать создание контрактов, давать инструкции участникам, отображать информацию о ходе операции. У участников будет вся информация, необходимая для завершения операции, а сервису не будут известны необходимые секретные ключи. Если сайт сломается, можно будет загрузить инфу на другой совместимый сайт и продолжить сделку. У отправителя будет возможность всё проверить перед тем, как отправлять биткоины на специальный адрес. Другие участники тоже могут всё проверить при желании. А при отсутствии желания или возможности, любой из участников может доверить работу сервису.

[killerstorm]

Созвучная тема https://forum.btcsec.com/index.php?/topic/791-avtomaticheskii-escrow-servis/

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

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

[killerstorm]

В blockchain.info My Wallet оно как бы есть в теории: https://blockchain.info/wallet/escrow

Но на практике нигде не вижу. Видимо, отключили.

[killerstorm]

https://bitcointalk.org/index.php?topic=141536.0

В общем, пишут что сам по себе multi-signature это не фича которую пользователи могли бы использовать напрямую.

Так что развивать это планируют после стандартизации нового платёжного протокола и т.д.