BIP Number Request: Open Asset

BIP Number Request: Open Asset
2016-05-26  3:53 ` Luke Dashjr
  
From: Nicolas Dorier @ 2016-05-26  2:50 UTC (permalink / raw)
  To: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 18013 bytes --]

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:

<pre>
  Title: Open Assets Protocol (OAP/1.0)
  Author: Flavien Charlon <flavien@charlon•net>
  Created: 2013-12-12
</pre>

==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 (<code>script_hash =
RIPEMD160(SHA256(script))</code>). 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:
<code>18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725</code>.
# He calculates the corresponding address:
<code>16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM</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>36e0ea8e93eaa0285d641305f4c81e563aa570a2</code>
# Finally, the hash is converted to a base 58 string with checksum
using version 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 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 <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-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 <code>metadata</code> field. || 1-9
bytes
|-
! Metadata             || Arbitrary metadata to be associated with
this transaction. This can be empty. || Variable
|}

Possible formats for the <code>metadata</code> field are outside of
scope of this protocol, and may be described in separate protocol
specifications 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://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 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 output, 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
output), the outputs in excess receive an asset quantity of zero. If
there are more items in the <code>asset quantity list</code> than the
number 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 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 <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
    =============================   =============================
=============================
    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
    =============================   -----------------------------
-----------------------------
                                    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 <code>H =
RIPEMD160(SHA256((S))</code> where <code>S</code> 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 <code>A1</code>, so the asset ID <code>A1</code> 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 <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.

==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,

[-- Attachment #2: Type: text/html, Size: 19894 bytes --]

 permalink raw reply	[|nested]
2016-05-26  2:50 [bitcoin-dev] BIP Number Request: Open Asset Nicolas Dorier

  2016-07-05 17:46   ` Peter Todd
  
From: Luke Dashjr @ 2016-05-26  3:53 UTC (permalink / raw)
  To: bitcoin-dev, Nicolas Dorier

On Thursday, May 26, 2016 2:50:26 AM Nicolas Dorier via bitcoin-dev wrote:
>   Author: Flavien Charlon <flavien@charlon•net>

Is he the author of this BIP, or merely the protocol described in it?
Would it perhaps make sense to include yourself in the author list?

> 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 (<code>script_hash =
> RIPEMD160(SHA256(script))</code>). 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.

Quite a bit ugly, giving a meaning to an input's pubkey script like that.
But more problematically: how can this work with other pubkey scripts? 
Particularly relevant now that this old script format is being deprecated.

Another possible problem is that I don't see a way to provably guarantee an 
asset issuance is final.

> Transactions that are not recognized as an Open Assets transaction are
> considered as having all their outputs uncolored.

And the assets attached to its inputs are destroyed? Or?

> 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.

Is it intentional that the first case is "parsable", and the second "valid"?
I think these need to be better specified; for example, it is not so clear how 
to reach if the OAP version number is something other than 1: is that 
parsable? valid?

> ! Asset quantity count || A
> [https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer
> var-integer] representing the number 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-encoded] unsigned integers
> representing the asset quantity of every output in order (excluding the
> marker output). || Variable

What determines the asset id? How would one issue and/or transfer multiple 
asset ids in the same transaction?

> The marker output is always uncolored.

What if I have a transaction with 5 outputs, the marker output at position 3, 
and all 4 other outputs are to receive assets? Does the marker output get 
skipped in the list (ie, the list is 4 elements long) or must it be set to 
zero quantity (ie, the list is 5 elements long)?

> 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.

I don't understand this.

> # This approach uses the recommended way to embed data in the Blockchain
> (OP_RETURN), and therefore does not pollute the UTXO.

Embedding data is not recommended at all. It seems a better way to have done 
this would be to put the info in an OP_DROP within a P2SH or witness script.

> # 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.

Addresses are not used for spending bitcoins, only for receiving them. The way 
this BIP uses inputs' pubkey script is extremely unusual and probably a bad 
idea.

> # 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.

As I understand it, this would require address reuse to setup, which is not 
supported behaviour and insecure.

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

How is this compatible? Won't an older client then accidentally destroy 
assets?

Luke


 permalink raw reply	[|nested]
2016-05-26  3:53 ` Luke Dashjr

  2016-07-06  1:22     ` Luke Dashjr
  
From: Peter Todd @ 2016-07-05 17:46 UTC (permalink / raw)
  To: Luke Dashjr, Bitcoin Protocol Discussion;  Nicolas Dorier

