📅 Original date posted:2023-02-06
🗒️ Summary of this message: The use of inscriptions to store NFT content on the Bitcoin chain is a topic of discussion among developers, with concerns about unlimited storage and potential malicious content. A size limit similar to OP_RETURN may be necessary, and an opt-out feature for potentially harmful content should be considered. However, the ordinal scheme is praised for its elegance and potential use in linking real-world property ownership to the blockchain.
📝 Original message:The inscriptions are designed to be easy to use, they even specify that
mime types should be used. I'd say, the way the data is stored is anything
but 'obscure'. UIs will be popping up to make this really easy. The main
chain can't be censored, what's in a block is in a block. I'm predicting a
huge success.
So, are we ready to accept that we'll likely see the first pictures with
insults or worse in the Bitcoin chain? I really like the idea, but the risk
is pretty obvious. I think it would be prudent to have at least an opt-out
feature for the data. So that it's possible to use the chain without the
potentially malicious content. That means the content shouldn't live in the
essential data of the main chain. Better would be something like the
extension blocks in Litecoin.
Best Regards
Claus
On Fri, Jan 27, 2023 at 1:47 PM Robert Dickinson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I'm curious what opinions exist and what actions might be taken by core
> developers regarding storing unlimited amounts of NFT (or other?) content
> as witness data (https://docs.ordinals.com/inscriptions.html). The
> ordinal scheme is elegant and genius IMHO, but when I think about the
> future disk use of all unpruned nodes, I question whether unlimited storage
> is wise to allow for such use cases. Wouldn't it be better to find a way to
> impose a size limit similar to OP_RETURN for such inscriptions?
>
> I think it would be useful to link a sat to a deed or other legal
> construct for proof of ownership in the real world, so that real property
> can be transferred on the blockchain using ordinals, but storing the
> property itself on the blockchain seems nonsensical to me.
> _______________________________________________
> 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/20230206/b8d52343/attachment.html>;
Claus Ehrenberg [ARCHIVE] /
npub1a8…e3wff
2023-06-07 23:19:21
in reply to nevent1q…nuk2
Author Public Key
npub1a8ck0asqq2y93057qzj5laj2c67mrdssw65txe5kr84g3a80v2nqye3wffPublished at
2023-06-07 23:19:21Event JSON
{
"id": "d76eebbb06d3c0a2e42dd0430fd3b0731346b785e01e6708633c968b67bb1341",
"pubkey": "e9f167f600028858be9e00a54ff64ac6bdb1b61076a8b3669619ea88f4ef62a6",
"created_at": 1686179961,
"kind": 1,
"tags": [
[
"e",
"34d6db3ddc3108e56564b6dcf8c8c3859e42db2015a3d0f2385689a789ea7ebf",
"",
"root"
],
[
"e",
"b37528da4b8c20fa3aedb7d4f498b285c4341a40f1bf313b9e79f1b352b0e896",
"",
"reply"
],
[
"p",
"22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa"
]
],
"content": "📅 Original date posted:2023-02-06\n🗒️ Summary of this message: The use of inscriptions to store NFT content on the Bitcoin chain is a topic of discussion among developers, with concerns about unlimited storage and potential malicious content. A size limit similar to OP_RETURN may be necessary, and an opt-out feature for potentially harmful content should be considered. However, the ordinal scheme is praised for its elegance and potential use in linking real-world property ownership to the blockchain.\n📝 Original message:The inscriptions are designed to be easy to use, they even specify that\nmime types should be used. I'd say, the way the data is stored is anything\nbut 'obscure'. UIs will be popping up to make this really easy. The main\nchain can't be censored, what's in a block is in a block. I'm predicting a\nhuge success.\n\nSo, are we ready to accept that we'll likely see the first pictures with\ninsults or worse in the Bitcoin chain? I really like the idea, but the risk\nis pretty obvious. I think it would be prudent to have at least an opt-out\nfeature for the data. So that it's possible to use the chain without the\npotentially malicious content. That means the content shouldn't live in the\nessential data of the main chain. Better would be something like the\nextension blocks in Litecoin.\n\nBest Regards\nClaus\n\nOn Fri, Jan 27, 2023 at 1:47 PM Robert Dickinson via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I'm curious what opinions exist and what actions might be taken by core\n\u003e developers regarding storing unlimited amounts of NFT (or other?) content\n\u003e as witness data (https://docs.ordinals.com/inscriptions.html). The\n\u003e ordinal scheme is elegant and genius IMHO, but when I think about the\n\u003e future disk use of all unpruned nodes, I question whether unlimited storage\n\u003e is wise to allow for such use cases. Wouldn't it be better to find a way to\n\u003e impose a size limit similar to OP_RETURN for such inscriptions?\n\u003e\n\u003e I think it would be useful to link a sat to a deed or other legal\n\u003e construct for proof of ownership in the real world, so that real property\n\u003e can be transferred on the blockchain using ordinals, but storing the\n\u003e property itself on the blockchain seems nonsensical to me.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230206/b8d52343/attachment.html\u003e",
"sig": "bb22e94d73ef1efe5bcbf3b4aff3632fadbd16d1b19642929375def9a9c9db17a0439f831d2482f7a6732050f206cb828273de9b9d72782e0e67df131cabad0e"
}