Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.178 as permitted sender)
	client-ip=209.85.212.178; envelope-from=btcdrak@gmail.com;
	helo=mail-wi0-f178.google.com; 
MIME-Version: 1.0
In-Reply-To: <CABbpET8yyZHO185Fzip61KoRTrGy4bEaoEpnzPuARfhhfPUTCg@mail.gmail.com>
References: <CABbpET9eTgk1GyxYbcG++O_rqsnfB7w5_Xp4XgE6qwkmGsm1eg@mail.gmail.com>
	<201411161724.19573.luke@dashjr.org>
	<CABm2gDpBOtZB01Qj3Dc3dWSpG2zLr+VPYbnwrq8YVh8qfxMW5Q@mail.gmail.com>
	<CABm2gDoi1593ssoGN69E42c-N3s02yYKAqDEDA2m-e+6LqjpTQ@mail.gmail.com>
	<5469692F.9030702@gmail.com>
	<CAPg+sBgM4ja0Y96KekJUN7Qg=o0xa1B0VUiiPuFQTYfrupoERg@mail.gmail.com>
	<CABbpET8yyZHO185Fzip61KoRTrGy4bEaoEpnzPuARfhhfPUTCg@mail.gmail.com>
From: Btc Drak <btcdrak@gmail.com>
Date: Tue, 18 Nov 2014 17:47:05 +0000
Message-ID: <CADJgMzub_UJpYPtpiWmmrDG47G50h7zh6vVo0q9NOwzVmcjCYA@mail.gmail.com>
To: Flavien Charlon <flavien.charlon@coinprism.com>
Content-Type: multipart/alternative; boundary=047d7ba97d68def91b050825afe9
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload
	size
Precedence: list

--047d7ba97d68def91b050825afe9
Content-Type: text/plain; charset=UTF-8

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/

--047d7ba97d68def91b050825afe9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Nov 17, 2014 at 11:43 AM, Flavien Charlon <span dir=3D"ltr">&lt;<a href=
=3D"mailto:flavien.charlon@coinprism.com" target=3D"_blank">flavien.charlon=
@coinprism.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg=
b(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><=
span><div>&gt; My main concern with OP_RETURN is that it seems to encourage=
 people to use the blockchain as a convenient transport channel</div><div><=
br></div></span><div>The number one user of the blockchain as a storage and=
 transport mechanism is Counterparty, and limiting OP_RETURN to 40 bytes di=
dn&#39;t prevent them from doing so. In fact they use multi-sig outputs whi=
ch is worse than OP_RETURN since it&#39;s not always prunable, and yet let =
them store much more than 40 bytes.</div><div><br></div><div>For <a href=3D=
"https://github.com/OpenAssets/open-assets-protocol" target=3D"_blank">Open=
 Assets</a>, we need to store a URL in the OP_RETURN output (with optionall=
y 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 ha=
ve 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 f=
ine for the most basic timestamping application, but it&#39;s hardly enough=
 to build something interesting.</div><div><br></div><div>I&#39;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.=C2=A0Assuming=
 they were all 40 bytes (the average is probably less than half of that), t=
hat means an increase of 14.37 bytes per block. Considering a 1 MB block, t=
hat&#39;s about <span>0.0013% of the block used up by OP_RETURN data in ave=
rage.</span></div><div><span><br></span></div><div><span>Increasing to 80 b=
ytes will have a negligible impact on bandwidth and storage requirements, w=
hile being extremely useful for many use cases where a hash only is not eno=
ugh.</span></div></div></blockquote><div><br></div><div>While I am not oppo=
sing the proposal, I am not sure about your statistics because while Counte=
rparty 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 cha=
rts at their block explorer[2]).</div><div><br></div><div>Refs:<br></div><d=
iv>[1]=C2=A0<a href=3D"http://counterparty.io/news/celebrating-100000-trans=
action-on-the-counterparty-network/" target=3D"_blank">http://counterparty.=
io/news/celebrating-100000-transaction-on-the-counterparty-network/</a></di=
v><div>[2]=C2=A0<a href=3D"http://blockscan.com/" target=3D"_blank">http://=
blockscan.com/</a></div><div><br></div></div></div></div>

--047d7ba97d68def91b050825afe9--