📅 Original date posted:2021-04-20
📝 Original message:Zach,
Thanks for the comments. I just sent out another email to the dev alias
with the other two BIPs that I mentioned last week. It is pending approval
now. I think it will talk about some of the things you mentioned. To avoid
having a lot of comments about those BIPs on this thread, let's use the new
thread for discussing those BIPs.
--Chris
On Tue, Apr 20, 2021 at 1:45 AM Zach Greenwood <zachgrw at gmail.com> wrote:
> [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/4995536f/attachment-0001.html>;
Christopher Gilliard [ARCHIVE] /
npub1qm…0hwnt
2023-06-07 22:51:49
in reply to nevent1q…0a4a
Author Public Key
npub1qmsejphez6np2my9fu40kj9en68d5fa3s7ap4ul7eh9aeuljusgs50hwntPublished at
2023-06-07 22:51:49Event JSON
{
"id": "72dcfb44783a59fc366d2f6e6815ba81a5516dac39aa9dc7640b97c0f2220843",
"pubkey": "06e19906f916a6156c854f2afb48b99e8eda27b187ba1af3fecdcbdcf3f2e411",
"created_at": 1686178309,
"kind": 1,
"tags": [
[
"e",
"603f39678bcc9e8e30f94bfe6386763f2e249a0ec7bc1f247dad6d882215065d",
"",
"root"
],
[
"e",
"0d03136acf439338a5c45559b4d6bbbf2daae15ce9fa2da9321503a645f2ff54",
"",
"reply"
],
[
"p",
"5ef3122d212705b4091e178e6421f4e2b52d9b71483874c61e473c4f70e765f0"
]
],
"content": "📅 Original date posted:2021-04-20\n📝 Original message:Zach,\n\nThanks for the comments. I just sent out another email to the dev alias\nwith the other two BIPs that I mentioned last week. It is pending approval\nnow. I think it will talk about some of the things you mentioned. To avoid\nhaving a lot of comments about those BIPs on this thread, let's use the new\nthread for discussing those BIPs.\n\n--Chris\n\nOn Tue, Apr 20, 2021 at 1:45 AM Zach Greenwood \u003czachgrw at gmail.com\u003e wrote:\n\n\u003e [Note: this is my first post to the list]\n\u003e\n\u003e Businesses storing data on-chain is undesirable but sadly unavoidable.\n\u003e Therefore one might as well *facilitate* data storage beyond just OP_RETURN\n\u003e by offering a more efficient way to store data on-chain, while still being\n\u003e almost as expensive in use per byte of payload (i.e., data) compared to\n\u003e using OP_RETURN.\n\u003e\n\u003e Storing data using OP_RETURN is still inefficient per byte of payload so a\n\u003e more efficient dedicated data storing facility might be created that stores\n\u003e more payload data per on-chain byte. Such a facility should be (marginally)\n\u003e cheaper to use per payload byte compared to using a hack such as OP_RETURN.\n\u003e This would encourage the use of this facility in favor of OP_RETURN or\n\u003e other hacks, while at the same time dramatically reducing the footprint of\n\u003e storing data on-chain.\n\u003e\n\u003e Zac\n\u003e\n\u003e On Tue, Apr 20, 2021 at 4:29 AM yanmaani--- via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e \u003e If only one hash is allowed per block, then those who wish to utilize\n\u003e\u003e \u003e the hash will have to out-bid each other (\"fee-bidding\"). This hash can\n\u003e\u003e \u003e then be used to create another chain (\"merged-mining\")\n\u003e\u003e\n\u003e\u003e Merged mining at present only needs one hash for a merkle root, and\n\u003e\u003e that's stored in the coinbase. It would be even simpler to add the\n\u003e\u003e following rules:\n\u003e\u003e\n\u003e\u003e 1) No OP_RETURN transactions allowed at all\n\u003e\u003e 2) If you want to commit data, do so in that one transaction in the\n\u003e\u003e coinbase\n\u003e\u003e\n\u003e\u003e Also curious about how you'd handle the payment - do I need to put in a\n\u003e\u003e transaction that burns bitcoins for the tx fee? That isn't free in terms\n\u003e\u003e of storage either.\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/20210420/4995536f/attachment-0001.html\u003e",
"sig": "ccf1740f994b702a9f62356721096b9fa699b61189d4c74672187e97bf1fb81d2058692a8d067daa9b1f966b9f73d50e9e6f27415352ab8cae901e2f6cb8a856"
}