Coloured Coins Bitcoin Transactions v5

Transaction A Transaction B
Version number Version number

Number of inputs Number of inputs
Prev Trans Output Prev Trans Output
Prev Trans Output index Prev Trans Output index
Script length Script length
ScriptSig ScriptSig
Sequence number Sequence number
Number of outputs Number of outputs
Output value Output value
Output script length Output script length
Output script Output script
LockTime LockTime
Verification steps
OP_0
Signature of Spender
Signature of Issuer
OP_2
Metadata1
Metadata2
Spender-pubkey
Issuer-pubkey
OP_4
OP_CHECKMULTSIG
OP_HASH160
Redeem Script Hash
OP_EQUAL
Generic Contract metadata format
Field Sub-field Bytes Value
Metadata1 ContractType 4
ContractPointer 16
ContractTypeData1 12
Metadata2 ContractHash 20
Fiat Currency metadata format

Metadata1 ContractType 4 0x00000001
ContractPointer 16
FiatDenomination 2
PeggingRate 1
TransactionType 1
Padding 8 0x00000…

Sequence number 4

Metadata1 TransactionType 1 0x01
0x02
0x03
Comments
Coded value indicates type of contract.
IPv6 address of the actual contract file location
Format depends on value of ContractType. Padded with zeros
RIPEMD-160(SHA256(actual contract file addressed by ContractPointer))
Comments
Indicates Fiat Currency
Coded value indicating currency (e.g. 0x0001=CAD, 0x0002=PHP, etc)
Coded value represents the BTC/fiat pegging rate.
Coded value represents type of output (issuance/payment/redemption)
Spare bytes
RIPEMD-160(SHA256(the actual contract file addressed by ContractPointer))
Spare bytes
Comments
Bitfield allocates inputs to outputs, starting with rightmost bit
Comments
Indicates an Issuance output (coloured coins being minted)
Indicates a payment output (transfer of coloured coins)
Indicates a redemption (Issuer pays fiat currency equivalent to bearer)
To minimise the bytes needed, the rule is as follows:
One bit will be used as a flag:
1 = rate expressed as Satoshis/cent (‘cent’ means min. fiat amount)
0 = rate expressed as Cent/Satoshi
Examples:
CAD 100000102 means rate of 100 satoshis/cent (flag is on)
PHP 000000002 means rate of 1 centavo/satoshi (flag is off)
IDR 000000012 means rate of 10 rupiah/satoshi (flag is off)
Validity check as follows:

If the originating output was coloured then the spending output is coloured.
If a spending output gets funds from more than one originating output
the originating outputs must all be coloured or all be uncoloured.
EXCEPTIONS:
Issuance transaction (minting coins)
Redemption transactions (convert colored back to uncoloured)
Originating transactions (transaction-id / Satoshis amount / script length / locking script)
ID-101
50,000
Output script length
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
Redeem script: OP_2 metadata1 metadata2 PubK-Bob PubK-Issuer OP_4 OP_CHECKMULTSIG
Redeem script: OP_2 metadata1 metadata2 PubK-Alice PubK-Issuer OP_4 OP_CHECKMULTSIG

Transaction: Alice pays Bob $7.30 CAD
ID-110
Version number
3
ID-101
IDX-00
Script length
OP_0 Sig-Alice Sig-Issuer <2 metadata1 metadata2 PubK-Alice PubK-Issuer 4 OP_CHECKMULTSIG>
00000000000000000000000000000001
ID-102
IDX-00
Script length
OP_0 Sig-Alice Sig-Issuer <OP_2 metadata1 metadata2 PubK-Alice PubK-Issuer OP_4 OP_CHECKMULTSIG>
00000000000000000000000000000011
ID-103
IDX-00
Script length
Sig-Issuer PubK-Issuer
00000000000000000000000000000100
3
73,000
27,000
9,999,000
LockTime
Transaction-ID
Version number
Number of inputs
Prev Trans Output
Prev Trans Output index
Script length
ScriptSig
Sequence number
Prev Trans Output
Script length
ScriptSig
Sequence number
Prev Trans Output
Script length
ScriptSig
Sequence number
Number of outputs
Output value
Output script
Output value
Output script
Output value
Output script
LockTime
Transfer Example 1: description
Alice has an account in the Issuer's system. This is a 'closed' system, so all the coloured coin
transactions are managed by the Issuer's system. Because P2SH is being used, the underlying bitcoins
can only be spent using the 'redeem script'. This is public knowledge (i.e. is reconstructable from
publicly available information) but it still needs to be signed by the account holder (Alice) and the
Issuer. Therefore, the underlying bitcoins cannot 'accidentally' be spent as uncoloured.
In this example, Alice does not pay the miner's fee. Exactly how we will handle these fees, and how we
will pass the cost onto the client (i.e. Alice) is a business decision and there are several alternatives.
For the current case we have assumed the following:
1. Clients pay a membership fee for using the service and 'straightforward' transactions do not incur a
separate fee. ('Straightforward' needs to be acuurately defined, but it excludes, for example, FX
transactions for now).
2. The Issuer funds the transactions from a pool of uncoloured bitcoin
Output 0 and 1 are coloured coin transactions for the payment to Bob and the change back to Alice.
Their inputs were from coloured coins. Output 2 is uncoloured and originated from an uncoloured
output; it is the 'change' on spending some of the Issuer's bitcoin, so that an amount can be taken by
the miner for a fee. Miner's fee must always originate from an uncoloured coin and therefore will be
spent as unoloured by the system.
ID-201
50,000,000

