From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XqmsC-0005Rp-Cw for bitcoin-development@lists.sourceforge.net; Tue, 18 Nov 2014 17:47:28 +0000 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; Received: from mail-wi0-f178.google.com ([209.85.212.178]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XqmsB-0000rG-1N for bitcoin-development@lists.sourceforge.net; Tue, 18 Nov 2014 17:47:28 +0000 Received: by mail-wi0-f178.google.com with SMTP id hi2so4943055wib.11 for ; Tue, 18 Nov 2014 09:47:21 -0800 (PST) X-Received: by 10.194.205.103 with SMTP id lf7mr5073822wjc.134.1416332840985; Tue, 18 Nov 2014 09:47:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.31.130 with HTTP; Tue, 18 Nov 2014 09:47:05 -0800 (PST) In-Reply-To: References: <201411161724.19573.luke@dashjr.org> <5469692F.9030702@gmail.com> From: Btc Drak Date: Tue, 18 Nov 2014 17:47:05 +0000 Message-ID: To: Flavien Charlon Content-Type: multipart/alternative; boundary=047d7ba97d68def91b050825afe9 X-Spam-Score: 0.0 (/) 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.6 HK_RANDOM_ENVFROM Envelope sender username looks random 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (btcdrak[at]gmail.com) -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: 1XqmsB-0000rG-1N Cc: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 17:47:28 -0000 --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 , 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
On M= on, Nov 17, 2014 at 11:43 AM, Flavien Charlon <flavien.charlon= @coinprism.com> wrote:
<= span>
> My main concern with OP_RETURN is that it seems to encourage= people to use the blockchain as a convenient transport channel
<= br>
The number one user of the blockchain as a storage and= transport mechanism is Counterparty, and limiting OP_RETURN to 40 bytes di= dn't prevent them from doing so. In fact they use multi-sig outputs whi= ch is worse than OP_RETURN since it's not always prunable, and yet let = them store much more than 40 bytes.

For Open= Assets, 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'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.=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's about 0.0013% of the block used up by OP_RETURN data in ave= rage.

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.

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

Refs:
[1]=C2=A0http://counterparty.= io/news/celebrating-100000-transaction-on-the-counterparty-network/

--047d7ba97d68def91b050825afe9--