[bitcoin-dev] Open Bitcoin Privacy Protect Privacy Questionnaire, Mid-Year 2015 report

[bitcoin-dev] Open Bitcoin Privacy Protect Privacy Questionnaire, Mid-Year 2015 report

[wei]

Hi,

Hope it is OK to post this on the list, was not sure where else to post 
for answers from Bitcoin-Qt client developers.

As part of the Open Bitcoin Privacy Project’s ongoing wallet privacy 
measurement efforts, we’ve selected the Bitcoin-Qt client v0.11.0 for 
inclusion into our 2015 mid year survey.

While our volunteers will be performing a series of functional tests by 
interacting with your application directly, several of the features we’d 
like to examine are not easily discernible by non-developers, and for 
this reason we’re asking for your help.

If you can answer the following questions about your wallet’s behavior 
it will assist us with the process of accurately rating your wallet’s 
privacy features.

	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?
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?
3.	Does your application minimize the harmful effects of address reuse 
by spending every spendable input (“sweeping”) from an address when a 
transaction is created?
4.	Does your application fully implement BIP 62?

Mixing

5.	If your application supports mixing:
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 confirmation?
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:
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’s device can reveal a connection 
between the addresses in their wallet.
a.	Does the application keep a complete copy of the blockchain locally 
(full node)?
b.	Does the user’s device provide a filter which matches some fraction 
of the blockchain while providing a false positive rate (bloom or prefix 
filters)?
i.	If so, approximately what fraction of the blockchain does the filter 
match in a default configuration (0% - 100%)?
c.	Does the user’s device query all of their addresses at the same time?
d.	Does the user’s device query addresses individually in a manner that 
does not allow the query responder to correlate queries for different 
addresses?
e.	Can users opt to obtain their balance information via Tor (or 
equivalent means)?
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?
9.	If your application supports multiple identities/wallets, does each 
one connect to the network as if it were completely independent from the 
other?
a.	Does the application ever request balance information for addresses 
belonging to multiple identities in the same network query?
b.	Are outgoing transactions from multiple identities routed 
independently of each other to the Bitcoin network?
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?

	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 email?
11.	Does your application perform any lookup external to the user’s 
device related to identifying transaction senders or recipients?
12.	Does you application connect to known endpoints which would be 
visible to an ISP, such as your domain?
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?

	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?
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?
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?
b.	Can the user set a password/PIN to protect their public keys and 
balance information?
c.	Can the user set a password/PIN to encrypt other wallet metadata, 
such as address books and transaction notes?
d.	Does the application use a single password/PIN to cover all protected 
data, or does it allow the use of multiple passwords/PINs?

Custodianship

17.	Do you as a wallet provider ever have access to unencrypted copies 
of the user’s private keys, public keys, or any other wallet metadata 
which may be used to associate a user with their transactions or 
balances?

	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 
is 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)?

Thank you for assisting us with this effort to measure privacy progress 
in the Bitcoin wallet space.  If at all possible, please return this 
survey before 2015/08/13 to ensure the score for your application will 
be as accurate as possible.

Sincerely,

Wei
Open Bitcoin Privacy Project Contributor

Re: [bitcoin-dev] Open Bitcoin Privacy Protect Privacy Questionnaire, Mid-Year 2015 report

[Kristov Atlas]

