path: root/f5/d638945aa4827bec28b2cd44b35248809c1503

Return-Path: <slashene@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 0C3032C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  2 Aug 2016 05:22:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f181.google.com (mail-qt0-f181.google.com
	[209.85.216.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BB223AF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  2 Aug 2016 05:22:10 +0000 (UTC)
Received: by mail-qt0-f181.google.com with SMTP id w38so117450720qtb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 01 Aug 2016 22:22:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:cc;
	bh=42g2EHMRR/gHvyi1srQxxC2yBhGQ8pncavU00CsF46k=;
	b=aZC5aGMIM64QxCjjMTcUuDlxe2Z4tJW44kXEjO77EyrKPehi6jRlqk1aHGbrfnGxFv
	0tMZmFa8t3zS/n/k1M2tldHUlbrBn/N5ECyMdcTHwvmTGO2k6he/WUI3ctxX2AsgEg8o
	2Ac29LtO1omN12ti0VCKcbRBamXAtFuPs2VNXvOCKZPKg7Fw+UP3xLm1KGF+GlDiDh1s
	00sMv7Xw8fV1YI8UfazVHJA2H7fv5Jm8fGxgqOpHhBXFKt/84edka2go5dU1Oqot8QSZ
	7ZWwkKnoEk9fZ4b1MCT3iO/WUKmxcFp/8I9nAC+V3pon/uUg48Awwf1gkKv6y2p0oXP4
	H4Sg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
	:date:message-id:subject:to:cc;
	bh=42g2EHMRR/gHvyi1srQxxC2yBhGQ8pncavU00CsF46k=;
	b=LMDetDldyHlSOJvHwx/W9qUXrmI7+RlU3f7Wddum5IHYUoYikCv13jZUeCbo9Y5/kr
	xnKxoKjXbjMkAkOM+9m0XgnoR2DHU5B+mkrZgHGzNbdmKArC5AOBnnSaKn/9+VDEqoKB
	6lnGGsV2XkNk3UgYhUcZ4C3gv7K1OAWxFF6vFfw0aZanouaYmYjxxBK5U4fMHwV10glI
	67qspDYSAyA9WGwrU/doa2jk0wGSkdJS8lxovHeMIBQ/6znc/fp5sm36fSDmo4EPupMZ
	UBPe2BOJLlGHKt0oO7VLc/SxRAu3895LqiVIK5F0c8Cc9xdhR4gmp6DCeAHh+Z+VQeBj
	5ZcQ==
X-Gm-Message-State: AEkoouu9rVPXUBVx9WU9fSx1//xnR1V1SAXmlM35UFzc6OcH8gbl3KO20MtPstgTJZcgl0qJ0uT7uirzaEEUbA==
X-Received: by 10.200.38.107 with SMTP id v40mr96676187qtv.76.1470115329905;
	Mon, 01 Aug 2016 22:22:09 -0700 (PDT)
MIME-Version: 1.0
Sender: slashene@gmail.com
Received: by 10.55.163.81 with HTTP; Mon, 1 Aug 2016 22:21:49 -0700 (PDT)
In-Reply-To: <CAH+Axy5A-_oDoPjabyzzAF8kVq9DsFwonEYPp9EU+Hf_BP1-DA@mail.gmail.com>
References: <CA+1nnrmZAdzBn-FMBVMGtp4n7bbG8W0VEGvi1WopS-M49zBXpw@mail.gmail.com>
	<201605260353.06939.luke@dashjr.org>
	<20160705174636.GA24068@fedora-21-dvm>
	<201607060122.20593.luke@dashjr.org>
	<CAH+Axy5A-_oDoPjabyzzAF8kVq9DsFwonEYPp9EU+Hf_BP1-DA@mail.gmail.com>
From: Nicolas Dorier <nicolas.dorier@gmail.com>
Date: Mon, 1 Aug 2016 22:21:49 -0700
X-Google-Sender-Auth: 7QQGcTLxZH6OzzEVEJTKISd361o
Message-ID: <CA+1nnrmsU5kLxuW=GJSmy8C7s6F3EM8sgFYoXDg1iM-eD2qzsg@mail.gmail.com>
To: James MacWhyte <macwhyte@gmail.com>
Content-Type: multipart/alternative; boundary=001a1140300c04b84905390fe60b
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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: Tue, 02 Aug 2016 05:22:12 -0000

--001a1140300c04b84905390fe60b
Content-Type: text/plain; charset=UTF-8

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

--001a1140300c04b84905390fe60b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Sorry, I completely forgot about having submitted the BIP =
as I was busy at this time.<div>Thanks for the review.<br><div><br></div><d=
iv>Open Asset is actually not an abandoned project and is a protocol alread=
y used in production with multiple implementation.</div><div>Wallet:=C2=A0<=
a href=3D"https://www.coinprism.com/" target=3D"_blank">https://www.coinpri=
sm.com/</a></div><div>Implementation C#: <a href=3D"https://github.com/Nico=
lasDorier/NBitcoin" target=3D"_blank">https://github.com/NicolasDorier/NBit=
coin</a>=C2=A0with heavy documentation (<a href=3D"https://programmingblock=
chain.gitbooks.io/programmingblockchain/content/other_types_of_asset/colore=
d_coins.html" target=3D"_blank">https://programmingblockchain.gitbooks.io/p=
rogrammingblockchain/content/other_types_of_asset/colored_coins.html</a>)</=
div><div>Implementation Ruby:=C2=A0<a href=3D"https://github.com/haw-itn/op=
enassets-ruby/" target=3D"_blank">https://github.com/haw-itn/openassets-rub=
y/</a></div><div>Usage stats:=C2=A0<a href=3D"http://opreturn.org/" target=
=3D"_blank">http://opreturn.org/</a></div><div><br></div><div>Concerning wh=
ether or not we can put my name in the BIP, I&#39;ll ask the original autho=
r that I know personally.</div></div><div><div><br></div><div><span style=
=3D"font-size:12.8px">&gt; Quite a bit ugly, giving a meaning to an input&#=
39;s pubkey script like that.</span><br style=3D"font-size:12.8px"><span st=
yle=3D"font-size:12.8px">&gt; But more problematically: how can this work w=
ith other pubkey scripts?</span><br style=3D"font-size:12.8px"><span style=
=3D"font-size:12.8px">&gt; Particularly relevant now that this old script f=
ormat is being deprecated.</span><br style=3D"font-size:12.8px"><span style=
=3D"font-size:12.8px">&gt; Another possible problem is that I don&#39;t see=
 a way to provably guarantee an</span><br style=3D"font-size:12.8px"><span =
style=3D"font-size:12.8px">&gt; asset issuance is final.</span></div><div><=
span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-s=
ize:12.8px">Yes, with open asset it is not possible to do provably limited =
issuance.</span></div><div><span style=3D"font-size:12.8px">The scriptPubKe=
y can be anything, not necessarily P2PK.</span></div><div><span style=3D"fo=
nt-size:12.8px">If you can spend the scriptPubkey, then you are the issuer.=
</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><s=
pan style=3D"font-size:12.8px">&gt;=C2=A0</span><span style=3D"font-size:12=
.8px">And the assets attached to its inputs are destroyed? Or?<br></span><s=
pan style=3D"font-size:12.8px"><br>Correct, if you spend a colored output i=
ncorrectly, it is effectively destroyed.<br><br></span><span style=3D"font-=
size:12.8px">&gt; Is it intentional that the first case is &quot;parsable&q=
uot;, and the second &quot;valid&quot;?</span><br style=3D"font-size:12.8px=
"><span style=3D"font-size:12.8px">&gt;=C2=A0</span><span style=3D"font-siz=
e:12.8px">I think these need to be better specified; for example, it is not=
 so clear how</span><br style=3D"font-size:12.8px"><span style=3D"font-size=
:12.8px">&gt;=C2=A0</span><span style=3D"font-size:12.8px">to reach if the =
OAP version number is something other than 1: is that</span><br style=3D"fo=
nt-size:12.8px"><span style=3D"font-size:12.8px">&gt;=C2=A0</span><span sty=
le=3D"font-size:12.8px">parsable? valid?</span></div><div><span style=3D"fo=
nt-size:12.8px"><br></span></div><div><div>The terminology is correct we ar=
e parsing PUSHDATA, if there is a parsable pushdata, the output is consider=
ed valid.</div><div>If there is multiple valid output, then we take the fir=
st one.</div><div><br></div><div><div>&gt;=C2=A0<span style=3D"font-size:12=
.8px">What determines the asset id? How would one issue and/or transfer mul=
tiple</span><br></div><span style=3D"font-size:12.8px">&gt; asset ids in th=
e same transaction?<br><br></span><span style=3D"font-size:12.8px">You can&=
#39;t issue more than one asset type in a transaction. (as the asset issued=
 is defined by the scriptPubKey of the first input)</span><br></div><div><s=
pan style=3D"font-size:12.8px">For multiple transfer it is possible, imagin=
e a transaction with the following 3 inputs and 6 outputs:</span></div><div=
><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font=
-size:12.8px">Inputs:=C2=A0</span>{0, 10a, 20b}</div><div>Outputs: {5, OP_R=
ETURN; 7; 3; 11; 9)</div><div><br></div><div>Inputs1: 0</div><div>Inputs2: =
Enqueue 10a in the queue ( {10a} )<br></div><div>Input3: Enqueue 20b in the=
 queue ( {=C2=A020b,=C2=A010a} )</div><div><br></div><div>Output1: Before O=
