1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3767C323
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
Nicolas Dorier <nicolas.dorier@gmail.com>
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: <CA+1nnrmZAdzBn-FMBVMGtp4n7bbG8W0VEGvi1WopS-M49zBXpw@mail.gmail.com>
In-Reply-To: <CA+1nnrmZAdzBn-FMBVMGtp4n7bbG8W0VEGvi1WopS-M49zBXpw@mail.gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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
|
