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 B00E4C016F for ; Fri, 1 May 2020 08:56:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 9E34789945 for ; Fri, 1 May 2020 08:56:09 +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 wrpRWmlI-hOU for ; Fri, 1 May 2020 08:56:08 +0000 (UTC) X-Greylist: delayed 00:07:14 by SQLgrey-1.7.6 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by whitealder.osuosl.org (Postfix) with ESMTPS id 22A068993C for ; Fri, 1 May 2020 08:56:08 +0000 (UTC) Received: by mail-ej1-f49.google.com with SMTP id n4so6992654ejs.11 for ; Fri, 01 May 2020 01:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=satoshilabs.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8/guNtx74L61OAm3KFL30rFLN430D+fE55D+rmKi2OE=; b=PFBFDAJgq2pjiaGJ68ritSyc2uB7unBSqV95eRdShqEWp4eCjCPWZYaDnWy9PN6csO Dfg8ikmH4hOzsHQ1kwUH83Yq6SArjLP9HcVrXilKqgN3rxuSYi9jXjRPE4TFMSP6ONyf mtXbS5Q4i/T98JNrID9M678Od3BHorMCH0AsngvDSYKInUOcAJpw4H3ClJELtC8fzC/X eubAx/Os3Y/c3eIPcxAX6MYvZWtA5URHcFbXA0QpZpX3bmQj1PuOJbFdvca4R549fr9p XOH5i8eWlWgHCoBh232UYm4qtOy3TYU1dz4JMgpmWiHf3l0FWTExHVkLs3MsdoYNlevA MjVw== 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=8/guNtx74L61OAm3KFL30rFLN430D+fE55D+rmKi2OE=; b=B3Rp1Gg7ffy/QOFaVcCGxcvk3Wr4XgUagPgw5bcsRS9v0my7ncONamYaIQQvnKowFn dCvTcYpX9XcSWCkXYgko9lf/BQkc7Y774Rc8wjUQ5sztYhGJtbNazv1GbcPW4xPvua2D J9K4xKMd08SA52lK3DukUCcl3r87Q6CUGTlN+cGDp8lhs2x1Ui2i50ICAgovAAi0um6G 0l7c1fwK3DJsKmV5vOMdjlwWuaZMU0Pt0SM6xt98owAY69CJfetprfrrBpzo+oh3fLp8 tvcCpjsbOpqmGQ6aVtg/sc4pfJRApdVOz8B7FkpRUe/P7B59ADM9JoPBkzqeg5gsESZa 4nIg== X-Gm-Message-State: AGi0PuZ8x6D5SpOXG1Cwf8OmspuULiRjb7KV52Wbu0CCS+VI9mr3HajU Wsddw6W2bhsvmEWl1me+l4MN+V0NdznoZsUscZoHNK1g X-Google-Smtp-Source: APiQypIShc87Y15TDK0+jho4XNG4gtAEXRe67DOZz210zkmMxhbg7Y5hq1aUVjsBUpk8VouRw1BfKjsWr8X85jCyoFU= X-Received: by 2002:a17:906:af6f:: with SMTP id os15mr2293224ejb.78.1588322932763; Fri, 01 May 2020 01:48:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrew Kozlik Date: Fri, 1 May 2020 10:48:41 +0200 Message-ID: To: Jeremy Content-Type: multipart/alternative; boundary="00000000000032446b05a49240de" X-Mailman-Approved-At: Fri, 01 May 2020 11:55:00 +0000 Cc: Bitcoin Protocol Discussion 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 08:56:09 -0000 --00000000000032446b05a49240de Content-Type: text/plain; charset="UTF-8" Hi Jeremy, What you are saying is correct and I am not disputing that there is sufficient cryptographic commitment in the signature message. As I tried to explain, my proposal is about avoiding the need for the metadata protocol you speak of. Avoiding such a protocol has been a design goal in both BIP-143 [1, 2] and BIP-341 [3, 4], because having to acquire each of the transactions being spent in their entirety places a significant burden on offline signing devices. Cheers, Andrew [1] https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#motivation [2] https://bitcointalk.org/index.php?topic=181734.0 [3] https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-16 [4] https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-17 On Fri, May 1, 2020 at 8:56 AM Jeremy wrote: > 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 >> > --00000000000032446b05a49240de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeremy,

What you are saying is correct and I am = not disputing that there is sufficient cryptographic commitment in the sign= ature message. As I tried to explain, my proposal is about avoiding the nee= d for the metadata protocol you speak of. Avoiding such a protocol has been= a design goal in both BIP-143 [1, 2] and BIP-341 [3, 4], because having to= acquire each of the transactions being spent in their entirety places a si= gnificant burden on offline signing devices.

Cheers,
Andrew
[1] https://github.com/bitcoin/bips/blob/mas= ter/bip-0143.mediawiki#motivation
[2] https://bitcointalk.org/= index.php?topic=3D181734.0
[3] https:= //github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-16[4] https://github.com/bitcoin/bips/blob/m= aster/bip-0341.mediawiki#cite_note-17

On Fri, May 1, 2020 at 8:56 AM Jer= emy <jlrubin@mit.ed= u> wrote:
Hi Andrew,

=
If you use SIGHASH_ALL it shall s= ign the COutPoints of all inputs which commit to the scriptPubKeys of the t= xn.

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

As a metadata protocol you can provide all input transac= tions 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 c= urrent draft of BIP-0341 [1] the signature message commits to the scriptPub= Key of the output being spent by the input. I propose that the signature me= ssage should commit to the scriptPubKeys of *all* transaction inputs.
In certain applications like CoinJoin, a wallet has to deal with transact= ions containing external inputs. To calculate the actual amount that the us= er is spending, the wallet needs to reliably determine for each input wheth= er it belongs to the wallet or not. Without such a mechanism an adversary c= an fool the wallet into displaying incorrect information about the amount b= eing 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 w= allet 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 implementat= ion of lightweight air-gapped wallets and hardware wallets in general. If t= he signature message would commit to the scriptPubKeys of all transaction i= nputs, then the wallet would only need to acquire the scriptPubKey of the o= utput being spent without having to acquire and verify the hash of the enti= re previous transaction. If an attacker would provide an incorrect scriptPu= bKey, then that would cause the wallet to generate an invalid signature mes= sage.

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 inpu= ts are precisely the ones that would not be included in any of the signatur= e messages produced by the wallet.

The obvious way to i= mplement this is to add another hash to the signature message:
sha_scrip= tPubKeys (32): the SHA256 of the serialization of all scriptPubKeys of the = previous outputs spent by this transaction.

Cheers,<= br>
Andrew Kozlik

[1] https://github.com/bitcoin/bips/blob/master/bip-0341.me= diawiki#common-signature-message
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014= 843.html
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000032446b05a49240de--