Quote from: uint512_t on Today at 04:03:21 PM

thanks for the unfound accusations on my intentions/funding etc. I wish you good luck in your endeavors, that's all I can say at this point Undecided

You really should reply to these points, its the least you can do, otherwise we can all assume that your concerns have been met.

Quote from: gmaxwell on Today at 03:43:17 PM

I appreciate the honorific, but unless you're in the business of handing out honory degrees I am not a PHD.

Quote from: uint512_t on Today at 02:29:55 PM

- Above certain size (~150bytes) [1], it is claimed it's cheaper to abuse witness exploit so not sure why you're so sure that ppl with malicious intent to embed large jpegs/data will switch to using OP_RETURN.

They won't. I did not intend to suggest otherwise. Did I? How is it relevant?

Quote

- When the actual UTXO bloat exploded like crazy during inscription attack, most Core devs were congratulating their ex coworker from Chaincode (Casey) on exploiting the witness vulnerability.

I don't know anything about this, if it's true, it sounds doubtful to me particularly since I was able to determine that a significant part of the ordinals ecosystem was in fact funded by Calvin Ayre, the same party funding Craig Wright's litigation against developers.

Quote

Now you've claims that they're anticipating some usage in more harmful ways(which hasn't happened btw)

There are existent transactions on the network right now shoving data in unspendable outputs, some have been discussed previously in this thread. I don't think I've made any arguments based on 'anticipating'.

Quote

I'm not so sure about your claim of OOB txs atleast for non-std txs. For inscriptions may be but my very first point clearly shows you that relaxing op_return limits doesn't make it cheaper for those inscription txs so they are not going to move there.

You are continuing to debate a point I never made.

Re miners, several of the largest pools will outright accept nonstandard txn and mine them for a payment, this is well documented. It's not clear to me if you're disagreeing with it or just doubting that it's used often for op_return vs non-standard in other respects.

Quote

"It was a limit that made sense at a different time in a different world", explain how are you quantifying that now the system is mature enough and people got educated.

Different time would be one where large miners were not allowing non-standard transactions and not being paid hundreds of millions of dollars for data traffic. As far as education, I'm not aware of anything people are doing where their goals would be satisfied by just using a commitment, and in fact petertodd reports that OTS now handles an average of 2.1 commitments per second, so that is a significant fraction of the whole chains bandwidth being saved by actually handing commitments the right way. The goal in originally limiting the size of op_return was to encourage users that could form their usage as a commitment to do so.

Quote

How can you claim people are educated, when Core devs themselves said things like use blocksonly

The hyperlink in your post didn't work for me but I dug through the PR and the quote is:

Quote from: sipa

I do not believe this to be in the interest of users of our software. The point of participating in transaction relay and having a mempool is being able to make a prediction about what the next blocks will look like. Intentionally excluding transactions for which a very clear (however stupid) economic demand exists breaks that ability, without even removing the need to validate them when they get mined.

Of course, anyone is free to run, or provide, software that relays/keeps/mines whatever they want, but if your goal isn't to have a realistic mempool, you can just as well run in -blocksonly mode. This has significantly greater resource savings, if that is the goal.

I think the comment speaks for itself just fine, there is absolutely nothing ridiculing about it (except towards inscriptions users). And also, I fail to see how it contributes to a discussion on removing the op_return limit.

Quote

even though counter arguments have been also made by people

Where?

Quote

who are not just theoreticians but practically running businesses.

Ah, so that's what the false honorific was for. I am not a "theoretician". Particularly to this discussion, I *invented* compact blocks, and (with collaborators) *deployed it*, and brought it through numerous in production developments and evolution, so it is galling that you're attempting to dismiss without argument by damning me with faint praise of being a theoretician.

Your post went through numerous points, but none of them appear to make the case that eliminating that particular limit would cause any harm. To make sure that I'm not missing any, allow me to make another pass on just that point:

- You suggest monkey jpegs won't shift to using OP_RETURN. I agree. This is not a reason that removing the op_return limit would be harmful.

- Core devs something with some person something another? Of no relevance to the op_return limit and not something I know anything about.

- You claim I claim that there is an anticipation of not yet happened more harmful ways. If so this is still not a reason removing the limit would be harmful. But as a point of order, users stuffing data in 'fake address' outputs is a current thing, not an anticipated thing.

- You claim Pieter ridiculed users, I think you're mistaken (unless you're complaining that he insulted inscriptions users) but it's also of no relevant to the op_return limit.

- You claim (and I don't dispute though I haven't checked) that there are not that many non-standard op_return transactions being mined. This is no a reason that removing the limit would be harmful, it is a confirmation of my point that they are being mined.

- You point out that inscriptions bloated the chainstate. This is not a reason that removing the op_return limit would be harmful (they don't use op_return, but if they did it would reduce chainstate bloat, though I don't expect them to).

- "when Core devs themselves said things like use blocksonly or a bad and shaky claim that we will have utreexo or assumeutreexo in the future" I have no idea what you're talking about, but again, it does not provide a reason that removing the op_return limit is harmful.

- You've vaguely referred to counter arguments to my point that mismatching relay with mining hurts propagation, which might be somewhat relevant but you haven't specified where so I don't know what you're talking about. But that said even if my argument on why failing to disable the limit causes harm was in error, this is still not a reason that it would be harmful to disable the limit.

- You attempt to dismiss my credibility on technology I invented *and* deployed, by dismissing me as a theoretician and suggesting that unspecified "practical" people know better. Yet again, not a reason it would be harmful to disable the limit.

- You suggest communications should improve, complain about moderation not having a good appearance. OK but, at this point you can sing it with me, still no reason removing the limit is harmful.

Have I understood correctly?

Hueristic

Posts

Merits

Most active boards