Create account

7d · Bitcoin Cash
@p0oker There was very limited interest in raising the OP_RETURN size when I brought it up about a year ago.
replied 7d
I think the tone will be different if ABC is no longer calling the shots.
replied 7d
ABC definitely not in favor of the idea, but i sensed the feeling was more general among other protocol devs too.
replied 7d
Perhaps some, but it is not my impression that there was a strong stance, as long as it isn't excessive like e.g. on BSV.
replied 7d

wrap some factual context around the topic:
current OP_RETURN data load barely exists.
The numbers are mostly "TX info".
1023Bytes would be OK.
replied 7d
Those file sizes are BYTES
and represent daily logs of the OP_RETURN plus supporting info.
I could count the total number of BYTES consumed
but I lost my tweezers.
replied 7d
Most OP_RETURN data is barely more than a "grunt, snort, yeah naw okay",
Most users would never use as much as 1023Bytes, too much Twitter conditioning.
replied 7d
@jonathansilverblood asked for feedback on allowing multiple larger OP_RETURN about six months back so might be some interest there.
replied 7d
Even some hostility I'd say. Most protocol devs consider it a closed matter.

Technically its a soft limit, you could broadcast and mine nodes with larger op_ret transactions. This
replied 7d
weakens zero conf security though.
replied 7d
Play the Devil's advocate, what's the harm in allowing larger OP_RETURNs? I guess it clutters the blocks, but since we have to send multiple TXs for message, the overhead makes us
replied 7d
use even more bytes in the long run. We still pay per byte, so it's not like a larger OP_RETURN would directly cause heavier usage. Right now, I don't think anyone's worrying about it.
replied 7d
playing devils advocate to your devils advocate, what's wrong with stringing txs together like member does? If it comes down to overhead then that in turn comes down to cost.
replied 7d
It does increase development complexity. So fewer features and more bugs for the same effort.
replied 7d
Only that the overall amount of bytes used is more, & I think the main complaint about larger OP_RETURN is bloating. I suppose there's a sweet spot. Unintended Consequences.
replied 7d
If we upped op_return some miners could respond by upping fees to 2 or 3 sats/b.
replied 7d
If they collude, I suppose, but unless there's a lot more TX, they'd be leaving sats on the table for other miners for no large extra burden.