From: Flavien Charlon <flavien.charlon@coinprism•com>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
Date: Mon, 17 Nov 2014 11:43:38 +0000 [thread overview]
Message-ID: <CABbpET8yyZHO185Fzip61KoRTrGy4bEaoEpnzPuARfhhfPUTCg@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBgM4ja0Y96KekJUN7Qg=o0xa1B0VUiiPuFQTYfrupoERg@mail.gmail.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 --]
next prev parent reply other threads:[~2014-11-17 11:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-16 16:21 Flavien Charlon
2014-11-16 17:24 ` Luke Dashjr
2014-11-16 18:44 ` Jorge Timón
2014-11-16 19:04 ` Jorge Timón
2014-11-17 3:19 ` Alan Reiner
2014-11-17 10:35 ` Pieter Wuille
2014-11-17 11:20 ` Adam Back
2014-11-17 12:31 ` Chris Pacia
2014-11-17 12:39 ` Pieter Wuille
2014-11-18 22:33 ` Chris Pacia
2014-11-17 11:43 ` Flavien Charlon [this message]
2014-11-17 12:00 ` Pieter Wuille
2014-11-17 12:22 ` Jorge Timón
2014-11-18 17:47 ` Btc Drak
2014-11-19 0:46 ` Flavien Charlon
2014-11-17 10:30 ` Wladimir
2014-11-20 23:39 ` Jean-Pierre Rupp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABbpET8yyZHO185Fzip61KoRTrGy4bEaoEpnzPuARfhhfPUTCg@mail.gmail.com \
--to=flavien.charlon@coinprism$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pieter.wuille@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox