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

Запас слов

Asset: сообщение с суммой, переведенной из одного открытого ключа (PUK) к другому.

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

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

Сценарий: язык сценариев похож на Bitcoin-х годов. Не Тьюринг-полной, чтобы избежать зацикливания на поверок.

----------
Роли

Minter: его подпись это необходимо для создания новых активов. Он отвечает за "поддержка" из этих активов.  

Accounter: A чеканщик доверие его к подписанию движения своих выпущенных активов. Он отвечает за предотвращение двойных расходов. Он должен быть всегда онлайн. Чеканщик может также выступать в качестве своего собственного Accounter.

TimeStamper: Актеры транзакции доверия одного из них или минимального количества их из списка, чтобы обеспечить атомарность для сделок, в которых перемещаются несколько активов. Они не являются обязательными, но предотвратить DoS-атаки. Они эквивалентны реестры в децентрализованный проект пульсации протокола.
  
Authenticator: Предоставляет цифровые сертификаты и юридическую базу для активов, связывая определенный открытый ключ правового договора. Здесь необходимо указать, если актив является вексель, облигация, акции акций, есть процентная ставка и т.д. Они не являются обязательными, и протокол все еще может быть использован в неофициальном порядке.

Рынок: получает и хранит обещания. Это опрашивается другими субъектами и рынками. Его природа в основном общественности. Для переходных операций (например, пульсация-х), его поиск путей.

Клиент: Реальные пользователи торгующих активов.

Доказательство работы цепи: а Bitcoin-подобная система. Деяния одновременно как Минтер, Accounter и TimeStamper для некоторых активов.
Цепь, где каждый может быть MINTER может быть создана тоже.

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

Случаи использования:

-Торговые активы непосредственно для Bitcoins, используя цепочку как TimeStamper. Примеры:
-Торговые активы мгновенно с сервером отметок времени.
-Децентрализованные Ripple
-Переходные операции (у меня есть NMC, и вы принимаете BTC. Продаю NMC для mtgoxUSD, mtgoxUSD БТД, и я заплачу вам все в одной транзакции)
-Круговые сделки (как выше, но я получаю еще один актив от вас вместо квитанции).

EDIT: Я должен переписать следующий дизайн: это недостатки.
-----------
Сообщения (буферы протокола)

сообщение BlockChain {
   требуется строка Nombre = 1;
   необходимые байты genesis_block_hash = 2;
   дополнительный int32 checkpoint_block_number = 3;
   дополнительный байт checkpoint_block_hash = 4;
}

Обозначает доказательство работы цепи, как Bitcoin или namecoin.

сообщение Minter {
   опционально PublicKey / хэш? Minter = 1;
   дополнительный BlockChain block_chain = 1;
}

Minter может быть либо блок-цепь или обычный узел.

сообщение Asset {
   по желанию Минтер Minter = 1;
   опционально PublicKey / хэш? Accounter = 2;
   требуется двойное количество = 3;
   опционально PublicKey / хэш? Приемник = 4;
   опционально PublicKey / хэш? отправитель = 5;
}

Для актива, чтобы быть действительным, он также нуждается в доказательстве, содержащее по меньшей мере, сигнатуры в Accounter и отправитель.
Если Accounter или отправитель не указан, чеканщик берет свои обязанности и должен подписать для них. Если не говорит, что актив они будут определены позже (задает переменную, а не фактического открытого ключа).
Не все участники сделки знают каждый актив, только те, которые имеют отношение к ним.

сообщение Сценарий {
   повторные байт assets_hashes = 1;
   повторяется строка? байт? Команды = 2;
}

Сообщение всего сценария является то, что OP_CHECKSIG в сценарии должен подписать. Второе поле содержит фактические команды сценария.

сообщение Proof {
   необходимый скрипт Script = 1;
   повторяющиеся байты signatures_hashes_secrets = 2;
}

Второе поле содержит подписи, хэш и секреты, и т.д. Все, что нужно для сценария возвращает истину.

Сообщение Транзакция {
   повторные Proof доказательства = 1;
}

Для того, чтобы быть действительным, все доказательства должны быть действительными. Timestampers не нужно читать активы, они просто должны подписать сценарии.
Язык сценариев должен иметь операцию OP_CHECKTIMESTAMP с двумя параметрами, подписи и истечения времени.
Так как доказательство работы цепей могут выступать в качестве timestampers, подобная операция необходима для них. В истекает выражаются в виде числа блоков и цепи должны быть идентифицированы. Хэш блока генеза или что и хэш данной контрольной точки блока должно быть достаточно.
Если цепь обозначается как TimeStamper, должно быть активом без чеканщика пострадавших от метки времени и транзакции, соответствующей этому актив должен появиться в цепочке.

