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

[Gregory Maxwell via bitcoin-dev]

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

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

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

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

[odinn via bitcoin-dev]

-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