📅 Original date posted:2023-02-04
🗒️ Summary of this message: Increasing the size of OP_RETURN to store proofs that can be checked using a third party/sidechain is reasonable, but storing on-chain is absurd.
📝 Original message:I don't get very well where all the current (other threats) discussions
are going, storing on-chain is absurd
It's absurd also to flood bitcoin with several useless transactions to
store in witness or others, looks like ethereum messy stuff
What is not absurd is to store the proofs that can be checked using a
notorious third party/sidechain but you need more than 80B
What is the official bitcoin channel to request the OP_RETURN size
change? (press often mentions that ethereum is good to manage changes
and bitcoin a complete zero)
As a very bad solution, I think I would be willing to store data in
addresses, with one single transaction, as people did in the past, then
burning bitcoins but still not expensive, or less than several txs,
because schemes involving several transactions do not work very well
In any case, we see the problem, then people will invent something and
most likely it will not comply at all with bitcoin good practices
Le 04/02/2023 à 15:11, Kostas Karasavvas via bitcoin-dev a écrit :
>
>
> On Fri, Feb 3, 2023 at 10:17 PM Christopher Allen via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto: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
> <mailto: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.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230204/5dfda935/attachment.html>;
Aymeric Vitte [ARCHIVE] /
npub15f…g5grz
2023-06-07 23:18:58
in reply to nevent1q…t9sd
Author Public Key
npub15fc36esk6dy2x4ptk2ner209rl9u0d736gr99edtu9knu9uny80s4g5grzPublished at
2023-06-07 23:18:58Event JSON
{
"id": "5dd6cb39d5b6a01a7e2b11b987b56e11f600ed8361c0aae38f929e2a7d081424",
"pubkey": "a2711d6616d348a3542bb2a791a9e51fcbc7b7d1d20652e5abe16d3e179321df",
"created_at": 1686179938,
"kind": 1,
"tags": [
[
"e",
"db7e30240de322a59459e6f6d735c7f019f73c8194514d70467812fbd7606451",
"",
"root"
],
[
"e",
"ae8450f09b8ebbd792c8fe7922ed063197a62902bdab9ad2c07368ec3f0388c8",
"",
"reply"
],
[
"p",
"583b87ea66416acca0bd5993658d2d707eaed613728cd1ae8acda872c6539dac"
]
],
"content": "📅 Original date posted:2023-02-04\n🗒️ Summary of this message: Increasing the size of OP_RETURN to store proofs that can be checked using a third party/sidechain is reasonable, but storing on-chain is absurd.\n📝 Original message:I don't get very well where all the current (other threats) discussions\nare going, storing on-chain is absurd\n\nIt's absurd also to flood bitcoin with several useless transactions to\nstore in witness or others, looks like ethereum messy stuff\n\nWhat is not absurd is to store the proofs that can be checked using a\nnotorious third party/sidechain but you need more than 80B\n\nWhat is the official bitcoin channel to request the OP_RETURN size\nchange? (press often mentions that ethereum is good to manage changes\nand bitcoin a complete zero)\n\nAs a very bad solution, I think I would be willing to store data in\naddresses, with one single transaction, as people did in the past, then\nburning bitcoins but still not expensive, or less than several txs,\nbecause schemes involving several transactions do not work very well\n\nIn any case, we see the problem, then people will invent something and\nmost likely it will not comply at all with bitcoin good practices\n\n\nLe 04/02/2023 à 15:11, Kostas Karasavvas via bitcoin-dev a écrit :\n\u003e\n\u003e\n\u003e On Fri, Feb 3, 2023 at 10:17 PM Christopher Allen via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e\n\u003e On Fri, Feb 3, 2023 at 3:52 AM Aymeric Vitte via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e\n\u003e I think the right way so people don't invent deviant things is to\n\u003e increase the size of OP_RETURN, I don't get this number of\n\u003e 80B, you can\n\u003e hardly store a signature (of what?) in there and not the\n\u003e \"what\" if the\n\u003e \"what\" is a hash for example\n\u003e\n\u003e\n\u003e Updating the size of OP_RETURN to support a hash (or two), a\n\u003e signature, and maybe a few more bytes for metadata, would be very\n\u003e helpful in a number of scenarios. It is still a limit but a\n\u003e reasonable one. Otherwise, I think we'll have a lot more\n\u003e inscription-style scenarios.\n\u003e\n\u003e\n\u003e I wouldn't be against an increase in OP_RETURN but I don't think it\n\u003e will make any difference in how often inscription-style use cases will\n\u003e be used. They will be used primarily for much larger datasets than,\n\u003e say 120 bytes, and they also have the segwit discount.\n\u003e\n\u003e\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\n-- \nSophia-Antipolis, France\nCV: https://www.peersm.com/CVAV.pdf\nLinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26\nGitHub : https://www.github.com/Ayms\nA Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7\nA bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7\nMove your coins by yourself (browser version): https://peersm.com/wallet\nBitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions\ntorrent-live: https://github.com/Ayms/torrent-live\nnode-Tor : https://www.github.com/Ayms/node-Tor\nAnti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com\nPeersm : http://www.peersm.com\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230204/5dfda935/attachment.html\u003e",
"sig": "9ec036b5ce6302af47a41858207d09f03d1218daa6b41ed1de3e9facf66dc9e178adad0eff49136dded31a1b4a2dd02868c2284a26e28863e3014f189063cf4a"
}