From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 788698CC for ; Thu, 26 May 2016 02:50:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E6136177 for ; Thu, 26 May 2016 02:50:46 +0000 (UTC) Received: by mail-qg0-f48.google.com with SMTP id e93so31918089qgf.2 for ; Wed, 25 May 2016 19:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=qpTdij97ZHYOCIuXaV3Fx1QluDJXuLNevZZjr1UVJto=; b=0cUkM5uxH+LXoipbaQsB26o40DwXwi7sPze+VZOxynWth5IbVisCoc9mZin9hbl/WW +ZnEj3VfEMYXznhnavz6ZyZv0F5p8PsZ9Gy9+QmHovcUd6ypVBsFMXzyNzcJPRcrJX04 oUr/9BrNK5IPQzp8JAS0j3dLs6S8VB6WM/RG1oZm48ezulbCF5h5yxR5gWwGnEJUS+iL y6JYnCJ+o4zdy+uhhAmShx8/YupXfHAl/aOQeTlkTv62wxN9dpcOqNTv/IbcnRIDX6c0 lROplkRgmfLFo68fu/afgHNJoHfHf2PFN4bZEJvtnjllnYm8kg5kvrFDuyrCfYkMgJST BABw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=qpTdij97ZHYOCIuXaV3Fx1QluDJXuLNevZZjr1UVJto=; b=KO42t7IttXsZLyBrzuRL+DnKdMOpaAct0YtWFbRJFAXBvk9WuGLxJoMiqqOKtTeOak w9OXiy8PQKXL5TBTsBUxLLU2wXkNqeeDi5xnSFEl+vV/aKZFAd9qWbi2VTNfV34G6fuE jft1JS1B7A4pzfZF9VkaYb6G2PwTujp97LjHpZvRP0XvGB4T9Bv1mfkflZD9Z+Qeij4C Wl9PykznMcbsXOBIBWPYRNbCZi/nlrMifDuqvpa8h71u4WY931bhkcjxf22vsDI+0EGR vCpuxj0qeZzou6no6wxLRPmuyJMnvgmIHRroH6JN42sbntNiUIWjzAUQg+ZPOR18VPP8 ROmg== X-Gm-Message-State: ALyK8tLmxsCGV8QqSftC8dI5hqqTqb6OTqoFPl7prKl5egDoZVvwR16gZSvW3x65M2IFoacR0A9mCzp9JF44dg== X-Received: by 10.140.167.130 with SMTP id n124mr7084303qhn.23.1464231045694; Wed, 25 May 2016 19:50:45 -0700 (PDT) MIME-Version: 1.0 Sender: slashene@gmail.com Received: by 10.55.92.7 with HTTP; Wed, 25 May 2016 19:50:26 -0700 (PDT) From: Nicolas Dorier Date: Thu, 26 May 2016 11:50:26 +0900 X-Google-Sender-Auth: VCH3C99pSAPgBV4vDiOzXNR0Z2w Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a113a48c2590a610533b5dbb0 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] BIP Number Request: Open Asset X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 02:50:49 -0000 --001a113a48c2590a610533b5dbb0 Content-Type: text/plain; charset=UTF-8 Open Asset is a simple and well known colored coin protocol made by Flavien Charlon, which has been around for more than two years ago. Open Asset is OP_RETURN to store coin's color. Since then, the only modification to the protocol has been for allowing OA data to be into any push into an OP_RETURN. The protocol is here: https://github.com/OpenAssets/open-assets-protocol/blob/master/specification.mediawiki I asked to Flavien Charlon if he was OK if I submit the protocol to the mailing list before posting. Additional BIP number might be required to cover for example the "colored address" format: https://github.com/OpenAssets/open-assets-protocol/blob/master/address-format.mediawiki But I will do it in a separate request. Here is the core of the Open Asset specification: 
  Title: Open Assets Protocol (OAP/1.0)
  Author: Flavien Charlon 
  Created: 2013-12-12
==Abstract== This document describes a protocol used for storing and transferring custom, non-native assets on the Blockchain. Assets are represented by tokens called colored coins. An issuer would first issue colored coins and associate them with a formal or informal promise that he will redeem the coins according to terms he has defined. Colored coins can then be transferred using transactions that preserve the quantity of every asset. ==Motivation== In the current Bitcoin implementation, outputs represent a quantity of Bitcoin, secured by an output script. With the Open Assets Protocol, outputs can encapsulate a quantity of a user-defined asset on top of that Bitcoin amount. There are many applications: * A company could issue colored coins representing shares. The shares could then be traded frictionlessly through the Bitcoin infrastructure. * A bank could issue colored coins backed by a cash reserve. People could withdraw and deposit money in colored coins, and trade those, or use them to pay for goods and services. The Blockchain becomes a system allowing to transact not only in Bitcoin, but in any currency. * Locks on cars or houses could be associated with a particular type of colored coins. The door would only open when presented with a wallet containing that specific coin. ==Protocol Overview== Outputs using the Open Assets Protocol to store an asset have two new characteristics: * The '''asset ID''' is a 160 bits hash, used to uniquely identify the asset stored on the output. * The '''asset quantity''' is an unsigned integer representing how many units of that asset are stored on the output. This document describes how the asset ID and asset quantity of an output are calculated. Each output in the Blockchain can be either colored or uncolored: * Uncolored outputs have no asset ID and no asset quantity (they are both undefined). * Colored outputs have a strictly positive asset quantity, and a non-null asset ID. The ID of an asset is the RIPEMD-160 hash of the SHA-256 hash of the output script referenced by the first input of the transaction that initially issued that asset (script_hash = RIPEMD160(SHA256(script))). An issuer can reissue more of an already existing asset as long as they retain the private key for that asset ID. Assets on two different outputs can only be mixed together if they have the same asset ID. Like addresses, asset IDs can be represented in base 58. They must use version byte 23 (115 in TestNet3) when represented in base 58. The base 58 representation of an asset ID therefore starts with the character 'A' in MainNet. The process to generate an asset ID and the matching private key is described in the following example: # The issuer first generates a private key: 18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725. # He calculates the corresponding address: 16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM. # Next, he builds the Pay-to-PubKey-Hash script associated to that address: OP_DUP OP_HASH160 010966776006953D5567439E5E39F86A0D273BEE OP_EQUALVERIFY OP_CHECKSIG. # The script is hashed: 36e0ea8e93eaa0285d641305f4c81e563aa570a2 # Finally, the hash is converted to a base 58 string with checksum using version byte 23: ALn3aK1fSuG27N96UGYB1kUYUpGKRhBuBC. The private key from the first step is required to issue assets identified by the asset ID ALn3aK1fSuG27N96UGYB1kUYUpGKRhBuBC. This acts as a digital signature, and gives the guarantee that nobody else but the original issuer is able to issue assets identified by this specific asset ID. ==Open Assets Transactions== Transactions relevant to the Open Assets Protocol must have a special output called the marker output. This allows clients to recognize such transactions. Open Assets transactions can be used to issue new assets, or transfer ownership of assets. Transactions that are not recognized as an Open Assets transaction are considered as having all their outputs uncolored. ===Marker output=== The marker output can have a zero or non-zero value. The marker output starts with the OP_RETURN opcode, and can be followed by any sequence of opcodes, but it must contain a PUSHDATA opcode containing a parsable Open Assets marker payload. If multiple parsable PUSHDATA opcodes exist in the same output, the first one is used, and the other ones are ignored. If multiple valid marker outputs exist in the same transaction, the first one is used and the other ones are considered as regular outputs. If no valid marker output exists in the transaction, all outputs are considered uncolored. The payload as defined by the Open Assets protocol has the following format: {| ! Field !! Description !! Size |- ! OAP Marker || A tag indicating that this transaction is an Open Assets transaction. It is always 0x4f41. || 2 bytes |- ! Version number || The major revision number of the Open Assets Protocol. For this version, it is 1 (0x0100). || 2 bytes |- ! Asset quantity count || A [https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer var-integer] representing the number of items in the asset quantity list field. || 1-9 bytes |- ! Asset quantity list || A list of zero or more [http://en.wikipedia.org/wiki/LEB128 LEB128-encoded] unsigned integers representing the asset quantity of every output in order (excluding the marker output). || Variable |- ! Metadata length || The [https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer var-integer] encoded length of the metadata field. || 1-9 bytes |- ! Metadata || Arbitrary metadata to be associated with this transaction. This can be empty. || Variable |} Possible formats for the metadata field are outside of scope of this protocol, and may be described in separate protocol specifications building on top of this one. The asset quantity list field is used to determine the asset quantity of each output. Each integer is encoded using variable length [http://en.wikipedia.org/wiki/LEB128 LEB128] encoding (also used in [https://developers.google.com/protocol-buffers/docs/encoding#varints Google Protocol Buffers]). If the LEB128-encoded asset quantity of any output exceeds 9 bytes, the marker output is deemed invalid. The maximum valid asset quantity for an output is 263 - 1 units. If the marker output is malformed, it is considered non-parsable. Coinbase transactions and transactions with zero inputs cannot have a valid marker output, even if it would be otherwise considered valid. If there are less items in the asset quantity list than the number of colorable outputs (all the outputs except the marker output), the outputs in excess receive an asset quantity of zero. If there are more items in the asset quantity list than the number of colorable outputs, the marker output is deemed invalid. The marker output is always uncolored. After the asset quantity list has been used to assign an asset quantity to every output, asset IDs are assigned to outputs. Outputs before the marker output are used for asset issuance, and outputs after the marker output are used for asset transfer. ====Example==== This example illustrates how a marker output is decoded. Assuming the marker output is output 1: Data in the marker output Description ----------------------------- ------------------------------------------------------------------- 0x6a The OP_RETURN opcode. 0x10 The PUSHDATA opcode for a 16 bytes payload. 0x4f 0x41 The Open Assets Protocol tag. 0x01 0x00 Version 1 of the protocol. 0x03 There are 3 items in the asset quantity list. 0xac 0x02 0x00 0xe5 0x8e 0x26 The asset quantity list: - '0xac 0x02' means output 0 has an asset quantity of 300. - Output 1 is skipped and has an asset quantity of 0 because it is the marker output. - '0x00' means output 2 has an asset quantity of 0. - '0xe5 0x8e 0x26' means output 3 has an asset quantity of 624,485. - Outputs after output 3 (if any) have an asset quantity of 0. 0x04 The metadata is 4 bytes long. 0x12 0x34 0x56 0x78 Some arbitrary metadata. ===Asset issuance outputs=== All the outputs before the marker output are used for asset issuance. All outputs preceding the marker output and with a non-zero asset quantity get assigned the asset ID defined as the RIPEMD-160 hash of the SHA-256 hash of the output script referenced by the first input of the transaction. Outputs that have an asset quantity of zero are uncolored. ===Asset transfer outputs=== All the outputs after the marker output are used for asset transfer. The asset IDs of those outputs are determined using a method called order-based coloring. Inputs are seen as a sequence of asset units, each having an asset ID. Similarly, outputs are seen as a sequence of asset units to be assigned an asset ID. These two sequences are built by taking each input or output in order, each of them adding a number of asset units equal to their asset quantity. The process starts with the first input of the transaction and the first output after the marker output. After the sequences have been built, the asset ID of every asset unit in the input sequence is assigned to the asset unit at the same position in the output sequence until all the asset units in the output sequence have received an asset ID. If there are less asset units in the input sequence than in the output sequence, the marker output is considered invalid. Finally, for each transfer output, if the asset units forming that output all have the same asset ID, the output gets assigned that asset ID. If any output is mixing units with more than one distinct asset ID, the marker output is considered invalid. Outputs with an asset quantity of zero are always considered uncolored. ===Example=== This is an example of an Open Assets transaction. The coloring process starts by retrieving the asset quantities and asset IDs of the outputs referenced by each input of the transaction. Then, the marker output is identified. In this example, it is output 2, and the asset quantity list field contains the following values: 0, 10, 6, 0, 7, 3 This list is used to assign asset quantities to outputs. Inputs Outputs - Initial state Outputs - Final result ============================= ============================= ============================= Input 0 Output 0 (Issuance) Output 0 (Issuance) Asset quantity: 3 Asset quantity: 0 Asset quantity: Asset ID: A1 Asset ID: Asset ID: ----------------------------- ----------------------------- ----------------------------- Input 1 Output 1 (Issuance) Output 1 (Issuance) Asset quantity: 2 Asset quantity: 10 Asset quantity: 10 Asset ID: A1 Asset ID: Asset ID: H ----------------------------- ----------------------------- ----------------------------- Input 2 Output 2 (Marker) Output 2 (Marker) Asset quantity: Asset quantity: Asset quantity: Asset ID: Asset ID: Asset ID: ----------------------------- ----------------------------- ----------------------------- Input 3 Output 3 (Transfer) Output 3 (Transfer) Asset quantity: 5 Asset quantity: 6 Asset quantity: 6 Asset ID: A1 Asset ID: Asset ID: A1 ----------------------------- ----------------------------- ----------------------------- Input 4 Output 4 (Transfer) Output 4 (Transfer) Asset quantity: 3 Asset quantity: 0 Asset quantity: Asset ID: A1 Asset ID: Asset ID: ----------------------------- ----------------------------- ----------------------------- Input 5 Output 5 (Transfer) Output 5 (Transfer) Asset quantity: 9 Asset quantity: 7 Asset quantity: 7 Asset ID: A2 Asset ID: Asset ID: A1 ============================= ----------------------------- ----------------------------- Output 6 (Transfer) Output 6 (Transfer) Asset quantity: 3 Asset quantity: 3 Asset ID: Asset ID: A2 ============================= ============================= Outputs are colored from the first to the last. Outputs before the marker output are issuance outputs: * Output 0 has an asset quantity of zero, so it is considered uncolored. * Output 1 gets assigned the asset ID defined by H = RIPEMD160(SHA256((S)) where S is the output script referenced by the first input of the transaction (input 0). Output 2 is the marker output, separating issuance outputs from transfer outputs. The marker output is always uncolored. Transfer outputs are then colored: * Output 3 receives 3 units from input 0, 2 units from input 1, 0 unit from input 2 and 1 unit from input 3. All the 6 units have the same asset ID A1, so the asset ID A1 is assigned to output 3. * Output 4 has an asset quantity of zero, so it is considered uncolored. * Output 5 receives the remaining 4 units of input 3, and 3 units from input 4. All the 7 units have the same asset ID A1, so the asset ID A1 is assigned to output 5. * Output 6 receives the first 3 units of input 5. Input 5 has the asset ID A2 so the asset ID A2 is assigned to output 6. ==Rationale== This approach offers a number of desirable characteristics: # Economical: The cost of issuing or transferring an asset is completely independent from the quantity issued or transferred. # Clients have a way to identify colored outputs simply by traversing the Blockchain, without needing to be fed external data. Transactions relevant to the Open Assets Protocol are identified by the special marker output. # It is possible to determine the asset ID and asset quantity of an output by traversing only a limited number of transactions. # Assets are pseudonymous. They are represented by an asset ID, which is enough to identify each asset uniquely, while still providing an adequate level of anonymity for both the issuer and users of the asset. # This approach uses the recommended way to embed data in the Blockchain (OP_RETURN), and therefore does not pollute the UTXO. # The whole cryptographic infrastructure that Bitcoin provides for securing the spending of outputs is reused for securing the ability to issue assets. There is a symmetry between ''an address + private key'' as a way to spend Bitcoins, and ''an address + private key'' as a way to issue assets. # Generating a new type of asset is as simple as generating an address, can be done offline, and for free. # Reissuing more of an existing asset is easy and can be done quickly and at no cost (except for the transaction fee) as long as the issuer retains the private key for the asset ID. # Single-issuance assets can be achieved by destroying the private key used to issue the asset immediately after issuing it. # Since issuance is based on standard Bitcoin output scripts, it is possible to create an asset that requires multiple signatures for issuance. ==Compatibility== For backward compatibility reasons, we consider than an older client is allowed to see a colored output as uncolored. ===Backward compatibility with existing Bitcoin protocol=== The Open Assets Protocol sits on top of the Bitcoin protocol. It does not require any change to the existing Bitcoin protocol. Existing clients that don't support the Open Assets Protocol will see all outputs as uncolored, and will not be able to perform transfer transactions. ===Compatibility between different versions of OAP=== New versions with the same major version number (e.g. 1.1) should be backwards compatible. New versions with a different major version number (e.g. 2.0) can introduce breaking changes, but transactions created by newer clients will be identifiable by a different version number in the output 0 of genesis and transfer transactions. ==Copyright== This document has been placed in the public domain. Nicolas Dorier, --001a113a48c2590a610533b5dbb0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Open Asset is a simple and well known colored coin protoco= l made by Flavien Charlon, which has been around for more than two years ag= o.
Open Asset is OP_RETURN to store coin's color. Since then, the o= nly modification to the protocol has been for allowing OA data to be into a= ny push into an OP_RETURN.


