How much text can you put in a bitcoin message?

[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. 

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..

Code:

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:

Code:

$ echo "hello bitcointalk" | xxd -p

[1] https://bitnodes.io/
[2] https://en.bitcoin.it/wiki/Genesis_block

[ranochigo]

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]

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]

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]

Only because the genesis block [2] stored data, doesn't mean every block should. Since the other blocks are not the genesis block..

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-message

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/

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]

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_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]

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]

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]

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-L1808
A 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:

Code:

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]

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]

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]

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

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.

[pooya87]

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]

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]

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.