Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D6C4A7AD for ; Sun, 30 Aug 2015 19:45:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 396D4195 for ; Sun, 30 Aug 2015 19:45:08 +0000 (UTC) Received: by obkg7 with SMTP id g7so76520870obk.3 for ; Sun, 30 Aug 2015 12:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sMpbDpumBETRzIBWrpLbo7Z2JHrsFuiJsKQ0TtVTbas=; b=Vdm5I6iy9xZwfvofKDxInfjCWK7HFvk5AJfF+dQp0OK5qfX7i22hpAm3mpoHBy5krD C64KOSnx2xfumuCLdoOs9uesVqmIhBm7b1EVZSCOq3PNm93Rb0RE7RWUuq4nWjqVTkNq FrlV6tlsZuo/ui8/1ArZwef46/cC7RK9FErhfBRRjxwfiPUYnI/l2yeYb7Okozo9YkR4 yLjGgvOjRGzlZmLlEWv1a+BaKRfYQSJBpxLAwr5IHDIaDEE1ywr1YWGP9I4MOS+O4kFf 96NxhmoJDAVsH6pTz+AUc4WIuGhOl2V2TA+Q3h8qc3rDE217sYD3X6Qx6mSAoAuDx+nK +hzQ== MIME-Version: 1.0 X-Received: by 10.60.45.104 with SMTP id l8mr12206621oem.61.1440963907438; Sun, 30 Aug 2015 12:45:07 -0700 (PDT) Received: by 10.202.183.215 with HTTP; Sun, 30 Aug 2015 12:45:07 -0700 (PDT) In-Reply-To: References: Date: Sun, 30 Aug 2015 15:45:07 -0400 Message-ID: From: Kristov Atlas To: wei@openbitcoinprivacyproject.org Content-Type: multipart/alternative; boundary=089e0149ce38d65ff1051e8c8d1e 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] Open Bitcoin Privacy Protect Privacy Questionnaire, Mid-Year 2015 report 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: Sun, 30 Aug 2015 19:45:10 -0000 --089e0149ce38d65ff1051e8c8d1e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Wei, As you know, I'm not a developer of Bitcoin-Qt, but we'll need to make our best guesses for these answers if the developers won't reply. I'm going to post my best guesses here so that people reading the list have a short window of opportunity to correct me if they wish. On Fri, Aug 7, 2015 at 2:46 PM, Wei via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Transaction Formatting > > 1. Does your application take any steps to create ambiguity between > transactions which unavoidably spend from multiple addresses at the same > time and intentional mixing transactions? > No, Bitcoin-Qt does not try to make non-mixing transactions look like mixing transactions. > 2. What algorithms does your application use for ordering inputs and > outputs in a transaction? In particular, how do you handle the change > output and do you take into account common practices of other wallet > applications when determining ordering? > Not yet BIP 69. These notes suggest that outputs are randomized: https://bitcoin.org/en/release/v0.8.1 > 3. Does your application minimize the harmful effects of address > reuse by spending every spendable input (=E2=80=9Csweeping=E2=80=9D) from= an address when a > transaction is created? > Unknown 4. Does your application fully implement BIP 62? > Here's a detailed answer on stack exchange: http://bitcoin.stackexchange.com/questions/35904/how-much-of-bip-62-dealing= -with-malleability-has-been-implemented By item, my extremely brief interpretation: Non-DER encoded ECDSA signatures: BIP66 soft fork has happened, so this is presumed to be implemented Non-push operations in scriptSig: Implemented Push operations in scriptSig of non-standard size type: Implemented in 0.9.= 0 Zero-padded number pushes: Implemented in 0.10.0 (current available version is 0.11.0) Inherent ECDSA signature malleability: ...implemented? Superfluous scriptSig operations: implemented 0.6.0 Inputs ignored by scripts: Only partly addressed by 0.10.0. It appears that the rest would require changes to consensus rules, so Bitcoin-Qt is as compliant as it can be. Sighash flags based masking and New signatures by the sender: Can't be implemented without changes to consensus rules. I would summarize this as a "yes." > > Mixing > > 5. If your application supports mixing: > It doesn't. There's an issue for CoinJoin here: https://github.com/bitcoin/bitcoin/issues/3226 > a. What is the average number of participants a user can expect to > interact with on a typical join transaction? > b. Does your application attempt to construct join transactions in a > way that avoids distinguishing them from non-join transactions? > c. Does your application perform any kind of reversibility analysis > on join transactions prior to presenting them to the user for confirmatio= n? > d. Is the mixing technique employed secure against correlation > attacks by the facilitator, such as a CoinJoin server or off-chain mixing > service? > e. Is the mixing technique employed secure against theft of funds by > the facilitator or its participants? > > Donations > > 6. If your application has a fee or donation to the developers > feature: > No donation feature last time I checked. > a. What steps do you take to make the donations indistinguishable > from regular spend in terms of output sizes and destination addresses? > > Balance Queries and Tx Broadcasting > > 7. Please describe how your application obtains balance information > in terms of how queries from the user=E2=80=99s device can reveal a conne= ction > between the addresses in their wallet. > a. Does the application keep a complete copy of the blockchain > locally (full node)? > Yes > b. Does the user=E2=80=99s device provide a filter which matches som= e > fraction of the blockchain while providing a false positive rate (bloom o= r > prefix filters)? > No, it just downloads the whole blockchain and performs local queries. > i. If so, approximately what fraction of the blockchain does the > filter match in a default configuration (0% - 100%)? > 100%, unless a user bootstraps downloading the blockchain. Bootstrapping will potentially limit the user's anonymity set to other people who have downloaded that bootstrap.dat file. > c. Does the user=E2=80=99s device query all of their addresses at th= e same > time? > N/A > d. Does the user=E2=80=99s device query addresses individually in a = manner > that does not allow the query responder to correlate queries for differen= t > addresses? > No. Just download blocks and processes that information locally. > e. Can users opt to obtain their balance information via Tor (or > equivalent means)? > If Tor is set up as a SOCKS proxy, you can configure Bitcoin-QT download the blockchain and broadcast txs through a single Tor circuit. This can be configured once before opening Bitcoin-Qt. 8. Does the applications route outgoing transactions independently > from the manner in which it obtains balance information? Can users opt to > have their transactions submitted to the Bitcoin network via Tor (or an > equivalent means) independently of how they obtain their balance > information? > No, you can only configure a single proxy. > 9. If your application supports multiple identities/wallets, does > each one connect to the network as if it were completely independent from > the other? > No built-in support for multiple identities. You can hotswap wallet files to crudely simulate this. You'd have to manually change the Tor connection outside of Bitcoin-Qt to create the effect of making the network connections independent. > a. Does the application ever request balance information for > addresses belonging to multiple identities in the same network query? > Blocks are downloaded and tx broadcasts received/relayed rather than querying the utxo set for a particular address. When swapping between wallet files, some information may be leaked e.g. the client may be at the same block height in terms of what it has downloaded from the p2p network, which may leak to global passive adversaries/AS's or sybil attackers the fact that a single client was used for multiple wallets. > b. Are outgoing transactions from multiple identities routed > independently of each other to the Bitcoin network? > Transactions from multiple identities would not be routed at the same time. I'm not clear what happens if you have a single wallet (identity) open and then open a new wallet (identity) without closing Bitcoin-Qt -- some of the same routing paths may still be used such that an attacker might observe transactions broadast signed by private keys from multiple wallets (identities) and observe that they appear to come from the same wallet client. OBPP should assume the worst unless prevented contrary evidence. > c. When an identity/wallet is deleted, does the deletion process > eliminate all evidence from the user's device that the wallet was > previously installed? > Identity is primarily tied to a wallet.dat file. Deleting it will remove most of the evidence that the wallet was installed on that device, but there may be some extra information in ancillary files that should also be deleted. This is an OS-level function, as there is no operation built into the client to delete a wallet file (identity). > Network Privacy > > 10. When a user performs a backup operation for their wallet, does > this generate any automatic network activity, such as a web query or emai= l? > No. Backups are local, and no email or SMS is linked. No web queries related to backup. > 11. Does your application perform any lookup external to the user=E2= =80=99s > device related to identifying transaction senders or recipients? > No > 12. Does you application connect to known endpoints which would be > visible to an ISP, such as your domain? > Yes, some connections to known p2p full nodes to bootstrap the connection to the Bitcoin p2p network. This is configurable, but there are defaults. An ISP is likely to be able to identify a customer as running the Bitcoin-Qt client in particular on this basis. > 13. If your application connects directly to nodes in the Bitcoin P2P > network, does it either use an unremarkable user agent string (Bitcoin > Core. BitcoinJ, etc), or randomize its user agent on each connection? > BIP12 specifies format for user agents: https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki It appears that the Bitcoin-QT leaks specific information about its client version through User Agent. This file defines the current client version: https://github.com/bitcoin/bitcoin/blob/55294a9fb673ab0a7c99b9c18279fe12a5a= 07890/src/clientversion.h Various other files seem to use this to build up the UA string, which is transmitted to other peers. > > Physical Access > > 14. Does the application uninstall process for your application > eliminate all evidence from the user's device that the application was > previously installed? Does it also eliminate wallet data? > Probably depends on the platform. Last time I checked, I think Bitcoin-Qt leaves behind a .bitcoin directory on most platforms even after you run an uninstall script. > 15. Does your application use techniques such as steganography to > store persistent wallet metadata in a form not identifiable as belong to = a > Bitcoin wallet application? > No > 16. Please describe the degree to which users can use passwords/PINs > to protect their data: > a. Can the user set a password/PIN to protect their private keys? > You can encrypt the wallet file with a password. The wallet is "locked" until the password is entered, preventing decryption of the private keys. > b. Can the user set a password/PIN to protect their public keys and > balance information? > No -- any wallet.dat file can be opened and the public keys inspected without the password. > c. Can the user set a password/PIN to encrypt other wallet metadata, > such as address books and transaction notes? > No -- any wallet.dat file can be opened and the metadata inspected without the password. > d. Does the application use a single password/PIN to cover all > protected data, or does it allow the use of multiple passwords/PINs? > A single password for the wallet file. > > Custodianship > > 17. Do you as a wallet provider ever have access to unencrypted copie= s > of the user=E2=80=99s private keys, public keys, or any other wallet meta= data which > may be used to associate a user with their transactions or balances? > No custodianship. > Telemetry Data > > 18. If your application reports telemetry data, such as usage > information or automatic crash reporting, does the user have the > opportunity to review and approve all information transmitted before it i= s > sent? > No obvious telemetry data being sent. > Source Code and Building > > 19. Can a user of your application compile the application themselves > in a manner that produces a binary version identical to the version you > distribute (deterministic build system)? > Yes, I think that's the point of the gitian stuff. -Kristov --089e0149ce38d65ff1051e8c8d1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Wei,

