📅 Original date posted:2023-02-04
🗒️ Summary of this message: Discussion on storing unlimited amounts of NFT content as witness data using the ordinal scheme, with concerns about future disk use and suggestions for imposing size limits or charging premiums.
📝 Original message:On Fri, Feb 3, 2023 at 10:17 PM Melvin Carvalho via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> pá 27. 1. 2023 v 13:47 odesílatel Robert Dickinson via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> napsal:
>
>> 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?
>>
>>
Personally, I was always considering future disk use at full capacity
anyway (and planning accordingly). Even without inscriptions/ordinals that
would happen. The latter competes for block space and are paying tx fees so
I don't see it as that much harmful (esp.now that it is out there... I
would be more conservative if we were talking about introducing it!).
> 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.
>>
>
> Low tech solution: miners charge a premium for storing images in the block
> chain. Say 2x, 5x, 10x.
>
> This encourages bitcoin to be used as a financial network, while
> increasing the security budget.
>
How would you enforce this technically? I only see it feasible if miners
agree by social contract.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230204/864a905e/attachment.html>