Transaction: Issuance (minting): Bob receives $1000 CAD as coloured bitcoin
ID-210
Version number
1
ID-201
IDX-00
Script length
00000000000000000000000000000011
2
10,000,000
39,999,000
LockTime
Transaction-ID
Version number
Number of inputs
Prev Trans Output
Script length
ScriptSig
Sequence number
Number of outputs
Output value
Output script
Output value
Output script
LockTime
A standard issuance transaction may have several inputs (all uncoloured bitcoin payments to the
issuer) as necessary to make up the required amount, but will only have two outputs. Output0 is the
issuance of coloured coins directly to the payee; output1 is the change that comes back to the Issuer.
An alternative procedure would be to first mint the coins by making an Issuer-to-Issuer payment
converting uncoloured to coloured coins, and then a regular transfer of the coloured coins to the client
(i.e. issuer-to-client payment). The final procedure is TBD.
Either way, this transaction must be accompanied by a deposit of the fiat amount from Bob to the
Issuer, who will then deposit it into their 'Reserve' bank account.
The metadata indicates that the output is an issuance (thereby enforcing that the originating
transaction must not be coloured).
ID-210
10,000,000
ID-110
9,999,000
Transaction: Redemption: Bob cashes in his $1000 worth of coloured bitcoin (option 1)
ID-310
Version number
2
ID-210
IDX-00
Script length
OP_0 Sig-Bob Sig-Issuer <OP_2 metadata1 metadata2 PubK-Bob PubK-Issuer OP_4 OP_CHECKMULTISIG>
00000000000000000000000000000001
ID-110
IDX-02
Script length
00000000000000000000000000000010
2
10,000,000
9,998,000
LockTime
Transaction-ID
Version number
Number of inputs
Prev Trans Output
Script length
ScriptSig
Sequence number
Prev Trans Output
Script length
ScriptSig
Sequence number
Number of outputs
Output value
Output script
Output value
Output script
LockTime
In this version, the coloured coins are redeemed in one step by a payment from the payer back to the
issuer converting the coloured coin to uncoloured 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 fact that the
spender is spending a coloured output by using a P2PKH locking script paid to the Issuer.
ID-210
10,000,000
ID-110
9,999,000

ID-410
Version number
2
ID-210
IDX-00
Script length
Sig-Bob Sig-Issuer <2 metadata1 metadata2 PubK-Bob PubK-Issuer 4 OP_CHECKMULTSIG>
00000000000000000000000000000001
ID-110
IDX-02
Script length
00000000000000000000000000000010
2
10,000,000
9,998,000
LockTime
Transaction-ID
Version number
Number of inputs
Prev Trans Output
Script length
ScriptSig
Sequence number
Prev Trans Output
Script length
ScriptSig
Sequence number
Number of outputs
Output value
Output script
Output value
Output script
LockTime
In this option for a redemption, Bob pays his coloured coins back to the issuer as coloured coins and
gets his fiat amount returned to his nominated bank account. As this transaction has metadata in the
output it will contain TransactionType = '0x03' indicating that it is a redemption. But then the Issuer
needs to spend the coloured coin as a P2PKH transaction to themselves to uncolour the bitcoins in a
separate transaction. The disadvantage is that there is an extra miner's fee as there are two
transactions to accomplish the uncolouring process.
(The second spend transaction is not shown)

ID-210
10,000,000
ID-110
9,999,000
Redeem script: OP_1 metadata1 metadata2 PubK-Issuer OP_3 OP_CHECKMULTISIG