------------
Случаи использования:

A) Торговые активы непосредственно для Bitcoins, используя цепочку как TimeStamper. Примеры:

чеканщик и Accounter: mtgoxUSD
Рынок: что-то в этом роде обмена Темного или просто обычный сервер

Ставит обещание (незавершенная транзакция), содержащее следующий (10 для 60 BTC mtgoxUSD):

asset1 = {Minter = mtgoxUSD_PuK, сумма = 60, отправитель = A1_PuK, приемник = $ asset1.receiver}
asset2 = {Minter = Bitcoin, сумма = 10, отправитель = $ asset1.receiver, приемник = A2_PuK}

script1 = {
   assets_hashes = {хэш (asset1), хэш (asset2)},
   Команды = {OP_CHECKSIG A1_PuK, OP_CHECKSIG $ asset1.receiver, OP_CHECKSIG mtgoxUSD_PuK, OP_CHECKTIMESTAMP Биткойн 170000}
}

proof1 = {
   Сценарий = script1,
   signatures_hashes_secrets = {A_PuK1_signature}
}

Transaction1 = {
   Доказательства = {proof1}
}

B видит сделку на рынке и хочет 60 mtgoxUSD

Он заполняет $ asset1.receiver = B1_PuK. Подписывает сделку и посылает это mtgox подписать.
Когда он получает его обратно, он строит сделку Bitcoin с исходным = B1_PuK, назначения = A2_PuK и трансляции его.
Когда транзакция подтверждается в Bitcoin цепи Transaction1 становится действительным.

Этот пример также может быть применен к облигации, акции, акции или другие активы вместо mtgoxUSD.

----
B) Торговые активы мгновенно с сервером отметок времени.

minters и accounters: mtgoxUSD, tradehillBTC
Рынок: что-то в этом роде обмена Темного или просто обычный сервер

asset1 = {Minter = mtgoxUSD_PuK, сумма = 60, отправитель = A1_PuK, приемник = $ asset1.receiver}
asset2 = {Minter = tradehillBTC_PuK, сумма = 10, отправитель = $ asset1.receiver, приемник = A2_PuK}

script1 = {
   assets_hashes = {хэш (asset1), хэш (asset2)},
   Команды = {OP_CHECKSIG A1_PuK, OP_CHECKSIG $ asset1.receiver, OP_CHECKSIG mtgoxUSD_PuK, OP_CHECKSIG tradehillBTC_PuK, OP_CHECKTIMESTAMP timestamper_PuK "22/01/2012 00:00:00"}
}

И А и Б должны доверять TimeStamper. Они могут запросить TimeStamper, чтобы увидеть состояние транзакции.

----
С) Сделки с не являются обязательными рекламы

В двух предыдущих случаях, предварительно подписали сделку и переплетен на обещание, но обещание может недоставать подпись и быть добавлено позже без необходимости переменных.
Кстати, я не очень уверен, о том, как переменные используются здесь. Может быть, они не совместимы с буферами протокола, как я использовал их в предыдущих примерах.

----
D) децентрализованная Пульсация

С цепью, как TimeStamper (за определенную плату, и с кем-то платит самому себе) или сервер временных меток.
Каждый пульсации узел является Minter.
accounters: ripplepay, деревня ...
рынки: что-то в этом роде обмен Темного (с клиентом плательщика также ведет себя как рынок для поиска пути), ripplepay, деревня ...

Рассмотрим пульсация транзакции A -> B -> C -> D
Рынки также рассчитать пути.
Например, запросы ripplepay_market "10 д ы от А до D", Рынок выглядит в своей базе данных и отвечать на обещании:

б для элементов а при 1: 1
C для Б 2: 1
d's для языка C в соотношении 1: 4
так что 10 d's 20 элементов а

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

E) Используя секреты и Bitcoin скрипты, чтобы сделать контракты я не думал.

Это кажется хорошей идеей для меня, но, возможно, есть фундаментальный недостаток, который я не вижу. Любая конструктивная критика приветствуется.
Как вы думаете?
Чего не хватает или не нужен?