Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.48 as permitted sender)
	client-ip=209.85.215.48; envelope-from=gmaxwell@gmail.com;
	helo=mail-la0-f48.google.com; 
MIME-Version: 1.0
In-Reply-To: <530BD076.3020606@petersson.at>
References: <CAJHLa0PXHY1qisXhN98DMxgp11ouqkzYMBvrTTNOtwX09T1kZg@mail.gmail.com>
	<CA+s+GJC1FgCW9spkViMPvuWNS84Ys33pj=RP1ZpzBCa++e-iMQ@mail.gmail.com>
	<530B8000.1070801@monetize.io> <530BD076.3020606@petersson.at>
Date: Mon, 24 Feb 2014 15:13:28 -0800
Message-ID: <CAAS2fgT6qFHBojoB-teCjF_YAd9TePdQ3+NWnO0dwf9Bv583_Q@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Andreas Petersson <andreas@petersson.at>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release
Precedence: list

On Mon, Feb 24, 2014 at 3:06 PM, Andreas Petersson <andreas@petersson.at> wrote:
> Regarding 80 bytes vs smaller: The objectives should be that if you are
> determined to put some extra data in the blockchain, OP_RETURN should be
> the superior alternative. if a user can include more data with less fees
> using a multisig TX, then this will happen.
>
> eventually dust-limit rules will not be the deciding factor here, since
> i suspect block propagation times will have a stronger effect on
> effective fees. therefore a slightly larger payload than the biggest
> multisig TX is the right answer. - that would be >= 64x3 bytes = 192 bytes.
> (this is my understanding of how large a 3-of-3 multisig tx can be, plus
> 1.5 bits encoded in the "n" parameter)

At least there is no ambiguity that such usage is abusive. Adoption of
the practices matters too. Right now I've seen a lot of people
promoting data storage as a virtuous use, and gearing up to directly
store data when a commitment would work.

If it turns out that encouraging people to use hashes is a lost cause
it can always be further relaxed in the future, going the other way is
much harder.