📅 Original date posted:2021-04-20 📝 Original message:[Note: this is my first ...

Zach Greenwood [ARCHIVE] /

npub1tme…0ncu

2023-06-07 22:51:49

in reply to nevent1q…ltpd

📅 Original date posted:2021-04-20
📝 Original message:[Note: this is my first post to the list]

Businesses storing data on-chain is undesirable but sadly unavoidable.
Therefore one might as well *facilitate* data storage beyond just OP_RETURN
by offering a more efficient way to store data on-chain, while still being
almost as expensive in use per byte of payload (i.e., data) compared to
using OP_RETURN.

Storing data using OP_RETURN is still inefficient per byte of payload so a
more efficient dedicated data storing facility might be created that stores
more payload data per on-chain byte. Such a facility should be (marginally)
cheaper to use per payload byte compared to using a hack such as OP_RETURN.
This would encourage the use of this facility in favor of OP_RETURN or
other hacks, while at the same time dramatically reducing the footprint of
storing data on-chain.

Zac

On Tue, Apr 20, 2021 at 4:29 AM yanmaani--- via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> > If only one hash is allowed per block, then those who wish to utilize
> > the hash will have to out-bid each other ("fee-bidding"). This hash can
> > then be used to create another chain ("merged-mining")
>
> Merged mining at present only needs one hash for a merkle root, and
> that's stored in the coinbase. It would be even simpler to add the
> following rules:
>
> 1) No OP_RETURN transactions allowed at all
> 2) If you want to commit data, do so in that one transaction in the
> coinbase
>
> Also curious about how you'd handle the payment - do I need to put in a
> transaction that burns bitcoins for the tx fee? That isn't free in terms
> of storage either.
> _______________________________________________
> 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/20210420/3f57baae/attachment.html>;

Author Public Key

npub1tme3ytfpyuzmgzg7z78xgg05u26jmxm3fqu8f3s7gu7y7u88vhcq7c0ncu

Show more details

Published at

2023-06-07 22:51:49

Kind type

1 Short Text Note

Event JSON

{ "id": "0d03136acf439338a5c45559b4d6bbbf2daae15ce9fa2da9321503a645f2ff54", "pubkey": "5ef3122d212705b4091e178e6421f4e2b52d9b71483874c61e473c4f70e765f0", "created_at": 1686178309, "kind": 1, "tags": [ [ "e", "603f39678bcc9e8e30f94bfe6386763f2e249a0ec7bc1f247dad6d882215065d", "", "root" ], [ "e", "36f01c736da96df2b4fb77a880fee0c4851024e1dbae321fde620cd7923a398b", "", "reply" ], [ "p", "8f5bcf9ba2de88dd877a672f629a5c6a7bebbeda3fa51324521e03863d8fe094" ] ], "content": "📅 Original date posted:2021-04-20\n📝 Original message:[Note: this is my first post to the list]\n\nBusinesses storing data on-chain is undesirable but sadly unavoidable.\nTherefore one might as well *facilitate* data storage beyond just OP_RETURN\nby offering a more efficient way to store data on-chain, while still being\nalmost as expensive in use per byte of payload (i.e., data) compared to\nusing OP_RETURN.\n\nStoring data using OP_RETURN is still inefficient per byte of payload so a\nmore efficient dedicated data storing facility might be created that stores\nmore payload data per on-chain byte. Such a facility should be (marginally)\ncheaper to use per payload byte compared to using a hack such as OP_RETURN.\nThis would encourage the use of this facility in favor of OP_RETURN or\nother hacks, while at the same time dramatically reducing the footprint of\nstoring data on-chain.\n\nZac\n\nOn Tue, Apr 20, 2021 at 4:29 AM yanmaani--- via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e \u003e If only one hash is allowed per block, then those who wish to utilize\n\u003e \u003e the hash will have to out-bid each other (\"fee-bidding\"). This hash can\n\u003e \u003e then be used to create another chain (\"merged-mining\")\n\u003e\n\u003e Merged mining at present only needs one hash for a merkle root, and\n\u003e that's stored in the coinbase. It would be even simpler to add the\n\u003e following rules:\n\u003e\n\u003e 1) No OP_RETURN transactions allowed at all\n\u003e 2) If you want to commit data, do so in that one transaction in the\n\u003e coinbase\n\u003e\n\u003e Also curious about how you'd handle the payment - do I need to put in a\n\u003e transaction that burns bitcoins for the tx fee? That isn't free in terms\n\u003e of storage either.\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/20210420/3f57baae/attachment.html\u003e", "sig": "f95f952bb08e4ad4538ac1464f43686e404c2874c4524e5695f62801a79e5cab0328e0a94d86bcfb9b54ea274481b78790668172a2550675cdb1ca9afdd84383" }