Bitcoin Forum

http://bitnovosti.com/2014/01/16/coinbase-2factor-auth/

Это они зря. Во-первых, если хотят улучшить безопасность - пусть сделают двухфакторную авторизацию по умолчанию, но так, чтобы пользователь мог ее отключить. А во-вторых - "для всех переводов в Биткойнах на сумму $100 и более" - это вообще извращение. Если они хотят продвижения Биткойна как средства платежа - пусть и суммы номинируют в биткойнах. Сделали бы 0,1 биткойн. В случае чего, всегда можно уменьшить.

Естественно, существует возможность изменить эти настройки безопасности в обе стороны — можно либо потребовать подтверждение любой биткойн-транзакции, либо совсем отменить такое подтверждение.
http://bitnovosti.files.wordpress.com/2014/01/coinbase.png?w=1050

Натолкнули на интересную идею.
А возможен ли в биткоине прием платежа, только когда он будет подтвержден ?

Например паролем, которым высылается по почте получателю.
В противном случае перевод отменяется ?

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

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

Это не совсем то. Если ключ по дороге кто-то подсмотрел, то он может все забрать себе.

Правильней так: https://bitcointalk.org/index.php?topic=282885.msg3064042#msg3064042

Суть задачи, хотя бы в том, что бы в случае отправки крипты на неверный адрес (умышленно или случайно) средства туда бы не поступили. Возврат.
Например сейчас в банках с переводами безнала дела обстоят именно так:
Если ошибка в номере счета, то тогда не совпадает наименование получателя, ну либо наоборот.

Фактически двухфакторная идентификация.
Ну и более сложные ситуации, с депонированием средств.
Петя приступает к работе если видит на счете денежку, что прислал Вася.
Петя сделал работу, Вася прислал ключ. Петя снял денежку - пошел пить пиво.
В банковской системе подобные варианты - работали.

Фактически однофакторная, а именно секретным ключом. Ну и возможность предварительно показать, что средства "в принципе" есть.

Что мешает Васе показать на любую сегодняшнюю транзакцию в blochain-е? Ну разве, что Петя поставит обязательное условие добавить какой-то свой коментарий к транзакции.

А если не прислал. Сам воспользовался ключом?
А если прислал, но по ошибке не Васе, а Коле?

Средства УЖЕ лежат у Пети, к Коле никак не попадут. К Васе - тоже не попадут. Так и будут лежать. У Пети.
Называется - задепонированные средства.

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

Не понял. Почему они у Пети? Кто первый встал - того и тапки Для "обычной" транзакции требующей одной подписи нет депонирования: у кого секретный ключ - у того и средства. Спасут только транзакции требующие несколько (в вашем примере 2-из-2) подписей.
Но в случае 2-из-2 не будет возврата, если не согласится Петя. А если у Васи есть возможность отменить платеж, то почему ему будет верить Петя? Опять нужна третья сторона - гарант.

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

Насчет Вашего вопроса: деньги УЖЕ пришли и лежат у Пети, но без одобрения Васи - он не может ими пользоваться.
В банке - вариант депонирования.
Банк выступает гарантом. Размораживает средства на счету клиента после получения подписанного обоими клиентами Акта. До этого Акта, деньги есть - а пользоваться никто не может.

Если цель только заморозить средства до соглашения, то можно воспользоваться адресом 2-из-2. Я уже писал (https://bitcointalk.org/index.php?topic=428384.msg4687552#msg4687552) о несколько похожей схеме. В нашем случае можно сделать так:
Допустим, Вася у Пети заказывает какую-нибудь серьёзную работу, и Петя хочет убедиться, что бюджет под этот заказ не будет пущен на другие цели - путём заморозки средств (доказать-то владение битками не проблема, но гарантий, что ты их завтра не переведёшь на другой адрес, обычно нет). Переводим битки на совместный адрес и генерируем отложенную транзакцию возврата всех средств на адрес заказчика Васи (которая, скажем, сработает не раньше чем через год). Это будет гарантией от невыполнения работы исполнителем и от его саботирования возврата. По мере выполнения этапов работы перевыпускаем транзакцию возврата (с более ранним временем срабатывания, чем предыдущая), которая будет иметь теперь 2 выхода - часть денег Пете за суммарный объём выполненной работы, остальное обратно Васе.
Если работа будет завершена - просто переводим всю сумму Пете без блокировки вообще.
Если она будет выполнена лишь частично - каждый из участников сможет активировать последний вариант транзакции возврата и получить свою часть. При этом Пете нужно не прозевать момент разблокировки - если время разблокировки предпоследней транзакции возврата наступит до того, как он опубликует последнюю, то Вася сможет опубликовать предпоследнюю и вернуть себе больше средств, чем было достигнуто последним соглашением. Для этого и нужно постоянное "омоложение" времени разблокировки. Но такое слежение - это уже проблема Пети.
Если время разблокировки неотвратимо приближается к текущему моменту, а договор расторгать желания нет - переводим средства хоть на тот же адрес и снова выпускаем транзакцию возврата (по последнему соглашению) с произвольным временем разблокировки. Строго говоря, так можно делать после каждого этапа, просто схема с уменьшающимся nlocktime выбрана для уменьшения количества мусора в блокчейне.
Если всё упирается лишь в согласие обеих сторон, то гарант не нужен.