[-- Attachment #1: Type: text/plain, Size: 321 bytes --]

On Thu, May 26, 2016 at 03:53:04AM +0000, Luke Dashjr via bitcoin-dev wrote:
> On Thursday, May 26, 2016 2:50:26 AM Nicolas Dorier via bitcoin-dev wrote:
> >   Author: Flavien Charlon <flavien@charlon•net>

What's the status of this BIP? Will it be assigned?

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

 permalink raw reply	[|nested]
2016-07-05 17:46   ` Peter Todd

  2016-07-06  2:14       ` James MacWhyte
  
From: Luke Dashjr @ 2016-07-06  1:22 UTC (permalink / raw)
  To: Peter Todd;  Bitcoin Protocol Discussion, Nicolas Dorier

On Tuesday, July 05, 2016 5:46:36 PM Peter Todd wrote:
> On Thu, May 26, 2016 at 03:53:04AM +0000, Luke Dashjr via bitcoin-dev wrote:
> > On Thursday, May 26, 2016 2:50:26 AM Nicolas Dorier via bitcoin-dev wrote:
> > >   Author: Flavien Charlon <flavien@charlon•net>
> 
> What's the status of this BIP? Will it be assigned?

I was waiting for clarification on the Author thing, but Nicholas hasn't 
responded yet. I am unaware of any reason NOT to assign it, and there appear 
to be no objections, so let's call it BIP 160.

Luke


 permalink raw reply	[|nested]
2016-07-06  1:22     ` Luke Dashjr

  2016-07-06  6:49         ` Alex Mizrahi
  2016-08-02  5:21         ` Nicolas Dorier
  
From: James MacWhyte @ 2016-07-06  2:14 UTC (permalink / raw)
  To: Luke Dashjr, Bitcoin Protocol Discussion, Peter Todd;  Nicolas Dorier

[-- Attachment #1: Type: text/plain, Size: 1249 bytes --]

I'm curious to hear the answers to the questions Luke asked earlier. I also
read through the documentation and wasn't convinced it was thought out well
enough to actually build something on top of, but there's no reason it
can't get a number as a work-in-progress.

I hope it does continue to get worked on, though. The lack of response or
discussion worries me that it might become an abandoned project.

On Tue, Jul 5, 2016, 18:32 Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> On Tuesday, July 05, 2016 5:46:36 PM Peter Todd wrote:
> > On Thu, May 26, 2016 at 03:53:04AM +0000, Luke Dashjr via bitcoin-dev
> wrote:
> > > On Thursday, May 26, 2016 2:50:26 AM Nicolas Dorier via bitcoin-dev
> wrote:
> > > >   Author: Flavien Charlon <flavien@charlon•net>
> >
> > What's the status of this BIP? Will it be assigned?
>
> I was waiting for clarification on the Author thing, but Nicholas hasn't
> responded yet. I am unaware of any reason NOT to assign it, and there
> appear
> to be no objections, so let's call it BIP 160.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 1866 bytes --]

 permalink raw reply	[|nested]
2016-07-06  2:14       ` James MacWhyte

  2016-08-02  5:21         ` Nicolas Dorier
  
From: Alex Mizrahi @ 2016-07-06  6:49 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]

> I'm curious to hear the answers to the questions Luke asked earlier. I
> also read through the documentation and wasn't convinced it was thought out
> well enough to actually build something on top of,
>
There are many colored coin protocols in use. OpenAssets is probably the
most popular one, but it has many critical flaws IMHO.
https://github.com/bitcoinx/colored-coin-tools/wiki/OpenAssets-deficiencies


> but there's no reason it can't get a number as a work-in-progress.
>
The protocol is not a work-in-progress, it is already in use, you cannot
change it without breaking stuff.
The doc can be improved, though. There is a lot of fluff but the actual
important stuff gets just few ambiguous sentences.

I hope it does continue to get worked on, though. The lack of response or
> discussion worries me that it might become an abandoned project.
>

The original author, Flavien, have abandoned it, he now does a private
blockchain thing, OpenChain.
There are others who still use OpenAssets, e.g. Nicolas, but the protocol
can't be changed.

There are other colored coin protocols in existence/in development, though.

[-- Attachment #2: Type: text/html, Size: 2020 bytes --]

 permalink raw reply	[|nested]
2016-07-06  2:14       ` James MacWhyte
  2016-07-06  6:49         ` Alex Mizrahi

  2016-08-02 14:53           ` Erik Aronesty
  
From: Nicolas Dorier @ 2016-08-02  5:21 UTC (permalink / raw)
  To: James MacWhyte;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 5415 bytes --]

