Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

["Jorge Timón" <jtimon@jtimon.cc>]

As an aside, the decision to make it 40 bytes made sense because it is
enough for timestamping. In fact, you can do cheaper and even secret
(and thus impossible to censor by miners) timestamping using
pay-to-contract [1], which uses exactly 0 extra bytes in your
transaction and the blockchain.
I remember people asking in #bitcoin-dev "Does anyone know any use
case for greater sizes OP_RETURNs?" and me answering "I do not know of
any use cases that require bigger sizes".
I'm aware that so called "proof of publication" is not equivalent to
timestamping, but I wasn't aware at the moment (and I don't think it's
very interesting but that's obviously only my opinion, "embedded
systems" developers will disagree).

[1] Here's a video explaining pay-to-contract in the context of
invoicing as a use case: https://www.youtube.com/watch?v=qwyALGlG33Q
Here's a generic working implementation:
https://github.com/Blockstream/contracthashtool


On Sun, Nov 16, 2014 at 7:44 PM, Jorge Timón <jtimon@jtimon.cc> wrote:
> I agree with Luke, we can endlessly discuss the "best defaults" like
> the default size allowed for OP_RETURN, minimum fees, anti-dust
> policies, first-seen vs replace-by-fee, etc; but the fact is that
> policies depend on miners. Unfortunately most miners and pools are
> quite apathetic when it comes to configure their own policy.
> In my opinion the best we can do is to make it easier for miners to
> implement their own policies by abstracting out those parts of the
> code. Pull requests like #5071 and #5114 are steps in that direction.
> So if you're interested in having more miners accepting 80 bytes
> OP_RETURN transactions, I suggest you invest some time reviewing and
> testing those PRs.
> Although this wasn't its main purpose, separating script/standard was
> also a little step in the same direction.