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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Ylk26-00029k-LL for bitcoin-development@lists.sourceforge.net; Fri, 24 Apr 2015 20:17:06 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.171 as permitted sender) client-ip=209.85.223.171; envelope-from=gmaxwell@gmail.com; helo=mail-ie0-f171.google.com; Received: from mail-ie0-f171.google.com ([209.85.223.171]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Ylk23-00015x-11 for bitcoin-development@lists.sourceforge.net; Fri, 24 Apr 2015 20:17:06 +0000 Received: by iedfl3 with SMTP id fl3so103312976ied.1 for ; Fri, 24 Apr 2015 13:16:57 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.12.10 with SMTP id u10mr1050523igb.8.1429906617777; Fri, 24 Apr 2015 13:16:57 -0700 (PDT) Received: by 10.107.15.82 with HTTP; Fri, 24 Apr 2015 13:16:57 -0700 (PDT) In-Reply-To: References: <552EF785.7000207@sky-ip.org> <552FDF73.6010104@sky-ip.org> Date: Fri, 24 Apr 2015 20:16:57 +0000 Message-ID: From: Gregory Maxwell To: William Swanson Content-Type: text/plain; charset=UTF-8 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: 1Ylk23-00015x-11 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] 75%/95% threshold for transaction versions 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: Fri, 24 Apr 2015 20:17:06 -0000 On Fri, Apr 24, 2015 at 7:58 PM, William Swanson wrote: > On Thu, Apr 16, 2015 at 9:12 AM, s7r wrote: >> Thanks for your reply. I agree. Allen has a good point in the previous >> email too, so the suggestion might not fix anything and complicate things. > > The BIP 62 approach to malleability isn't the only option. Another > approach is to sign the transaction in such a way that the input > txid's are allowed to change without invalidating the signatures. That > way, if malleability happens, you just adjust you transaction to match > and re-broadcast. That proposal is here: This is not a free choice. There are several concerns, from mild to severe, that arise when you do not sign enough. In particular not covering the ID allows for transaction replay which can result in monetary losses far more severe than any possible mishandling of malleability could result in. Byzantine attackers can costlessly replay your old transactions any time anyone reuses an address, even accidentally (which cannot be easily prevented since they can race). Other fun effects also show up like being able to backwards compute signatures to result in a kind of limited covenant- coins which can only be spent a particular way which has some implications for fungibility. (See here for a discussion in general of covenants: https://bitcointalk.org/index.php?topic=278122.0) There are no free lunches; the proposal linked to there is itself a game of wack-a-mole with assorted masking flags; many of which we have no notion of if they're useful for any particular application(s); and it doesn't provide tools to address the replay issue; and in order to 'improve' malleability via that mechanism you must always mask out the inputs completely; meaning you'd always be exposed to replay and not just in specialized 'contract' applications where "there won't be address reuse" could be a strong assumption enforced by the application.