Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WGDvI-0006UQ-8C for bitcoin-development@lists.sourceforge.net; Wed, 19 Feb 2014 20:39:16 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.169 as permitted sender) client-ip=209.85.217.169; envelope-from=gmaxwell@gmail.com; helo=mail-lb0-f169.google.com; Received: from mail-lb0-f169.google.com ([209.85.217.169]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WGDvG-0004SE-C1 for bitcoin-development@lists.sourceforge.net; Wed, 19 Feb 2014 20:39:16 +0000 Received: by mail-lb0-f169.google.com with SMTP id q8so695430lbi.14 for ; Wed, 19 Feb 2014 12:39:07 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.66.168 with SMTP id g8mr1523244lbt.91.1392842347729; Wed, 19 Feb 2014 12:39:07 -0800 (PST) Received: by 10.112.189.164 with HTTP; Wed, 19 Feb 2014 12:39:07 -0800 (PST) In-Reply-To: <601EE159-9022-4ADF-80AC-7E1C39E86A65@mac.com> References: <52FBD948.906@monetize.io> <201402122252.31060.luke@dashjr.org> <601EE159-9022-4ADF-80AC-7E1C39E86A65@mac.com> Date: Wed, 19 Feb 2014 12:39:07 -0800 Message-ID: From: Gregory Maxwell To: Michael Gronager 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: 1WGDvG-0004SE-C1 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 20:39:16 -0000 On Wed, Feb 19, 2014 at 12:28 PM, Michael Gronager wrote= : > Twisting your words a bit I read: > > * you want to support relay of transactions that can be changed on the fl= y, but you consider it wrong to modify them. > * #3 is already not forwarded, but you still find it relevant to support = it. > > Rational use cases of #3 will be pretty hard to find given the fact that = they can be changed on the fly. We are down to inclusion in blocks by miner= s for special purposes - or did I miss out something? You did. See the other sighash flags. > I think that we could guarantee fewer incidents by making version 1 trans= actions unmalleable and then optionally introduce a version 3 that supporte= d the malleability feature. That way most existing problematic implementati= ons would be fixed and no doors were closed for people experimenting with o= ther stuff - tx v 3 would probably then be called experimental transactions= . In exchange you make the behavior basically impossible do deploy without first blocking all ongoing transactions. This seems foolish. All signers need to be updated to change their behavior to be anti-malleability compatible, they can change their version at the same time... and leave things actually working for the things which can't be easily updated.