Topic: [PAID] What do you think about OP_RETURN ? (Read 1673 times)
There are already many developers building applications using OP_RETURN. The BTC core developers know this and I am sure will keep the OP_RETURN in the system.
Quote
I tried to search if the OP_RETURN was no longer accepted by the network, but in fact it is. But I have read that it first allowed 80 bytes of information, and then they lowered it to 40 bytes... Who knows what they might do to my new best friend OP_RETURN in the future...
No, it was 80 bytes (I think never deployed though), then lowered to 40 bytes, then now it is back to 80 bytes.
The 0.12 version will allow multiple push in the OP_RETURN, but the limit will still be 80 bytes for all data (more precisely 83 bytes for the OP_RETURN script)
OP_RETURN is relatively safe, I don't think devs will break anything here since it does not cost anything on the UTXO set and is prunable.
If you want a reason not to use OP_RETURN, it would be if the fee rate rise so much than the added value of using OP_RETURN for your case is not worth the price of the added bytes in your transaction.
Thank you very much for your reply. I didn't know the limit was raised to 80 bytes again.
I will definitely keep using OP_RETURN for my application, unless someone comes up with a reason to not do it.
I remember the controversy. When did it move back to 80 and why?
0.10, check on github the PR about it, too lazy to make archeology. :p
EDIT : Found : https://github.com/bitcoin/bitcoin/pull/5286
Quote
I tried to search if the OP_RETURN was no longer accepted by the network, but in fact it is. But I have read that it first allowed 80 bytes of information, and then they lowered it to 40 bytes... Who knows what they might do to my new best friend OP_RETURN in the future...
No, it was 80 bytes (I think never deployed though), then lowered to 40 bytes, then now it is back to 80 bytes.
The 0.12 version will allow multiple push in the OP_RETURN, but the limit will still be 80 bytes for all data (more precisely 83 bytes for the OP_RETURN script)
OP_RETURN is relatively safe, I don't think devs will break anything here since it does not cost anything on the UTXO set and is prunable.
If you want a reason not to use OP_RETURN, it would be if the fee rate rise so much than the added value of using OP_RETURN for your case is not worth the price of the added bytes in your transaction.
Thank you very much for your reply. I didn't know the limit was raised to 80 bytes again.
I will definitely keep using OP_RETURN for my application, unless someone comes up with a reason to not do it.
I remember the controversy. When did it move back to 80 and why?
Quote
I tried to search if the OP_RETURN was no longer accepted by the network, but in fact it is. But I have read that it first allowed 80 bytes of information, and then they lowered it to 40 bytes... Who knows what they might do to my new best friend OP_RETURN in the future...
No, it was 80 bytes (I think never deployed though), then lowered to 40 bytes, then now it is back to 80 bytes.
The 0.12 version will allow multiple push in the OP_RETURN, but the limit will still be 80 bytes for all data (more precisely 83 bytes for the OP_RETURN script)
OP_RETURN is relatively safe, I don't think devs will break anything here since it does not cost anything on the UTXO set and is prunable.
If you want a reason not to use OP_RETURN, it would be if the fee rate rise so much than the added value of using OP_RETURN for your case is not worth the price of the added bytes in your transaction.
Thank you very much for your reply. I didn't know the limit was raised to 80 bytes again.
I will definitely keep using OP_RETURN for my application, unless someone comes up with a reason to not do it.
Quote
I tried to search if the OP_RETURN was no longer accepted by the network, but in fact it is. But I have read that it first allowed 80 bytes of information, and then they lowered it to 40 bytes... Who knows what they might do to my new best friend OP_RETURN in the future...
No, it was 80 bytes (I think never deployed though), then lowered to 40 bytes, then now it is back to 80 bytes.
The 0.12 version will allow multiple push in the OP_RETURN, but the limit will still be 80 bytes for all data (more precisely 83 bytes for the OP_RETURN script)
OP_RETURN is relatively safe, I don't think devs will break anything here since it does not cost anything on the UTXO set and is prunable.
If you want a reason not to use OP_RETURN, it would be if the fee rate rise so much than the added value of using OP_RETURN for your case is not worth the price of the added bytes in your transaction.
You can still use OP_RETURN. I highly doubt that it will be dropped. Try pushing it through other pushtx options like blockcypher or blocktrail's. You can also try pushing the transaction through your own full node, that should work. Blockchain.info is just being stupid as usual.
Hey thanks for the reply. Let me invite you to a cofee https://blockexplorer.com/tx/aa02fd76ad9004df566722d4f68a276def329c5f59ac25ca40fca718036f2227
If anyone else can provide any information on why I should not use OP_RETURN, I will award it.
I strongly prefer to pay somebody now rather than pay the consecuences in the future
You can still use OP_RETURN. I highly doubt that it will be dropped. Try pushing it through other pushtx options like blockcypher or blocktrail's. You can also try pushing the transaction through your own full node, that should work. Blockchain.info is just being stupid as usual.
I am designing an application that has to store ripemd160 hashes of data on the blockchain.
I know most of you don't like this idea of bloating that thing even more than it is, and even I don't like it very much, but I will say to my defense, that this application will only store 20 bytes on transactions that it would need to perform anyway. It will store a tiny amount of data on transactions that really have a purpose, and really were ment to exist. And by the way, if these little amounts of bytes are really going to damage the network so much, then why did satoshi had to allocate 4 bytes for the transaction version in every transaction? Seriously, is the version number 4,294,967,296 ever coming out? Almost 8 years and we are still in the version 1...
But I will get to the point. My first thought of how should I store 20 bytes of data in a transaction was add an output sending a tiny amount of satoshis to a fake bitcoin address which was formed by that hash. But I really don't like this dirty way of doing it, because it destroys bitcoins and creates fake UTXOs that would be a problem in the future.
Then, some guy on stackoverflow told me to use the OP_RETURN code. I really loved how it worked, it doesn't cost money (because it is attached to a transaction that I was going to send anyways) and it doesn't generate UTXOs. It's like a dream come true. So I implemented the application using exactly that.
When I was testing if the application was generating transactions correctly, (since I haven't yet programmed the part that broadcasts transactions to bitcoin peers) I decided to get the hex of the transaction and push it to blockchain.info using its web api: https://blockchain.info/pushtx
I got a little upset when the website told me something along the lines of "your transaction has been rejected because it contains a suspicious code OP_RETURN".
This transaction: https://blockchain.info/tx/8bae12b5f4c088d940733dcd1455efc6a3a69cf9340e17a981286d3778615684 has an OP_RETURN output. Note how blockchain.info marks it as "Strange".
I tried to search if the OP_RETURN was no longer accepted by the network, but in fact it is. But I have read that it first allowed 80 bytes of information, and then they lowered it to 40 bytes... Who knows what they might do to my new best friend OP_RETURN in the future...
I want my application to be reliable. I don't want that suddenly, one day, all my customers can't use the application because the bitcoin developers decided that OP_RETURN's life was over, or that the most influent miners don't want to accept those kind of transactions anymore.
Should I trust OP_RETURN or should I try other methods?
Thanks for reading!
I know most of you don't like this idea of bloating that thing even more than it is, and even I don't like it very much, but I will say to my defense, that this application will only store 20 bytes on transactions that it would need to perform anyway. It will store a tiny amount of data on transactions that really have a purpose, and really were ment to exist. And by the way, if these little amounts of bytes are really going to damage the network so much, then why did satoshi had to allocate 4 bytes for the transaction version in every transaction? Seriously, is the version number 4,294,967,296 ever coming out? Almost 8 years and we are still in the version 1...
But I will get to the point. My first thought of how should I store 20 bytes of data in a transaction was add an output sending a tiny amount of satoshis to a fake bitcoin address which was formed by that hash. But I really don't like this dirty way of doing it, because it destroys bitcoins and creates fake UTXOs that would be a problem in the future.
Then, some guy on stackoverflow told me to use the OP_RETURN code. I really loved how it worked, it doesn't cost money (because it is attached to a transaction that I was going to send anyways) and it doesn't generate UTXOs. It's like a dream come true. So I implemented the application using exactly that.
When I was testing if the application was generating transactions correctly, (since I haven't yet programmed the part that broadcasts transactions to bitcoin peers) I decided to get the hex of the transaction and push it to blockchain.info using its web api: https://blockchain.info/pushtx
I got a little upset when the website told me something along the lines of "your transaction has been rejected because it contains a suspicious code OP_RETURN".
This transaction: https://blockchain.info/tx/8bae12b5f4c088d940733dcd1455efc6a3a69cf9340e17a981286d3778615684 has an OP_RETURN output. Note how blockchain.info marks it as "Strange".
I tried to search if the OP_RETURN was no longer accepted by the network, but in fact it is. But I have read that it first allowed 80 bytes of information, and then they lowered it to 40 bytes... Who knows what they might do to my new best friend OP_RETURN in the future...
I want my application to be reliable. I don't want that suddenly, one day, all my customers can't use the application because the bitcoin developers decided that OP_RETURN's life was over, or that the most influent miners don't want to accept those kind of transactions anymore.
Should I trust OP_RETURN or should I try other methods?
Thanks for reading!
Jump to: