No, there is a couple of important differences.

First, everything is configured and agreed upon outside of wallet software. Wallet software is used to approve or reject payment, and it only needs to show some details of this payment.

This makes a lot of difference: since it is external, it can be very flexible, i.e. UI will be tailored for a particular case. Also, wallet software can be relatively simple, it doesn't need to have a list of dispute mediators, for example.

I'll give you an example: if you buy something via bitmit, bitmit is the dispute mediator, there are no other options, there is no third party. You simply get a payment URL from bitmit, which will send your money to 2-of-2 multi-sig address. It would require 2 signatures to unblock: your and Bitmit's.

However, some independent shop can use third-party mediator, thus you'll need 2-of-3 multi-sig and UI is considerably different, now mediator needs to be agreed upon.

Another use case is instant payments. Suppose there is a company which is sort of a instant payment operator, let's call it bit-pay. User can pre-fill his bit-pay account, sending it to 2-of-2 multisig address. Now suppose he wants to pay to a merchant which trusts bit-pay. Payment can go without any delay because merchant will trust bit-pay's signature. (I.e. merchant trusts that bit-pay won't double-spend.)

The thing is that if wallet UI is not specific to dispute mediation it's possible to do everything with a single UI, so user won't need many different clients and whatnot.


I would not call it "mediated disputes", in my view it's more like user deposits money into his account within some services, but service doesn't have full access to that money.

Oracles might be good for individual bets, but a service can aggregate them.

For example, it might function as a prediction market, where you have current price and you can close your position whenever you want. That's quite a bit more advanced than personal bets.


Yeah, I think FX volatility hedges is an important use case. You can do that with icbit.se futures, but you need to deposit your bitcoins unconditionally, which is unacceptable in terms of risk.

What's about this:

1. User visit's merchant's web site (foostore.com), orders and item. He is able to select a dispute mediator from a drop-down menu (bitmediator.com) and get HTTPS URL for this specific invoice. (https://bitmediator.com/invoice?id=31337)

2. User copy-pastes this URL into his client. Client fetches data by that URL and shows information like amount, name of mediator, name of merchant etc. This information can be trusted as long as mediator is trusted, but optionally original invoice can be signed by merchant.

3. When user confirms the payment client will send money to address provided by mediator and store all relevant information into a local file for reference.

4. Client shows a list of pending payments. Client can click them to open a form which provides an option to confirm or dispute payment.

I believe this can work for a wide range of applications, including dispute mediation and betting.

Perhaps I should elaborate on betting, it can work that way for any service which requires user's deposit. For example, leveraged trading sites like Bitcoinica become much more secure this way.

IMHO that might be more important than dispute mediation since it would be an unique advantage of Bitcoin.

What's about the use case I've mentioned:

Suppose there is a betting service. When user makes a bet he sends his funds to 2-of-2 multisig address. When bet outcome is known funds are released (using user's and service's signatures), either back to user or to other side of the bet.

?

It think it's much better than betting web sites which require you to send them money directly. (So they can simply run away with that money, or claim it is hacked.)

It isn't hard to make a protocol which would let user to put in HTTPS address of such betting services, and it will do the rest (i.e. negotiate address, later negotiate release of funds).

Well, I just want to see what's available right now...

One of obvious use cases is escrow. There are many possible forms of it, but I'm sure there is some overlap.

Do you think we'll need a special client for each particular application? I'd rather see some more-or-less general protocol which will be the least common denominator in terms of user interface.

E.g. suppose there is a betting service. When user makes a bet he sends his funds into escrow. When bet outcome is known funds are released, either back to user or to other side of the bet.


I already solved similar problem in p2ptrade: two users agree on transaction and then sign their inputs.

It didn't require any identity confirmation, but I think for the start bitcoin address can be a poor man's analog of identity.

Is there already a client with an usable interface for multi-signature transactions?

I've found this: https://blockchain.info/wallet/escrow But I found no way to get there from My Wallet so I assume this functionality is currently disabled.

If there is none I'll try to implement it myself... I'm waiting this feature for 1.5 years or so, I wanted to implement a secure betting/derivative trading service...

Change in variation margin IS your gain/loss. It is just that it might be spread over multiple log lines.

E.g. suppose you bought at 20, then clearing price that day was 21, you get profit. Then you sell at 20.50, you get loss.

Simply sum this profit and loss and you'll get your overall profit over this trade. (Also, don't forget fees, they can totally ruin your profits, if price difference is smaller than ~1% you get overall loss.)

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

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

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

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

Нужен очень большой тираж ASIC

Для того, чтобы подобрать подходящий хэш нужен именно "brute force", "birthday paradox" в данном случае не работает. Для хэша длиной 160 бит нужно порядка 2^159 операций.

Это скорее всего превосходит пределы того, что вообще физически возможно на Земле. См.  https://blogs.oracle.com/bonwick/entry/128_bit_storage_are_you , http://en.wikipedia.org/wiki/Limits_to_computation

Если же поломают SHA-256, тут уже не важно по хэшу или по публичному ключу транзакция идёт: ключ подписывает хэш транзакции, злоумышленник сможет подменить адресата не меняя хэш и присвоить деньги.

Да. новый интерфейс google groups ужасен, но с ним приходится сталкиваться только для чтения архивов, а так вообще мы его используем как mailing list. Полезную инфу впоследствии предполагается перенести в wiki.


Спасибо, но я думаю мы пока перебъёмся на google groups (всё-таки хотелось бы mailing list), а дальше посмотрим...

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

Сопоставление цветным коинам какого-то "физического" смысла и поддержание ценности -- это уже задачи эмитента.

К примеру, в случае с облигациями ("бондами") эмитент гарантирует обратный выкуп по какой-то цене. Если эмитент по какой-то причине отказывается их выкупать ценность падает практически до нуля.

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


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

То есть эмитент обязуется выкупать их обратно по определённой цене в определённые интервалы времени.

Самый простой пример -- займ: эмитент продаёт свои коины-облигации по 1 BTC, через месяц начинает их скупать по 1.1 BTC. Таким образом инвесторы получают номинальный профит в BTC, а эмитент может пользоваться биткоинами в течении месяца. Если эмитент не скупает облигации по этой цене в оговоренное время, то мы наблюдаем дефолт, и инвесторы могут обратиться в суд/набить морду.

Аналогично можно выпустить облигации с номиналом 1 USD. В примеру, сейчас цена 1 BTC составляет 20 USD, соответственно я продаю облигации по 0.05 BTC. Через месяц курс уже 40 USD за BTC, и я скупаю облигации по 0.025 BTC.

Если эмитент обязуется выступать в роли market maker'а, то есть постоянно скупать/продавать такие облигации по цене близкой к рыночной, то можно сказать что это уже новая цифровая валюта, привязанная к USD.

К примеру, компания Foo может назвать свою валюту Foo-USD. Магазины могут принимать эту валюту так же, как они принимают WebMoney WMZ, разница только в том, что используется платёжная система Bitcoin со свойственной ей анонимностью, надёжностью и т.д. То есть привязка к доллару организуется в обоих случаях какой-то компанией (в одном случае Foo, в другой -- WebMoney), но в случае в Foo-USD не нужно предъявлять паспорт и больше прозрачности.

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

К примеру, таким образом можно организовать выпуск бинарных опционов, CFD, NDF, prediction market. (См. сообщения в https://groups.google.com/group/bitcoinx )

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

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

Также я считаю интересным направлением выпуск товарных ваучеров. К примеру, если я хочу продать 1000 бутылок водки, я продаю 1000 ваучеров на 1 бутылку водки каждый на распределённом рынке. Затем покупатели обращаются ко мне с этими ваучерами и я высылаю им водку.

Интересно это тем, что такая система намного надёжнее и гибче чем обычные биткоиновые выплаты на адрес: 1) возможно аутентифицировать торговца посредством цифровой подписи, что исключать атаку MitM и другие виды атак; 2) возможно покупать товар в любой "цветной" валюте через посредников.

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

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

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

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

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

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

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