As you know, I'm not a devel= oper of Bitcoin-Qt, but we'll need to make our best guesses for these a= nswers if the developers won't reply. I'm going to post my best gue= sses here so that people reading the list have a short window of opportunit= y to correct me if they wish.


On Fri, Aug 7, 2015 at 2:46 PM, Wei via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wro= te:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Transaction Formatting

1.=C2=A0 =C2=A0 =C2=A0 Does your application take any steps to create ambig= uity between transactions which unavoidably spend from multiple addresses a= t the same time and intentional mixing transactions?
<= br>
No, Bitcoin-Qt does not try to make non-mixing transactions l= ook like mixing transactions.
=C2=A0
2.=C2=A0 =C2=A0 =C2=A0 What algorithms does your application use for orderi= ng inputs and outputs in a transaction? In particular, how do you handle th= e change output and do you take into account common practices of other wall= et applications when determining ordering?

<= div>Not yet BIP 69. These notes suggest that outputs are randomized: https://bitcoin.org/en/release/= v0.8.1
=C2=A0
3.=C2=A0 =C2=A0 =C2=A0 Does your application minimize the harmful effects o= f address reuse by spending every spendable input (=E2=80=9Csweeping=E2=80= =9D) from an address when a transaction is created?
Unknown

4.=C2=A0 =C2=A0 =C2=A0 Does your application fully implement BIP 62?

