Coloured Coins White Paper v6

DEMORGAN LTD COMMERCIAL-IN-CONFIDENCE SEP-2015
White Papers
WP0165
Tokenisation
(Coloured Coins)
1|Page
Contents
Executive Summary....................................................................................................................................... 3
Introduction .................................................................................................................................................. 4
Functional Specification ................................................................................................................................ 4
Regular Bitcoin Transaction ...................................................................................................................... 4
Coloured Coins .......................................................................................................................................... 6
Setting the Coloured Rate ......................................................................................................................... 7
Transaction Examples ............................................................................................................................... 8
Foreign Exchange Transactions............................................................................................................... 11
Melting Coloured Coins........................................................................................................................... 11
Technical Specification [WIP] ...................................................................................................................... 12
Embodiment 1: Fiat Currency (divisible contracts) ............................................................................. 13
References .................................................................................................................................................. 20
Appendix 1 ..................................................................................................... Error! Bookmark not defined.
Appendix 2 ..................................................................................................... Error! Bookmark not defined.
2|Page
Executive Summary
3|Page
Introduction
This document outlines a method for utilising the Bitcoin blockchain to enable transactions within and
between any fiat currencies. The business line targeted in this document is financial services, whereby the
clients of the service provider deposit funds with the service provider and can then electronically use
those funds to pay other clients of the service provider for goods and services. In addition clients may
perform a foreign exchange transaction to convert between any two different fiat currencies. This allows
the client to pay for a product in any currency or to remit funds to an account in a foreign currency. The
method described herein directly addresses the requirements for this simple business model, but it should
be noted that the method will enable far more complex transactions. These will be the subject of
forthcoming white papers.
In current models for financial services the service provider maintains a balance sheet on
a database to record the clients’ account balances and keeps a record of transactions. In
essence, transactions are enacted by simple double-entry ledger entries made to the Why use the
database. Thus, clients must trust the service provider to correctly and honestly maintain Blockchain?
account information. In contrast, the blockchain model is based on a trustless,
decentralised paradigm. In this case there is no central database of transactions and
balances maintained by the service provider; instead this information is maintained on a
network of servers that collectively concur on its veracity. Whereas the traditional model is subject to
malicious attacks from inside or outside the organisation, the blockchain model is completely secure
against fraud, cyber-attacks and physical catastrophe. Furthermore, the blockchain record is permanent
and free from authoritarian interference.
The blockchain protocol[1] was designed to perform transactions in a new electronic currency known as
‘bitcoin’ (BTC). However, the underlying infrastructure can be utilised for a variety of purposes where (for
example) a permanent record is desired or where two or more parties wish to perform any type of
transaction. The full spectrum of purposes to be exploited will be described in future white papers. In this
paper we describe a method for conducting financial transactions in fiat currency built on the concept of
‘coloured coins’. In this method, the bitcoins on the transaction are used only as tokens representing an
amount of fiat currency. The bitcoin value is small and acts as a transport mechanism for the true value
being transacted. In this way, fiat currencies can be transacted even though the blockchain transaction is
in bitcoins.
Functional Specification
This section explains the concept of coloured coins and describes how the traditional model will be
replaced by the blockchain. A highly simplified explanation of a bitcoin transaction is presented first,
followed by a description of how coloured coins can be created using bitcoins. Then some simple use cases
are presented in the traditional model and the blockchain model.
Regular Bitcoin Transaction

