OP_RETURN can accept 80 bytes #1129
Conversation
|
This really shouldn't be in the docs at all. OP_RETURN isn't used in any standard transactions, and the IsStandard policy is merely a policy. |
|
Coloredcoin and also counterparty I believe. Not libbitcoin. However this change was relevant to many, there is no point in hiding it now: what do we obtain through obscurity really? If it is undesired behavior or not can be debated and deprecated, but I doubt things will change quickly. Refer to 5286 bitcoin issue... |
|
I've found that a great many new-to-Bitcoin developers and enthusiasts are extremely curious about ways to store data in the blockchain, even if it isn't for the types of opaque transactional data we think is the most appropriate use of null data outputs. I think we should endeavor to satiate their curiosity with the best information we have available, including information about the increased risks to nodes and miners if non-opaque data (such as ASCII-encoded text) is notably placed in null data outputs. Hiding information about null data outputs can have sad side effects. I was recently asked to edit a document which put forth Dan Kaminsky's tribute to Len Sassaman as a model for storing data in the blockchain, even though that placed ASCII-encoded text in the hash part of P2PKH outputs, creating UTXOs that look spendable (but aren't) to nodes and so can't be automatically pruned from the UTXO db. (I hopefully cleared up the confusion by providing more information on null data and also pay-to-contract hashes.) To help avoid these confusions, I think we should continue providing this information prominently in the Bitcoin.org dev docs, although I'm completely open to rewrites and the addition of disclaimers and other useful information for developers who want to use null data outputs. @alexkuck Thanks for submitting this PR! Addressing the content of this PR directly, I would like to see it mentioned that this is a relay rule and so the bytes allowed frequently varies from node to node and miner to miner, as well as mentioning that the upcoming rule allows multiple pushes data in a single null data output. I'll compose that information and coordinate with you to either update this PR or open a new one. |
|
Blockchains don't store data. Implying they do is just misinformation, which isn't something I'd like to see in documentation I recommend to others. |
|
I think there is consensus on the fact the present state of things should not be obscured. I agree with @luke-jr on the fact that the Bitcoin blockchain was not designed to store data, but this does not mean people out there will not do it, even in subtle ways. Anyway, there are blockchains which do not impact Bitcoin mining and are designed to store data (see counterparty, for which StorJ is a derivative). There will also be sidechains, one day, soon. It is perhaps good to inform devs looking for ways to store data in other directions. @luke-jr I recommend more serendipity on these matters: on the long term, playing cat and mouse and changing the spec of a protocol against popular uses will ultimately create a lot of problems and FUD around the Bitcoin blockchain, which is the world's biggest blockchain and its even in the interest of miners to not have it subject to such "regulatory" postures, IMHO. I believe we must hold the grounds, whatever it is built upon them, and if any change is needed proceed carefully, evaluate all current uses and ensure backward compatibility. |
|
@luke-jr I agree blockchains don't store data in the same way that your hard drive stores data; however, there is data whose existence is attested to by block headers on a best blockchain. For data placed directly in a scriptPubKey or a scriptSig that are part of a block on the best chain, that data needs to be downloaded and processed by every full node to validate that block. A lot of that data is public keys, hashes of public keys, and signatures, but some of that data is arbitrary and unrelated to creating or satisfying encumbrances. What name would you give to that arbitrary data which is attested to by the blockchain and which must be downloaded by full nodes during validation? Something like "null data in the blockchain"? |
|
@ABISprotocol for the record, you are right OP_RETURN is used in libbitcoin for stealth addresses
In Relatively recent times (Feb 2015) @genjix expresses his wish to stop using OP_RETURN and start using Bitcoin addresses for the function This 'trivial change' as he defines it was not elaborated into a push request. Amir is busy on other things at the moment so this should be really an argument of discussion with @evoskuil Still I think documentation of the present situation + recommendations should be there, beyond the outcomes of any process of harmonization. |
|
I also noticed that @alexkuck himself is working on an app compatible with the "ahimsa bulletin" protocol. Interesting! I didn't knew it before. I cannot find much more documentation than this https://godoc.org/github.com/NSkelsey/protocol/ahimsa and it may be also using OP_RETURN to store some metadata (my supposition, did not check carefully). This is indeed another one of many examples. I think that the developer's doc section regarding OP_RETURN should be extended to include a longer explanation on what it is for, what is (abusively?) used for, what shouldn't really be used for and what it is encouraged to use in place of this trick. Said that, I believe this part of the Bitcoin protocol will not change any time soon. |
|
Consensus determines what is valid, and OP_RETURN is currently valid. Good documentation would reflect this. Because an OP_RETURN output is provably unspendable it is preferrable to the alternative of UTXO bloat, and I believe this is why it exists. At best not documenting it would drive people into the less optimal scenario, although it seems more likely they will find out about OP_RETURN anyway. It is true that libbitcoin indexes OP_RETURN outputs as potential stealth ephemeral keys. It is also the case that libbitcoin (and I believe Core) treats up to 80 byte OP_RETURN outputs as standard. It is of course possible to index ephemeral keys in spendable outputs, and this would increase their obscurity. However desired obscurity can be managed by prefix length, so the trade-off in terms of blockchain block and stealth index explosion isn't necessary. |
|
@jaromil So I did understand this correctly... libbitcoin does have the OP_RETURN for stealth addresses (I was running on my memory of the matter so forgive my initial comment which may not have been too clear), however, as you have noted, @genjix does not wish to use OP_RETURN further based on your citation of the Feb 2015 comment. |
|
@ABISprotocol Libbitcoin does index null-data outputs as potential stealth ephemeral keys. There is no plan to change this. |
|
FWIW I do have it on my todo list to author BIP-63, but am not sure when I'll get to it due to other libbitcoin priorities. But we do have a comprehensive reference implementation, which is an important step. The libbitcoin stack implements all aspects of stealth, including server indexing of and query support for ephemeral keys by prefix, prefix grinding, address parsing with altcoin support, stealth math, and bx commands documentation. |
|
@evoskuil TY |
|
Please see #1191 which fulfills the commitment I made here: #1129 (comment) |
bitcoin/bitcoin#5286 increased
MAX_OP_RETURN_RELAYto 80 bytes.