From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3F365C016F for ; Fri, 1 May 2020 12:23:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 2CF3289F61 for ; Fri, 1 May 2020 12:23:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hh7RGwLA4Ciu for ; Fri, 1 May 2020 12:23:20 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-il1-f179.google.com (mail-il1-f179.google.com [209.85.166.179]) by hemlock.osuosl.org (Postfix) with ESMTPS id 1B18189F5B for ; Fri, 1 May 2020 12:23:20 +0000 (UTC) Received: by mail-il1-f179.google.com with SMTP id c18so4298955ile.5 for ; Fri, 01 May 2020 05:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=d6KUntkmhyIbnxWDmgnsn/FytgMWau3pe64B0+7HrDw=; b=Q90xq4db/uD82X5qbi2M9F1vrX3OvuKhqwVBbIdnPkww3z2ncP0glkVjJGbyl3JBa4 U79yOZhZRh57OpBoXHmOOrPe2+OVO4JcYJsI44bbnr+jPF26gP+OVVyzsx2ZVmlkT768 mQIq2jEg2qBnQpZp0df0dXJhRDY39RiOSbBbUKEhqfSseUqrCLBasoLkfTMLdvezoz+b rGmcsqHHJnB7L6lP/sLKz0MUGjjWLZRodtd+GZjKowWDc0l49ujhjF7dxEqBIS5Q5n1u YWeRsVJ5wWpCUizJ5vwUk6Q7XRG3P9dYeETHA3uP4pYCi8xlnv3jOyNlSs62pED7XpFv 3+tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=d6KUntkmhyIbnxWDmgnsn/FytgMWau3pe64B0+7HrDw=; b=FddtLd8cZF25aKEbec1wuPwSC3piWqOlNH2wXBnwgvr1JI+pt1tkCHnUHMwg238kIw cYTOKVoMidvUjLXhIkEvFmgwNDMDfjzkrbY1NZqiBAYabYChLExBwhADtyks84LxIppF eTjkCNqEKRSzK7yPVszaG/Tzi+2NyIusbuqbZxDmXfDrSTxWCJxx3wXaPRx7sL9O9/K5 /BHMSiN5sa2hfbNdzFlNvBx75AUB0wwgivf8DaiygSe6DrQtCSWBDSb1+Mc6TaiuAgFg kco1rYx7ZGYxosPDsy51fCOQdyvDv5ENPPqAS/vXv/LrDMelQKaZG3kE9qdXjKOeIGsp al1g== X-Gm-Message-State: AGi0PuammJ83xC4BBpVG6Ybs0Xg8xtlvr1THvvTES4fvw8//HoRatRrf zPDkM+VdNbdralyIorAeVpPNUQXknRX/K+rGueqWuA== X-Google-Smtp-Source: APiQypLFahiSvZMxh4u3sjTunOR2dUp0uLS0k0QnRX5dhvDGPbbziO/s6gjW/Uvw7YSWpZ/Muut1pPjfAq5OLH0LyJY= X-Received: by 2002:a92:89d5:: with SMTP id w82mr3144821ilk.153.1588335799258; Fri, 01 May 2020 05:23:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Russell O'Connor" Date: Fri, 1 May 2020 08:23:07 -0400 Message-ID: To: Andrew Kozlik , Bitcoin Protocol Discussion , Pieter Wuille , jonasd.nick@gmail.com, Anthony Towns Content-Type: multipart/alternative; boundary="000000000000196de005a4953f67" Subject: Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 12:23:21 -0000 --000000000000196de005a4953f67 Content-Type: text/plain; charset="UTF-8" While I'm not entirely convinced yet that accertaining non-ownership of an input is a robust method of solving the problem here, I also see little reason not to amend BIP-341 as proposed. The ScriptPubKeys in question is already indirectly covered through the outpoints, so it is just a matter of optimization. Furthermore in the consensus code, the ScriptPubKeys are part of the UTXO data set, and it is already being retrieved as part of the transaction checking process, so it is readily available. I'm not sure how much my opinion on the topic matters, but I did include this kind of functionality in my design for Simplicity on Elements, and I have been leaning towards adding this kind of functionality in my Bitcoin demo application of Simplicity. Regarding specifics, I personally think it would be better to keep the hashes of the ScriptPubKeys separate from the hashes of the input values. This way anyone only interested in input values does not need to wade through what are, in principle, arbitrarily long ScriptPubKeys in order to check the input values (which each fixed size). To that end, I would also (and independently) propose separating the hashing of the output values from the output ScriptPubKeys in `sha_outputs` so again, applications interested only in summing the values of the outputs (for instance to compute fees) do not have to wade through those arbitrarily long ScriptPubKeys in the outputs. On Thu, Apr 30, 2020 at 4:22 AM Andrew Kozlik via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi everyone, > > In the current draft of BIP-0341 [1] the signature message commits to the > scriptPubKey of the output being spent by the input. I propose that the > signature message should commit to the scriptPubKeys of *all* transaction > inputs. > > In certain applications like CoinJoin, a wallet has to deal with > transactions containing external inputs. To calculate the actual amount > that the user is spending, the wallet needs to reliably determine for each > input whether it belongs to the wallet or not. Without such a mechanism an > adversary can fool the wallet into displaying incorrect information about > the amount being spent, which can result in theft of user funds [2]. > > In order to ascertain non-ownership of an input which is claimed to be > external, the wallet needs the scriptPubKey of the previous output spent by > this input. It must acquire the full transaction being spent and verify its > hash against that which is given in the outpoint. This is an obstacle in > the implementation of lightweight air-gapped wallets and hardware wallets > in general. If the signature message would commit to the scriptPubKeys of > all transaction inputs, then the wallet would only need to acquire the > scriptPubKey of the output being spent without having to acquire and verify > the hash of the entire previous transaction. If an attacker would provide > an incorrect scriptPubKey, then that would cause the wallet to generate an > invalid signature message. > > Note that committing only to the scriptPubKey of the output being spent is > insufficient for this application, because the scriptPubKeys which are > needed to ascertain non-ownership of external inputs are precisely the ones > that would not be included in any of the signature messages produced by the > wallet. > > The obvious way to implement this is to add another hash to the signature > message: > sha_scriptPubKeys (32): the SHA256 of the serialization of all > scriptPubKeys of the previous outputs spent by this transaction. > > Cheers, > Andrew Kozlik > > [1] > https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#common-signature-message > [2] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014843.html > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000196de005a4953f67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While I'm not entirely convinced yet that accerta= ining non-ownership of an input is a robust method of solving the problem h= ere, I also see little reason not to amend BIP-341 as proposed. The ScriptP= ubKeys in question is already indirectly covered through the outpoints, so = it is just a matter of optimization.=C2=A0 Furthermore in the consensus cod= e, the ScriptPubKeys are part of the UTXO data set, and it is already bein= g retrieved as part of the transaction checking process, so it is readily a= vailable.