In a normal bitcoin transaction the value transacted is denominated in bitcoins. At the time of writing
bitcoins were hovering around a value of $300. Therefore, sending someone 1 BTC in a normal transaction
is equivalent to sending them about $300. In the blockchain explicit account balances are not kept; rather
these are derived purely from the chain of transactions. A bitcoin transaction is made up of one or more
inputs and one or more outputs. An input is composed of a back-reference to a previous transaction
output plus the payee’s cryptographic signature. An output is composed of the amount of BTC to be paid
4|Page
and the rules of payment (usually just the address of the payee). Figure 1 shows a simplified bitcoin
transaction.
Figure 1: Simple schematic of a bitcoin transaction with one input and one output
In a bitcoin transaction, the full amount of a referenced output must be paid out. This means that if only
a portion of the BTC amount referenced is to be paid in the new transaction, then the resulting ‘change’
must be paid back to the payer. For example, figure 2 shows Alice, who owns 1.5BTC from a previous
transaction, paying Bob 1.0 BTC and getting 0.5 BTC back as change.
Figure 2: Alice pays Bob 1.0 BTC from her 1.5 BTC and gets 0.5 BTC change
Note that in this example the ‘miner’s fee’ has been excluded for simplicity. When the sum of BTCs from
all the outputs of a transaction total to less than the sum of the input amounts the difference is taken by
the miner as a fee. Theoretically the fee can be zero but this reduces the likelihood of the transaction
being processed by miners (i.e. it will remain unprocessed for a very long time). Accordingly there are
standards for calculating the minimum transaction fee a transaction must pay for a full bitcoin node
(server) to relay that transaction to other nodes. This amount is known as the relay fee and is based on
the size (in bytes) of the transaction.
5|Page
The BTC amount on any output cannot be zero and, in fact, must exceed a certain
minimum threshold to be considered valid. This threshold is known as dust[3] and BTC has 8 decimal
its value will change over time as the value of BTC varies. Dust is set by the places.
protocol rules as 1/3 of what it would take to spend it in an input of typical size.
At the time of writing, given the current default relay fee, dust is set to 546 1 satoshi = 10-8 BTC
satoshis.
Coloured Coins
A coloured coin[4] works the same as a banknote. It is a token issued by an issuing authority which can be
redeemed for its face value by the issuer. Whereas banknotes are backed by gold reserves, coloured
bitcoins will be backed by fiat currency. Banknotes are essentially printed certificates
displaying their face value plus the promise to redeem that face value; coloured
bitcoins will have an electronic certificate attached to them.
Banknotes are signed by a representative of the issuing
In practice, only a signed
authority (e.g. the governor of the reserve bank); coloured
‘hash’[5] of the certificate
bitcoins are cryptographically signed by the issuer’s private
is actually stored on the
key.
transaction, along with key
In effect, the electronic certificate attached to the coloured information such as the
bitcoin is a contract[7] that legally and indelibly binds the issuer to the specified coloured rate, Issuer-ID,
contract requirements. As the contract is stored on the blockchain it is safe from denomination (etc.)
alteration and as the signature can be verified against the issuer’s public key it
The actual certificate is
cannot be forged or denied. Figure 3 shows a simplified structure for a coloured
stored as a torrent file[6] in
coin.
the cloud, and is verifiable
by comparing it with the
stored hash.
Figure 3: Schematic of a coloured bitcoin. The certificate is ‘attached’ to the transaction output
Notice that this is still a trustless system despite the dependency on the issuer. Although it seems coloured
bitcoin holders need to ‘trust’ that the issuer will fulfil their contractual commitment, this is a risk issue
and not a trust issue. The holders have recourse to legally enforce the contract and only take the risk of
the issuer’s financial collapse.
6|Page
Setting the Coloured Rate

Like a real coin, a coloured bitcoin has an intrinsic value. A silver dollar, for example, contains some
amount of precious metal. In practice, the precious metal content in coins is much less than the face value
of the coin (else there would be incentive to melt coins down and sell the raw
metal). As coloured bitcoins are to be used as the transport mechanism, the Alternative Colouring
coloured rate is arbitrary and can be set by the issuer. There are several ways this Process
can be accomplished. In the current proposal the issuer will set the intrinsic value
Instead of pegging the BTC
by pegging it to the fiat value using a ‘coloured rate’ that the issuer determines
amount to fiat, the issuer
based on the following simple guidelines:
could simply conduct each
1. The underlying bitcoin amount should be much less in intrinsic value than transaction output with
the fiat face value. dust. There would be no
2. For any particular transaction: the intrinsic bitcoin value must be larger lower limit on the
than the minimum allowed (i.e. must exceed the ‘dust’ limit) transacted fiat amount.
This technique is useful for
The rate chosen will be embedded into the electronic certificate, which will read
other types of contract but
along the lines of: “IssuerX promises to pay the redeemer of these bitcoins at a
is cumbersome for
rate of $xxx.xx per BTC” (naturally the full certificate will be tightly worded as a
currencies for several
formal legal contract). Note that for any particular fiat currency there could be
reasons. For example, it
multiple rates: for each different coloured rate a new certificate would be issued
complicates giving change.
authorising that rate.
One implication of the proposed colouring process is that the issuer will need to
impose a minimum fiat transaction value, which is the amount that translates to bitcoin dust at the
coloured rate. In practice this should not pose a problem, as the following examples demonstrate.
Colouring Example 1: Canadian dollars.
As of Sep 2015 the actual CAD/BTC rate is approximately: 1 BTC = $300. Accordingly, an appropriate
coloured rate is of the order of: 1 BTC ≡ $10,000 (we use the ‘≡’ symbol to show the equivalent fiat value
for 1.0 coloured bitcoin). This setting means that Canadian dollars will be transacted in coloured bitcoins
using about 3% of its face value. Using this coloured rate we can calculate the fiat dust value as follows:
Dust = 546 Satoshis

≡ 546 x 10-8 x $10,000
≡ $0.0546
Thus, at this setting the minimum transaction allowed is 6c (CAD).
Colouring Example 2: Philippines Pesos.
As of Sep 2015 the actual PHP/BTC rate is approximately: 1 BTC = P11,000. Accordingly, an appropriate
coloured rate is of the order of: 1 BTC ≡ P1,000,000. This setting means that Philippines pesos can be
transacted using about 1% of its face value. Using this coloured rate we can calculate the dust value as
follows:
Dust = 546 Satoshis
7|Page
≡ 546 x 10-8 x P1,000,000

Bitcoin transactions are
≡ P5.46
managed by the Issuer’s
Thus, at this setting the minimum transaction allowed is P5.46 (approximately
eWallet. As far as the
$0.15).
Issuer’s clients are
Transaction Examples concerned, they are
The following examples compare the traditional method with the coloured coin transacting in fiat currency
method. and they need have no
knowledge that the
Transaction Example 1: Alice opens an account at CCBank with $1000 mechanics of their
Figure 4 shows a schematic of the transaction in the traditional model. Alice opens transactions are handled by
an account at the financial services provider (“CCBank”) by depositing $1000 with the bitcoin Blockchain .
them. CCBank deposits this amount at their own bank, and updates their customer
database and their ledger.
Figure 4: Alice opens account at CCBank
Figure 5 shows the same transaction in the blockchain model. CCBank mints coloured coins according to
demand. In this case Alice’s $1000 is deposited into a special ‘reserve’ account. By attaching their signed
certificate to the transaction output, CCBank have committed to redeeming the issued coloured amount
at the specified rate. Thus, the amount in the reserve account must match the amount of coloured BTC in
circulation.
8|Page
Figure 5: CCBank ‘mints’ coloured BTC at a face value of $1000
Transaction Example 2: Alice pays Bob $900
In figure 6 Alice pays Bob $900. In the traditional model this is simply a ledger entry on the database
(assumes Bob already has an account at CCBank).
Figure 6: Alice uses CCBank’s system to make a payment to Bob. System updates the ledger database
Figure 7 shows the blockchain version of the transaction. CCBank’s eWallet creates the required bitcoin
transaction. The payment to Bob is 0.09 BTC, which is equivalent to $900 using the previous colouring
example, and the change that comes back to Alice is 0.01 BTC. Notice that the Issuer-certificate is
propagated onto each output, so each output is coloured. The Issuer certificate is re-signed by the Issuer
for every output.
9|Page
Figure 7: Alice uses CCBank’s system to make a payment to Bob. System creates the bitcoin transaction
In the foregoing examples the miner’s fee has been omitted for simplicity. In practice many transactions
can be bundled together to minimise the miner’s fee. The miner’s fee will be paid out in uncoloured
satoshis (i.e. the output will not carry the Issuer’s certificate).
Transaction Example 3: Alice withdraws $50 from her CCBank account
The next example shows the transaction for a withdrawal: Alice withdraws $50 from her CCBank account.
The traditional model is straightforward: CCBank update their ledger and transfer $50 from their bank
account into Alice’s nominated bank account. Figure 8 shows the bitcoin transaction.
Figure 8: Alice withdraws $50 from her CCBank account, triggering a redemption transaction
10 | P a g e
In Figure 8 Output0 is a redemption transaction: the Issuer certificate has been ‘detached’ from the
output, thereby converting the underlying amount into uncoloured bitcoins.
The transaction examples
Foreign Exchange Transactions have been simplified for
Alice might choose to pay another CCBank client in a different fiat currency. For clarity. In practice there are
example, she might want to pay Nino $50 converted into Philippines Pesos (PHP). likely to be more
This will appear as a straightforward action for Alice using the CCBank client transactions, reflecting
interface. Behind the scenes, the CCBank system will perform a series of interim movements. For
transactions, simplified as follows: example, minting may
1. Create a bitcoin transaction to redeem $50 worth of coloured bitcoins involve paying to the
2. Withdraw $50 from Reserve account and convert to PHP at spot rate issuer’s own address prior
(say, P2500) through a regular FX transaction to transferring to the
3. Deposit the P2500 at a PHP-denominated Reserve account held at a client.
Philippines bank
4. Mint P2500 worth of Coloured bitcoin. Using colouring example 2 this comes to 0.0025 BTC. The
transaction is similar to the example in figure 5, except that (i) the recipient is Nino’s address, (ii)
the BTC amount is 0.0025, and (iii) there is a different Issuer certificate: this one promising to
redeem the underlying bitcoins at the coloured rate of 1 BTC ≡ P1,000,000.
Melting Coloured Coins

