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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XF4tL-0008MQ-AP for bitcoin-development@lists.sourceforge.net; Wed, 06 Aug 2014 17:20:47 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.113 as permitted sender) client-ip=62.13.148.113; envelope-from=pete@petertodd.org; helo=outmail148113.authsmtp.com; Received: from outmail148113.authsmtp.com ([62.13.148.113]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1XF4tJ-00078e-MX for bitcoin-development@lists.sourceforge.net; Wed, 06 Aug 2014 17:20:47 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s76HKdNT072382; Wed, 6 Aug 2014 18:20:39 +0100 (BST) Received: from [25.186.101.212] ([24.114.23.154]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s76HKUfD054120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2014 18:20:33 +0100 (BST) User-Agent: K-9 Mail for Android In-Reply-To: <53E2585C.8070009@monetize.io> References: <53E1A8AF.4030206@thinlink.com> <53E23F49.3020605@thinlink.com> <63a80796-609e-43f5-9280-4cd8cf5d2648@email.android.com> <53E2585C.8070009@monetize.io> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Peter Todd Date: Wed, 06 Aug 2014 10:20:25 -0700 To: Mark Friedenbach , Bitcoin Dev Message-ID: X-Server-Quench: f9a56901-1d8d-11e4-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdgQUGUATAgsB AmIbWlxeUl17Wmc7 aQ5PbARZfEhNQQRv VFdNRFdNFUsrBhp5 fXtIJhl3cwREeDB5 YkJjECZSDUF8fEZ8 X08AHTkbZGY1bH0W BkdcagNUcgZDfk5E aVUrVz1vNG8XDQg5 AwQ0PjZ0MThBJSBS WgQAK04nCUoGAjMm QhEEHC4zHEZNWz86 KQcvIUIdG0BZP1Uq MEEoRVMfNXc8 X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 24.114.23.154/465 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) 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.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1XF4tJ-00078e-MX 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:20:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 6 August 2014 09:31:24 GMT-07:00, Mark Friedenbach wrote: >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. The general case doesn't require transmission of any merkle data; it is derived from the tx data. Equally changing a data format is certainly: note how Freimarkets has no third-party library support because you've made it incompatible with the standard Bitcoin data structures. Merkle radix tree formatting OTOH is just a cryptographically committed extension of the tag-value concept seen in protobuf, among others. re: efficiency, we need fundamental improvements in efficiency, not little micro-optimisations everywhere done at high cost to maintainability. re: validation, note how the merkle radix tree meets that need by allowing the absence of data to be proven. >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. It's also rather useless without consensus. Expiry is only useful if it is a guarantee, if not you might as well just implement tx replacement directly. -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQFQBAEBCAA6BQJT4mPZMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhcbKCACz/Qh3wm7ud9iwbvm3 Hzib36/fixk2++z6xlxh8G8afUaAe7ADCoz/TLK7RNIhUnr2hlsPO+Id2XvVBSm1 gXavj4iDxq8TpWsC8zPs5vyyY/dVwQ0RbidQFSpncmdW6EYVpIQp9nP3sSnBv1M8 c7BVidg708tc44uYiM9jeTzh6amP5yD0+G9FYYmy36BAQj8+4iD1ZCkiye1y5WUL 9MSN8LOxRFEwWQJmySXmJ1I9V81l1NSRQcQtfLVCzEIWLJXrZ0xwOq0SryEObg73 72NZKc2u8la3CPDoCG773ENbGHl+mGJW9M5ypV0s2RdkdZMgaFNnl/SBrWAcPd43 FkLr =OMOy -----END PGP SIGNATURE-----