I asked= to Flavien Charlon if he was OK if I submit the protocol to the mailing li= st before posting.

Additional BIP number might be = required to cover for example the "colored address" format:=C2=A0= https://github.com/OpenAssets/open-assets-protocol= /blob/master/address-format.mediawiki
But I will do it in a s= eparate request.

Here is the core of the Open Asse= t specification:
<pre>
  Title: Open Assets Protocol (OAP/1.0)
  Author: Flavien Charlon <flavie=
n@charlon.net>
  Created: 2013-12-12
</pre>

=3D=3DAbstract=3D=3D

This document describes a protocol used for storing and transferring custom=
, non-native assets on the Blockchain. Assets are represented by tokens cal=
led colored coins.

An issuer would first issue colored coins and associate them with a formal =
or informal promise that he will redeem the coins according to terms he has=
 defined. Colored coins can then be transferred using transactions that pre=
serve the quantity of every asset.

=3D=3DMotivation=3D=3D

In the current Bitcoin implementation, outputs represent a quantity of Bitc=
oin, secured by an output script. With the Open Assets Protocol, outputs ca=
n encapsulate a quantity of a user-defined asset on top of that Bitcoin amo=
unt.

There are many applications:

* A company could issue colored coins representing shares. The shares could=
 then be traded frictionlessly through the Bitcoin infrastructure.