In theory, Alice could use an alternative eWallet to spend her underlying bitcoins by creating a transaction
to pay them to someone else. However, only CCBank’s eWallet can sign transactions to propagate the
Issuer certificate. Therefore, if Alice spends her bitcoins outside of CCBank’s system they will be
uncoloured and will retain only the intrinsic value of the bitcoins (i.e. she will have ‘melted’ her coloured
coins down for their ‘metal’ content). In practice Alice is protected from doing this as standard eWallets
will not be able to create a valid transaction from a CCBank coloured coin (see Technical Specification
section for explanation). In order to create a valid uncoloured transaction from a CCBank coloured coin
Alice would have to ‘handcraft’ a ‘raw’ transaction. In other words, this could not happen by accident;
Alice would have to deliberately melt her coins. Note that if Alice were to perform this action, the reserve
account containing the fiat currency amount would then exceed the value of coloured coins in circulation.
11 | P a g e
Technical Specification [WIP]

The invention is a method constructing bitcoin transactions such that the bitcoin value on the transaction
acts a token representing a rights contract in digital form. The contract itself may be stored on the
transaction or may be kept in a publicly accessible location, or may be held privately by the parties to the
contract depending on the particular embodiment.
The key elements of the invention are as follows:

1. Bitcoin transactions will use the P2SH (pay-to-script-hash) method of spending bitcoins
2. Metadata will be stored on the transaction. The content of the metadata will depend on the
particular embodiment, but as a minimum will include the following:
a. The type of contract (e.g. fiat currency; property ownership, etc)
b. The actual contract or a pointer to the contract and hashed version of the contract
c. Information on how to process the transaction
3. A redeem script format for locking/unlocking the transaction
The P2SH takes the following format:

(i) OP_0 Sig1 Sig2 … <NumSigs Metadata1 Metadata2… PubK1 PubK2… NumKeys
OP_CHECKMULTSIG>
The content of the angled brackets <> is the redeem script.
Where:
Sig1… cryptographic signatures
NumSigs Number of signatures required in an ‘m of n’ multisig output
Metadata1… 32 byte blocks of metadata (acting as ‘pretend’ public keys)
PubK1… True public keys
NumKeys Number of ‘public keys’ (including metadata) in the multisig
The value of NumSigs is the actual number of signatures preceding the redeem script, and matches the
number of true public keys (PubK1 PubK2…). The value of NumKeys is NumSigs plus the number of blocks
of metadata. When this script is executed, the metadata blocks will effectively be ignored and the
signatures will be matched against the true public keys.
The following example relates to the Fiat Currency embodiment to be described below:
(ii) OP_0 Sig-Alice Sig-Issuer <OP_2 metadata1 metadata2 PubK-Alice PubK-Issuer OP_4
OP_CHECKMULTSIG>
The above example is a ‘2 of 4’ mutisignature P2SH script in which the signatories are Alice and the Issuer
of the contract. As the signatures match up with the two true public keys, the metadata blocks will be
ignored and script execution will return a value of True, indicating a valid transaction.
The number of metadata blocks is flexible but as the maximum number of public keys in a multisig output
is 15, the following constraint applies:
(iii) (NumSigs) + (number of metadata blocks) ≤ 15
12 | P a g e
The decision as to whether to store the actual contract in metadata or outside the blockchain will depend
on considerations such as the size of the contract and level of privacy expected. If the contract is to be
stored in metadata it must first be broken down into 32-byte blocks (simulating public keys) and must fit
within the constraint in equation (iii).
The embodiments described below require only two metadata blocks and assumes that the contract itself
is not directly stored on the transaction. The format is given in figure 2.
Field Sub-field Bytes Value Comments

Metadata1 ContractType 4 Coded value indicates type of contract.
ContractPointer 16 IPv6 address of the actual contract file location
ContractTypeData1 12 Format depends on value of ContractType. Padded with zeros
Metadata2 ContractHash 20 RIPEMD-160(SHA256(actual contract file addressed by ContractPointer))
ContractTypeData2 12 Format depends on value of ContractType. Padded with zeros
Figure 2: Format of metadata for all embodiments described in this document
The first 4 bytes of metadata1 indicates the type of contract. For example, in the first embodiment
described below the contract type will be ‘Fiat Currency’. The next 16 bytes holds the IP address of the
location of the actual electronic contract file, making allowance for IPv6 addresses. Note that in some
embodiments this value will point to the seed of a torrent file such that the contract file can be distributed
over the cloud rather than centralised. The following 12 bytes contains data specific to the type of contract
(examples are provided below in the descriptions of embodiments).
The first 20 bytes of metadata2 is a hash of the actual contract file using RIPEMD-160 over SHA256 applied
to the file. As the actual contract file is retrievable this allows validation of the transaction against the
contract. Note that the contract file itself may be completely public (unencrypted and human readable)
or may be encrypted for privacy, depending on the requirements of the specific embodiment. The content
of the remaining 12 bytes of metadata2 depends on the type of contract.
Embodiment 1: Fiat Currency (divisible contracts)