ID-510
Version number
2
ID-210
IDX-00
Script length
OP_0 Sig-Bob Sig-Issuer <OP_2 metadata1 metadata2 PubK-Bob PubK-Issuer OP_4 OP_CHECKMULTSIG>
00000000000000000000000000000001
ID-110
IDX-02
Script length
00000000000000000000000000000010
2
10,000,000
9,998,000
LockTime
Transaction-ID
Version number
Number of inputs
Prev Trans Output
Script length
ScriptSig
Sequence number
Prev Trans Output
Script length
ScriptSig
Sequence number
Number of outputs
Output value
Output script
Output value
Output script
LockTime
In this version, the coloured coins are redeemed in one step by a payment from the payer back to the
issuer converting the coloured coin to uncoloured by providing a P2SH script as the locking script,
which is specific to redemption (i.e. it is different to the regular P2SH for payments). In this case, there
is a TransactionType = '0x03' as there is a metadata field associated to the output. This fact signals that
it is a redemption transaction.
Then to spend this uncoloured output, the issuer will use the following SigScript:
Sig-Issuer <redeem script>
where redeem script is:
1 metadata1 metadata2 PubK-Issuer 3 OP_CHECKMULTSIG
As the TransactionType in the metadata = '0x03' (i.e. the originating output was a redemption) then
by definition this bitcoin is already uncoloured.
ContractPointer 16
Race Horse metadata format

Metadata1 ContractType 4 0x0000F001
ContractPointer 16
NumShares 2
PeggingRate 1
TransactionType 1

Sequence number 4

0x02
0x03
Comments
Comments
Indicates Race horse
e.g. 0x0064 indicates 100 shares
Coded value represents the BTC/share pegging rate.
Spare bytes
Spare bytes
Comments
Comments
Contract names the Race Horse and details of the ownership rules, etc.

1 = rate expressed as Satoshis/share
0 = rate expressed as Share/Satoshi
Examples:
100000102 means rate of 100 satoshis/share (flag is on)
000000002 means rate of 1 share/satoshi (flag is off)
000000012 means rate of 10 shares/satoshi (flag is off)

EXCEPTIONS:
ContractPointer 16
Concert Ticket metadata format

Metadata1 ContractType 4 0x0000F0D1
ContractPointer 16
NumShares 2 0x0001
PeggingRate 1 000000002
TransactionType 1

Sequence number 4

0x02
0x03
Comments
Comments
Indicates Concert Ticket
Indicates exactly 1 share - i.e. this token is not divisible
Coded value represents the BTC/share (for non-divisible tokens always 1/1)
Spare bytes
Spare bytes
Comments
Comments
Contract specifies performer, venue, date… and other ticket details

1 = rate expressed as Satoshis/share
0 = rate expressed as Share/Satoshi
Examples:
100000102 means rate of 100 satoshis/share (flag is on)
000000002 means rate of 1 share/satoshi (flag is off)
000000012 means rate of 10 shares/satoshi (flag is off)

EXCEPTIONS:

Coloured Coins Bitcoin Transactions v5

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Coloured Coins Bitcoin Transactions v5

Uploaded by

Copyright:

Available Formats

Transaction A Transaction B

Version number Version number

Fiat Currency metadata format

Field Sub-field Bytes Value

Field Sub-field Bytes Value

Validity check as follows:

Redeem script: OP_2 metadata1 metadata2 PubK-Bob PubK-Issuer OP_4 OP_CHECKMULTSIG

Redeem script: OP_2 metadata1 metadata2 PubK-Alice PubK-Issuer OP_4 OP_CHECKMULTSIG

Redeem script: OP_2 metadata1 metadata2 PubK-Bob PubK-Issuer OP_4 OP_CHECKMULTSIG

Redeem script: OP_2 metadata1 metadata2 PubK-Bob PubK-Issuer OP_4 OP_CHECKMULTSIG

(The second spend transaction is not shown)

Redeem script: OP_1 metadata1 metadata2 PubK-Issuer OP_3 OP_CHECKMULTISIG

Sig-Issuer <redeem script>

where redeem script is:

1 metadata1 metadata2 PubK-Issuer 3 OP_CHECKMULTSIG

Race Horse metadata format

Field Sub-field Bytes Value

Field Sub-field Bytes Value

To minimise the bytes needed, the rule is as follows:

Validity check as follows:

Concert Ticket metadata format

Field Sub-field Bytes Value

Field Sub-field Bytes Value

To minimise the bytes needed, the rule is as follows:

Validity check as follows:

You might also like