* A bank could issue colored coins backed by a cash reserve. People could w=
ithdraw and deposit money in colored coins, and trade those, or use them to=
 pay for goods and services. The Blockchain becomes a system allowing to tr=
ansact not only in Bitcoin, but in any currency.
* Locks on cars or houses could be associated with a particular type of col=
ored coins. The door would only open when presented with a wallet containin=
g that specific coin.

=3D=3DProtocol Overview=3D=3D

Outputs using the Open Assets Protocol to store an asset have two new chara=
cteristics:
* The '''asset ID''' is a 160 bits hash, used to un=
iquely identify the asset stored on the output.
* The '''asset quantity''' is an unsigned integer r=
epresenting how many units of that asset are stored on the output.

This document describes how the asset ID and asset quantity of an output ar=
e calculated.

Each output in the Blockchain can be either colored or uncolored:
* Uncolored outputs have no asset ID and no asset quantity (they are both u=
ndefined).
* Colored outputs have a strictly positive asset quantity, and a non-null a=
sset ID.

The ID of an asset is the RIPEMD-160 hash of the SHA-256 hash of the output=
 script referenced by the first input of the transaction that initially iss=
ued that asset (<code>script_hash =3D RIPEMD160(SHA256(script))</c=
ode>). An issuer can reissue more of an already existing asset as long a=
s they retain the private key for that asset ID. Assets on two different ou=
tputs can only be mixed together if they have the same asset ID.