The following describes an embodiment whereby a financial services provider issues contracts
redeemable in fiat currency in exchange for a deposit of funds by clients in the fiat currency (refer to figure
1). The service provider (henceforth ‘Issuer’) will process transfers of value between clients by creating
appropriate bitcoin transactions and broadcasting them to the bitcoin network. This embodiment
represents a type of contract where the rights entailed by the contract are divisible (i.e. the contract can
be ‘split’ such as when part of the contract value is used as payment and ‘change’ is given). As non-divisible
contracts (those that must be transferred as a whole) represent a subcategory of divisible contracts, the
description below also applies to non-divisible contracts. There are several variations to the
implementation, which will be denoted as ‘options’ within the description.
In order to process transactions in the Fiat Currency embodiment, key parameters must be available to
the Issuer. These may be retrieved from the contract file as one option or may be stored directly on the
transaction via metadata for greater processing efficiency. Figure 3 shows the format of the metadata for
the latter option.
13 | P a g e
Field Sub-field Bytes Value Comments

Metadata1 ContractType 4 0x00000001 Indicates Fiat Currency
ContractPointer 16 IPv6 address of the actual contract file location
FiatDenomination 2 Coded value indicating currency (e.g. 0x0001=CAD, 0x0002=PHP, etc)
PeggingRate 1 Coded value represents the BTC/fiat pegging rate.
TransactionType 1 Coded value represents type of output (issuance/payment/redemption)
Padding 8 0x00000… Spare bytes
Metadata2 ContractHash 20 RIPEMD-160(SHA256(the actual contract file addressed by ContractPointer))
Padding 12 0x00000… Spare bytes
Figure 3: Fiat Currency metadata format for the option where key parameters are stored
The value of the token BTC amount must exceed a threshold value (known as ‘dust’) for a transaction
output to be considered valid. Provided this requirement is met the value chosen for the token is at the
discretion of the Issuer. In one option (‘Dust Token’ method) the Issuer could elect to set the token BTC
value to the minimum required (dust) on all transactions irrespective of the fiat value. In this case the
Issuer would need to allocate extra dust tokens to transactions whenever contracts are divided (for
example, when a payment is made and change is given: both payment and change need to be tokenised).
Furthermore, the Issuer would need a way to keep track of all transferred fiat value as contracts continue
to be further split. This would lead to further options of either (a) carrying this value within the spare
metadata bytes or (b) implementing a process to recalculate values from scratch starting with the initial
tokenisation for every transaction in the chain.
An alternative to the Dust Token option is the ‘Pegging’ option, in which the token value is pegged to the
fiat value represented by the token. In this option there is no need to separately keep track of transferred
fiat value as this value is directly related to the BTC value on the transaction output.
The decision as to whether to use the Dust Token option or the Pegging option will depend on the Issuer’s
business model and funding considerations. The current illustration continues assuming the Pegging
option.
In figure 3 the metadata contains a 2-byte field to indicate the fiat currency (FiatDenomination) and 1-
byte field called PeggingRate. The pegging rate is set by the Issuer. Several different rates may be set for
the same fiat currency, however, a new contract will be needed for each different rate. The choice of rate
is at the discretion of the Issuer, however there are two key considerations:
1. The intrinsic value of the token should be (much) less than the represented fiat value. This is
because tokenisation imposes a cost of carry, so the higher the token value the higher the cost of
carry.
2. For any particular transaction the intrinsic token value must exceed the minimum allowed (i.e.
must exceed the ‘dust’ limit). This imposes a lower limit on the amount of fiat value transferable.
PeggingRate is an 8-bit coded value as follows:
Leftmost bit will be used as a flag:

