path: root/9e/e49a503b21d236d962644893bbde1a4e9c30ea

Return-Path: <odinn.cyberguerrilla@riseup.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id CD8559F3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 30 Aug 2015 23:29:02 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9F288189
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 30 Aug 2015 23:29:01 +0000 (UTC)
Received: from cotinga.riseup.net (unknown [10.0.1.161])
	(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "*.riseup.net",
	Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
	by mx1.riseup.net (Postfix) with ESMTPS id 09E6BC1E71;
	Sun, 30 Aug 2015 16:29:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
	t=1440977341; bh=qEjqJZ9RwJnulpN+pAeEfkI+vqmPpveWNdR8Ck/ypak=;
	h=Date:From:To:CC:Subject:References:In-Reply-To:From;
	b=TdqRLnQGeN4NKzvdzyjHU2LT6Df1kWpYrG99g2bXdiuH/TOajrE97Scd2VSZ+yMNb
	Yj0sTGELdlwMim1sfLj1bV75HrpvyeJ5u+zZqsZmPsMMb2IU7wUbYTTSGLbTcG4Fgs
	9rUF6mxRejORXF1Teg+71HCLmNDxONYyGGds4M6I=
Received: from [127.0.0.1] (localhost [127.0.0.1])
	(Authenticated sender: odinn.cyberguerrilla)
	with ESMTPSA id 37F201C03F8
Message-ID: <55E391B5.3060300@riseup.net>
Date: Sun, 30 Aug 2015 23:28:53 +0000
From: odinn <odinn.cyberguerrilla@riseup.net>
MIME-Version: 1.0
To: Kristov Atlas <kristovatlas.lists@gmail.com>, 
	wei@openbitcoinprivacyproject.org
References: <b0813349d690442d6ef3961748d1c9fb@openbitcoinprivacyproject.org>
	<CAGH37SLB2bsSCzC1+u-L6v1bQ305MLvDE2uXHVGCy7y61mE5bQ@mail.gmail.com>
In-Reply-To: <CAGH37SLB2bsSCzC1+u-L6v1bQ305MLvDE2uXHVGCy7y61mE5bQ@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.7 at mx1.riseup.net
X-Virus-Status: Clean
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD,
	UNPARSEABLE_RELAY 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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Aug 2015 23:29:02 -0000

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