[-- Attachment #1: Type: text/plain, Size: 11585 bytes --]

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 (“sweeping”) 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 confirmation?
> 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’s device can reveal a connection
> 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’s device provide a filter which 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.


> 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’s device query all of their addresses at the same
> time?
>

N/A


> d.      Does the user’s device query addresses individually in a manner
> that does not allow the query responder to correlate queries for different
> 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 email?
>

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’s
> 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/55294a9fb673ab0a7c99b9c18279fe12a5a07890/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 copies
> of the user’s private keys, public keys, or any other wallet metadata 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 is
> 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

[-- Attachment #2: Type: text/html, Size: 17336 bytes --]

Re: [bitcoin-dev] Open Bitcoin Privacy Protect Privacy Questionnaire, Mid-Year 2015 report

[odinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Related:

https://github.com/bitcoin/bitcoin/issues/6568

Kristov Atlas via bitcoin-dev:
> 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 (“sweeping”) 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-de
aling-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 confirmation? 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’s device can
>> reveal a connection 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’s device provide a filter which 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.
> 
> 
>> 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’s device query all of their addresses at
>> the same time?
>> 
> 
> N/A
> 
> 
>> d.      Does the user’s device query addresses individually in a
>> manner that does not allow the query responder to correlate
>> queries for different 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 email?
>> 
> 
> 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’s 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/55294a9fb673ab0a7c99b9c18279fe
12a5a07890/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 copies of the user’s private keys, public keys, or
>> any other wallet metadata 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 is 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
> 
> 
> 
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJV45G0AAoJEGxwq/inSG8CbZkH/06DGCXKdHUQlOKaeXYvLb7S
AonXX8/ZMB4D/Z2J9lE9BJP+CDZOUYAOwwaLDD/ecZvtiIgG0O7NP/pj6qLW3nW6
muazJH95u6Bac1jGxTf+cuEo3ntJFwtsXuP907GMpWGqM1Bk2BwrMIfUQFYm+9Rs
hpMpux/40d+dqs5daaBVr975d9+jkwcHRnpXJY/fYOCOXo+sF8lmRjeKoeMHyyw1
H2yJOuTIwZklEfg01yyuxKBRUpl2fGwO34yJp6/Ap+gjdHPP+DNOCYHEPQiPOxf8
rKTq9kgoABUj6aukS2phgDcbGJ6+YCuSWbh04GKviWLhvmzSmXXUQig6Ixz1PhM=
=3fIz
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Open Bitcoin Privacy Protect Privacy Questionnaire, Mid-Year 2015 report

[Gregory Maxwell]

Better late than never, I should correct things here. In the future it
would probably be more productive to open an issue. Otherwise there is
no mechanism for someone to take ownership of a response.

On Sun, Aug 30, 2015 at 7:45 PM, Kristov Atlas via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>> 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

The ordering used by Bitcoin-QT is cryptographically randomized. This
provides the greatest privacy possible.

The BIP 69 recommendation would currently be equally as private if
universally used, but today would reduce privacy by making the
software more distinguishable.  It is unclear if BIP69 will be equal
in privacy in the future, because external infrastructure may impose
ordering requirements that are incompatible with it.

>> 3.      Does your application minimize the harmful effects of address
>> reuse by spending every spendable input (“sweeping”) from an address when a
>> transaction is created?
>
> Unknown

>> 4.      Does your application fully implement BIP 62?

BIP 62 is withdrawn. The useful mechanisms in it for standardness
rules are, of course, implemeted in Bitcoin Core-- were invented
there, and have been there for years.

>> Mixing
>>
>> 5.      If your application supports mixing:

It's unclear to me precisely what is meant here. I'll answer broadly.

Bitcoin Core is compatible with and can be used with the joinmarket
module to include coinjoins. The raw transaction functionality in
Bitcoin Core was also created specifically to facilitate coinjoins.
Beyond joinmarket there have been several other coinjoin modules
created for Bitcoin Core though today JM is by far the most common,

This functionality is not directly implemented for a number of reasons
including the non-existence of decenteralized tools for this that
don't harm the user's privacy in other ways.

>> 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 confirmation?
>> 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?

Skipped as these are specific to the implementation in use.

>> 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?

As Kristov noted, Bitcoin Core does not implement anti-features like donations.

>> Balance Queries and Tx Broadcasting
>>
>> 7.      Please describe how your application obtains balance information
>> in terms of how queries from the user’s device can reveal a connection
>> between the addresses in their wallet.
>> a.      Does the application keep a complete copy of the blockchain
>> locally (full node)?
> Yes

Optionally, but in all cases the user's privacy is indistinguishable
from keeping all the data locally.

>> b.      Does the user’s device provide a filter which 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.

It would be more correct to say that Bitcoin Core always has the
highest possible FP rate.  It uses the only currently available tool
to avoid leaking private address information to indexing services.  As
several academic studies have shown, bloom filters are completely
inadequate for protecting user privacy.

>> 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.

I user that has downloaded a bootstrap.dat is indistinguishable from
any other user on the network; their transaction anonymity set is not
reduced in any way by doing this.  By running bitcoin at all they are
distinguished from other people who do not, but thousands of hosts run
Bitcoin without even having a wallet.

>> c.      Does the user’s device query all of their addresses at the same
>> time?
> N/A

To be clear: This is N/A because there are no queries that would leak
private information about the user's wallet.

  >> d.      Does the user’s device query addresses individually in a manner
>> that does not allow the query responder to correlate queries for different
>> addresses?
> No. Just download blocks and processes that information locally.

Yes. Because the Bitcoin Core downlaods all information, the third
parties cannot correlate responses.

>> 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.

Bitcoin Core does make remote queries to obtain "balance information",
but it can be directed to perform all commmunications via tor, before
starting it as noted.

>> 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.

Bitcoin Core can simultaneously connect to both Tor hidden services
and the public IPv4 network for improved partitioning resistance (and
has been able to for years). Instead of setting the socks proxy, the
user configures onion=<tor proxy>.

As of 0.12 inbound tor HS is also auto-configured by default when tor
is installed.

>> 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.

All network connections are independent via Tor by default, no manual
change is required there. Separate "identities" do require separate
wallets, as noted.

>> a.      Does the application ever request balance information for
>> addresses belonging to multiple identities in the same network query?

No it does not and cannot. Freedom from this kind of leak is one of
the benefits of the current design that doesn't allow intermixing
"identities" in wallets.

> 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.

However, unlikely most other wallets, Bitcoin nodes forward
transactions for third parties and do not make external queries for
private information. Because of this the ability to correlate a
particular node connection multiple times does not necessarily leak
anything about wallet usage.

>> 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.

This assumption is incorrect. All the private wallet state is stored
in the wallet. If the wallet is changed the node does know any of them
anymore.  There is no ability to open a new wallet without restarting
the software.

That said, Bitcoin Core normally relays transactions for third
parties-- unlikely virtually all other wallets. This means that where
observation of a transaction from another wallet would give a nearly
guaranteed identification that the system on the other end of the link
is the source, with Bitcoin Core sending a transaction is merely
potentially suggestive of origination.

>> 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).

After review and testing we've determined that reliable deletion of
private data is not very feasible on current hardware/OSes. Techniques
which used to work, like overwriting are defeated by write balancing.
We recommend users use OS level encryption to protect their privacy
locally.

>>         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 email?
> No. Backups are local, and no email or SMS is linked. No web queries related
> to backup.

Right.

>> 11.     Does your application perform any lookup external to the user’s
>> device related to identifying transaction senders or recipients?
> No

Not for normal transactions. Bitcoin Core currently supports payment
URIs and BIP70, and if a user follows a payment URI it may instruct
the user to make a connection to a location requested by the payee.

>> 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.

Kind of.  If a Bitcoin Core node already knows of peers through prior
operation and is able to get at least two network connections within
11 seconds, it will make no further queries.

If a node is completely new and hasn't been otherwise configured; it
will perform four DNS queries to determine lists of candidate nodes.
These queries are frequently answered by caching name servers and do
not go all the way back to their origins. Only if both of these step
fail does it consult a hardcoded list of several hundred nodes to
attempt initialization.

That said, Bitcoin traffic is easily identifiable regardless of how
peers are found. We recommend users run Tor, and if tor is used no
identifiable traffic should happen, except for timing/volume analysis.
And many parties run Bitcoin Core nodes without running wallets; so
the use of Bitcoin does not identify a user as even having a wallet at
all.

>> 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/55294a9fb673ab0a7c99b9c18279fe12a5a07890/src/clientversion.h
>
> Various other files seem to use this to build up the UA string, which is
> transmitted to other peers.

Bitcoin Core is this questions _definition_ of an unremarkable useragent.

But yes, the useragent notes the major/minor version. Concealing this
would have little to no privacy advantage, as functional/behavioral
analysis would easily reveal the version with at least that level of
precision.

>> 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.

If uninstall deleted the wallet it would reliably result in massive
funds loss for users.

To conceal their user of Bitcoin users should at a minimum do a
security erase of their system.

Other wallets who claim to "delete" private information which was
previously stored on disk are likely giving their users a false sense
of security. Doubly so in that many other wallets are written in
dynamic lanaguages which make it impossible to prevent highly secret
data from being written to system swap.

>> 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

I believe any software which claimed to do this would have to meet a
rather high burden of proof.

>> 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.

Correct. And unlike some other Wallets the KDF used to harden the
users key takes 100ms with efficient native code; this substantially
limits attacker brute for performance.

>> 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.

We recommend users use full disk encryption. Encrypting the public
data in the wallet would require the wallet to enter their key at
every use and increase the probability that their key was leaked (or
if two keys were used, that they'd forget their spending key).

Even if the public key information were encrypted, other data on their
computer (browser cache, swap, logs) would likely compromise the
user's privacy, thus the full disk encryption recommendation. Full
disk encryption is a common, easily used tool; and I don't believe any
wallet software that stores data locally can provide strong privacy in
practice without it.

>> 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.

Right. Each wallet file can have it's own single password which
protect spending.

>> 17.     Do you as a wallet provider ever have access to unencrypted copies
>> of the user’s private keys, public keys, or any other wallet metadata which
>> may be used to associate a user with their transactions or balances?
> No custodianship.

Right.

>>        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 is sent?
> No obvious telemetry data being sent.

No telemetry data.

>>         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, and a large portion of our user base does their own builds. Our
determinstic build process is also actively audited by a good dozen
parties who post cryptographic signatures of their duplicated builds.