Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mark@monetize.io>) id 1WgfPV-0005qy-FI
	for bitcoin-development@lists.sourceforge.net;
	Sat, 03 May 2014 19:15:45 +0000
Received: from mail-pa0-f42.google.com ([209.85.220.42])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WgfPU-00047d-EX
	for bitcoin-development@lists.sourceforge.net;
	Sat, 03 May 2014 19:15:45 +0000
Received: by mail-pa0-f42.google.com with SMTP id bj1so7231905pad.1
	for <bitcoin-development@lists.sourceforge.net>;
	Sat, 03 May 2014 12:15:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:organization:user-agent
	:mime-version:to:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=tU7W9WfljrO7qW6fFS+ejKSrr69iPwRUy+5lInEhejg=;
	b=Tk59UCJ86QHtVJSFiJenJkMOFtml5/PX/zmG05CbOIiocmKa+WVohrFGdnFXkX1PkM
	/60I8mfG2XMdsk/IAwNwLfbGONHYTab3Bc98bNgBOBpE0nl2hz+j5ZKK4KbHRQQnkxBI
	w4VEy8eWV6Y8VvZMkaxmazMtuoEak4NjdFCG5aj4LMjIFhV0uOFGZhSqjNSm94A/zG8Z
	xosmQlv12RR8sLNO1bl5eh9YzZUSbgf9jQpi/saM6gUNdZgcvJjjgKWP1epasAAhw4kZ
	dgG+e70tdpiFGO8uG7yN1yEC0e9u3CHtcl9WsnGNnAOc3MtdlrlrxHAItMxJdBKB21/k
	J3mw==
X-Gm-Message-State: ALoCoQmV6mDqVbBFLc1r3kybernoKpoUNJRme0kHs2iNJO+Jweodo6feYzRSlvsgWgEUskGDd+xr
X-Received: by 10.67.5.7 with SMTP id ci7mr8807168pad.99.1399144538304;
	Sat, 03 May 2014 12:15:38 -0700 (PDT)
Received: from [192.168.127.188] (50-0-36-93.dsl.dynamic.sonic.net.
	[50.0.36.93]) by mx.google.com with ESMTPSA id
	xg8sm25841308pac.26.2014.05.03.12.15.36 for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Sat, 03 May 2014 12:15:37 -0700 (PDT)
Message-ID: <53654057.1080105@monetize.io>
Date: Sat, 03 May 2014 12:15:35 -0700
From: Mark Friedenbach <mark@monetize.io>
Organization: Monetize.io Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Gregory Maxwell <gmaxwell@gmail.com>
References: <CABbpET-uDQRFQ_XAFeWkgc=A1jEW62Q+8BTZZuW5UbZXX0y+HQ@mail.gmail.com>	<218332ea-948d-4af0-b4c5-ced83f25d734@email.android.com>	<53653B90.4070401@monetize.io>
	<CAAS2fgS61rxB3x4ii68XTHC-V_jpfng-Px6Tv9GV20-putiLUQ@mail.gmail.com>
In-Reply-To: <CAAS2fgS61rxB3x4ii68XTHC-V_jpfng-Px6Tv9GV20-putiLUQ@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1WgfPU-00047d-EX
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bug with handing of OP_RETURN?
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: Sat, 03 May 2014 19:15:45 -0000

Is it more complex? The current implementation using template matching
seems more complex than `if script.vch[0] == OP_RETURN &&
script.vch.size() < 42`

On 05/03/2014 12:08 PM, Gregory Maxwell wrote:
> On Sat, May 3, 2014 at 11:55 AM, Mark Friedenbach <mark@monetize.io> wrote:
>> I don't think such a pull request would be accepted. The point was to
>> minimize impact to the block chain. Each extras txout adds 9 bytes
>> minimum, with zero benefit over serializing the data together in a
>> single OP_RETURN.
> 
> In this case it's not a question extra txouts, its a question of
> additional pushes. Assuming you didn't get the push overhead for free,
> the only issue I see with that off the cuff is extra complexity in the
> IsStandard rule... but really, why?  Your application already needs to
> define the meaning of the data— what point is there in making your
> hash commitment less uniform with the rest of the network?
>