Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3767C323 for ; Thu, 26 May 2016 03:53:44 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 6BA7AD5 for ; Thu, 26 May 2016 03:53:43 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id DA38938A17C5; Thu, 26 May 2016 03:53:07 +0000 (UTC) X-Hashcash: 1:25:160526:bitcoin-dev@lists.linuxfoundation.org::YOxW7lbe4XhZpzrL:elUe7 X-Hashcash: 1:25:160526:nicolas.dorier@gmail.com::bVtWz0kwtPrbgCCl:l6dy From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Nicolas Dorier Date: Thu, 26 May 2016 03:53:04 +0000 User-Agent: KMail/1.13.7 (Linux/4.1.18-gentoo; KDE/4.14.16; x86_64; ; ) References: In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201605260353.06939.luke@dashjr.org> X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [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 03:53:44 -0000 On Thursday, May 26, 2016 2:50:26 AM Nicolas Dorier via bitcoin-dev wrote: > Author: Flavien Charlon 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 (

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

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