From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 77A33C016F for ; Fri, 1 May 2020 12:26:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 65A6F88C91 for ; Fri, 1 May 2020 12:26:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1ltsf1-voBl for ; Fri, 1 May 2020 12:26:06 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) by whitealder.osuosl.org (Postfix) with ESMTPS id 3A11C88C98 for ; Fri, 1 May 2020 12:26:06 +0000 (UTC) Received: by mail-wr1-f51.google.com with SMTP id o27so6038372wra.12 for ; Fri, 01 May 2020 05:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UpyhgpTnz1rNjyPStFL6ir8iKbnIfYRGb3S39QqvEBo=; b=YEzGQe2QECH2Db0aJFJ0UnXC6KOC6KVNLzA3lT+5+eASe2zgMyRpEFEFwAvLiuAs+1 Yg/M5M4V1KPSRpoa+1UooeKMnS6zm+5HOtM/7ofdERZiXH1/vUDigb/QL2CvG7bJHauF n0KbMCR2vwbHpta6xIwIpVSdcwi5FNSM9iopG27OLhh6zlOl1nHGc/aJ14seRfVPv9rg bC/jgiu19dkulhVzPZrrhQuBZLyeUvl3dyGNt4YbbsUroSC+SxrNYW8+NytDwLVl9A1J p3W0+fP7/bf3VtD8WnBt86C/H6V/cKwDXWxzON5hbh+awRIPqETwrGjwK+g2z/11QJQn ualA== 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:cc; bh=UpyhgpTnz1rNjyPStFL6ir8iKbnIfYRGb3S39QqvEBo=; b=T7IDg8CLx/M2fZyZDBxX6skBqtsTp3sy5LkwYK7ghFbr7Mv7kOKH9SfSLG1abWkeAT uz+9AT3FlD18zWnVlyueKh9ua3hk5BtqR1emvgJZuLsesjXD6xKWTYGBqMEFM0psSGqz V6XnflgmRuXBPOwjR3a46GvkqR3cmP3KHW4uoE99sSdkc/M6iSsBQCMWDtJ+XxPhaQhZ kL39YWyYDpx34kZf+FTNxXOUbU/DiHXMg80pjBeVWN70zfeVsDQmwzBlCudUG9YvM5rj 2q4ekeBYkSCeKFNmCepY+DNkzZTCS032aMtiuCLB2kzqEPBOsgva7P5Lxxaj67lfkMNo qfsA== X-Gm-Message-State: AGi0Pubgk5faacJ8SAERXbAa79WWw2HSDzAt3qiN3PVykKoqmMKUYhwD EmjAgkMdQnxxugAXQF+6hCaSl22f+56jOLnSfgI= X-Google-Smtp-Source: APiQypLPejuiAdJBgRXwqa6iojfuJ/F185BxZqlsr7muN5jma9vb0jDIeXIfLqyaPpiEvA44U5vlSxRmymcws91Y5jA= X-Received: by 2002:adf:dd07:: with SMTP id a7mr3843546wrm.349.1588335964670; Fri, 01 May 2020 05:26:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Sanders Date: Fri, 1 May 2020 08:25:53 -0400 Message-ID: To: "Russell O'Connor" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000f5523a05a495484e" Cc: jonasd.nick@gmail.com, Pieter Wuille 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:26:07 -0000 --000000000000f5523a05a495484e Content-Type: text/plain; charset="UTF-8" For what it's worth this measure had been discussed as a lightweight way of informing offline signers if inputs were segwit or not for malleability analysis reasons. So there's at least a couple direct use-cases it seems. On Fri, May 1, 2020, 8:23 AM Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000f5523a05a495484e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For what=C2=A0it's worth this measure had been discus= sed as a lightweight way of informing offline signers if inputs were segwit= or not for malleability analysis reasons. So there's at least a couple= direct use-cases it seems.=C2=A0

On Fri, May 1, 2020, 8:23 AM Russell O'= ;Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
While I'm not entirel= y convinced yet that accertaining non-ownership of an input is a robust met= hod of solving the problem here, I also see little reason not to amend BIP-= 341 as proposed. The ScriptPubKeys in question is already indirectly covere= d through the outpoints, so it is just a matter of optimization.=C2=A0 Furt= hermore 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 l= eaning towards adding this kind of functionality in my Bitcoin demo applica= tion of Simplicity.

Regarding specifics, I persona= lly think it would be better to keep the hashes of the ScriptPubKeys separa= te from the hashes of the input values.=C2=A0 This way anyone only interest= ed in input values does not need to wade through what are, in principle, ar= bitrarily long ScriptPubKeys in order to check the input values (which each= fixed size).=C2=A0 To that end, I would also (and independently) propose s= eparating 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, 202= 0 at 4:22 AM Andrew Kozlik via bitcoin-dev <bitcoin-d= ev@lists.linuxfoundation.org> wrote:
Hi everyone,

In the cur= rent draft of BIP-0341 [1] the signature message commits to the scriptPubKe= y of the output being spent by the input. I propose that the signature mess= age should commit to the scriptPubKeys of *all* transaction inputs.

= In certain applications like CoinJoin, a wallet has to deal with transactio= ns 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 bei= ng spent, which can result in theft of user funds [2].

In order to a= scertain non-ownership of an input which is claimed to be external, the wal= let needs the scriptPubKey of the previous output spent by this input. It m= ust acquire the full transaction being spent and verify its hash against th= at which is given in the outpoint. This is an obstacle in the implementatio= n of lightweight air-gapped wallets and hardware wallets in general. If the= signature message would commit to the scriptPubKeys of all transaction inp= uts, then the wallet would only need to acquire the scriptPubKey of the out= put being spent without having to acquire and verify the hash of the entire= previous transaction. If an attacker would provide an incorrect scriptPubK= ey, then that would cause the wallet to generate an invalid signature messa= ge.

Note that committing only to the scriptPubKey of= the output being spent is insufficient for this application, because the s= criptPubKeys 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 imp= lement this is to add another hash to the signature message:
sha_scriptP= ubKeys (32): the SHA256 of the serialization of all scriptPubKeys of the pr= evious outputs spent by this transaction.

Cheers,
Andrew Kozlik

[1] https://github.com/bitcoin/bips/blob/m= aster/bip-0341.mediawiki#common-signature-message
[2] https://lists.linuxfoundation.org/p= ipermail/bitcoin-dev/2017-August/014843.html
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000f5523a05a495484e--