Ну я бы так не сказал...

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

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

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

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

Да, нужно заметить что проблемы предполагается решать спомощью обмена. К примеру, выпустили сначала FooCoin. Потом захотелось что-то изменить, но изменить FooCoin уже нельзя.

Тогда выпускаем FooCoin.2 и предлагаем обмен 1 FooCoin -> 1 FooCoin.2. Поскольку клиент предполагает возможность обмена атомарными транзакциями, обмен можно автоматизировать, пользователям нужно только подтвердить что они желают обменять монеты старого образца на новые.

Если обмен не возможен по техническим причинам (к примеру, полностью поменялся протокол), issuer может скупить старые монеты на рынке и продать новые по тому же курсу.

Но скорее всего возможность обмена сохранится даже при смене протокола.

Для форка нужны майнеры, с этим больше всего проблем.


Да в принципе ничего делать не нужно, всё опционально...

Конечно, операции на рынке можно проводить для поддержания курса, но если нет какого-то целевого курса в этом нет необходимости.

Допольнительный выпуск, опять же, опционален.

В долгосрочной перспективе теоретически может понадобиться "дефрагментация" для того чтобы тонким клиентам было легче работать. Но пока что не совсем понятно нужно ли это на самом деле и как это организовать. Скорее всего к тому времени когда дефрагментация будет необходима появится также и возможность делать это более-менее автоматически.


Грубо говоря затраты практически нулевые... По-минимуму: скачать клиент, запустить, залить в него немного биткоинов, нажать на кнопку "выпустить", вбить название и параметры.

Дальше уже по желанию: можно продавать на рынке, либо отослать кому-нибудь...

Но нужно заметить, что сейчас технология экспериментальная. То есть нельзя исключать возможности того, что протокол изменится. (В том плане что общепринятым станет какой-то новый протокол цветных коинов, а тот что сейчас реализован забросят.)

Да. В принципе предполагается адаптировать bitcoinJS, это не так уж сложно.

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


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

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

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

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

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


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


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

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

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


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

При переводе долларов на счёт СПД договор ОБЯЗАТЕЛЕН, причём к договору есть ряд требований. Копию контракта со всеми подписями и печатями требуется предъявить в день перевода, в противном случае деньги отошлют обратно.

Так что это просто невозможно если нет только людей готовых поработать в качестве прокси.

(Самого такой вопрос интересует, хотелось бы иметь возможность получать оплату за фриланс в коинах.)

Счёт обязательно должен быть в USD, но с этим проблем нет: банк счёт может октрыть за день без вопросов. Весь гемор в договорах.

Если у кого есть желание, можем обсудить на русском.

Ключевые слова:

• выпуск частных валют/бондов/акций/ценных бумаг и т.д.
• распределённые торговые площадки
• smart property
• ripple-подобные структуры на базе bitcoin blockchain

Да, кстати, программисты на JavaScript и, возможно, Python имеют шанс заработать bounty за разработку open source реализаций цветных коинов. Сколько именно и за что не могу пока точно сказать, пока нет детального плана. Но можете написать в личку если что, обсудим. (Сразу замечу что здесь требуется способность разбираться в больших объёмах чужого кода и нетривиальных алгоритмах, так что это не для новичков.)

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

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

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