public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
	Nicolas Dorier <nicolas.dorier@gmail.com>
Subject: Re: [bitcoin-dev] BIP Number Request: Open Asset
Date: Thu, 26 May 2016 03:53:04 +0000	[thread overview]
Message-ID: <201605260353.06939.luke@dashjr.org> (raw)
In-Reply-To: <CA+1nnrmZAdzBn-FMBVMGtp4n7bbG8W0VEGvi1WopS-M49zBXpw@mail.gmail.com>

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


  reply	other threads:[~2016-05-26  3:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-26  2:50 [bitcoin-dev] BIP Number Request: Open Asset Nicolas Dorier
2016-05-26  3:53 ` Luke Dashjr [this message]
2016-07-05 17:46   ` Peter Todd
2016-07-06  1:22     ` Luke Dashjr
2016-07-06  2:14       ` James MacWhyte
2016-07-06  6:49         ` Alex Mizrahi
2016-08-02  5:21         ` Nicolas Dorier
2016-08-02 14:53           ` Erik Aronesty
2016-08-02 17:25             ` Alex Mizrahi
     [not found]               ` <CABbpET83UAt-TZfQsi0ZyhPAEznucc2yKYA4Md9y78=XH-vpmw@mail.gmail.com>
2016-08-13  2:25                 ` Nicolas Dorier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201605260353.06939.luke@dashjr.org \
    --to=luke@dashjr.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=nicolas.dorier@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox