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 --]
next prev 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