Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A1E031BB for ; Wed, 21 Oct 2015 08:45:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AAB54E4 for ; Wed, 21 Oct 2015 08:45:04 +0000 (UTC) Received: by wikq8 with SMTP id q8so82473645wik.1 for ; Wed, 21 Oct 2015 01:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=7Rz1MfQxdiK1hEnf4obOZhS6VVV3c2MSFKaM7T2yWxA=; b=oJBjF1sU+utZWCUfPX8He+XeFVeJzBP/agYh/lfJX+HyOvCMZHGdDuC0Oqb6P4Ojz0 tNatoDirc3uDHtSoiktg7bclEGbzj1wKOhRjr9OH/I0eTTIW0hPdcvEMygPe8DVMveFR k5haQD/eEFkouVsXK4paMRNourKG8aQb+J+0KPdbzKYk9+VSTaprmZmSo3M4AWVf3u+w 9TtBBM/y1e41SdvPQHChRByzkCr13VicAaDiMOq0lxkctA5e+n/LH/hjuo+c0U2mUxX9 p+d2wqwwb36k2XsH+R+6pFubOBwR2+jmpBk7ALS3cTP+UgDLohs+8/bIQm9TIgILs/Yt 8l0w== X-Received: by 10.194.111.198 with SMTP id ik6mr10158556wjb.96.1445417103136; Wed, 21 Oct 2015 01:45:03 -0700 (PDT) MIME-Version: 1.0 References: <201510210752.17527.luke@dashjr.org> <201510210839.42420.luke@dashjr.org> In-Reply-To: <201510210839.42420.luke@dashjr.org> From: Christian Decker Date: Wed, 21 Oct 2015 08:44:53 +0000 Message-ID: To: Luke Dashjr Content-Type: multipart/alternative; boundary=001a1130cfa2fc3903052299648c X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 08:45:05 -0000 --001a1130cfa2fc3903052299648c Content-Type: text/plain; charset=UTF-8 Hm, that is true as long as the signer is the only signer of the transaction, otherwise he'd be invalidating the signatures of the other signers. That can however be fixed by having a canonical ordering of Inputs and Outputs, which has been discussed before in order to decrease information that can be gained about the spender. Maybe we can defer to that effort? On Wed, Oct 21, 2015 at 10:41 AM Luke Dashjr wrote: > On Wednesday, October 21, 2015 8:31:42 AM Christian Decker wrote: > > On Wed, Oct 21, 2015 at 9:52 AM Luke Dashjr wrote: > > > On Wednesday, October 21, 2015 7:39:45 AM Christian Decker wrote: > > > > On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr wrote: > > > > > This doesn't completely close malleability (which should be > > > > > documented > > > > > > in > > > > > > > > the BIP), so I'm not sure it's worth the cost, especially if > closing > > > > > malleability later on would need more. How about specifying flags > > > > > > upfront > > > > > > > > in the UTXO-creating transaction specifying which parts the > signature > > > > > will cover? This would allow implementation of fully > > > > > malleability-proof wallets. > > > > > > > > As far as I see it the only remaining venues for malleability are the > > > > use of sighash flags that are not SIGHASH_ALL, as mentioned in the > > > > BIP. Any > > > > > > use > > > > > > > of non-sighash_all flags is already an explicit permission to modify > > > > the transactions, by adding and removing inputs and outputs, so I > > > > don't see > > > > > > how > > > > > > > these can be made non-malleable. Am I missing something? > > > > > > Signer malleability is still a notable concern needing consideration. > > > Ideally, > > > wallets should be trying to actively CoinJoin, bump fees on, etc any > > > pending > > > transactions in the background. These forms of malleability affect > nearly > > > as > > > many real use cases as third-party malleability. > > > > > > Luke > > > > How is signer malleability still a problem if we remove the signatures > from > > the transaction ID of the transaction and all preceding transactions? The > > signer can re-sign a transaction but it won't change the transaction ID. > > The signer can also change the order of the inputs, the inputs themselves, > add/remove outputs, etc... all which should be possible without becoming a > different logical transaction. The only unique property of the logical > transaction is the scriptPubKey/address. > > Luke > --001a1130cfa2fc3903052299648c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hm, that is true as long as the signer is the only signer = of the transaction, otherwise he'd be invalidating the signatures of th= e other signers. That can however be fixed by having a canonical ordering o= f Inputs and Outputs, which has been discussed before in order to decrease = information that can be gained about the spender. Maybe we can defer to tha= t effort?

On Wed, Oct = 21, 2015 at 10:41 AM Luke Dashjr <luk= e@dashjr.org> wrote:
On Wedn= esday, October 21, 2015 8:31:42 AM Christian Decker wrote:
> On Wed, Oct 21, 2015 at 9:52 AM Luke Dashjr <luke@dashjr.org> wrote:
> > On Wednesday, October 21, 2015 7:39:45 AM Christian Decker wrote:=
> > > On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr <luke@dashjr.org> wrote:
> > > > This doesn't completely close malleability (which s= hould be
> > > > documented
> >
> > in
> >
> > > > the BIP), so I'm not sure it's worth the cost, = especially if closing
> > > > malleability later on would need more. How about specif= ying flags
> >
> > upfront
> >
> > > > in the UTXO-creating transaction specifying which parts= the signature
> > > > will cover? This would allow implementation of fully > > > > malleability-proof wallets.
> > >
> > > As far as I see it the only remaining venues for malleabilit= y are the
> > > use of sighash flags that are not SIGHASH_ALL, as mentioned = in the
> > > BIP. Any
> >
> > use
> >
> > > of non-sighash_all flags is already an explicit permission t= o modify
> > > the transactions, by adding and removing inputs and outputs,= so I
> > > don't see
> >
> > how
> >
> > > these can be made non-malleable. Am I missing something?
> >
> > Signer malleability is still a notable concern needing considerat= ion.
> > Ideally,
> > wallets should be trying to actively CoinJoin, bump fees on, etc = any
> > pending
> > transactions in the background. These forms of malleability affec= t nearly
> > as
> > many real use cases as third-party malleability.
> >
> > Luke
>
> How is signer malleability still a problem if we remove the signatures= from
> the transaction ID of the transaction and all preceding transactions? = The
> signer can re-sign a transaction but it won't change the transacti= on ID.

The signer can also change the order of the inputs, the inputs themselves,<= br> add/remove outputs, etc... all which should be possible without becoming a<= br> different logical transaction. The only unique property of the logical
transaction is the scriptPubKey/address.

Luke
--001a1130cfa2fc3903052299648c--