1 = rate expressed as satoshis/Share (‘share’ refers to the minimum fiat amount – i.e. 1 cent)
0 = rate expressed as Share/satoshi
The rightmost seven bits represents the rate as a power of ten in binary:
Examples:
14 | P a g e
USD 10000010 means rate of 100 satoshis/share (flag is on) (1 share = 1 cent)
PHP 00000000 means rate of 1 share/satoshi (flag is off) (1 share = 1 centavo)
IDR 00000001 means rate of 10 share/satoshi (flag is off) (1 share = 1 rupiah)
TransactionType is a 1-byte field indicating whether the transaction is an issuance (in which bitcoins are
converted into tokens); a payment (in which value is transferred from one client to another); or a
redemption (in which tokens are converted back to regular bitcoins).
In bitcoin transactions each contains a 4-byte field called ‘sequence number’ which is no longer used by
the bitcoin core. Depending on the Issuer’s implementation, an option is to utilise this field to allocate
transaction inputs to outputs. The sequence number can represent a string of 1-bit flags whereby the
position of each flag starting with the rightmost bit indicates that the input has contributed part of its
funds to the flagged output. For example, the following value for sequence number indicates that the
input it belongs to has paid into outputs 0, 5 and 7:
00000000000000000000000010100001
The current illustration continues assuming this option.
The following are examples of three types of transaction: a payment, an issuance and a redemption. In
each case the following parameters are assumed to be coded into the metadata:
FiatDenomination 0x01 USD

PeggingRate 10000010 100 satoshis/share (1 share = 1 cent)
Example 1: Alice has $10 worth of tokenised bitcoin and pays Bob $7:30
Figure 4 shows the originating transaction outputs (transaction-id / Satoshis amount / locking script).
ID-101
50,000
OP_HASH160 <redeem script hash> OP_EQUAL
ID-102
50,000
ID-103
10,000,000
OP_DUP OP_HASH160 <PubK-Issuer hash> OP_EQUALVERIFY OP_CHECKSIG
Figure 4: Originating transaction outputs for Example 1.
ID-101 and ID-102 show Alice being paid $5.00 each as tokenised bitcoin. ID-103 shows a payment to the
Issuer of regular (i.e. not tokenised) 0.1 BTC. Note that <redeem script hash> is the hashed value of the
redeem script used in the ScriptSig of the first two inputs of the spending transaction (see figure 5).
15 | P a g e
ID-110 Transaction-ID
Version number Version number
3 Number of inputs
ID-101 Prev Trans Output
IDX-00 Prev Trans Output index
Script length Script length
OP_0 Sig-Alice Sig-Issuer <2 metadata1 metadata2 PubK-Alice PubK-Issuer ScriptSig
4 OP_CHECKMULTSIG>
00000000000000000000000000000001 Sequence number
OP_0 Sig-Alice Sig-Issuer <OP_2 metadata1 metadata2 PubK-Alice PubK- ScriptSig
Issuer OP_4 OP_CHECKMULTSIG>
00000000000000000000000000000011 Sequence number
Sig-Issuer PubK-Issuer ScriptSig
00000000000000000000000000000100 Sequence number
3 Number of outputs
73,000 Output value
Output script length Output script length
OP_HASH160 <redeem script hash> OP_EQUAL Output script
27,000 Output value
9,999,000 Output value
OP_DUP OP_HASH160 <PubK-Issuer hash> OP_EQUALVERIFY Output script
OP_CHECKSIG
LockTime LockTime
Figure 5: The full transaction showing Alice’s payment of $7:30 to Bob
Figure 5 shows that there are three inputs and three outputs. The ScriptSig for the first two inputs shows
that in this implementation both the spender’s signature and Issuer’s signature are required to perform
the tokenised transaction. The sequence number of the first input indicates that all the funds from the
originating transaction (ID-101) goes into the first output (output 0), while the sequence number of the
second input shows that the funds from its originating transaction (ID-102) is paid partially into output 0
and partially into output 1. The third input is a regular (non-tokenised) payment (i.e. a P2PKH payment)
16 | P a g e
from the Issuer back to the Issuer and its sequence number shows that the originating transaction’s funds
get paid into the third output (output 2).
Key points to note in this example:

 A single bitcoin transaction may have a mixture of tokenised and non-tokenised transfers.
 Output 0 is the payment to Bob. Thus, the <redeem script hash> is a hash of the following:
(iv) <OP_2 metadata1 metadata2 PubK-Bob PubK-Issuer OP_4 OP_CHECKMULTSIG>
i.e., a 2 of 4 multisignature P2SH to be signed by both Bob and the Issuer.
 Output 1 is the change of $2.70 that gets paid back to Alice. Thus, its <redeem script hash> is a
hash of:
(v) <OP_2 metadata1 metadata2 PubK-Alice PubK-Issuer OP_4 OP_CHECKMULTSIG>
i.e., a 2 of 4 multisignature P2SH to be signed by both Alice and the Issuer.
 The metadata for both outputs include a value for the TransactionType indicating that these are