P_RETURN, so is issuance whose color is defined by the scriptPubKey of Inpu=
t1. (say c)</div><div>Output2: No color (marker)</div><div>Output3: Dequeue=
 7a ( {20b, 3a} ), color output with a.</div><div>Output4: Dequeue 3a ( {20=
b} ), color output with a</div><div>Output5: Dequeue 11b ( {9b} ), color ou=
tput with b</div><div>Output5: Dequeue 9b ( {0} ), color output with b<br><=
/div><div><br></div><div>Finally, outputs color are</div><div>Outputs: {5c,=
 OP_RETURN; 7a; 3a; 11b; 9b)<br></div><div><br></div><div><span style=3D"fo=
nt-size:12.8px">&gt; What if I have a transaction with 5 outputs, the marke=
r output at position 3,</span><br style=3D"font-size:12.8px"><span style=3D=
"font-size:12.8px">&gt; and all 4 other outputs are to receive assets? Does=
 the marker output get</span><br style=3D"font-size:12.8px"><span style=3D"=
font-size:12.8px">&gt; skipped in the list (ie, the list is 4 elements long=
) or must it be set to</span><br style=3D"font-size:12.8px"><span style=3D"=
font-size:12.8px">&gt; zero quantity (ie, the list is 5 elements long)?</sp=
an><br></div><div><span style=3D"font-size:12.8px"><br></span></div><div><s=
pan style=3D"font-size:12.8px">Marker output is skipped (explained in the e=
xample)</span></div><div><span style=3D"font-size:12.8px"><br></span></div>=
<div><span style=3D"font-size:12.8px">&gt; Addresses are not used for spend=
ing bitcoins, only for receiving them. The way</span><br style=3D"font-size=
:12.8px"><span style=3D"font-size:12.8px">&gt; this BIP uses inputs&#39; pu=
bkey script is extremely unusual and probably a bad</span><br style=3D"font=
-size:12.8px"><span style=3D"font-size:12.8px">&gt; idea.</span><span style=
=3D"font-size:12.8px"><br></span></div><div><br></div><div>Actually there i=
s no &quot;issuance address&quot;, just the AssetId is defined by the scrip=
tPubKey of the issuer.</div><div><br></div><div><span style=3D"font-size:12=
.8px">&gt; As I understand it, this would require address reuse to setup, w=
hich is not</span><br style=3D"font-size:12.8px"><span style=3D"font-size:1=
2.8px">&gt; supported behaviour and insecure.</span><br></div><div><span st=
yle=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.=
8px">Yes, it requires address reuse for issuing.</span></div><div><span sty=
le=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8=
px">&gt;=C2=A0</span><span style=3D"font-size:12.8px">Won&#39;t an older cl=
ient then accidentally destroy=C2=A0</span><span style=3D"font-size:12.8px"=
>assets?</span></div></div><div><span style=3D"font-size:12.8px"><br></span=
></div><div><span style=3D"font-size:12.8px">Correct. Actually we prevent u=
sers sending asset to wallet which does not support OA via another address =
scheme described in another document (<a href=3D"https://github.com/OpenAss=
ets/open-assets-protocol/blob/master/address-format.mediawiki" target=3D"_b=
lank">https://github.com/OpenAssets/open-assets-protocol/blob/master/addres=
s-format.mediawiki</a>)</span></div><div><span style=3D"font-size:12.8px"><=
br></span></div><div>As said, Open Asset is not a draft proposal and is alr=
eady used in the wild since 2014. We can&#39;t easily modify the protocol b=
y now for improving it.</div><div><div><br></div><div><span style=3D"font-s=
ize:12.8px">PS:=C2=A0<a href=3D"https://github.com/OpenAssets/open-assets-p=
rotocol/blob/master/specification.mediawiki" target=3D"_blank">https://gith=
ub.com/OpenAssets/open-assets-protocol/blob/master/specification.mediawiki<=
/a>=C2=A0is more readable than a mail.</span></div><div><br></div><div>Nico=
las,</div></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">On Tue, Jul 5, 2016 at 7:14 PM, James MacWhyte <span dir=3D"ltr">&lt;<=
a href=3D"mailto:macwhyte@gmail.com" target=3D"_blank">macwhyte@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">I&#39=
;m curious to hear the answers to the questions Luke asked earlier. I also =
read through the documentation and wasn&#39;t convinced it was thought out =
well enough to actually build something on top of, but there&#39;s no reaso=
n it can&#39;t get a number as a work-in-progress.</p>
<p dir=3D"ltr">I hope it does continue to get worked on, though. The lack o=
f response or discussion worries me that it might become an abandoned proje=
ct.</p>
<br><div class=3D"gmail_quote"><div><div><div dir=3D"ltr">On Tue, Jul 5, 20=
16, 18:32 Luke Dashjr via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt; wrote:<br></div></div></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v><div>On Tuesday, July 05, 2016 5:46:36 PM Peter Todd wrote:<br>
&gt; On Thu, May 26, 2016 at 03:53:04AM +0000, Luke Dashjr via bitcoin-dev =
wrote:<br>
&gt; &gt; On Thursday, May 26, 2016 2:50:26 AM Nicolas Dorier via bitcoin-d=
ev wrote:<br>
&gt; &gt; &gt;=C2=A0 =C2=A0Author: Flavien Charlon &lt;<a href=3D"mailto:fl=
avien@charlon.net" target=3D"_blank">flavien@charlon.net</a>&gt;<br>
&gt;<br>
&gt; What&#39;s the status of this BIP? Will it be assigned?<br>
<br>
I was waiting for clarification on the Author thing, but Nicholas hasn&#39;=
t<br>
responded yet. I am unaware of any reason NOT to assign it, and there appea=
r<br>
to be no objections, so let&#39;s call it BIP 160.<br>
<br>
Luke<br></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div><br></div></div>

--001a1140300c04b84905390fe60b--