Sorry, I completely forgot about having submitted the BIP as I was busy at
this time.
Thanks for the review.

Open Asset is actually not an abandoned project and is a protocol already
used in production with multiple implementation.
Wallet: https://www.coinprism.com/
Implementation C#: https://github.com/NicolasDorier/NBitcoin with heavy
documentation (
https://programmingblockchain.gitbooks.io/programmingblockchain/content/other_types_of_asset/colored_coins.html
)
Implementation Ruby: https://github.com/haw-itn/openassets-ruby/
Usage stats: http://opreturn.org/

Concerning whether or not we can put my name in the BIP, I'll ask the
original author that I know personally.

> Quite a bit ugly, giving a meaning to an input's pubkey script like that.
> But more problematically: how can this work with other pubkey scripts?
> Particularly relevant now that this old script format is being deprecated.
> Another possible problem is that I don't see a way to provably guarantee
an
> asset issuance is final.

Yes, with open asset it is not possible to do provably limited issuance.
The scriptPubKey can be anything, not necessarily P2PK.
If you can spend the scriptPubkey, then you are the issuer.

> And the assets attached to its inputs are destroyed? Or?

Correct, if you spend a colored output incorrectly, it is effectively
destroyed.

> Is it intentional that the first case is "parsable", and the second
"valid"?
> I think these need to be better specified; for example, it is not so
clear how
> to reach if the OAP version number is something other than 1: is that
> parsable? valid?

The terminology is correct we are parsing PUSHDATA, if there is a parsable
pushdata, the output is considered valid.
If there is multiple valid output, then we take the first one.

> What determines the asset id? How would one issue and/or transfer multiple
> asset ids in the same transaction?

You can't issue more than one asset type in a transaction. (as the asset
issued is defined by the scriptPubKey of the first input)
For multiple transfer it is possible, imagine a transaction with the
following 3 inputs and 6 outputs:

Inputs: {0, 10a, 20b}
Outputs: {5, OP_RETURN; 7; 3; 11; 9)

Inputs1: 0
Inputs2: Enqueue 10a in the queue ( {10a} )
Input3: Enqueue 20b in the queue ( { 20b, 10a} )

Output1: Before OP_RETURN, so is issuance whose color is defined by the
scriptPubKey of Input1. (say c)
Output2: No color (marker)
Output3: Dequeue 7a ( {20b, 3a} ), color output with a.
Output4: Dequeue 3a ( {20b} ), color output with a
Output5: Dequeue 11b ( {9b} ), color output with b
Output5: Dequeue 9b ( {0} ), color output with b

Finally, outputs color are
Outputs: {5c, OP_RETURN; 7a; 3a; 11b; 9b)

> What if I have a transaction with 5 outputs, the marker output at
position 3,
> and all 4 other outputs are to receive assets? Does the marker output get
> skipped in the list (ie, the list is 4 elements long) or must it be set to
> zero quantity (ie, the list is 5 elements long)?

Marker output is skipped (explained in the example)

> Addresses are not used for spending bitcoins, only for receiving them.
The way
> this BIP uses inputs' pubkey script is extremely unusual and probably a
bad
> idea.

Actually there is no "issuance address", just the AssetId is defined by the
scriptPubKey of the issuer.

> As I understand it, this would require address reuse to setup, which is
not
> supported behaviour and insecure.

Yes, it requires address reuse for issuing.

> Won't an older client then accidentally destroy assets?

Correct. Actually we prevent users sending asset to wallet which does not
support OA via another address scheme described in another document (
https://github.com/OpenAssets/open-assets-protocol/blob/master/address-format.mediawiki
)

As said, Open Asset is not a draft proposal and is already used in the wild
since 2014. We can't easily modify the protocol by now for improving it.

PS:
https://github.com/OpenAssets/open-assets-protocol/blob/master/specification.mediawiki
is
more readable than a mail.

Nicolas,

On Tue, Jul 5, 2016 at 7:14 PM, James MacWhyte <macwhyte@gmail•com> wrote:

