📅 Original date posted:2014-11-17
📝 Original message:On Mon, Nov 17, 2014 at 12:43 PM, Flavien Charlon
<flavien.charlon at coinprism.com> wrote:
>> My main concern with OP_RETURN is that it seems to encourage people to use
>> the blockchain as a convenient transport channel
>
> The number one user of the blockchain as a storage and transport mechanism
> is Counterparty, and limiting OP_RETURN to 40 bytes didn't prevent them from
> doing so. In fact they use multi-sig outputs which is worse than OP_RETURN
> since it's not always prunable, and yet let them store much more than 40
> bytes.
It wasn't limited to stop them from using it. It was limited to avoid
giving others the impression that OP_RETURN was intended for data
storage. For the intended purpose (making a transaction commit to some
external data) a 32-byte hash + 8 byte id is more than sufficient.
> For Open Assets, we need to store a URL in the OP_RETURN output (with
> optionally a hash) plus some bytes of overhead. 40 bytes comes really short
> for that. The benefit of having a URL in there is that any storage mechanism
> can be used (Web, FTP, BitTorrent, MaidSafe...), whereas with only a hash,
> you have to hardcode the storing mechanism in the protocol (and even then, a
> hash is not enough to address a HTTP or FTP resource). Storing only a hash
> is fine for the most basic timestamping application, but it's hardly enough
> to build something interesting.
Do you really need that data published to everyone? You're at the very
least exposing yourself to censorship, and (depending on the design)
potentially decreased privacy for your users. I would expect that for
most colored coin applications, just having the color transfer
information in external data sent directly to the receiver with
transactions committing to it should suffice.
--
Pieter
Pieter Wuille [ARCHIVE] /
npub1tj…jtl6r
2023-06-07 15:27:30
in reply to nevent1q…wtvg
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rPublished at
2023-06-07 15:27:30Event JSON
{
"id": "9d55d26c0dbcd7e665642e3e0cfafc739ab7eebc0fe38374420d54ac0eed903e",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686151650,
"kind": 1,
"tags": [
[
"e",
"9ea4322dc19e55ba7a16fb4778826be5d9520c59d79239c258ee43cc77449b49",
"",
"root"
],
[
"e",
"b2e2d23c56f687c060691e9247d78008a14bc403290459724040594a8ac4a287",
"",
"reply"
],
[
"p",
"b547fc2b2933799322cbf35a54c99d7b87d230e7dbb2e4ae62df07fc8a733161"
]
],
"content": "📅 Original date posted:2014-11-17\n📝 Original message:On Mon, Nov 17, 2014 at 12:43 PM, Flavien Charlon\n\u003cflavien.charlon at coinprism.com\u003e wrote:\n\u003e\u003e My main concern with OP_RETURN is that it seems to encourage people to use\n\u003e\u003e the blockchain as a convenient transport channel\n\u003e\n\u003e The number one user of the blockchain as a storage and transport mechanism\n\u003e is Counterparty, and limiting OP_RETURN to 40 bytes didn't prevent them from\n\u003e doing so. In fact they use multi-sig outputs which is worse than OP_RETURN\n\u003e since it's not always prunable, and yet let them store much more than 40\n\u003e bytes.\n\nIt wasn't limited to stop them from using it. It was limited to avoid\ngiving others the impression that OP_RETURN was intended for data\nstorage. For the intended purpose (making a transaction commit to some\nexternal data) a 32-byte hash + 8 byte id is more than sufficient.\n\n\u003e For Open Assets, we need to store a URL in the OP_RETURN output (with\n\u003e optionally a hash) plus some bytes of overhead. 40 bytes comes really short\n\u003e for that. The benefit of having a URL in there is that any storage mechanism\n\u003e can be used (Web, FTP, BitTorrent, MaidSafe...), whereas with only a hash,\n\u003e you have to hardcode the storing mechanism in the protocol (and even then, a\n\u003e hash is not enough to address a HTTP or FTP resource). Storing only a hash\n\u003e is fine for the most basic timestamping application, but it's hardly enough\n\u003e to build something interesting.\n\nDo you really need that data published to everyone? You're at the very\nleast exposing yourself to censorship, and (depending on the design)\npotentially decreased privacy for your users. I would expect that for\nmost colored coin applications, just having the color transfer\ninformation in external data sent directly to the receiver with\ntransactions committing to it should suffice.\n\n-- \nPieter",
"sig": "bd25c2ea27874b47215d5adcb1b821566f8ebcb8ac00e92c51464d2b7eb78208e7099a550f1f26cc0a8652f75f277e86b10444d0f5b678964a30cc2491d453ce"
}