payment transactions.
 As part of the Issuer’s verification process, it must verify that the total amount of input tokenised
BTC is equal to the total output tokenised BTC.
 Output 3 exists in order to fund the transaction. I.e., since the total input satoshis of all
transactions is 10,100,000 but the total of all outputs is 10,099,000 the difference (1,000 satoshis)
will be taken by the miner as a fee.
Example 2: Issuance. Bob deposits $1000 at Issuer and receives $1000 worth of tokenised bitcoins in return
Figure 6 shows the originating transaction output (transaction-id / Satoshis amount / locking script).
ID-201
50,000,000
Figure 6: a regular P2PKH transaction paying to the Issuer
Figure 6 represents some payment of regular BTC to the Issuer that will be used to fund the issuance of
tokens (or, ‘minting’). For example, it may be part of a capitalisation in which the Issuer initially purchased
BTC to fund their tokenisation operations.
Figure 7 shows the issuance transaction.
1 Number of inputs
17 | P a g e

00000000000000000000000000000011 Sequence number
2 Number of outputs
OP_CHECKSIG
LockTime LockTime
Figure 7: The full transaction showing issuance of tokenised $1000 to Bob
In figure 7 are one input and two outputs. The first output is the tokenisation of 10,000,000 and has been
locked with a P2SH script. The script that was hashed to create <redeem script hash> is as follows:
(vi) OP_2 metadata1 metadata2 PubK-Bob PubK-Issuer OP_4 OP_CHECKMULTSIG
Accordingly, the script needed to spend (unlock) these tokens is:
(vii) Sig-Bob Sig-Issuer <OP_2 metadata1 metadata2 PubK-Bob PubK-Issuer OP_4

OP_CHECKMULTSIG>
The second output is the Issuer’s untokenised change, once again leaving a small amount for the miner’s
fee. The metadata in the first output includes a value for the TransactionType indicating that this is an
Issuance transaction.
Example 3: Redemption. Bob cashes in his $1000 worth of tokenised bitcoins
Depending on the Issuer’s implementation there are several options for how to create a redemption.
Three options are described with the third supported by transaction diagram.
Redemption Option 1
In this option the tokens are redeemed in one step by a payment from Bob back to the Issuer converting
the tokenised bitcoins to untokenised by providing a P2PKH script as the locking script. In this case, there
is no TransactionType as there is no metadata field associated to the output. Therefore the fact that it is
a redemption must be inferred from other implicit data, such as the combination of (a) a tokenised output
is being spent using a P2PKH locking script instead of a P2SH, plus (b) the recipient is the Issuer.
Redemption Option 2
This option requires two steps. First Bob pays his tokenised bitcoins back to the issuer as tokenised coins.
As this transaction has metadata in the output it will contain TransactionType value indicating that it is a
redemption. Second, the Issuer spends the tokenised bitcoin as a P2PKH transaction to themselves to
18 | P a g e
‘untokenise’ the bitcoins in a separate transaction. This option has the disadvantage that there is an extra
miner's fee as there are two transactions to accomplish the process.
Redemption Option 3
In this option, the tokenised bitcoins are redeemed in one step by a payment from Bob to the issuer. The
tokenised bitcoin is converted the untokenised by dint of a P2SH script that is specific to redemption (i.e.
it is different to the regular P2SH for payments). In this case, there is a TransactionType to indicate a
redemption as there is a metadata field associated to the output.
Then to spend this untokenised output, the issuer will use the following SigScript:
(viii) Sig-Issuer <OP_1 metadata1 metadata2 PubK-Issuer OP_3 OP_CHECKMULTSIG>
As the TransactionType in the metadata indicates the originating output was a redemption then by
definition this bitcoin is already untokenised.
Figure 8 shows the originating transaction outputs (using the outputs from previous examples)
ID-210
10,000,000
ID-110
9,999,000
Figure 8: originating transaction outputs for the redemption
Figure 9 shows the redemption transaction.
2 Number of inputs
OP_0 Sig-Bob Sig-Issuer <OP_2 metadata1 metadata2 PubK-Bob PubK- ScriptSig
Issuer OP_4 OP_CHECKMULTSIG>
00000000000000000000000000000001 Sequence number
00000000000000000000000000000010 Sequence number
2 Number of outputs
19 | P a g e