By item, my extremely brief inter= pretation:

Non-DER encoded ECDSA signatures: BIP66 soft fork has hap= pened, so this is presumed to be implemented
Non-push operations in scri= ptSig: Implemented
Push operations in scriptSig of non-standard size typ= e: Implemented in 0.9.0
Zero-padded number pushes: Implemented in 0.10.0= (current available version is 0.11.0)
Inherent ECDSA signature malleabi= lity: ...implemented?
Superfluous scriptSig operations: imple= mented 0.6.0
Inputs ignored by scripts: Only partly addressed by 0.10.0.= =C2=A0 It appears that the rest would require changes to consensus rules, s= o Bitcoin-Qt is as compliant as it can be.
Sighash flags based masking a= nd New signatures by the sender: Can't be implemented without changes t= o consensus rules.

I would summarize this as a "yes.= "
=C2=A0

Mixing

5.=C2=A0 =C2=A0 =C2=A0 If your application supports mixing:

It doesn't. There's an issue for CoinJoin here= : https://github= .com/bitcoin/bitcoin/issues/3226
=C2=A0
a.=C2=A0 =C2=A0 =C2=A0 What is the average number of participants a user ca= n expect to interact with on a typical join transaction?
b.=C2=A0 =C2=A0 =C2=A0 Does your application attempt to construct join tran= sactions in a way that avoids distinguishing them from non-join transaction= s?
c.=C2=A0 =C2=A0 =C2=A0 Does your application perform any kind of reversibil= ity analysis on join transactions prior to presenting them to the user for = confirmation?
d.=C2=A0 =C2=A0 =C2=A0 Is the mixing technique employed secure against corr= elation attacks by the facilitator, such as a CoinJoin server or off-chain = mixing service?
e.=C2=A0 =C2=A0 =C2=A0 Is the mixing technique employed secure against thef= t of funds by the facilitator or its participants?

