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
next prev parent 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 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$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=nicolas.dorier@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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