From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 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 , Bitcoin Dev References: <53E1A8AF.4030206@thinlink.com> <53E23F49.3020605@thinlink.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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > 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.