Like addresses, asset IDs can be represented in base 58. They must use vers=
ion byte 23 (115 in TestNet3) when represented in base 58. The base 58 repr=
esentation of an asset ID therefore starts with the character 'A' i=
n MainNet.

The process to generate an asset ID and the matching private key is describ=
ed in the following example:
# The issuer first generates a private key: <code>18E14A7B6A307F426A9=
4F8114701E7C8E774E7F9A47E2C2035DB29A206321725</code>.
# He calculates the corresponding address: <code>16UwLL9Risc3QfPqBUvK=
ofHmBQ7wMtjvM</code>.
# Next, he builds the Pay-to-PubKey-Hash script associated to that address:=
 <code>OP_DUP OP_HASH160 010966776006953D5567439E5E39F86A0D273BEE OP_=
EQUALVERIFY OP_CHECKSIG</code>.
# The script is hashed: <code>36e0ea8e93eaa0285d641305f4c81e563aa570a=
2</code>
# Finally, the hash is converted to a base 58 string with checksum using ve=
rsion byte 23: <code>ALn3aK1fSuG27N96UGYB1kUYUpGKRhBuBC</code>.

The private key from the first step is required to issue assets identified =
by the asset ID <code>ALn3aK1fSuG27N96UGYB1kUYUpGKRhBuBC</code>=
. This acts as a digital signature, and gives the guarantee that nobody els=
e but the original issuer is able to issue assets identified by this specif=
ic asset ID.

