n0nce
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 31, 2022, 11:09:58 PM Last edit: May 31, 2022, 11:21:05 PM by n0nce |
|
Bitcoin is a payment system and its blockchain is a place to store payment history not arbitrary messages.
Sadly bitcoin offers a solution to store such messages through an OP_RETURN output and the standard size limit for that is 80 bytes.
Bitcoin isn't what "pooya87" says it is. ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif) I'm siding with pooya87. Sure, you can store data using OP_RETURN, but is it really needed for a dozen thousand nodes [1] to store a copy of it? If everyone starts doing this, the blockchain gets crowded with (probably pointless) 'data transactions' and actual 'value transactions' have to wait longer or pay more. This data also needs to be stored forever, by everyone; I think this is only required in the most extreme edge cases, like the genesis block, which did this to prove there was no premine. Only because the genesis block [2] stored data, doesn't mean every block should. Since the other blocks are not the genesis block.. ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) 00000000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 3B A3 ED FD 7A 7B 12 B2 7A C7 2C 3E ....;£íýz{.²zÇ,> 00000030 67 76 8F 61 7F C8 1B C3 88 8A 51 32 3A 9F B8 AA gv.a.È.ÈŠQ2:Ÿ¸ª 00000040 4B 1E 5E 4A 29 AB 5F 49 FF FF 00 1D 1D AC 2B 7C K.^J)«_Iÿÿ...¬+| 00000050 01 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 ................ 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000070 00 00 00 00 00 00 FF FF FF FF 4D 04 FF FF 00 1D ......ÿÿÿÿM.ÿÿ.. 00000080 01 04 45 54 68 65 20 54 69 6D 65 73 20 30 33 2F ..EThe Times 03/ 00000090 4A 61 6E 2F 32 30 30 39 20 43 68 61 6E 63 65 6C Jan/2009 Chancel 000000A0 6C 6F 72 20 6F 6E 20 62 72 69 6E 6B 20 6F 66 20 lor on brink of 000000B0 73 65 63 6F 6E 64 20 62 61 69 6C 6F 75 74 20 66 second bailout f 000000C0 6F 72 20 62 61 6E 6B 73 FF FF FF FF 01 00 F2 05 or banksÿÿÿÿ..ò. 000000D0 2A 01 00 00 00 43 41 04 67 8A FD B0 FE 55 48 27 *....CA.gŠý°þUH' 000000E0 19 67 F1 A6 71 30 B7 10 5C D6 A8 28 E0 39 09 A6 .gñ¦q0·.\Ö¨(à9.¦ 000000F0 79 62 E0 EA 1F 61 DE B6 49 F6 BC 3F 4C EF 38 C4 ybàê.aÞ¶Iö¼?Lï8Ä 00000100 F3 55 04 E5 1E C1 12 DE 5C 38 4D F7 BA 0B 8D 57 óU.å.Á.Þ\8M÷º..W 00000110 8A 4C 70 2B 6B F1 1D 5F AC 00 00 00 00 ŠLp+kñ._¬....
If you don't know how to encode ASCII as hexadecimal, I'm not sure you should try writing data to the Bitcoin blockchain. But I'll leave this here anyway: $ echo "hello bitcointalk" | xxd -p
[1] https://bitnodes.io/[2] https://en.bitcoin.it/wiki/Genesis_block
|
|
|
|
ranochigo
Legendary
Offline
Activity: 3038
Merit: 4418
Crypto Swap Exchange
|
I'm not sure why are the responses in this thread so hostile towards OP_return. The 80bytes limit is fairly reasonable, not to mention that users are required to pay for the junk that they store. Without OP_return, you would have people using transaction scripts to store junk, which presents an even bigger problem to blockchain bloat.
OP_return is a provable burn, which means that the data are not stored in a chainstate, which is good so that we don't have to waste additional storage to store these things that can't be spent eitherways. If we didn't provide OP_return, then users would be inserting arbitrary data into their P2PKH script, which would present an even bigger problem because it is also stored in the UTXO set even though it would never be spent.
|
|
|
|
garlonicon
Legendary
Offline
Activity: 850
Merit: 2087
Pawns are the soul of chess
|
Without OP_return, you would have people using transaction scripts to store junk, which presents an even bigger problem to blockchain bloat. They can still spam the blockchain, because it is always possible. There are many things stored on-chain, including the whitepaper, and a lot of scripts. See: https://bitcoinstrings.com/If we didn't provide OP_return, then users would be inserting arbitrary data into their P2PKH script, which would present an even bigger problem because it is also stored in the UTXO set even though it would never be spent. They can use non-standard P2SH (if they are miners), or even better, they can use P2WSH (then they can use any scripts, without being miners). Even more: they can use P2TR, then they can always count the total cost of pushing data, and decide to go spend-by-key route, instead of spend-by-script, just to make it cheaper, and reveal their TapScript (or some part of it) somewhere else, just to commit to their data, instead of revealing that. Also, using many OP_DROP or OP_2DROP opcodes, combined with some OP_CHECKSIG, is safe, and cheaper than OP_RETURN, because putting data as a witness is cheaper (because of Segwit).
|
|
|
|
ranochigo
Legendary
Offline
Activity: 3038
Merit: 4418
Crypto Swap Exchange
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 01, 2022, 05:23:02 AM |
|
They can use non-standard P2SH (if they are miners), or even better, they can use P2WSH (then they can use any scripts, without being miners). Even more: they can use P2TR, then they can always count the total cost of pushing data, and decide to go spend-by-key route, instead of spend-by-script, just to make it cheaper, and reveal their TapScript (or some part of it) somewhere else, just to commit to their data, instead of revealing that. Also, using many OP_DROP or OP_2DROP opcodes, combined with some OP_CHECKSIG, is safe, and cheaper than OP_RETURN, because putting data as a witness is cheaper (because of Segwit).
Yep correct. OP_return is still the standard way of storing data, and it is really all that we can do to try to get them to do so properly. Cost might be secondary at times, there are still plenty of instances where spammers specifically use OP_return because blockexplorers display them by default. Can't really think of a good way to stop this from happening without potentially affecting someone else, so I'd say that OP_return does what it can do.
|
|
|
|
ABCbits
Legendary
Offline
Activity: 2996
Merit: 7864
Crypto Swap Exchange
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 01, 2022, 12:10:51 PM |
|
Only because the genesis block [2] stored data, doesn't mean every block should. Since the other blocks are not the genesis block.. ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) Actually you can include message on each coinbase transaction. Some mining pool usually use it to add information about how the block is mined[1], but sometimes it's used for merged mining[1] and add other message[2]. [1] https://mempool.space/tx/e8b5ce1b6e46b5880fc6e8e82f7c99a289efab57f70adaeebb561b554d6d1b8e[2] https://decrypt.co/28508/the-final-bitcoin-halving-block-had-a-secret-messageWithout OP_return, you would have people using transaction scripts to store junk, which presents an even bigger problem to blockchain bloat. They can still spam the blockchain, because it is always possible. There are many things stored on-chain, including the whitepaper, and a lot of scripts. See: https://bitcoinstrings.com/Also see, http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html. People who want to put more than 80 bytes is forced to contact mining pool (since 80 bytes limitation only exist for transaction relay) or use other method which already mentioned.
|
|
|
|
garlonicon
Legendary
Offline
Activity: 850
Merit: 2087
Pawns are the soul of chess
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 01, 2022, 06:53:47 PM |
|
OP_return is still the standard way of storing data If you use Taproot, then OP_SUCCESS, followed by anything, is even cheaper and more convenient way of storing data. And you can always first require some signature, and then put OP_SUCCESS, followed by anything. Then, you are only limited by larger numbers, like max transaction input size or max transaction size, before you will touch non-standardness. Another thing is that you can always use that experimentally in just one more TapScript branch, so you could always change your mind later, just before spending those coins.
|
|
|
|
Guessti (OP)
Jr. Member
Offline
Activity: 91
Merit: 5
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 01, 2022, 11:39:24 PM |
|
OP_return is still the standard way of storing data If you use Taproot, then OP_SUCCESS, followed by anything, is even cheaper and more convenient way of storing data. And you can always first require some signature, and then put OP_SUCCESS, followed by anything. Then, you are only limited by larger numbers, like max transaction input size or max transaction size, before you will touch non-standardness. Another thing is that you can always use that experimentally in just one more TapScript branch, so you could always change your mind later, just before spending those coins. Do you have some more information on this? Thanks.
|
|
|
|
pooya87
Legendary
Offline
Activity: 3570
Merit: 10850
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 02, 2022, 03:33:16 AM |
|
OP_return is still the standard way of storing data If you use Taproot, then OP_SUCCESS, followed by anything, is even cheaper and more convenient way of storing data. And you can always first require some signature, and then put OP_SUCCESS, followed by anything. Then, you are only limited by larger numbers, like max transaction input size or max transaction size, before you will touch non-standardness. Another thing is that you can always use that experimentally in just one more TapScript branch, so you could always change your mind later, just before spending those coins. Anyone could spend your coins if the script contains OP_SUCCESS since it overrides everything including the signature check and returns true when evaluating the script. Additionally the scripts containing OP_SUCCESS are also considered non-standard and will be rejected by bitcoin core nodes.
|
|
|
|
garlonicon
Legendary
Offline
Activity: 850
Merit: 2087
Pawns are the soul of chess
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 02, 2022, 04:14:08 AM |
|
since it overrides everything including the signature check You mean it overrides OP_VERIFY executed before OP_SUCCESS? Additionally the scripts containing OP_SUCCESS are also considered non-standard and will be rejected by bitcoin core nodes. Is it true only on mainnet? I guess it could be accepted on testnet. I also wonder if OP_SUCCESS in some input is invalid by consensus or only non-standard.
|
|
|
|
pooya87
Legendary
Offline
Activity: 3570
Merit: 10850
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 02, 2022, 05:30:10 AM |
|
You mean it overrides OP_VERIFY executed before OP_SUCCESS?
Yes, it doesn't even execute the script to reach OP_VERIFY or any other OP code, it first goes through the script and looks for OP_SUCCESS if it founds any it will return true: https://github.com/bitcoin/bitcoin/blob/1c7ef0abd11f35a27cc860ceb7e075b78f53cecf/src/script/interpreter.cpp#L1792-L1808A funny side-effect of this is that if the script is invalid after the OP_SUCCESS (like having a wrong push data) it is not even going to reject it and will still pass! Like this: OP_SUCCESS OP_PUSH10 <5 bytes>
Is it true only on mainnet? I guess it could be accepted on testnet. I also wonder if OP_SUCCESS in some input is invalid by consensus or only non-standard.
OP_SUCEESS is only non-standard because if it were invalid we wouldn't be able to achieve backward compatibility when new OP code is introduced through one of these. Since SCRIPT_VERIFY_DISCOURAGE_OP_SUCCESS is part of the standard policy and the flag is not active when on testnet I suppose you should be able to send a transaction containing this OP code on testnet.
|
|
|
|
garlonicon
Legendary
Offline
Activity: 850
Merit: 2087
Pawns are the soul of chess
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 02, 2022, 06:34:19 AM |
|
OP_SUCEESS is only non-standard because if it were invalid we wouldn't be able to achieve backward compatibility when new OP code is introduced through one of these. I mean, if OP_SUCCESS allows us to make it automatically valid, then what stops miners from putting "OP_SUCCESS" as an input script anywhere, where users broadcast spend-by-script path? For example, someone could use "<pubkey> OP_CHECKSIG" as a TapScript output, and can provide "<signature>", but any miner could replace that "<signature>" with "OP_SUCCESS". So I guess it should make that transaction invalid, right? Because if not, then spend-by-script is unsafe by design.
|
|
|
|
pooya87
Legendary
Offline
Activity: 3570
Merit: 10850
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 02, 2022, 08:23:36 AM |
|
I mean, if OP_SUCCESS allows us to make it automatically valid, then what stops miners from putting "OP_SUCCESS" as an input script anywhere, where users broadcast spend-by-script path? For example, someone could use "<pubkey> OP_CHECKSIG" as a TapScript output, and can provide "<signature>", but any miner could replace that "<signature>" with "OP_SUCCESS". So I guess it should make that transaction invalid, right? Because if not, then spend-by-script is unsafe by design.
Because if anybody modifies the spending script the corresponding hash would change and the evaluation fails there. It's similar to P2SH, you can't modify the redeem script without changing the hash. Of course it's a bit more complicated in Taproot due to the way Tapleaf and Tapbranch hashes are computed but the principle is the same; if you modify the spending script the following check called VerifyTaprootCommitment should fail before we even start evaluating the OP_SUCCESS: https://github.com/bitcoin/bitcoin/blob/1c7ef0abd11f35a27cc860ceb7e075b78f53cecf/src/script/interpreter.cpp#L1925-L1928
|
|
|
|
Guessti (OP)
Jr. Member
Offline
Activity: 91
Merit: 5
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 03, 2022, 04:13:34 AM |
|
I mean, if OP_SUCCESS allows us to make it automatically valid, then what stops miners from putting "OP_SUCCESS" as an input script anywhere, where users broadcast spend-by-script path? For example, someone could use "<pubkey> OP_CHECKSIG" as a TapScript output, and can provide "<signature>", but any miner could replace that "<signature>" with "OP_SUCCESS". So I guess it should make that transaction invalid, right? Because if not, then spend-by-script is unsafe by design.
Because if anybody modifies the spending script the corresponding hash would change and the evaluation fails there. It's similar to P2SH, you can't modify the redeem script without changing the hash. Of course it's a bit more complicated in Taproot due to the way Tapleaf and Tapbranch hashes are computed but the principle is the same; if you modify the spending script the following check called VerifyTaprootCommitment should fail before we even start evaluating the OP_SUCCESS: https://github.com/bitcoin/bitcoin/blob/1c7ef0abd11f35a27cc860ceb7e075b78f53cecf/src/script/interpreter.cpp#L1925-L1928Thanks for your information. I tried to PM you asking how much you would charge for a bitcoin client that sends messages to the blockchain.
|
|
|
|
pooya87
Legendary
Offline
Activity: 3570
Merit: 10850
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 03, 2022, 04:46:54 AM |
|
Thanks for your information. I tried to PM you asking how much you would charge for a bitcoin client that sends messages to the blockchain.
Electrum wallet already exists and as it was pointed out in this topic it allows you to create OP_RETURN outputs that are used to include an arbitrary message in your transactions, there is no need to pay someone else to create a new client for you.
|
|
|
|
Guessti (OP)
Jr. Member
Offline
Activity: 91
Merit: 5
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 03, 2022, 01:18:03 PM |
|
Thanks for your information. I tried to PM you asking how much you would charge for a bitcoin client that sends messages to the blockchain.
Electrum wallet already exists and as it was pointed out in this topic it allows you to create OP_RETURN outputs that are used to include an arbitrary message in your transactions, there is no need to pay someone else to create a new client for you. So instead of that bitcoin address I put that? But then what address does the funds get sent to? Sorry very confused. I downloaded the client but that isn't so straight forward to me. I just want to send BTC to an address and attach a message to it on the block chain.
|
|
|
|
garlonicon
Legendary
Offline
Activity: 850
Merit: 2087
Pawns are the soul of chess
|
But then what address does the funds get sent to? Nowhere. They are burned. And that's why most people send zero coins there. I just want to send BTC to an address and attach a message to it on the block chain. There are two different things: attaching a message to a transaction, or attaching a message to some specific address. Because the first case can be handled by OP_RETURN in a separate output, but the second case is something different, where you could use P2WSH or P2TR address, and create "OP_DROP <pubkey> OP_CHECKSIG" spending script. But in the second case, you should first test that on some test network, maybe also regtest on your local computer, to make sure you can handle that correctly.
|
|
|
|
|