Donations

6.=C2=A0 =C2=A0 =C2=A0 If your application has a fee or donation to the dev= elopers feature:

No donation feature la= st time I checked.
=C2=A0
a.=C2=A0 =C2=A0 =C2=A0 What steps do you take to make the donations indisti= nguishable from regular spend in terms of output sizes and destination addr= esses?

Balance Queries and Tx Broadcasting

7.=C2=A0 =C2=A0 =C2=A0 Please describe how your application obtains balance= information in terms of how queries from the user=E2=80=99s device can rev= eal a connection between the addresses in their wallet.
a.=C2=A0 =C2=A0 =C2=A0 Does the application keep a complete copy of the blo= ckchain locally (full node)?

Yes
=C2= =A0
b.=C2=A0 =C2=A0 =C2=A0 Does the user=E2=80=99s device provide a filter whic= h matches some fraction of the blockchain while providing a false positive = rate (bloom or prefix filters)?

No, it = just downloads the whole blockchain and performs local queries.
=C2=A0
i.=C2=A0 =C2=A0 =C2=A0 If so, approximately what fraction of the blockchain= does the filter match in a default configuration (0% - 100%)?

100%, unless a user bootstraps downloading the bloc= kchain. Bootstrapping will potentially limit the user's anonymity set t= o other people who have downloaded that bootstrap.dat file.
= =C2=A0
c.=C2=A0 =C2=A0 =C2=A0 Does the user=E2=80=99s device query all of their ad= dresses at the same time?

N/A
=C2=A0=
d.=C2=A0 =C2=A0 =C2=A0 Does the user=E2=80=99s device query addresses indiv= idually in a manner that does not allow the query responder to correlate qu= eries for different addresses?

No. Just= download blocks and processes that information locally.
=C2=A0
e.=C2=A0 =C2=A0 =C2=A0 Can users opt to obtain their balance information vi= a Tor (or equivalent means)?

If Tor is = set up as a SOCKS proxy, you can configure Bitcoin-QT download the blockcha= in and broadcast txs through a single Tor circuit. This can be configured o= nce before opening Bitcoin-Qt.

8.=C2=A0 =C2=A0 =C2=A0 Does the applications route outgoing transactions in= dependently from the manner in which it obtains balance information? Can us= ers opt to have their transactions submitted to the Bitcoin network via Tor= (or an equivalent means) independently of how they obtain their balance in= formation?

No, you can only configure a= single proxy.
=C2=A0
9.=C2=A0 =C2=A0 =C2=A0 If your application supports multiple identities/wal= lets, does each one connect to the network as if it were completely indepen= dent from the other?

No built-in suppor= t for multiple identities. You can hotswap wallet files to crudely simulate= this. You'd have to manually change the Tor connection outside of Bitc= oin-Qt to create the effect of making the network connections independent.<= br>=C2=A0
a.=C2=A0 =C2=A0 =C2=A0 Does the application ever request balance informatio= n for addresses belonging to multiple identities in the same network query?=

Blocks are downloaded and tx broadcast= s received/relayed rather than querying the utxo set for a particular addre= ss. When swapping between wallet files, some information may be leaked e.g.= the client may be at the same block height in terms of what it has downloa= ded from the p2p network, which may leak to global passive adversaries/AS&#= 39;s or sybil attackers the fact that a single client was used for multiple= wallets.
=C2=A0
b.=C2=A0 =C2=A0 =C2=A0 Are outgoing transactions from multiple identities r= outed independently of each other to the Bitcoin network?
<= div>
Transactions from multiple identities would not be route= d at the same time. I'm not clear what happens if you have a single wal= let (identity) open and then open a new wallet (identity) without closing B= itcoin-Qt -- some of the same routing paths may still be used such that an = attacker might observe transactions broadast signed by private keys from mu= ltiple wallets (identities) and observe that they appear to come from the s= ame wallet client. OBPP should assume the worst unless prevented contrary e= vidence.
=C2=A0
c.=C2=A0 =C2=A0 =C2=A0 When an identity/wallet is deleted, does the deletio= n process eliminate all evidence from the user's device that the wallet= was previously installed?