> I'm curious to hear the answers to the questions Luke asked earlier. I
> also read through the documentation and wasn't convinced it was thought out
> well enough to actually build something on top of, but there's no reason it
> can't get a number as a work-in-progress.
>
> I hope it does continue to get worked on, though. The lack of response or
> discussion worries me that it might become an abandoned project.
>
> On Tue, Jul 5, 2016, 18:32 Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> On Tuesday, July 05, 2016 5:46:36 PM Peter Todd wrote:
>> > On Thu, May 26, 2016 at 03:53:04AM +0000, Luke Dashjr via bitcoin-dev
>> wrote:
>> > > On Thursday, May 26, 2016 2:50:26 AM Nicolas Dorier via bitcoin-dev
>> wrote:
>> > > >   Author: Flavien Charlon <flavien@charlon•net>
>> >
>> > What's the status of this BIP? Will it be assigned?
>>
>> I was waiting for clarification on the Author thing, but Nicholas hasn't
>> responded yet. I am unaware of any reason NOT to assign it, and there
>> appear
>> to be no objections, so let's call it BIP 160.
>>
>> Luke
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

[-- Attachment #2: Type: text/html, Size: 10180 bytes --]

 permalink raw reply	[|nested]
2016-08-02  5:21         ` Nicolas Dorier

  2016-08-02 17:25             ` Alex Mizrahi
  
From: Erik Aronesty @ 2016-08-02 14:53 UTC (permalink / raw)
  To: Nicolas Dorier, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]

> As said, Open Asset is not a draft proposal and is already used in the
wild since 2014. We can't easily modify the protocol by now for improving
it.

You can, however, provide a new OA2.0 protocol that improves upon these
issues, and assure that upgraded wallets maintain support for both
versions.

It seems like OA's stance has *always *been to focus on integration, rather
than fixing the core protocol and then, by virtue of having the largest
integration, saying things like "it's too late to turn back now".    Colu
and Chromaway/EPOBC also have stuff "in the wild".

I would love to see an RFC-style standard "multiple-colored-coin-protocol"
written by reps from all of the major protocols and that meta-merges the
features of these implementations - in collaboration with feedback from
core developers that understand the direction the protocol will be taking
and the issues to avoid.   HTTP/TCP/IP MCCP/BTC

As it stands, investors have to install multiple wallets to deal with these
varying implementations.   Merging them into one "meta-specification"
fairly soon might be in the best interests of the community and of future
shareholders.

