summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorFlavien Charlon <flavien.charlon@coinprism.com>2014-11-19 00:46:51 +0000
committerbitcoindev <bitcoindev@gnusha.org>2014-11-19 00:47:44 +0000
commitef3fe9ac888710db47269e1810bdf1a6478725d7 (patch)
treef96344ffd3c73bad1d9afce6cb6d54e648875246
parentd3d6fbf3fbd1ed24339b81bddd66e7c83989b9db (diff)
downloadpi-bitcoindev-ef3fe9ac888710db47269e1810bdf1a6478725d7.tar.gz
pi-bitcoindev-ef3fe9ac888710db47269e1810bdf1a6478725d7.zip
Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
-rw-r--r--c0/b9e40b4c56ce50ac6f3702603dbd512dcb1255221
1 files changed, 221 insertions, 0 deletions
diff --git a/c0/b9e40b4c56ce50ac6f3702603dbd512dcb1255 b/c0/b9e40b4c56ce50ac6f3702603dbd512dcb1255
new file mode 100644
index 000000000..371aedcfd
--- /dev/null
+++ b/c0/b9e40b4c56ce50ac6f3702603dbd512dcb1255
@@ -0,0 +1,221 @@
+Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
+ helo=mx.sourceforge.net)
+ by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
+ (envelope-from <flavien.charlon@pixodegames.com>) id 1XqtQt-0002Y5-Eo
+ for bitcoin-development@lists.sourceforge.net;
+ Wed, 19 Nov 2014 00:47:44 +0000
+Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of
+ pixodegames.com designates 209.85.217.180 as permitted sender)
+ client-ip=209.85.217.180;
+ envelope-from=flavien.charlon@pixodegames.com;
+ helo=mail-lb0-f180.google.com;
+Received: from mail-lb0-f180.google.com ([209.85.217.180])
+ by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
+ (Exim 4.76) id 1XqtQr-0004hL-9f
+ for bitcoin-development@lists.sourceforge.net;
+ Wed, 19 Nov 2014 00:47:43 +0000
+Received: by mail-lb0-f180.google.com with SMTP id z11so11520272lbi.39
+ for <bitcoin-development@lists.sourceforge.net>;
+ Tue, 18 Nov 2014 16:47:34 -0800 (PST)
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=1e100.net; s=20130820;
+ h=x-gm-message-state:mime-version:in-reply-to:references:from:date
+ :message-id:subject:to:cc:content-type;
+ bh=dhuP7oUASY6QX2lO3L+DLLgeRtFV0ZjttZk5g9aRRcg=;
+ b=BQ2sSIyyEXOvNle1Jku2qE7WTuJATa2Bmtre5oVmG822yoTW6Rq6mpn5Mp3NgVIHPX
+ t7RTa19dS4v2gTu+mh0l4t81FWWV7D5Ouax3ivv4uavFp8QDI8hdKmpqb5kYFAqXpuCW
+ F/Dny4gjKNydqfN7oM3b0zSx2fVtSOyyX/8DgA6DopoYRaqMe0qG8lZgVLhwfkJccGqm
+ AiPfMt6nqGS8pd1Cmzuk+INELD8qwky7qgyO5QtviL/piA9JPbfW0C5RuBnkcGY+w8GT
+ xmstYuAM3BuD/7+rybILgyJC40/VazORoCdB+LE9McGPEDZXCo9kKitleZROgcsNTiut
+ ewjw==
+X-Gm-Message-State: ALoCoQl0u8v+8ItJo2GJKZn2uq+5c/gdaxakrtEZCo42GkBb6yqnjIF8F1qWBwx32gnJ3TyYcjsO
+X-Received: by 10.112.254.162 with SMTP id aj2mr2360833lbd.70.1416358054731;
+ Tue, 18 Nov 2014 16:47:34 -0800 (PST)
+Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com.
+ [209.85.217.180])
+ by mx.google.com with ESMTPSA id w8sm44469lbp.46.2014.11.18.16.47.34
+ for <bitcoin-development@lists.sourceforge.net>
+ (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
+ Tue, 18 Nov 2014 16:47:34 -0800 (PST)
+Received: by mail-lb0-f180.google.com with SMTP id z11so11777402lbi.11
+ for <bitcoin-development@lists.sourceforge.net>;
+ Tue, 18 Nov 2014 16:47:34 -0800 (PST)
+X-Received: by 10.152.42.226 with SMTP id r2mr2444758lal.29.1416358054258;
+ Tue, 18 Nov 2014 16:47:34 -0800 (PST)
+MIME-Version: 1.0
+Received: by 10.114.23.227 with HTTP; Tue, 18 Nov 2014 16:46:51 -0800 (PST)
+X-Originating-IP: [89.100.161.202]
+In-Reply-To: <CADJgMzub_UJpYPtpiWmmrDG47G50h7zh6vVo0q9NOwzVmcjCYA@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>
+ <CADJgMzub_UJpYPtpiWmmrDG47G50h7zh6vVo0q9NOwzVmcjCYA@mail.gmail.com>
+From: Flavien Charlon <flavien.charlon@coinprism.com>
+Date: Wed, 19 Nov 2014 00:46:51 +0000
+Message-ID: <CABbpET_ycdiQV+1F+rCjhuwQXv=1W=4ywdES-rxvqDf3v2HfuQ@mail.gmail.com>
+To: Btc Drak <btcdrak@gmail.com>
+Content-Type: multipart/alternative; boundary=001a11c35088b3003605082b8eca
+X-Spam-Score: -0.6 (/)
+X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
+ See http://spamassassin.org/tag/ for more details.
+ -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
+ sender-domain
+ -0.0 SPF_PASS SPF: sender matches SPF record
+ 1.0 HTML_MESSAGE BODY: HTML included in message
+ -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
+ author's domain
+ 0.1 DKIM_SIGNED Message has a DKIM or DK signature,
+ not necessarily valid
+ -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
+X-Headers-End: 1XqtQr-0004hL-9f
+Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
+Subject: Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload
+ size
+X-BeenThere: bitcoin-development@lists.sourceforge.net
+X-Mailman-Version: 2.1.9
+Precedence: list
+List-Id: <bitcoin-development.lists.sourceforge.net>
+List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
+ <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
+List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
+List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
+List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
+List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
+ <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
+X-List-Received-Date: Wed, 19 Nov 2014 00:47:44 -0000
+
+--001a11c35088b3003605082b8eca
+Content-Type: text/plain; charset=UTF-8
+
+>
+> 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]).
+
+
+Sure, but even if they are not permitted to store their data in OP_RETURN,
+they will still store it in the blockchain in bare multisig outputs, so
+it's not contributing to an overhead (in fact, it would consume less space
+in the blockchain if they used OP_RETURN).
+
+On Tue, Nov 18, 2014 at 5:47 PM, Btc Drak <btcdrak@gmail.com> wrote:
+
+> 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/
+>
+>
+
+--001a11c35088b3003605082b8eca
+Content-Type: text/html; charset=UTF-8
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
+0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-w=
+idth:1px;border-left-style:solid">While I am not opposing the proposal, I a=
+m not sure about your statistics because while Counterparty is not currentl=
+y using OP_RETURN encoding, you should factor in the number of CP transacti=
+ons that would have been OP_RETURNs if they had been permitted (100,000 sin=
+ce inception according their blog[1] with monthly charts at their block exp=
+lorer[2]).</blockquote><div><br></div><div>Sure, but even if they are not p=
+ermitted to store their data in OP_RETURN, they will still store it in the =
+blockchain in bare multisig outputs, so it&#39;s not contributing to an ove=
+rhead (in fact, it would consume less space in the blockchain if they used =
+OP_RETURN).=C2=A0</div></div><div class=3D"gmail_extra"><br><div class=3D"g=
+mail_quote">On Tue, Nov 18, 2014 at 5:47 PM, Btc Drak <span dir=3D"ltr">&lt=
+;<a href=3D"mailto:btcdrak@gmail.com" target=3D"_blank">btcdrak@gmail.com</=
+a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
+ 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
+v class=3D"gmail_extra"><div class=3D"gmail_quote"><span>On Mon, Nov 17, 20=
+14 at 11:43 AM, Flavien Charlon <span dir=3D"ltr">&lt;<a href=3D"mailto:fla=
+vien.charlon@coinprism.com" target=3D"_blank">flavien.charlon@coinprism.com=
+</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
+:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bord=
+er-left-width:1px;border-left-style:solid"><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></spa=
+n><div>The number one user of the blockchain as a storage and transport mec=
+hanism is Counterparty, and limiting OP_RETURN to 40 bytes didn&#39;t preve=
+nt them from doing so. In fact they use multi-sig outputs which is worse th=
+an OP_RETURN since it&#39;s not always prunable, and yet let them store muc=
+h more than 40 bytes.</div><div><br></div><div>For <a href=3D"https://githu=
+b.com/OpenAssets/open-assets-protocol" target=3D"_blank">Open Assets</a>, w=
+e 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, FT=
+P, 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 mo=
+st basic timestamping application, but it&#39;s hardly enough to build some=
+thing 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 we=
+re 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), that means an i=
+ncrease of 14.37 bytes per block. Considering a 1 MB block, that&#39;s abou=
+t <span>0.0013% of the block used up by OP_RETURN data in average.</span></=
+div><div><span><br></span></div><div><span>Increasing to 80 bytes will have=
+ a negligible impact on bandwidth and storage requirements, while being ext=
+remely useful for many use cases where a hash only is not enough.</span></d=
+iv></div></blockquote><div><br></div></span><div>While I am not opposing th=
+e 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 permitt=
+ed (100,000 since inception according their blog[1] with monthly charts at =
+their block explorer[2]).</div><div><br></div><div>Refs:<br></div><div>[1]=
+=C2=A0<a href=3D"http://counterparty.io/news/celebrating-100000-transaction=
+-on-the-counterparty-network/" target=3D"_blank">http://counterparty.io/new=
+s/celebrating-100000-transaction-on-the-counterparty-network/</a></div><div=
+>[2]=C2=A0<a href=3D"http://blockscan.com/" target=3D"_blank">http://blocks=
+can.com/</a></div><div><br></div></div></div></div>
+</blockquote></div><br></div>
+
+--001a11c35088b3003605082b8eca--
+
+