Identity is = primarily tied to a wallet.dat file. Deleting it will remove most of the ev= idence that the wallet was installed on that device, but there may be some = extra information in ancillary files that should also be deleted.=C2=A0 Thi= s is an OS-level function, as there is no operation built into the client t= o delete a wallet file (identity).


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Network Privacy

10.=C2=A0 =C2=A0 =C2=A0When a user performs a backup operation for their wa= llet, does this generate any automatic network activity, such as a web quer= y or email?

No. Backups are local, and = no email or SMS is linked. No web queries related to backup.
=C2=A0
<= /div>
11.=C2=A0 =C2=A0 =C2=A0Does your application perform any lookup external to= the user=E2=80=99s device related to identifying transaction senders or re= cipients?

No
=C2=A0
12.=C2=A0 =C2=A0 =C2=A0Does you application connect to known endpoints whic= h would be visible to an ISP, such as your domain?
Yes, some connections to known p2p full nodes to bootstrap the = connection to the Bitcoin p2p network. This is configurable, but there are = defaults. An ISP is likely to be able to identify a customer as running the= Bitcoin-Qt client in particular on this basis.
=C2=A0
13.=C2=A0 =C2=A0 =C2=A0If your application connects directly to nodes in th= e Bitcoin P2P network, does it either use an unremarkable user agent string= (Bitcoin Core. BitcoinJ, etc), or randomize its user agent on each connect= ion?

BIP12 specifies format for user ag= ents: https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki
It appears that the Bitcoin-QT leaks specific information a= bout its client version through User Agent. This file defines the current c= lient version:
https://github.com/= bitcoin/bitcoin/blob/55294a9fb673ab0a7c99b9c18279fe12a5a07890/src/clientver= sion.h

Various other files seem to use this to build = up the UA string, which is transmitted to other peers.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Physical Access

14.=C2=A0 =C2=A0 =C2=A0Does the application uninstall process for your appl= ication eliminate all evidence from the user's device that the applicat= ion was previously installed? Does it also eliminate wallet data?

Probably depends on the platform. Last time I ch= ecked, I think Bitcoin-Qt leaves behind a .bitcoin directory on most platfo= rms even after you run an uninstall script.
=C2=A0
15.=C2=A0 =C2=A0 =C2=A0Does your application use techniques such as stegano= graphy to store persistent wallet metadata in a form not identifiable as be= long to a Bitcoin wallet application?

N= o
=C2=A0
16.=C2=A0 =C2=A0 =C2=A0Please describe the degree to which users can use pa= sswords/PINs to protect their data:
a.=C2=A0 =C2=A0 =C2=A0 Can the user set a password/PIN to protect their pri= vate keys?

You can encrypt the wallet f= ile with a password. The wallet is "locked" until the password is= entered, preventing decryption of the private keys.
=C2=A0
b.=C2=A0 =C2=A0 =C2=A0 Can the user set a password/PIN to protect their pub= lic keys and balance information?

No --= any wallet.dat file can be opened and the public keys inspected without th= e password.
=C2=A0
c.=C2=A0 =C2=A0 =C2=A0 Can the user set a password/PIN to encrypt other wal= let metadata, such as address books and transaction notes?
=

No -- any wallet.dat file can be opened and the me= tadata inspected without the password.
=C2=A0
d.=C2=A0 =C2=A0 =C2=A0 Does the application use a single password/PIN to co= ver all protected data, or does it allow the use of multiple passwords/PINs= ?

A single password for the wallet file= .
=C2=A0

Custodianship

17.=C2=A0 =C2=A0 =C2=A0Do you as a wallet provider ever have access to unen= crypted copies of the user=E2=80=99s private keys, public keys, or any othe= r wallet metadata which may be used to associate a user with their transact= ions or balances?

No custodianship.
= =C2=A0
=C2=A0 =C2=A0 =C2=A0=C2=A0 Telemetry Data

18.=C2=A0 =C2=A0 =C2=A0If your application reports telemetry data, such as = usage information or automatic crash reporting, does the user have the oppo= rtunity to review and approve all information transmitted before it is sent= ?

No obvious telemetry data being sent.=
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Source Code and Building

19.=C2=A0 =C2=A0 =C2=A0Can a user of your application compile the applicati= on themselves in a manner that produces a binary version identical to the v= ersion you distribute (deterministic build system)?
Yes, I think that's the point of the gitian stuff.
=C2= =A0
-Kristov
--089e0149ce38d65ff1051e8c8d1e--