[-- Attachment #2: Type: text/html, Size: 1437 bytes --]

 permalink raw reply	[|nested]
2016-08-02 14:53           ` Erik Aronesty

       [not found]               ` <CABbpET83UAt-TZfQsi0ZyhPAEznucc2yKYA4Md9y78=XH-vpmw@mail.gmail.com>
  
From: Alex Mizrahi @ 2016-08-02 17:25 UTC ( / )
  To: Erik Aronesty, Bitcoin Protocol Discussion;  Nicolas Dorier



>
> I would love to see an RFC-style standard "multiple-colored-coin-protocol"
> written by reps from all of the major protocols and that meta-merges the
> features of these implementations
>

We actually tried to do that in 2014-2015, but that effort have failed...
Nobody was really interested in collaboration, each company only cared
about it's own product.
Especially Colu, they asked everyone for requirements, and then developed a
new protocol completely on their own without taking anyone's input.

I'm not sure that merging the protocols makes sense, as some protocols
value simplicity, and a combined protocol cannot have this feature.

I don't think there is much interest in a merged colored coin protocol now.
Colu is moving away from colored coins, as far as I can tell.
CoinSpark is now doing MultiChain closed-source private blockchain.
CoinPrism also seems to be largely disinterested in colored coins.

We (ChromaWay) won't mind replacing EPOBC with something better, our
software could always support multiple different kernels so adding a new
protocol isn't a big deal for us.

So if somebody is interested in a new protocol please ping me.

One of ideas I have is to decouple input-output mapping/multiplexing from
coloring.
So one layer will describe a mapping, e.g. "Inputs 0 and 1 should go into
outputs 0, 1 and 2".
In this case it will be possible to create more advanced protocols (e.g.
with support for 'smart contracts' and whatnot) while also keeping them
compatible with old ones to some extent, e.g. a wallet can safely engage in
p2ptrade or CoinJoin transactions without understanding all protocols used
in a transaction.


> - in collaboration with feedback from core developers that understand the
> direction the protocol will be taking and the issues to avoid.
>

Core developers generally dislike things like colored coins, so I doubt
they are going to help.

Blockstream is developing a sidechain with user-defined assets, so I guess
they see it as the preferred way of doing things:
https://elementsproject.org/elements/asset-issuance/


> As it stands, investors have to install multiple wallets to deal with
> these varying implementations.
>

Actually this can be solved without making a new "merged protocol": one can
just implement a wallet which supports multiple protocols.
[not found]               ` <CABbpET83UAt-TZfQsi0ZyhPAEznucc2yKYA4Md9y78=XH-vpmw@mail.gmail.com>

  
From: Nicolas Dorier @ 2016-08-13  2:25 UTC (permalink / raw)
  To: Flavien Charlon;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 4768 bytes --]

I think that regardless of merits protocol or limitations of protocols,
once they become used and stable they merit their place as a BIP.
I'd like to submit OA as is on flavien's repository, and update or reword
things once it is there. (so he can ACK easily and we can keep track of
changes instead of using mails back and forth)
It would be useful to have other colored coin protocols as well. (EPOBC and
Colu)

On Thu, Aug 4, 2016 at 9:37 PM, Flavien Charlon <
flavien.charlon@coinprism•com> wrote:

> Hi,
>
> > I would love to see an RFC-style standard "multiple-colored-coin-protocol"
> written by reps from all of the major protocols and that meta-merges the
> features of these implementations
>
> Alex summarizes the situation well. Efforts to come up with a
> "multiple-colored-coin-protocol" have failed since the different
> protocols take different assumptions and different tradeoffs and are built
> for different use cases. In the end, we ended up exactly in the same
> situation as the well known XKCD comic strip about standards (
> https://xkcd.com/927/).
>
> > You can, however, provide a new OA2.0 protocol that improves upon these
> issues, and assure that upgraded wallets maintain support for both versions.
>
> I don't think there is a point in doing that. This would just result in
> having yet another "standard", which nobody uses. Open Assets 1.0 took 3
> years to get where it is today, and is used by many companies across the
> industry. It has well over 20 different implementations, some open source,
> some proprietary.
>
> The goal of this process is to have OA 1.0 becoming the BIP since this is
> the one people are using.
>
> > I was waiting for clarification on the Author thing, but Nicholas hasn't
> responded yet. I am unaware of any reason NOT to assign it, and there
> appear to be no objections, so let's call it BIP 160.
>
> Nicolas is proposing the BIP on my behalf. I'll ACK as needed but he can
> drive the discussions.
>
> Best,
> Flavien
>
> On Tue, Aug 2, 2016 at 6:25 PM, Alex Mizrahi via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> I would love to see an RFC-style standard "multiple-colored-coin-protocol"
>>> written by reps from all of the major protocols and that meta-merges the
>>> features of these implementations
>>>
>>
>> We actually tried to do that in 2014-2015, but that effort have failed...
>> Nobody was really interested in collaboration, each company only cared
>> about it's own product.
>> Especially Colu, they asked everyone for requirements, and then developed
>> a new protocol completely on their own without taking anyone's input.
>>
>> I'm not sure that merging the protocols makes sense, as some protocols
>> value simplicity, and a combined protocol cannot have this feature.
>>
>> I don't think there is much interest in a merged colored coin protocol
>> now.
>> Colu is moving away from colored coins, as far as I can tell.
>> CoinSpark is now doing MultiChain closed-source private blockchain.
>> CoinPrism also seems to be largely disinterested in colored coins.
>>
>> We (ChromaWay) won't mind replacing EPOBC with something better, our
>> software could always support multiple different kernels so adding a new
>> protocol isn't a big deal for us.
>>
>> So if somebody is interested in a new protocol please ping me.
>>
>> One of ideas I have is to decouple input-output mapping/multiplexing from
>> coloring.
>> So one layer will describe a mapping, e.g. "Inputs 0 and 1 should go into
>> outputs 0, 1 and 2".
>> In this case it will be possible to create more advanced protocols (e.g.
>> with support for 'smart contracts' and whatnot) while also keeping them
>> compatible with old ones to some extent, e.g. a wallet can safely engage in
>> p2ptrade or CoinJoin transactions without understanding all protocols used
>> in a transaction.
>>
>>
>>> - in collaboration with feedback from core developers that understand
>>> the direction the protocol will be taking and the issues to avoid.
>>>
>>
>> Core developers generally dislike things like colored coins, so I doubt
>> they are going to help.
>>
>> Blockstream is developing a sidechain with user-defined assets, so I
>> guess they see it as the preferred way of doing things:
>> https://elementsproject.org/elements/asset-issuance/
>>
>>
>>> As it stands, investors have to install multiple wallets to deal with
>>> these varying implementations.
>>>
>>
>> Actually this can be solved without making a new "merged protocol": one
>> can just implement a wallet which supports multiple protocols.
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 7213 bytes --]

 permalink raw reply	[|nested]