How much text can you put in a bitcoin message?

garlonicon

copper member

Activity: 821

Merit: 1992

Pawns are the soul of chess

Quote

But then what address does the funds get sent to?

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

Quote

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

Guessti

jr. member

Activity: 91

Merit: 5

Quote from: pooya87 on June 03, 2022, 12:46:54 AM

Quote from: Guessti on June 03, 2022, 12:13:34 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.

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.

pooya87

legendary

Activity: 3472

Merit: 10611

Quote from: Guessti on June 03, 2022, 12:13:34 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

jr. member

Activity: 91

Merit: 5

Quote from: pooya87 on June 02, 2022, 04:23:36 AM

Quote from: garlonicon on June 02, 2022, 02:34:19 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 " 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.

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

legendary

Activity: 3472

Merit: 10611

Quote from: garlonicon on June 02, 2022, 02:34:19 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 " 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.

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

garlonicon

copper member

Activity: 821

Merit: 1992

Pawns are the soul of chess

Quote

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

pooya87

legendary

Activity: 3472

Merit: 10611

Quote from: garlonicon on June 02, 2022, 12:14:08 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-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>

Quote

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

copper member

Activity: 821

Merit: 1992

Pawns are the soul of chess

Quote

since it overrides everything including the signature check

You mean it overrides OP_VERIFY executed before OP_SUCCESS?

Quote

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

Activity: 3472

Merit: 10611

Quote from: garlonicon on June 01, 2022, 02:53:47 PM

Quote

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.

Guessti

jr. member

Activity: 91

Merit: 5

Quote from: garlonicon on June 01, 2022, 02:53:47 PM

Quote

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.

garlonicon

copper member

Activity: 821

Merit: 1992

Pawns are the soul of chess

Quote

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.

ABCbits

legendary

Activity: 2870

Merit: 7490

Crypto Swap Exchange

Quote from: n0nce on May 31, 2022, 07:09:58 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

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

Quote from: garlonicon on June 01, 2022, 01:17:53 AM

Quote

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.

ranochigo

legendary

Activity: 3038

Merit: 4418

Crypto Swap Exchange

Quote from: garlonicon on June 01, 2022, 01:17:53 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.

garlonicon

copper member

Activity: 821

Merit: 1992

Pawns are the soul of chess

Quote

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/

Quote

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

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.

n0nce

hero member

Activity: 882

Merit: 5834

not your keys, not your coins!

Quote from: Guessti on May 30, 2022, 10:21:25 AM

Quote from: pooya87 on May 30, 2022, 09:57:33 AM

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

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

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

vjudeu

hero member

Activity: 813

Merit: 1944

Quote

Sign it but don't broadcast since it will be a waste of satoshi

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.

nc50lc

legendary

Activity: 2534

Merit: 6080

Self-proclaimed Genius

Quote from: LoyceV on May 31, 2022, 03:13:02 AM

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.

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.

Quote from: LoyceV

Quote

In "pay to many", the 'Pay to' field should be like this:

Code:

OP_RETURN 555555555555555,0

Does this actually work with 0 sats?

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.

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: LoyceV on May 31, 2022, 03:13:02 AM

Does this actually work with 0 sats?

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

LoyceV

legendary

Activity: 3290

Merit: 16489

Thick-Skinned Gang Leader and Golden Feather 2021

Quote from: nc50lc on May 31, 2022, 12:12:09 AM

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

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.

Quote

In "pay to many", the 'Pay to' field should be like this:

Code:

OP_RETURN 555555555555555,0

Does this actually work with 0 sats?

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