Topic: How much text can you put in a bitcoin message? (Read 483 times)

Nowhere. They are burned. And that's why most people send zero coins there.

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

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.

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.

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.

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

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 " OP_CHECKSIG" as a TapScript output, and can provide "", but any miner could replace that "" with "OP_SUCCESS". So I guess it should make that transaction invalid, right? Because if not, then spend-by-script is unsafe by design.

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:

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.

You mean it overrides OP_VERIFY executed before OP_SUCCESS?

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.

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.

Do you have some more information on this?

Thanks.

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.

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


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.

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.

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/

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

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.

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

---

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:

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

Exactly, all people trying to use blockchain as their data storage, would pay for that. Except miners, because they collect transaction fees. But you can also use testnet as your data storage, those coins are considered worthless, so you can use your coins only to pay fees, and only to share your test cases publicly. Also, you can always use regtest to see if something is possible on mainnet or not.

I just pointed out a correction to BlackHatCoiner's instruction to satisfy the OP's request.
I'll leave the questions to OP to you guys.

I've seen a couple of those transactions in mainnet but if you want to test it yourself,
you can construct a transaction in Electrum (using the instructions above) or Bitcoin Core using createrawtransaction with OP_RETURN output: {\"data\": \"555555555555555\"} w/o amount, don't forget the change.
Sign it but don't broadcast since it will be a waste of satoshi,
instead: Open Bitcoin Core's console and use the command testmempoolaccept '["RAW_TXN"]' to see if it can be accepted by your mempool.

Yes, because it doesn't take space in the UTXO set. OP_RETURN outputs are simply ignored.

Unless the receiver expects a message, I don't think it's very likely he'll notice the message. I don't check most of the transactions I receive in a block explorer.

Does this actually work with 0 sats?

The missed most important step is to utilize "Pay to many".
That way, he can 'send BTC' as one output and put the message in another,
OP_RETURN alone will work in "normal send" but if he wants to include another output, it wont work.

In "pay to many", the 'Pay to' field should be like this:
(no need to use 'Tools->Pay to many' if using the latest Electrum versions, just enter multiple lines)

e.g.: e3da55f62afcb69a3908324bf6eaf310f48d9366d14c5f0fd19acd3da23af3ae
Some screenshots:

All english characters take up one byte.

Some greek/cryllic as well as extended latin characters might take up two bytes if we us Unicode [specifically, the UTF-8 encoding]. That leaves 40 chars.

Arabic and CJK are the worst offenders taking up mostly 2-3 bytes per character. That leaves somewhere between some 30ish characters to encode in there. Not a lot though.

Bytes can be saved by encoding the message in gzip, or LZMA (.xz) format before inserting as hexadecimal.

To be fair if you want to use non-common features in bitcoin such as OP_RETURN you have to have some basic understanding of computers since there is no easy to use GUI to enter a text and click send! Even using Electrum requires first converting your text into base16.

You can mine a transaction. Then, it is equivalent of "hashing each message separately". Some example: 000000000fdf0c619cd8e0d512c7e2c0da5a5808e60f12f1e0d01522d2986a51. In this case, no blockchain is needed, but only miners can send valuable messages, most people can only send CPU-mined messages in this case. It is just a hashcash, you can use that as your antispam filter in e-mails.

You can hide all commitments of any arbitrary size in a single signature. Just use your r-value as a Taproot public key of your commitment. It can be very simple: you can just make any Taproot address, by using some random public key, and creating all of your commitments inside your TapScript. Then, you can put your 32 bytes in a signature, and by the act of making it, you can prove that you control the relation between your public key and your signature nonce.

Later, it is technically possible to validate your commitment, just by taking r-value from your signature, and checking if some commitment can satisfy that public key. If it can, then your commitment is valid. Also, you can sort commitments in your TapScript tree, by putting all hashes for all leaves in ascending order. If everything is always sorted, then you can create an SPV proof, just to show that some spending path is not a part of your TapScript. Then, in your own network, you can reject unsorted commitments as invalid, in this way you can write conditions that would take two leaves, to prove that no commitment is between them.

Could you elaborate a bit more about this idea? I'm not understanding neither of the two options...

i think the know the use-case would be relevant to choose the way to store the message: OP_RETURN is for sure the cleanest/most elegant way, however it's prunable (https://en.bitcoin.it/wiki/OP_RETURN)... so imho it should be evaluated if its presence guaranteed only in full nodes is ok or not

If you use Bitcoin Core, then you can make any transaction. For example, you can send coins to "OP_DROP OP_CHECKSIG", then you can spend it by pushing " ". And then, you can push bigger things than 80 bytes (as far as I know, up to 520 bytes, but then you can use more tricks to go above that). Also, putting message as a witness is cheaper, because of Segwit.

Quote

Do I understand correctly that there is no such possibility on hardware wallets?

Technically, it is possible. Practically, it could require writing some software for them. And that's another reason why I avoid hardware wallets: they are too limited for me.

Quote

how many characters can approximately contain these 80 bytes?

That means 80 English characters. For other languages, it may be less, but probably between 2 and 4 bytes per character. Also, you can use Unicode to put "" as emoji, then it could make it shorter, because "burger" will take 6 bytes, but some icon would take at most 4 (unless you want to use a combination, for example a "hand" with a "skin tone one").

Quote

(I've once made a thought experiment: if Bitcoin was banned globally, one could replace the current payments with "human-readable" messages like "I want to thank the person X." or the like, with the public key hash encoded in that message. Would be perfectly possible although obviously we would need to change the tx format for efficiency. Of course that wouldn't impress the regulators much, but it's funny to think about it.)

I also thought about that. But then, there is a bigger problem, because you need some way to implement mining. So, I can see two options: hashing each message separately, or implementing a hidden chain. I prefer the second, because then all hashes could be hidden as commitments. Then, the only option to stop that, would require banning all ways of encrypting anything (or pushing any random, non-explained data), which is hard to enforce.

On which wallets is it possible to write a bitcoin message? About Electrum I now know for sure, thanks to your post. Bitcoin Core may be too?
Do I understand correctly that there is no such possibility on hardware wallets?

OK. And now, could you explain in a language that is understandable to the general public, how many characters can approximately contain these 80 bytes?   Not all bitcoin lovers are tech savvy.

In theory yes, as a payment is also a simple message. A signed message allowing the transfer of a value from the owner of one key to the owner of another one (in the simplest form - more exactly: to the person able to provide a signature matching the public key hash, i.e. address).

(I've once made a thought experiment: if Bitcoin was banned globally, one could replace the current payments with "human-readable" messages like "I want to thank the person X." or the like, with the public key hash encoded in that message. Would be perfectly possible although obviously we would need to change the tx format for efficiency. Of course that wouldn't impress the regulators much, but it's funny to think about it.)

The Bitcoin blockchain obviously wouldn't work if there were only "non-payment messages", because there was no value attached, no miner would like to provide security for it. But even if there are only few payments and 90% non-payment messages it wouldn't be a problem, because of simple economics - storing only text messages in the Bitcoin blockchain would be way too expensive in the long term, and they would have to at least compete with miners wanting to sell their coins. So a "non-payment message spam attack" would probably not put bitcoin in danger as long as the fee market works (this is obviously an argument against BCH/BSV and other "big block" shitcoins, in BSV for example there was a weather app which spammed 96% of the blockchain space).

About the original question: BlackHatCoiner's method with OP_RETURN is imo the way to go.

Do you want the message to be visible to the receiver? That's going to be difficult.
Or do you want the message (for instance a hash) to be stored forever, so you can for instance prove ownership of a certain document on a certain date?

That's a lot easier than I expected!

Which wallet do you use? In Electrum, enter OP_RETURN and, right after, your hexadecimally represented message. For example, this message:


Check the transaction, made in testnet, on a block explorer: d1cc92eb8af8e21f11177886a95ccda37c5236eafa170a446c031da6f8834a1d

• blockchair.com
• mempool.space

What is your definition of Bitcoin, is it perhaps a system for permanently storing messages on the blockchain? Maybe Satoshi made a mistake when he added the message "EThe Times 03/Jan/2009 Chancellor on brink of second bailout for banks" in Genesis block

If we search the blockchain we can find really interesting messages, such as those about marriage propositions - I wonder if any of them resulted in marriage

Bitcoin isn't what "pooya87" says it is. 

The topic is wider than what I also thought...

Many choices are possible, this is a quite complete survey as far as I know:
https://digitalcommons.augustana.edu/cscfaculty/1/

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.

I would like to send BTC and put a message in it. Can someone guide me?

Thanks.