OP_CHECKSIG
LockTime LockTime
Figure 9: The full transaction showing Bob’s redemption of $1000 worth of tokenised bitcoins
In this case, the <redeem script hash> is a hash of the following:
(ix) OP_1 metadata1 metadata2 PubK-Issuer OP_3 OP_CHECKMULTSIG
I.e. a 1 of 3 multisignature P2SH (specific to spending redeemed tokens).
References
[1] For a broad overview: http://staging.spectrum.ieee.org/img/06Bitcoin-1338412974774.jpg. A good
detailed description written for the layperson can be found here:
http://www.michaelnielsen.org/ddi/how-the-bitcoin-protocol-actually-works/. Complete details and
technical specifications can be viewed at the Bitcoin Wiki site: https://en.bitcoin.it/wiki/Main_Page
[2] Miners are Bitcoin nodes that add new blocks to the blockchain: https://bitcoin.org/en/developer-
guide#mining
[3] Dust is explained in this discussion thread: http://bitcoin.stackexchange.com/questions/10986/what-
is-meant-by-bitcoin-dust
[4] Several different ways to implement coloured coins on the Bitcoin blockchain have been proposed,
each with its own advantages and disadvantages. An early proposal can be found here:
https://docs.google.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit#
heading=h.wxrvzqj8997r. Two rival open source protocols are: https://github.com/OpenAssets/open-
assets-protocol and https://github.com/Colored-Coins/Colored-Coins-Protocol-Specification. The
protocol described in the Technical Specification section of this document are proprietary to
DeMorgan Ltd.
[5] A hash is the result of performing a mathematical operation on a (usually very large) integer, for
example, a text document represented as a hexadecimal number. The hashing algorithm used by the
Bitcoin protocol is known as RIPEMD160 and always results in a 20-byte integer. More details can be
viewed here: https://en.wikipedia.org/wiki/RIPEMD
[6] https://en.wikipedia.org/wiki/BitTorrent
[7] https://en.bitcoin.it/wiki/Contract
20 | P a g e
21 | P a g e

Coloured Coins White Paper v6

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Coloured Coins White Paper v6

Transféré par

Droits d'auteur :

Formats disponibles

DEMORGAN LTD COMMERCIAL-IN-CONFIDENCE SEP-2015

Regular Bitcoin Transaction

Setting the Coloured Rate

Colouring Example 1: Canadian dollars.

Dust = 546 Satoshis

Colouring Example 2: Philippines Pesos.

Dust = 546 Satoshis

≡ 546 x 10-8 x P1,000,000

Figure 4: Alice opens account at CCBank

Figure 5: CCBank ‘mints’ coloured BTC at a face value of $1000

Transaction Example 2: Alice pays Bob $900

Transaction Example 3: Alice withdraws $50 from her CCBank account

Melting Coloured Coins

Technical Specification [WIP]

The key elements of the invention are as follows:

The P2SH takes the following format:

The content of the angled brackets <> is the redeem script.

(iii) (NumSigs) + (number of metadata blocks) ≤ 15

Field Sub-field Bytes Value Comments

Embodiment 1: Fiat Currency (divisible contracts)

Field Sub-field Bytes Value Comments

PeggingRate is an 8-bit coded value as follows:

Leftmost bit will be used as a flag:

The current illustration continues assuming this option.

FiatDenomination 0x01 USD

Figure 5: The full transaction showing Alice’s payment of $7:30 to Bob

Key points to note in this example:

(iv) <OP_2 metadata1 metadata2 PubK-Bob PubK-Issuer OP_4 OP_CHECKMULTSIG>

i.e., a 2 of 4 multisignature P2SH to be signed by both Bob and the Issuer.

(v) <OP_2 metadata1 metadata2 PubK-Alice PubK-Issuer OP_4 OP_CHECKMULTSIG>

i.e., a 2 of 4 multisignature P2SH to be signed by both Alice and the Issuer.

Figure 7 shows the issuance transaction.

Script length Script length

Figure 7: The full transaction showing issuance of tokenised $1000 to Bob

(vi) OP_2 metadata1 metadata2 PubK-Bob PubK-Issuer OP_4 OP_CHECKMULTSIG

Accordingly, the script needed to spend (unlock) these tokens is:

(vii) Sig-Bob Sig-Issuer <OP_2 metadata1 metadata2 PubK-Bob PubK-Issuer OP_4

Example 3: Redemption. Bob cashes in his $1000 worth of tokenised bitcoins

(viii) Sig-Issuer <OP_1 metadata1 metadata2 PubK-Issuer OP_3 OP_CHECKMULTSIG>

Figure 9 shows the redemption transaction.

Output script length Output script length

In this case, the <redeem script hash> is a hash of the following:

(ix) OP_1 metadata1 metadata2 PubK-Issuer OP_3 OP_CHECKMULTSIG

I.e. a 1 of 3 multisignature P2SH (specific to spending redeemed tokens).

Vous aimerez peut-être aussi