Allow several OP_RETURN in one tx and no limited size #27043
Comments
|
A datacarrier output is in the non-witness part of a transaction. An inventory vector sent in a getdata message can not request to discard the datacarrier. For example, a 0x2 inv type to request a block will be answered with the datacarrier included, however it will have its witness data removed. Same for 0x1. |
|
Yes, but what do you mean? |
|
My comment implies that your suggested change may put more network and storage load on peers in the network that make use of the 0x1 and 0x2 inv types to strip witness data |
|
Yes but then? What is the use of those nodes? And the same pb occurs with the taproot witness (if people for example decide to store big images in it) It's not really my proposal but the conclusion of the discussion for the thread mentionned above where at the end @petertodd proposed to let people free to decide whether they want to use several OP_RETURN and no size limit, and everybody agreed so far, my proposal was more to increase the size limit but I think that what is proposed here is the right way to go I don't think that the threat is storage/load limit but more that people invent things that would harm bitcoin (in my specific proposals the witness trick or others do not work very well) |
Any node that wants to learn the state of the network while trusting that witnesses are legit (for example a tool which monitors for unexpected spends of specific coins, or a node doing IBD and [reasonably IMHO] assuming that any blocks more than 1000 deep are legit, without bothering to validate the witnesses). This sort of use case is major benefit of segwit's design -- that, and allowing witnesses to be partially constructed without causing unpredictable txid changes. In particular, this category of use is one reason that the Segwit rules allow more witness space than non-witness space.
It doesn't, because nodes that don't download witnesses won't see these images at all.
Well, the thread is still active, but my opinion (and I believe that of Peter Todd) is that (a) because users have found ways to store data on the blockchain no matter what, limiting |
|
On Mon, Feb 06, 2023 at 06:29:20AM -0800, Andrew Poelstra wrote:
Well, the thread is still active, but my opinion (and I believe that of Peter Todd) is that (a) because users have found ways to store data on the blockchain no matter what, limiting `OP_RETURN` is technically complicated, may undermine some "legitimate" proof-of-publication protocols, and fails to achieve its goal of preventing blockchain spam; and (b) to the extent that non-witness data is worse for the p2p network than witness data (e.g. non-witness-validating nodes being forced to download the data), the economics of the "witness discount" will encourage people to do the least bad thing.
Also, given those reasons, it's a waste of developer time to argue about
specific numbers. We've already raised it from 40 bytes to 80 bytes once.
We stopped trying to impose standard templates on scriptSigs for this reason
too. It's a waste of time and unnecessarily limiting.
|
|
Yes, the non witness transmission, OK, then witness taproot will affect other witness nodes anyway, then... (do we have more non witness nodes than witness ones?) Anyway again, I think also that we can trust people not to do stupid things with this change (which will never be a spam stuff unlike others, if people want to misuse it and pay plenty of fees, that's their problem) |
|
And @apoelstra if I were to monitor bitcoin to track dubious/illegal spending or secret messages, then I will for sure look into witness fields, so at the end what is proposed here does not make any difference |
|
just let people continue to encode whatever they want into witness data. no need to make it easier. its already easy enough. decoding multisig-as-data or tapscript-as-data is trivial. since 2017 we have had very large and discounted witness data. my only concern is that the witness discount was a mistake. the real cost of witness data is nearly as high as the rest of the block. |
|
Not sure if you are for the change or against, it seems like you are against while advocating that it does not nearly change anything at the end, "no need to make it easier", no, you spare useless txs with op_return and is more straight forward (and yes decoding whatever you like is "trivial" for bitcoin experts, not for usual people, op_return remains more visible), and since witness allows no size limit (and you estimate that the discount is minor) then op_return should do the same |
|
|
Even though I know I could get a discount by using witness data, I prefer the single transaction nature of using OP_RETURN and the ability to use TxREF BIP-136 to point to it. |
|
What is the process to have someone do the PR for this? Or I do it and most likely it will be a very shxtty one since I am not a C/C++ expert, then wasting the time of everybody It's urgently required, I did consider OP_RETURN as a dart in the past but changed my mind, it's adapted to the current evolutions, not flooding bitcoin with 2 txs while only 1 is needed If not the best 1 tx solution is super simple: store in addresses, and super bad at the end because burning bitcoins, while still not expensive if you don't need to store big things |
|
Concept NACK, at least SegWit allows for this data to be not downloaded. Alternative would be to make 256-512 byte OP_RETURNs. |
|
@MarcoFalke super simple... @Semisol as mentionned in the thread there are so many ways to store things that there is no rationale to impose a limit in OP_RETURN, this is cleary a handicap for bitcoin and future uses/evolutions, bitcoin can clearly do far better what ethereum and all the messy stuff around pretend to do but we need this change |
|
Why do you close it "as not planned"? Of course a modification request is "not planned", or who decided that it is "not planned" |
|
The fact that Core devs feel like they can close this with no explanation at all suggests that protocols should use the backup mechanism of polluting the UTXO set. The dust limit is low enough that for a lot of use cases a few extra outputs isn't a big deal.
…On February 26, 2023 12:29:49 PM GMT+01:00, Aymeric Vitte ***@***.***> wrote:
Why do you close it "as not planned"? Of course a modification request is "not planned", or who decided that it is "not planned"
--
Reply to this email directly or view it on GitHub:
#27043 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
|
Agree |
|
@petertodd If I understand correctly your comment, you mean that without this change (as I think too) people will invent stupid things like I am myself proposing here (ie storing in addresses, with uncompressed keys, worse method on earth, but not expensive as you say and as I wrote, let's say that we will survive it and don't care for the future) : https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7#workaround-to-the-80b-op_return-limitation, then indeed polluting the UTXO set with not spendable txs |
|
On February 26, 2023 4:17:28 PM GMT+01:00, Aymeric Vitte ***@***.***> wrote:
@petertodd If I understand correctly your comment, you mean that without this change (as I think too) people will invent stupid things like I am myself proposing here (ie storing in addresses, with uncompressed keys, worse method on earth, but not expensive as you say and as I wrote, let's say that we will survive it and don't care for the future) : https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7#workaround-to-the-80b-op_return-limitation, then indeed polluting the UTXO set with not spendable txs
No. I'm saying that protocols who would otherwise use multiple OpReturns or longer OpReturns should go ahead and implement other mechanisms now, in parallel to also using OpReturn.
Often you can define standards in such a way that multiple different transaction forms are valid. And of course, these are just standardness rules so in some cases you can work with miners to get non-std stuff mined.
OpenTimestamps, for example, is defined in such a way that if OpReturn is blocked it can easily use other alternatives. And in the past, it actually has.
|
|
You can invent whatever non standard solution you like as long as the tx is valid and then work with miners, but that's not the easy/standard way to go What other standard alternatives to OP_RETURN uses Opentimestamps? As far as I know we have only two for now as standard: taproot IF but 2tx, taproot annex 1tx (not available right now), that's the other mechanisms you are refering to? Opentimestamps looks to be working the very same way for some parts than what I am proposing for NFTs, but not for the same use cases, that's probably another discussion, I read the docs but did not find the specs, obviously a third party is needed to provide the merkle proof (and store the timestamped thing), which is very exactly what I am proposing also, only the proof is stored in bitcoin Unless someone makes a very clear point, I don't see the issue with OP_RETURN (which again I did consider in the past as shxtty stuff), and the argument based on nodes not downloading witness does not work very well, those nodes are of no use, or please prove me the contrary |
|
On February 26, 2023 7:01:05 PM GMT+01:00, Aymeric Vitte ***@***.***> wrote:
You can invent whatever non standard solution you like as long as the tx is valid and then work with miners, but that's not the easy/standard way to go
What other standard alternatives to OP_RETURN uses Opentimestamps? As far as I know we have only two for now as standard: taproot IF but 2tx, taproot annex 1tx (not available right now), that's the other mechanisms you are refering to?
You've misunderstood my comment. I mentioned OpenTimestamps as an example of a protocol that used multiple different ways of putting data in Bitcoin transactions.
I did not mention OpenTimestamps as an alternative to OpReturn. It usually is not.
|
|
Rephrasing then since you misunderstood my comment also, the question was in fact: what are the (standard) "multiple different ways of putting data in Bitcoin transactions" for opentimestamps ? |
|
Apologies for the mistaken close and thank you for the ping to reopen. |
|
@glozow Thanks, @1440000bytes I saw your comments that you have deleted apparently (maybe a misunderstanding about my intentions), for my information who are the current 4 maintainers? I don't see where I could be dishonest in this thread and why I would be trying to force/bypass some processes, I am a bit used to this since many years here and elsewhere, my only concerns are: what is the issue with this trivial change compared to other standard storage methods? And not doing it might lead people to invent stupid things/pollute the utxo set |
|
So the next step here for people who want to actually see this implemented is code, and perhaps more importantly, tests. The code change is fairly simple: change the Second, tests. You need to check that:
ScriptPubKeys that fill up entire blocks already exist in testnet, eg from the time I rick-rolled testnet. But OP_Return outputs are handled very slightly, so better if you can at least find one/mine one in testnet to prove they cause no consensus problems. An explicit test for this case wouldn't hurt either. As for large numbers of OP_Returns, again, we already have transactions with large numbers of outputs and OP_Return should not be any different. But it doesn't hurt to test this explicitly. |
|
@petertodd then could someone please do it? (you?) I am good with js/nodejs/browsers but can't pretend to be a C/C++ expert, even if the change is simple it would be a waste of time/not serious I believe that I issue a PR for this, and approximation can't work with Bitcoin code @ChristopherA did open the debate, which did intersect some discussions that I started, that's why I opened this issue myself, you proposed a solution but at the end it just must be done |
There are many C++ devs you could pay to have this PR done for you. That would be much quicker, especially considering how simple the change is. The only hard part might be writing tests, since the testing harness etc. does take a bit of getting used to... (that said, looking at the other tests usually can give one a good head start) There are also many bounty websites where you can lock BTC into a vault that is only released to the person who does the bounty. I doubt many people that are sympathetic with this issue will see your comment unless you advertise it somewhere and/or offer a cash reward... or take a crack and learning some C++, maybe? (it's actually not as hard as it sounds) |
|
@MarcoFalke perhaps this could also use a "good first issue" tag? Seems pretty straight forward. |
|
Blockchain Commons would be glad to contribute US$1K (paid in BTC) towards a joint bounty with others to see this as a PR with the core changes and a testing harness. Who else will contribute to the pot? |
|
@junderw thanks for the tip, I know C/C++ in fact, but I don't consider to be an expert, probably you can yourself fix the wasm stuff for Tor Rust @ChristopherA the change is trivial as you know, would take 5mn for an expert if I were to do it in my area, and for free, good to see that there is some funding proposal, but, really, in a worldwide important project like bitcoin, nobody can do this without adding funding to funding? |
|
@Ayms The change to the C++ code core is fairly trivial, but for the PR to be acceptable, it must have the test frameworks changed for it, which is less so as they are in Python. I've not touched that for years, and I don't have a current build environment. It should, however, be a relatively easy first contribution for someone who wants to learn how to do bitcoin core contributions. |
|
Alright, I'm going to take a crack at this. I'll ask that anyone else who hasn't already implemented this patch wait until next Monday before starting work on it. :) |
|
Cool, I am a bit like @ChristopherA probably , even if still operating a bitcoin node that I did compile myself (+ some slight modifications for testing), I did not work on it since years |
|
FYI, first bit of work on this, a minor cleanup to the logic: #27261 |
|
This feature seems to be controversial and so unlikely to be implemented. |
and others
The rationale is explained in this thread [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
And other threads around that are addressing about the same subject: bring NFTs or other systems on or off chain and easy storage to Bitcoin
As mentionned in the thread there are so many possibilities to store things in Bitcoin, including very deviant practices like storing in addresses (then burning bitcoins), that there is no rationale for the OP_RETURN limitation, this change has a minimal impact
The current limit of 80B does not even allow to store a signature and a hash
Not doing the requested change can lead people to invent very bad practices, which will still remain not expensive but will have an impact on the future of Bitcoin
The text was updated successfully, but these errors were encountered: