đ
Original date posted:2023-02-04
đď¸ Summary of this message: Increasing the size of OP_RETURN to support a hash, signature, and metadata would be helpful, but inscription-style use cases will still be primarily for larger datasets.
đ Original message:On Fri, Feb 3, 2023 at 10:17 PM Christopher Allen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Feb 3, 2023 at 3:52 AM Aymeric Vitte via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I think the right way so people don't invent deviant things is to
>> increase the size of OP_RETURN, I don't get this number of 80B, you can
>> hardly store a signature (of what?) in there and not the "what" if the
>> "what" is a hash for example
>>
>
> Updating the size of OP_RETURN to support a hash (or two), a signature,
> and maybe a few more bytes for metadata, would be very helpful in a number
> of scenarios. It is still a limit but a reasonable one. Otherwise, I think
> we'll have a lot more inscription-style scenarios.
>
I wouldn't be against an increase in OP_RETURN but I don't think it will
make any difference in how often inscription-style use cases will be used.
They will be used primarily for much larger datasets than, say 120 bytes,
and they also have the segwit discount.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230204/c2c7730d/attachment.html>;
Kostas Karasavvas [ARCHIVE] /
npub1tqâŚy3e9m
2023-06-08 01:18:58
in reply to nevent1qâŚzkg3
Author Public Key
npub1tqac06nxg94veg9atxfktrfdwpl2a4snw2xdrt52ek5893jnnkkqey3e9mPublished at
2023-06-08 01:18:58Event JSON
{
"id": "ae8450f09b8ebbd792c8fe7922ed063197a62902bdab9ad2c07368ec3f0388c8",
"pubkey": "583b87ea66416acca0bd5993658d2d707eaed613728cd1ae8acda872c6539dac",
"created_at": 1686179938,
"kind": 1,
"tags": [
[
"e",
"db7e30240de322a59459e6f6d735c7f019f73c8194514d70467812fbd7606451",
"",
"root"
],
[
"e",
"0f737219f8c9557ceaa5e8e04876b2057d1dfb210bf31e5e0f2e25351fc92de9",
"",
"reply"
],
[
"p",
"2a2be7532ec03e16fa6ff38360d30cc714893870cbd9fafbefeb1df2df858c4d"
]
],
"content": "đ
Original date posted:2023-02-04\nđď¸ Summary of this message: Increasing the size of OP_RETURN to support a hash, signature, and metadata would be helpful, but inscription-style use cases will still be primarily for larger datasets.\nđ Original message:On Fri, Feb 3, 2023 at 10:17 PM Christopher Allen via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Fri, Feb 3, 2023 at 3:52 AM Aymeric Vitte via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e I think the right way so people don't invent deviant things is to\n\u003e\u003e increase the size of OP_RETURN, I don't get this number of 80B, you can\n\u003e\u003e hardly store a signature (of what?) in there and not the \"what\" if the\n\u003e\u003e \"what\" is a hash for example\n\u003e\u003e\n\u003e\n\u003e Updating the size of OP_RETURN to support a hash (or two), a signature,\n\u003e and maybe a few more bytes for metadata, would be very helpful in a number\n\u003e of scenarios. It is still a limit but a reasonable one. Otherwise, I think\n\u003e we'll have a lot more inscription-style scenarios.\n\u003e\n\nI wouldn't be against an increase in OP_RETURN but I don't think it will\nmake any difference in how often inscription-style use cases will be used.\nThey will be used primarily for much larger datasets than, say 120 bytes,\nand they also have the segwit discount.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230204/c2c7730d/attachment.html\u003e",
"sig": "6903969b371cbf8322668642056590af21dcec43bde9a741a26aff035fb04f26048e5bcb5a928b5fa007e32851dc6c4476656e16d35bfa0004a12bc1a966f9a3"
}