📅 Original date posted:2016-08-02
📝 Original message: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 at 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 at 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160801/7028265d/attachment.html>;
Nicolas Dorier [ARCHIVE] /
npub1hu…9q4u3
2023-06-07 17:52:07
in reply to nevent1q…f700
Author Public Key
npub1huz53hq26gu7nc0qhw3uj6tr9hk5q2ngpywduxep5zy4ay9unftsm9q4u3Published at
2023-06-07 17:52:07Event JSON
{
"id": "990d56b2fcdc8ba0653e509b0881db8215cb8afc51853d4009fcd4d0019da52e",
"pubkey": "bf0548dc0ad239e9e1e0bba3c969632ded402a68091cde1b21a0895e90bc9a57",
"created_at": 1686160327,
"kind": 1,
"tags": [
[
"e",
"0783d681e47ad95de85334a9475b6d99aaf4ff98031409a24b5b1988373a8ca0",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2016-08-02\n📝 Original message:Sorry, I completely forgot about having submitted the BIP as I was busy at\nthis time.\nThanks for the review.\n\nOpen Asset is actually not an abandoned project and is a protocol already\nused in production with multiple implementation.\nWallet: https://www.coinprism.com/\nImplementation C#: https://github.com/NicolasDorier/NBitcoin with heavy\ndocumentation (\nhttps://programmingblockchain.gitbooks.io/programmingblockchain/content/other_types_of_asset/colored_coins.html\n)\nImplementation Ruby: https://github.com/haw-itn/openassets-ruby/\nUsage stats: http://opreturn.org/\n\nConcerning whether or not we can put my name in the BIP, I'll ask the\noriginal author that I know personally.\n\n\u003e Quite a bit ugly, giving a meaning to an input's pubkey script like that.\n\u003e But more problematically: how can this work with other pubkey scripts?\n\u003e Particularly relevant now that this old script format is being deprecated.\n\u003e Another possible problem is that I don't see a way to provably guarantee\nan\n\u003e asset issuance is final.\n\nYes, with open asset it is not possible to do provably limited issuance.\nThe scriptPubKey can be anything, not necessarily P2PK.\nIf you can spend the scriptPubkey, then you are the issuer.\n\n\u003e And the assets attached to its inputs are destroyed? Or?\n\nCorrect, if you spend a colored output incorrectly, it is effectively\ndestroyed.\n\n\u003e Is it intentional that the first case is \"parsable\", and the second\n\"valid\"?\n\u003e I think these need to be better specified; for example, it is not so\nclear how\n\u003e to reach if the OAP version number is something other than 1: is that\n\u003e parsable? valid?\n\nThe terminology is correct we are parsing PUSHDATA, if there is a parsable\npushdata, the output is considered valid.\nIf there is multiple valid output, then we take the first one.\n\n\u003e What determines the asset id? How would one issue and/or transfer multiple\n\u003e asset ids in the same transaction?\n\nYou can't issue more than one asset type in a transaction. (as the asset\nissued is defined by the scriptPubKey of the first input)\nFor multiple transfer it is possible, imagine a transaction with the\nfollowing 3 inputs and 6 outputs:\n\nInputs: {0, 10a, 20b}\nOutputs: {5, OP_RETURN; 7; 3; 11; 9)\n\nInputs1: 0\nInputs2: Enqueue 10a in the queue ( {10a} )\nInput3: Enqueue 20b in the queue ( { 20b, 10a} )\n\nOutput1: Before OP_RETURN, so is issuance whose color is defined by the\nscriptPubKey of Input1. (say c)\nOutput2: No color (marker)\nOutput3: Dequeue 7a ( {20b, 3a} ), color output with a.\nOutput4: Dequeue 3a ( {20b} ), color output with a\nOutput5: Dequeue 11b ( {9b} ), color output with b\nOutput5: Dequeue 9b ( {0} ), color output with b\n\nFinally, outputs color are\nOutputs: {5c, OP_RETURN; 7a; 3a; 11b; 9b)\n\n\u003e What if I have a transaction with 5 outputs, the marker output at\nposition 3,\n\u003e and all 4 other outputs are to receive assets? Does the marker output get\n\u003e skipped in the list (ie, the list is 4 elements long) or must it be set to\n\u003e zero quantity (ie, the list is 5 elements long)?\n\nMarker output is skipped (explained in the example)\n\n\u003e Addresses are not used for spending bitcoins, only for receiving them.\nThe way\n\u003e this BIP uses inputs' pubkey script is extremely unusual and probably a\nbad\n\u003e idea.\n\nActually there is no \"issuance address\", just the AssetId is defined by the\nscriptPubKey of the issuer.\n\n\u003e As I understand it, this would require address reuse to setup, which is\nnot\n\u003e supported behaviour and insecure.\n\nYes, it requires address reuse for issuing.\n\n\u003e Won't an older client then accidentally destroy assets?\n\nCorrect. Actually we prevent users sending asset to wallet which does not\nsupport OA via another address scheme described in another document (\nhttps://github.com/OpenAssets/open-assets-protocol/blob/master/address-format.mediawiki\n)\n\nAs said, Open Asset is not a draft proposal and is already used in the wild\nsince 2014. We can't easily modify the protocol by now for improving it.\n\nPS:\nhttps://github.com/OpenAssets/open-assets-protocol/blob/master/specification.mediawiki\nis\nmore readable than a mail.\n\nNicolas,\n\nOn Tue, Jul 5, 2016 at 7:14 PM, James MacWhyte \u003cmacwhyte at gmail.com\u003e wrote:\n\n\u003e I'm curious to hear the answers to the questions Luke asked earlier. I\n\u003e also read through the documentation and wasn't convinced it was thought out\n\u003e well enough to actually build something on top of, but there's no reason it\n\u003e can't get a number as a work-in-progress.\n\u003e\n\u003e I hope it does continue to get worked on, though. The lack of response or\n\u003e discussion worries me that it might become an abandoned project.\n\u003e\n\u003e On Tue, Jul 5, 2016, 18:32 Luke Dashjr via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e On Tuesday, July 05, 2016 5:46:36 PM Peter Todd wrote:\n\u003e\u003e \u003e On Thu, May 26, 2016 at 03:53:04AM +0000, Luke Dashjr via bitcoin-dev\n\u003e\u003e wrote:\n\u003e\u003e \u003e \u003e On Thursday, May 26, 2016 2:50:26 AM Nicolas Dorier via bitcoin-dev\n\u003e\u003e wrote:\n\u003e\u003e \u003e \u003e \u003e Author: Flavien Charlon \u003cflavien at charlon.net\u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e What's the status of this BIP? Will it be assigned?\n\u003e\u003e\n\u003e\u003e I was waiting for clarification on the Author thing, but Nicholas hasn't\n\u003e\u003e responded yet. I am unaware of any reason NOT to assign it, and there\n\u003e\u003e appear\n\u003e\u003e to be no objections, so let's call it BIP 160.\n\u003e\u003e\n\u003e\u003e Luke\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160801/7028265d/attachment.html\u003e",
"sig": "f9bff13d6a4bce8ce6b14413b12a46b8d5819a3f0f518c2150fe44a0828846afd4b34c705fe05466ba385bf434d9a79c9d3da120922bae0ec0281e6bd23a29db"
}