📅 Original date posted:2023-02-01
🗒️ Summary of this message: The debate is on the standard for OP_RETURN in Bitcoin, with data limited to 80B and only one allowed per transaction, leading to storage workarounds. Some suggest using spent taproot transactions instead.
📝 Original message:Could someone clarify what is the standard for OP_RETURN? As far as I
understand the data is limited to 80B and only one OP_RETURN is allowed
in one transaction, if not the tx is non standard, correct?
Then the debate can be to store in witness indeed
Or you can store in output addresses (with super big size), then you
will never be able to spend the dust and we have a utxo forever
In any case there is a storage workaround, probably others exist, not
sure why people are so opposed to a OP_RETURN bitcoin storage (I thought
the max size was 512B, but apparently I am wrong, 80B is ridiculous,
can't do anything with this, except bypassing this limit by other worse
means)
Storage is the main difference between bitcoin and other systems
(ethereum), without it, repeating myself here again the future of
bitcoin is very limited
PS: I saw the answer of Peter, I am proposing something else for
timestamp proofs
Le 01/02/2023 à 01:46, Christopher Allen via bitcoin-dev a écrit :
> All other things being equal, which is better if you need to place a
> 64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a
> spent taproot transaction such as:
>
> OP_FALSE
> OP_IF
> OP_PUSH my64bytes
> OP_ENDIF
>
> I know that the anti-OP_RETURN folk would say “neither.” But if there
> was no other choice for a particular protocol, such as a timestamp or
> a commitment, which is better? Or is there a safer place to put 64
> bytes that is more uncensorable but also does not clog UTXO space,
> only spent transaction `-txindex` space?
>
> My best guess was that the taproot method is better, but I suspect
> there might be some who disagree. I'd love to hear all sides.
>
> -- Christopher Allen
>
>
>
> _______________________________________________
> 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/20230201/0fed77e3/attachment-0001.html>;
Aymeric Vitte [ARCHIVE] /
npub15f…g5grz
2023-06-07 23:18:57
in reply to nevent1q…sa2m
Author Public Key
npub15fc36esk6dy2x4ptk2ner209rl9u0d736gr99edtu9knu9uny80s4g5grzPublished at
2023-06-07 23:18:57Event JSON
{
"id": "61218a68a6e2ae9b6764b188f9847286a1b7fa35c67fdf46060e94904cc84f80",
"pubkey": "a2711d6616d348a3542bb2a791a9e51fcbc7b7d1d20652e5abe16d3e179321df",
"created_at": 1686179937,
"kind": 1,
"tags": [
[
"e",
"db7e30240de322a59459e6f6d735c7f019f73c8194514d70467812fbd7606451",
"",
"root"
],
[
"e",
"fab244c9cd27afcefbd2f164dd11741beec7bca556b0a94a963d2f3758474986",
"",
"reply"
],
[
"p",
"a2711d6616d348a3542bb2a791a9e51fcbc7b7d1d20652e5abe16d3e179321df"
]
],
"content": "📅 Original date posted:2023-02-01\n🗒️ Summary of this message: The debate is on the standard for OP_RETURN in Bitcoin, with data limited to 80B and only one allowed per transaction, leading to storage workarounds. Some suggest using spent taproot transactions instead.\n📝 Original message:Could someone clarify what is the standard for OP_RETURN? As far as I\nunderstand the data is limited to 80B and only one OP_RETURN is allowed\nin one transaction, if not the tx is non standard, correct?\n\nThen the debate can be to store in witness indeed\n\nOr you can store in output addresses (with super big size), then you\nwill never be able to spend the dust and we have a utxo forever\n\nIn any case there is a storage workaround, probably others exist, not\nsure why people are so opposed to a OP_RETURN bitcoin storage (I thought\nthe max size was 512B, but apparently I am wrong, 80B is ridiculous,\ncan't do anything with this, except bypassing this limit by other worse\nmeans)\n\nStorage is the main difference between bitcoin and other systems\n(ethereum), without it, repeating myself here again the future of\nbitcoin is very limited\n\nPS: I saw the answer of Peter, I am proposing something else for\ntimestamp proofs\n\nLe 01/02/2023 à 01:46, Christopher Allen via bitcoin-dev a écrit :\n\u003e All other things being equal, which is better if you need to place a\n\u003e 64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a\n\u003e spent taproot transaction such as:\n\u003e\n\u003e OP_FALSE\n\u003e OP_IF \n\u003e OP_PUSH my64bytes\n\u003e OP_ENDIF\n\u003e\n\u003e I know that the anti-OP_RETURN folk would say “neither.” But if there\n\u003e was no other choice for a particular protocol, such as a timestamp or\n\u003e a commitment, which is better? Or is there a safer place to put 64\n\u003e bytes that is more uncensorable but also does not clog UTXO space,\n\u003e only spent transaction `-txindex` space?\n\u003e\n\u003e My best guess was that the taproot method is better, but I suspect\n\u003e there might be some who disagree. I'd love to hear all sides.\n\u003e\n\u003e -- Christopher Allen\n\u003e\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/20230201/0fed77e3/attachment-0001.html\u003e",
"sig": "fe12f153f7389e54624cd4626de0b2fad98fe5a13f851a630a8c5499aa9f516b54396404e218169eb924ca307e569eb2c6e0b2d39ca14518710979ecfa506151"
}