Я определил следующие общие подходы, которые могут быть использованы для окрашивания выходов сделки:

1. На основании закона сохранения, то есть отображение цвета справедливо, когда он сохраняет количество монет, участвующих в сделке.
2. На основании упорядочения, то есть цвет зависит от упорядочения выходов в рамках транзакции.
3. На основе мета-информации, включенных в сделку. Скажем, цветные выходы могут иметь специальный мета-данные, встроенный в скрипт (например OP_DROP сообщении).

Закон сохранения может работать в некоторых случаях, например, если вход 3 красных и синие 7 монет, а выходы 7 Х и 3 Y, то Х = синие и Y = красные.
Тем не менее, существует потенциальная неоднозначность: если у нас есть 5 красных и 5 синих, мы не будем знать, как цвета выходов.
Кроме того, окраска может потребовать экспоненциального времени.

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

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

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

Входы: [1 красный, 1 синий, 1 зеленый]
Выходы: [1 X, Y 1, Z 1].

Очевидно, что X = красный, Y = синий, Z = зеленый.

Теперь немного более сложный пример, где число входов и выходов не совпадают:

Входы: [1 красный, 1 красный, 1 синий, 1 зеленый]
Выходы: [2 X, Y 1, Z 1]

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

Входы: [2 красные, 1 синий, 1 зеленый]
Выходы: [1, X 1 Y, Z 1, 1 Вт]

Входы определяют заказ R->Г->B. Первый выход должен быть R, но у нас есть одна красная монета ушла. Поэтому второй выход красный тоже, а остальное тривиально.

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

Затем мы проходим через выходы для того, наличие двух переменных состояния: цвет тока и количество монет этого цвета слева. Для каждого выхода мы заявляем, что она имеет «текущий цвет» и уменьшить количество монет, оставленных суммы, что объем производства в. Когда сумма стремится к нулю, мы идем в следующий цвет. Если мы когда-либо иметь отрицательное значение, окрашивание является ошибочным, и мы предполагаем, что все выходы неокрашенные. (Т.е. владелец не заботится о цветах больше.)

Довольно просто.

Что о неокрашенных монетах? Мы хотим, чтобы платить взносы с неокрашенными монетами. Чтобы сделать это, мы должны включить их в конце транзакции.

В случае, если плата выплачивается, мы в конечном итоге с положительной суммой осталась в конце концов, но это не проблема, потому что у нас нет больше выхода на цвет, и он не будет путать наш алгоритм. (Кроме того, можно внести плату с цветной монетой:., Что цвет должен просто прийти в последний раз)

Пример:

Входы: [1 красный, 1 синий, 1 неокрашенный]
Выходы: [1 красный, 1 синий, 0,95 неокрашенный]

Наконец, предположим, что мы не знаем о некоторых цветов, то есть мы видим, как эти цвета неокрашенной. Это проблема? Нет. Пример:

Входы: [1 неокрашенный, 1 неокрашенный, 1 красный]
Выходы: [1, X 1 Y 1 Z]

Х и Y будут неокрашенной, Z имеет красный цвет. Мы не знаем, является ли X и Y имеют тот же цвет или нет, но мы заботимся только о красном, и мы можем выяснить, красный.

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