From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WGEKN-0003Q8-5u for bitcoin-development@lists.sourceforge.net; Wed, 19 Feb 2014 21:05:11 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.51 as permitted sender) client-ip=209.85.215.51; envelope-from=gmaxwell@gmail.com; helo=mail-la0-f51.google.com; Received: from mail-la0-f51.google.com ([209.85.215.51]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WGEKM-0005oO-7J for bitcoin-development@lists.sourceforge.net; Wed, 19 Feb 2014 21:05:11 +0000 Received: by mail-la0-f51.google.com with SMTP id c6so703046lan.24 for ; Wed, 19 Feb 2014 13:05:03 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.153.11.129 with SMTP id ei1mr1648885lad.78.1392843903525; Wed, 19 Feb 2014 13:05:03 -0800 (PST) Received: by 10.112.189.164 with HTTP; Wed, 19 Feb 2014 13:05:03 -0800 (PST) In-Reply-To: References: <52FBD948.906@monetize.io> <201402122252.31060.luke@dashjr.org> <601EE159-9022-4ADF-80AC-7E1C39E86A65@mac.com> Date: Wed, 19 Feb 2014 13:05:03 -0800 Message-ID: From: Gregory Maxwell To: Peter Todd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.6 (-) 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WGEKM-0005oO-7J Cc: Bitcoin Development Subject: Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability 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, 19 Feb 2014 21:05:11 -0000 dOn Wed, Feb 19, 2014 at 12:49 PM, Peter Todd wrote: > While we might be able to get away with a retroactive change in meaning r= ight now in the future that won't be so easy. There are lots if proposed ap= plications for nLockTime-using protocols that depend on transactions (or pa= rts of transactions) being possible to mine as is. Making existing transact= ions impossible to mine in the future will break those types of application= s. We might as well use this as a learning experience for what a version bu= mp would look like infrastructures wise. For some reason it took me a couple reads to get this so I thought I'd restate it in a more blunt form. There may exist people today who have send funds to addresses, authored nlocktime releases, and destroyed the key the funds are at now in order to achieve a timelock. This might be a foolish thing to do, but it's the kind of thing that you have to worry about when potentially breaking existing transactions. (This kind of us is, fwiw, another example of why ANYONE_CAN_PAY is useful)= .