=3D=3DOpen Assets Transactions=3D=3D

Transactions relevant to the Open Assets Protocol must have a special outpu=
t called the marker output. This allows clients to recognize such transacti=
ons. Open Assets transactions can be used to issue new assets, or transfer =
ownership of assets.

Transactions that are not recognized as an Open Assets transaction are cons=
idered as having all their outputs uncolored.

=3D=3D=3DMarker output=3D=3D=3D

The marker output can have a zero or non-zero value. The marker output star=
ts with the OP_RETURN opcode, and can be followed by any sequence of opcode=
s, but it must contain a PUSHDATA opcode containing a parsable Open Assets =
marker payload. If multiple parsable PUSHDATA opcodes exist in the same out=
put, the first one is used, and the other ones are ignored.

If multiple valid marker outputs exist in the same transaction, the first o=
ne is used and the other ones are considered as regular outputs. If no vali=
d marker output exists in the transaction, all outputs are considered uncol=
ored.

The payload as defined by the Open Assets protocol has the following format=
:

{|
! Field                !! Description !! Size
|-
! OAP Marker           || A tag indicating that this transaction is an Open=
 Assets transaction. It is always 0x4f41. || 2 bytes
|-
! Version number       || The major revision number of the Open Assets Prot=
ocol. For this version, it is 1 (0x0100). || 2 bytes
|-
! Asset quantity count || A [https://en.bitcoin.it/wiki/Protocol=
_specification#Variable_length_integer var-integer] representing the nu=
mber of items in the <code>asset quantity list</code> field. ||=
 1-9 bytes
|-
! Asset quantity list  || A list of zero or more [http://en.wikipedia.org/wiki/LEB128 LEB128-encod=
ed] unsigned integers representing the asset quantity of every output in or=
der (excluding the marker output). || Variable
|-
! Metadata length      || The [https://en.bitcoin.it/wiki/Protoc=
ol_specification#Variable_length_integer var-integer] encoded length of=
 the <code>metadata</code> field. || 1-9 bytes
|-
! Metadata             || Arbitrary metadata to be associated with this tra=
nsaction. This can be empty. || Variable
|}

Possible formats for the <code>metadata</code> field are outsid=
e of scope of this protocol, and may be described in separate protocol spec=
ifications building on top of this one.

The <code>asset quantity list</code> field is used to determine=
 the asset quantity of each output. Each integer is encoded using variable =
length [http://en.wikipedia=
.org/wiki/LEB128 LEB128] encoding (also used in [https://develope=
rs.google.com/protocol-buffers/docs/encoding#varints Google Protocol Bu=
ffers]). If the LEB128-encoded asset quantity of any output exceeds 9 bytes=
, the marker output is deemed invalid. The maximum valid asset quantity for=
 an output is 2<sup>63</sup> - 1 units.

If the marker output is malformed, it is considered non-parsable. Coinbase =
transactions and transactions with zero inputs cannot have a valid marker o=
utput, even if it would be otherwise considered valid.

If there are less items in the <code>asset quantity list</code>=
 than the number of colorable outputs (all the outputs except the marker ou=
tput), the outputs in excess receive an asset quantity of zero. If there ar=
e more items in the <code>asset quantity list</code> than the n=
umber of colorable outputs, the marker output is deemed invalid. The marker=
 output is always uncolored.

After the <code>asset quantity list</code> has been used to ass=
ign an asset quantity to every output, asset IDs are assigned to outputs. O=
utputs before the marker output are used for asset issuance, and outputs af=
ter the marker output are used for asset transfer.

=3D=3D=3D=3DExample=3D=3D=3D=3D

This example illustrates how a marker output is decoded. Assuming the marke=
r output is output 1:

    Data in the marker output      Description
    -----------------------------  ----------------------------------------=
---------------------------
    0x6a                           The OP_RETURN opcode.
    0x10                           The PUSHDATA opcode for a 16 bytes paylo=
ad.
    0x4f 0x41                      The Open Assets Protocol tag.
    0x01 0x00                      Version 1 of the protocol.
    0x03                           There are 3 items in the asset quantity =
list.
    0xac 0x02 0x00 0xe5 0x8e 0x26  The asset quantity list:
                                   - '0xac 0x02' means output 0 has=
 an asset quantity of 300.
                                   - Output 1 is skipped and has an asset q=
uantity of 0
                                     because it is the marker output.
                                   - '0x00' means output 2 has an a=
sset quantity of 0.
                                   - '0xe5 0x8e 0x26' means output =
3 has an asset quantity of 624,485.
                                   - Outputs after output 3 (if any) have a=
n asset quantity of 0.
    0x04                           The metadata is 4 bytes long.
    0x12 0x34 0x56 0x78            Some arbitrary metadata.

=3D=3D=3DAsset issuance outputs=3D=3D=3D

All the outputs before the marker output are used for asset issuance.

All outputs preceding the marker output and with a non-zero asset quantity =
get assigned the asset ID defined as the RIPEMD-160 hash of the SHA-256 has=
h of the output script referenced by the first input of the transaction. Ou=
tputs that have an asset quantity of zero are uncolored.

=3D=3D=3DAsset transfer outputs=3D=3D=3D

All the outputs after the marker output are used for asset transfer.

The asset IDs of those outputs are determined using a method called order-b=
ased coloring.

Inputs are seen as a sequence of asset units, each having an asset ID. Simi=
larly, outputs are seen as a sequence of asset units to be assigned an asse=
t ID. These two sequences are built by taking each input or output in order=
, each of them adding a number of asset units equal to their asset quantity=
. The process starts with the first input of the transaction and the first =
output after the marker output.

After the sequences have been built, the asset ID of every asset unit in th=
e input sequence is assigned to the asset unit at the same position in the =
output sequence until all the asset units in the output sequence have recei=
ved an asset ID. If there are less asset units in the input sequence than i=
n the output sequence, the marker output is considered invalid.

Finally, for each transfer output, if the asset units forming that output a=
ll have the same asset ID, the output gets assigned that asset ID. If any o=
utput is mixing units with more than one distinct asset ID, the marker outp=
ut is considered invalid. Outputs with an asset quantity of zero are always=
 considered uncolored.

=3D=3D=3DExample=3D=3D=3D

This is an example of an Open Assets transaction.

The coloring process starts by retrieving the asset quantities and asset ID=
s of the outputs referenced by each input of the transaction. Then, the mar=
ker output is identified. In this example, it is output 2, and the <code=
>asset quantity list</code> field contains the following values:

    0, 10, 6, 0, 7, 3

This list is used to assign asset quantities to outputs.


    Inputs                          Outputs - Initial state        Outputs =
- Final result
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D   =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D  =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    Input 0                         Output 0 (Issuance)            Output 0=
 (Issuance)
      Asset quantity:     3           Asset quantity:     0          Asset =
quantity:     <NULL>
      Asset ID:           A1          Asset ID:                      Asset =
ID:           <NULL>
    -----------------------------   -----------------------------  --------=
---------------------
    Input 1                         Output 1 (Issuance)            Output 1=
 (Issuance)
      Asset quantity:     2           Asset quantity:     10         Asset =
quantity:     10
      Asset ID:           A1          Asset ID:                      Asset =
ID:           H
    -----------------------------   -----------------------------  --------=
---------------------
    Input 2                         Output 2 (Marker)              Output 2=
 (Marker)
      Asset quantity:     <NULL>      Asset quantity:     <NULL>=
;     Asset quantity:     <NULL>
      Asset ID:           <NULL>      Asset ID:           <NULL>=
;     Asset ID:           <NULL>
    -----------------------------   -----------------------------  --------=
---------------------
    Input 3                         Output 3 (Transfer)            Output 3=
 (Transfer)
      Asset quantity:     5           Asset quantity:     6          Asset =
quantity:     6
      Asset ID:           A1          Asset ID:                      Asset =
ID:           A1
    -----------------------------   -----------------------------  --------=
---------------------
    Input 4                         Output 4 (Transfer)            Output 4=
 (Transfer)
      Asset quantity:     3           Asset quantity:     0          Asset =
quantity:     <NULL>
      Asset ID:           A1          Asset ID:                      Asset =
ID:           <NULL>
    -----------------------------   -----------------------------  --------=
---------------------
    Input 5                         Output 5 (Transfer)            Output 5=
 (Transfer)
      Asset quantity:     9           Asset quantity:     7          Asset =
quantity:     7
      Asset ID:           A2          Asset ID:                      Asset =
ID:           A1
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D   -----------------------------  -----------------------=
------
                                    Output 6 (Transfer)            Output 6=
 (Transfer)
                                      Asset quantity:     3          Asset =
quantity:     3
                                      Asset ID:                      Asset =
ID:           A2
                                    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D  =3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Outputs are colored from the first to the last. Outputs before the marker o=
utput are issuance outputs:
* Output 0 has an asset quantity of zero, so it is considered uncolored.
* Output 1 gets assigned the asset ID defined by <code>H =3D RIPEMD16=
0(SHA256((S))</code> where <code>S</code> is the output s=
cript referenced by the first input of the transaction (input 0).

Output 2 is the marker output, separating issuance outputs from transfer ou=
tputs. The marker output is always uncolored.

Transfer outputs are then colored:
* Output 3 receives 3 units from input 0, 2 units from input 1, 0 unit from=
 input 2 and 1 unit from input 3. All the 6 units have the same asset ID &l=
t;code>A1</code>, so the asset ID <code>A1</code> is a=
ssigned to output 3.
* Output 4 has an asset quantity of zero, so it is considered uncolored.
* Output 5 receives the remaining 4 units of input 3, and 3 units from inpu=
t 4. All the 7 units have the same asset ID <code>A1</code>, so=
 the asset ID <code>A1</code> is assigned to output 5.
* Output 6 receives the first 3 units of input 5. Input 5 has the asset ID =
<code>A2</code> so the asset ID <code>A2</code> is =
assigned to output 6.

=3D=3DRationale=3D=3D

This approach offers a number of desirable characteristics:

# Economical: The cost of issuing or transferring an asset is completely in=
dependent from the quantity issued or transferred.
# Clients have a way to identify colored outputs simply by traversing the B=
lockchain, without needing to be fed external data. Transactions relevant t=
o the Open Assets Protocol are identified by the special marker output.
# It is possible to determine the asset ID and asset quantity of an output =
by traversing only a limited number of transactions.
# Assets are pseudonymous. They are represented by an asset ID, which is en=
ough to identify each asset uniquely, while still providing an adequate lev=
el of anonymity for both the issuer and users of the asset.
# This approach uses the recommended way to embed data in the Blockchain (O=
P_RETURN), and therefore does not pollute the UTXO.
# The whole cryptographic infrastructure that Bitcoin provides for securing=
 the spending of outputs is reused for securing the ability to issue assets=
. There is a symmetry between ''an address + private key'' =
as a way to spend Bitcoins, and ''an address + private key''=
; as a way to issue assets.
# Generating a new type of asset is as simple as generating an address, can=
 be done offline, and for free.
# Reissuing more of an existing asset is easy and can be done quickly and a=
t no cost (except for the transaction fee) as long as the issuer retains th=
e private key for the asset ID.
# Single-issuance assets can be achieved by destroying the private key used=
 to issue the asset immediately after issuing it.
# Since issuance is based on standard Bitcoin output scripts, it is possibl=
e to create an asset that requires multiple signatures for issuance.

=3D=3DCompatibility=3D=3D

For backward compatibility reasons, we consider than an older client is all=
owed to see a colored output as uncolored.

=3D=3D=3DBackward compatibility with existing Bitcoin protocol=3D=3D=3D

The Open Assets Protocol sits on top of the Bitcoin protocol. It does not r=
equire any change to the existing Bitcoin protocol. Existing clients that d=
on't support the Open Assets Protocol will see all outputs as uncolored=
, and will not be able to perform transfer transactions.

=3D=3D=3DCompatibility between different versions of OAP=3D=3D=3D

New versions with the same major version number (e.g. 1.1) should be backwa=
rds compatible. New versions with a different major version number (e.g. 2.=
0) can introduce breaking changes, but transactions created by newer client=
s will be identifiable by a different version number in the output 0 of gen=
esis and transfer transactions.

=3D=3DCopyright=3D=3D

This document has been placed in the public domain.
=

Nicolas Dorier,
--001a113a48c2590a610533b5dbb0--