Topic: How much text can you put in a bitcoin message? - page 2. (Read 461 times)

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.