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 9CB5FC016F for ; Fri, 1 May 2020 06:56:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 84AD88B042 for ; Fri, 1 May 2020 06:56:34 +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 D9Avuv30fSaA for ; Fri, 1 May 2020 06:56:33 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by hemlock.osuosl.org (Postfix) with ESMTPS id 5BB468B041 for ; Fri, 1 May 2020 06:56:33 +0000 (UTC) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0416uV6H025151 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 1 May 2020 02:56:32 -0400 Received: by mail-io1-f47.google.com with SMTP id k23so4095782ios.5 for ; Thu, 30 Apr 2020 23:56:31 -0700 (PDT) X-Gm-Message-State: AGi0PuatZC6HMBPizUFWoub0/fBYdbutpL8wMAFv0ZL27JaPm2xSNxNi rWsLRvYczl1cl65y7yXhbt3LM/sSBNmTY5y3+Ng= X-Google-Smtp-Source: APiQypLiLojARnNUrkCI5qLGJFleA3kDji9lCno5/oBWAZ8u3OYq1g6C+1IxWl8kCE1AGgFnOUByu+gezCWEKoE7l2w= X-Received: by 2002:a5d:97cf:: with SMTP id k15mr2564093ios.49.1588316191173; Thu, 30 Apr 2020 23:56:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Date: Thu, 30 Apr 2020 23:57:09 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Andrew Kozlik , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000005dbd8a05a490ae90" 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 06:56:34 -0000 --0000000000005dbd8a05a490ae90 Content-Type: text/plain; charset="UTF-8" Hi Andrew, If you use SIGHASH_ALL it shall sign the COutPoints of all inputs which commit to the scriptPubKeys of the txn. Thus the 341 hash doesn't need to sign any additional data. As a metadata protocol you can provide all input transactions to check the scriptPubKeys. Best, Jeremy -- @JeremyRubin On Thu, Apr 30, 2020 at 1: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 > --0000000000005dbd8a05a490ae90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Andrew,

If you use SIGHASH_ALL it shall sign the COutPoin= ts of all inputs which commit to the scriptPubKeys of the txn.

= Thus the 341 hash doesn't need to sign any additional data.

As a metadata protocol you can provide all input transactions to check the= scriptPubKeys.

Best,
=
Jeremy
--
@JeremyRubin


On Thu, Apr 30, 202= 0 at 1:22 AM Andrew Kozlik via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> = wrote:
Hi everyone,

In the current draft of BIP-0341 [1] the signa= ture message commits to the scriptPubKey of the output being spent by the i= nput. I propose that the signature message should commit to the scriptPubKe= ys of *all* transaction inputs.

In certain applications like CoinJoi= n, a wallet has to deal with transactions containing external inputs. To ca= lculate the actual amount that the user is spending, the wallet needs to re= liably determine for each input whether it belongs to the wallet or not. Wi= thout such a mechanism an adversary can fool the wallet into displaying inc= orrect information about the amount being spent, which can result in theft = of user funds [2].

In order to ascertain non-ownership of an input w= hich is claimed to be external, the wallet needs the scriptPubKey of the pr= evious output spent by this input. It must acquire the full transaction bei= ng spent and verify its hash against that which is given in the outpoint. T= his is an obstacle in the implementation of lightweight air-gapped wallets = and hardware wallets in general. If the signature message would commit to t= he scriptPubKeys of all transaction inputs, then the wallet would only need= to acquire the scriptPubKey of the output being spent without having to ac= quire and verify the hash of the entire previous transaction. If an attacke= r 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 insuffici= ent for this application, because the scriptPubKeys which are needed to asc= ertain non-ownership of external inputs are precisely the ones that would n= ot be included in any of the signature messages produced by the wallet.

The obvious way to implement this is to add another hash t= o the signature message:
sha_scriptPubKeys (32): the SHA256 of the seria= lization of all scriptPubKeys of the previous outputs spent by this transac= tion.

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/mail= man/listinfo/bitcoin-dev
--0000000000005dbd8a05a490ae90--