You are on page 1of 30

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
ContractTypeData2 12

Fiat Currency metadata format


Field Sub-field Bytes Value
Metadata1 ContractType 4 0x00000001
ContractPointer 16
FiatDenomination 2
PeggingRate 1
TransactionType 1
Padding 8 0x00000…
Metadata2 ContractHash 20
Padding 12 0x00000…

Field Sub-field Bytes Value


Sequence number 4

Field Sub-field Bytes Value


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))
Format depends on value of ContractType. Padded with zeros

Comments
Indicates Fiat Currency
IPv6 address of the actual contract file location
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
Output script length
OP_HASH160 <redeem script hash> OP_EQUAL

ID-103
10,000,000
Output script length
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
Output script length
OP_HASH160 <redeem script hash> OP_EQUAL
27,000
Output script length
OP_HASH160 <redeem script hash> OP_EQUAL
9,999,000
Output script length
OP_DUP OP_HASH160 <PubK-Issuer hash> OP_EQUALVERIFY OP_CHECKSIG
LockTime
Transaction-ID
Version number
Number of inputs
Prev Trans Output
Prev Trans Output index
Script length
ScriptSig
Sequence number
Prev Trans Output
Prev Trans Output index
Script length
ScriptSig
Sequence number
Prev Trans Output
Prev Trans Output index
Script length
ScriptSig
Sequence number
Number of outputs
Output value
Output script length
Output script
Output value
Output script length
Output script
Output value
Output script length
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.
Originating transactions (transaction-id / Satoshis amount / script length / locking script)
ID-201
50,000,000
Output script length
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


Transaction: Issuance (minting): Bob receives $1000 CAD as coloured bitcoin
ID-210
Version number
1
ID-201
IDX-00
Script length
Sig-Issuer PubK-Issuer
00000000000000000000000000000011
2
10,000,000
Output script length
OP_HASH160 <redeem script hash> OP_EQUAL
39,999,000
Output script length
OP_DUP OP_HASH160 <PubK-Issuer hash> OP_EQUALVERIFY OP_CHECKSIG
LockTime
Transaction-ID
Version number
Number of inputs
Prev Trans Output
Prev Trans Output index
Script length
ScriptSig
Sequence number
Number of outputs
Output value
Output script length
Output script
Output value
Output script length
Output script
LockTime
Transfer Example 2: description
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).
Originating transactions (transaction-id / Satoshis amount / script length / locking script)
ID-210
10,000,000
Output script length
OP_HASH160 <redeem script hash> OP_EQUAL

ID-110
9,999,000
Output script length
OP_DUP OP_HASH160 <PubK-Issuer hash> OP_EQUALVERIFY OP_CHECKSIG
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
Sig-Issuer PubK-Issuer
00000000000000000000000000000010
2
10,000,000
Output script length
OP_DUP OP_HASH160 <PubK-Issuer hash> OP_EQUALVERIFY OP_CHECKSIG
9,998,000
Output script length
OP_DUP OP_HASH160 <PubK-Issuer hash> OP_EQUALVERIFY OP_CHECKSIG
LockTime
Transaction-ID
Version number
Number of inputs
Prev Trans Output
Prev Trans Output index
Script length
ScriptSig
Sequence number
Prev Trans Output
Prev Trans Output index
Script length
ScriptSig
Sequence number
Number of outputs
Output value
Output script length
Output script
Output value
Output script length
Output script
LockTime
Transfer Example 3: description
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.
Originating transactions (transaction-id / Satoshis amount / script length / locking script)
ID-210
10,000,000
Output script length
OP_HASH160 <redeem script hash> OP_EQUAL

ID-110
9,999,000
Output script length
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


Transaction: Redemption: Bob cashes in his $1000 worth of coloured bitcoin (option 2)
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
Sig-Issuer PubK-Issuer
00000000000000000000000000000010
2
10,000,000
Output script length
OP_HASH160 <redeem script hash> OP_EQUAL
9,998,000
Output script length
OP_DUP OP_HASH160 <PubK-Issuer hash> OP_EQUALVERIFY OP_CHECKSIG
LockTime
Transaction-ID
Version number
Number of inputs
Prev Trans Output
Prev Trans Output index
Script length
ScriptSig
Sequence number
Prev Trans Output
Prev Trans Output index
Script length
ScriptSig
Sequence number
Number of outputs
Output value
Output script length
Output script
Output value
Output script length
Output script
LockTime
Transfer Example 4: description
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)


Originating transactions (transaction-id / Satoshis amount / script length / locking script)
ID-210
10,000,000
Output script length
OP_HASH160 <redeem script hash> OP_EQUAL

ID-110
9,999,000
Output script length
OP_DUP OP_HASH160 <PubK-Issuer hash> OP_EQUALVERIFY OP_CHECKSIG

Redeem script: OP_1 metadata1 metadata2 PubK-Issuer OP_3 OP_CHECKMULTISIG


Transaction: Redemption: Bob cashes in his $1000 worth of coloured bitcoin (option 3)
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
Sig-Issuer PubK-Issuer
00000000000000000000000000000010
2
10,000,000
Output script length
OP_HASH160 <redeem script hash> OP_EQUAL
9,998,000
Output script length
OP_DUP OP_HASH160 <PubK-Issuer hash> OP_EQUALVERIFY OP_CHECKSIG
LockTime
Transaction-ID
Version number
Number of inputs
Prev Trans Output
Prev Trans Output index
Script length
ScriptSig
Sequence number
Prev Trans Output
Prev Trans Output index
Script length
ScriptSig
Sequence number
Number of outputs
Output value
Output script length
Output script
Output value
Output script length
Output script
LockTime
Transfer Example 5: description
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.
Generic Contract metadata format
Field Sub-field Bytes Value
Metadata1 ContractType 4
ContractPointer 16
ContractTypeData1 12
Metadata2 ContractHash 20
ContractTypeData2 12

Race Horse metadata format


Field Sub-field Bytes Value
Metadata1 ContractType 4 0x0000F001
ContractPointer 16
NumShares 2
PeggingRate 1
TransactionType 1
Padding 8 0x00000…
Metadata2 ContractHash 20
Padding 12 0x00000…

Field Sub-field Bytes Value


Sequence number 4

Field Sub-field Bytes Value


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))
Format depends on value of ContractType. Padded with zeros

Comments
Indicates Race horse
IPv6 address of the actual contract file location
e.g. 0x0064 indicates 100 shares
Coded value represents the BTC/share 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)
Contract names the Race Horse and details of the ownership rules, etc.

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


One bit will be used as a flag:
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)

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)
Generic Contract metadata format
Field Sub-field Bytes Value
Metadata1 ContractType 4
ContractPointer 16
ContractTypeData1 12
Metadata2 ContractHash 20
ContractTypeData2 12

Concert Ticket metadata format


Field Sub-field Bytes Value
Metadata1 ContractType 4 0x0000F0D1
ContractPointer 16
NumShares 2 0x0001
PeggingRate 1 000000002
TransactionType 1
Padding 8 0x00000…
Metadata2 ContractHash 20
Padding 12 0x00000…

Field Sub-field Bytes Value


Sequence number 4

Field Sub-field Bytes Value


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))
Format depends on value of ContractType. Padded with zeros

Comments
Indicates Concert Ticket
IPv6 address of the actual contract file location
Indicates exactly 1 share - i.e. this token is not divisible
Coded value represents the BTC/share (for non-divisible tokens always 1/1)
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)
Contract specifies performer, venue, date… and other ticket details

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


One bit will be used as a flag:
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)

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)