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

[Flavien Charlon <flavien.charlon@coinprism.com>]

[-- Attachment #1: Type: text/plain, Size: 3982 bytes --]

> My main concern with OP_RETURN is that it seems to encourage people to
use the blockchain as a convenient transport channel

The number one user of the blockchain as a storage and transport mechanism
is Counterparty, and limiting OP_RETURN to 40 bytes didn't prevent them
from doing so. In fact they use multi-sig outputs which is worse than
OP_RETURN since it's not always prunable, and yet let them store much more
than 40 bytes.

For Open Assets <https://github.com/OpenAssets/open-assets-protocol>, we
need to store a URL in the OP_RETURN output (with optionally a hash) plus
some bytes of overhead. 40 bytes comes really short for that. The benefit
of having a URL in there is that any storage mechanism can be used (Web,
FTP, BitTorrent, MaidSafe...), whereas with only a hash, you have to
hardcode the storing mechanism in the protocol (and even then, a hash is
not enough to address a HTTP or FTP resource). Storing only a hash is fine
for the most basic timestamping application, but it's hardly enough to
build something interesting.

I've counted the number of OP_RETURN outputs in the blockchain for the
month of October 2014. There were 1,674 OP_RETURNs for a span of 4,659
blocks. Assuming they were all 40 bytes (the average is probably less than
half of that), that means an increase of 14.37 bytes per block. Considering
a 1 MB block, that's about 0.0013% of the block used up by OP_RETURN data
in average.

Increasing to 80 bytes will have a negligible impact on bandwidth and
storage requirements, while being extremely useful for many use cases where
a hash only is not enough.

Flavien

On Mon, Nov 17, 2014 at 10:35 AM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:

> On Mon, Nov 17, 2014 at 4:19 AM, Alan Reiner <etotheipi@gmail.com> wrote:
> >
> > On 11/16/2014 02:04 PM, Jorge Timón wrote:
> >> 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".
> >
> > For reference, there was a brief time where I was irritated that the
> > size had been reduced to 40 bytes, because I had an application where I
> > wanted to put ECDSA in signatures in the OP_RETURN, and you're going to
> > need at least 64 bytes for that.   Unfortunately I can't remember now
> > what that application was, so it's difficult for me to argue for it.
> > But I don't think that's an unreasonable use case:  sending a payment
> > with a signature, essentially all timestamped in the blockchain.
>
> You can still send the signature out of band (for example using the
> payment protocol), and just have the transaction commit to a hash of
> that signature (or message in general), either using an OP_RETURN
> output to store the hash, or using the pay-to-contract scheme that
> Jorge mentioned above. That has exactly the same timestamping
> properties.
>
> My main concern with OP_RETURN is that it seems to encourage people to
> use the blockchain as a convenient transport channel, rather than just
> for data that the world needs to see to validate it. I'd rather
> encourage solutions that don't require additional data there, which in
> many cases (but not all) is perfectly possible.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 5105 bytes --]