I'm not sure how much my opinion on = the topic matters, but I did include this kind of functionality in my desig= n for Simplicity on Elements, and I have been leaning towards adding this k= ind of functionality in my Bitcoin demo application of Simplicity.

Regarding specifics, I personally think it would be better= to keep the hashes of the ScriptPubKeys separate from the hashes of the in= put values.=C2=A0 This way anyone only interested in input values does not = need to wade through what are, in principle, arbitrarily long ScriptPubKeys= in order to check the input values (which each fixed size).=C2=A0 To that = end, I would also (and independently) propose separating the hashing of the= output values from the output ScriptPubKeys in `sha_outputs` so again, app= lications interested only in summing the values of the outputs (for instanc= e to compute fees) do not have to wade through those arbitrarily long Scrip= tPubKeys in the outputs.

On Thu, Apr 30, 2020 at 4:22 AM Andrew Kozlik= via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Hi everyone,
In the current draft of BIP-0341 [1] the signature message commits to the= scriptPubKey of the output being spent by the input. I propose that the si= gnature message should commit to the scriptPubKeys of *all* transaction inp= uts.

In certain applications like CoinJoin, a wallet has to deal wit= h transactions containing external inputs. To calculate the actual amount t= hat the user is spending, the wallet needs to reliably determine for each i= nput whether it belongs to the wallet or not. Without such a mechanism an a= dversary can fool the wallet into displaying incorrect information about th= e amount being spent, which can result in theft of user funds [2].

I= n order to ascertain non-ownership of an input which is claimed to be exter= nal, the wallet needs the scriptPubKey of the previous output spent by this= input. It must acquire the full transaction being spent and verify its has= h against that which is given in the outpoint. This is an obstacle in the i= mplementation of lightweight air-gapped wallets and hardware wallets in gen= eral. If the signature message would commit to the scriptPubKeys of all tra= nsaction inputs, then the wallet would only need to acquire the scriptPubKe= y of the output being spent without having to acquire and verify the hash o= f the entire previous transaction. If an attacker would provide an incorrec= t scriptPubKey, then that would cause the wallet to generate an invalid sig= nature message.

Note that committing only to the scr= iptPubKey of the output being spent is insufficient for this application, b= ecause the scriptPubKeys which are needed to ascertain non-ownership of ext= ernal inputs are precisely the ones that would not be included in any of th= e signature messages produced by the wallet.

The obviou= s way to implement this is to add another hash to the signature message:sha_scriptPubKeys (32): the SHA256 of the serialization of all scriptPubKe= ys of the previous outputs spent by this transaction.

Cheers,
Andrew Kozlik

[1] https://github.com/bitcoin/bips/blob/master/b= ip-0341.mediawiki#common-signature-message
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-= August/014843.html
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000196de005a4953f67--