public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Btc Drak <btcdrak@gmail.com>
To: Flavien Charlon <flavien.charlon@coinprism.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
Date: Tue, 18 Nov 2014 17:47:05 +0000	[thread overview]
Message-ID: <CADJgMzub_UJpYPtpiWmmrDG47G50h7zh6vVo0q9NOwzVmcjCYA@mail.gmail.com> (raw)
In-Reply-To: <CABbpET8yyZHO185Fzip61KoRTrGy4bEaoEpnzPuARfhhfPUTCg@mail.gmail.com>

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

On Mon, Nov 17, 2014 at 11:43 AM, Flavien Charlon <
flavien.charlon@coinprism.com> wrote:

> > 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.
>

While I am not opposing the proposal, I am not sure about your statistics
because while Counterparty is not currently using OP_RETURN encoding, you
should factor in the number of CP transactions that would have been
OP_RETURNs if they had been permitted (100,000 since inception according
their blog[1] with monthly charts at their block explorer[2]).

Refs:
[1]
http://counterparty.io/news/celebrating-100000-transaction-on-the-counterparty-network/
[2] http://blockscan.com/

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

  parent reply	other threads:[~2014-11-18 17:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-16 16:21 [Bitcoin-development] Increasing the OP_RETURN maximum payload size 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
2014-11-17 12:00             ` Pieter Wuille
2014-11-17 12:22             ` Jorge Timón
2014-11-18 17:47             ` Btc Drak [this message]
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=CADJgMzub_UJpYPtpiWmmrDG47G50h7zh6vVo0q9NOwzVmcjCYA@mail.gmail.com \
    --to=btcdrak@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=flavien.charlon@coinprism.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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