Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mark@monetize.io>) id 1XF4aN-0006C9-BY
	for bitcoin-development@lists.sourceforge.net;
	Wed, 06 Aug 2014 17:01:11 +0000
Received: from mail-pa0-f52.google.com ([209.85.220.52])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1XF4aL-0006Rl-Tr
	for bitcoin-development@lists.sourceforge.net;
	Wed, 06 Aug 2014 17:01:11 +0000
Received: by mail-pa0-f52.google.com with SMTP id bj1so3730155pad.25
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 06 Aug 2014 10:01:04 -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:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=z/Atgc0fPGQLrd+NPQc2CQL8T5VmuciOWblAKBzhJ+Y=;
	b=Lu+EZTIWiGhw0QTqm+IYws1eKBYQ3CpnP4MzFpsQF7XMvru+Zh+Gn0MYf28z+g1+Oa
	Nn6sV6pHGJto4zpF59EvNzmlelIfdx+SzVzc/WoIUcjuwBcfb3KLQF/N+DC6E4QKfgwi
	mDJjH/5RVrD2WuZPS23e4+oSwF2KJJFoCUucVHdMoX+RC+iwbA1RoJApgYYY19hRp22r
	Bq8QoU9LV2gWVs5xYCuBhVaKeCZ171YSn61uVPwXPWu4UaqQKtZbiFYGJffyrAp2Z84M
	wmMmGwJqUcDvmaCKeLxqFBMAmIih+ZBoNR2H7GbVt4O0wtSFhy2hHOT+aqA+8+OyAiWP
	ie6Q==
X-Gm-Message-State: ALoCoQl6EkiDt2Wq+QJn4sXhg6ldT0tqwLgWa4g/eznUt7azQo2ZNdcQcxUE+Gpofozk8yghyR0a
X-Received: by 10.68.223.202 with SMTP id qw10mr4242235pbc.163.1407342685552; 
	Wed, 06 Aug 2014 09:31:25 -0700 (PDT)
Received: from [192.168.127.194] (173-228-106-61.dsl.dynamic.sonic.net.
	[173.228.106.61])
	by mx.google.com with ESMTPSA id e14sm2410380pdm.86.2014.08.06.09.31.24
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 06 Aug 2014 09:31:24 -0700 (PDT)
Message-ID: <53E2585C.8070009@monetize.io>
Date: Wed, 06 Aug 2014 12:31:24 -0400
From: Mark Friedenbach <mark@monetize.io>
Organization: Monetize.io Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Peter Todd <pete@petertodd.org>, 
	Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
References: <CA+iPb=HkxeVPF0SynxCPgUkq4msrdfayFrVNFjzg29rFwqXv1w@mail.gmail.com>	<CAJHLa0O2wFq2Vs5Bes_8x1q_j0VC+U4DQkx=6GqT8w5e8Lh5Qg@mail.gmail.com>	<CA+iPb=ET+A-qB8TgPX8D-ut1DWnq9tZJ=14igfRVWO6eog6Xgw@mail.gmail.com>	<53E1A8AF.4030206@thinlink.com>	<CAJHLa0MfRhCPX8H92qc1kSebc=WrUzmSgbG331t4-zDHhTNu4w@mail.gmail.com>	<CANEZrP3eEiLxYfsAURRm4ysfS4TRgXxa_THxJ43cVH1OyR95JQ@mail.gmail.com>	<53E23F49.3020605@thinlink.com>	<CAJHLa0OtPA3DGQuJhp3zkK5dnBux6TFAw3qDsBdO0zaxrqBgRg@mail.gmail.com>	<CALxbBHXh-Fktsr96PMXdohJdgcUKoNreJ-ZuApKOX3-qSkdk2w@mail.gmail.com>
	<63a80796-609e-43f5-9280-4cd8cf5d2648@email.android.com>
In-Reply-To: <63a80796-609e-43f5-9280-4cd8cf5d2648@email.android.com>
Content-Type: text/plain; charset=windows-1252
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: 1XF4aL-0006Rl-Tr
Subject: Re: [Bitcoin-development] deterministic transaction expiration
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, 06 Aug 2014 17:01:11 -0000

On 08/06/2014 11:42 AM, Peter Todd wrote:
> On 6 August 2014 08:17:02 GMT-07:00, Christian Decker
> <decker.christian@gmail.com> wrote:
>> +1 for the new field, overloading fields with new meaning is
>> definitely not a good idea.
> 
> To add a new field the best way to do it is create a new, parallel,
> tx format where fields are committed by merkle radix tree in an
> extensible and provable way. You'd then commit to that tree with a
> mandatory OP_RETURN output in the last txout, or with a new merkle
> root.
> 
> Changing the tx format itself in a hard-fork is needlessly
> disruptive, and in this case, wastes opportunities for improvement.

I highly doubt that is the best approach.

If this nExpiry field is a consensus rule, then the Merkle tree or the
appropriate paths through needs to be included with the transaction as
part of the network and on-disk data structures, so that proper
validation can be done. This would be both more disruptive and less
efficient than simply adding an nExpiry field to the transaction format,
as we do in Freimarkets.

If the field is pre-consensus (a mempool gentleman's agreement), then it
has no business in the transaction structure at all and should be
packaged in some sort of envelope container.