From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VtdTi-0001Mx-5D for bitcoin-development@lists.sourceforge.net; Thu, 19 Dec 2013 13:17:26 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.111 as permitted sender) client-ip=62.13.148.111; envelope-from=pete@petertodd.org; helo=outmail148111.authsmtp.net; Received: from outmail148111.authsmtp.net ([62.13.148.111]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VtdTf-0007H7-M8 for bitcoin-development@lists.sourceforge.net; Thu, 19 Dec 2013 13:17:25 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rBJDHDjI098045; Thu, 19 Dec 2013 13:17:13 GMT Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rBJDH7aP053490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 19 Dec 2013 13:17:09 GMT Date: Thu, 19 Dec 2013 08:17:06 -0500 From: Peter Todd To: unsystem@lists.dyne.org, bitcoin-development@lists.sourceforge.net, Wendell , Amir Taaki Message-ID: <20131219131706.GA21179@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: de0b8569-68af-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR bgdMdwsUHFAXAgsB AmUbWldeUVp7WGM7 bAxPbAVDY01GQQRq WVdMSlVNFUsqc2Z1 fhlPMhl3dAFPeDBx ZUNgV3UVCBF6J054 REdJE2VXM3phaTUc TRJQdwFJcANIexZF O1F6ACIKLxFWJCEH Fgs3Mix5FzhENGxt WAgGMVMZTF1j X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: petertodd.org] X-Headers-End: 1VtdTf-0007H7-M8 Subject: [Bitcoin-development] DarkWallet Best Practices X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 13:17:26 -0000 --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Here's my draft. I don't claim this to be "official", but I think this should represent the consensus we've come to at the DarkWallet Hackathon; I'm writing it up as an email in part to preserve a record of that consensus. * General Principles We believe in decentralization, user-defined privacy, education as opposed to "magic", and security based on openness rather than just trust. We consider users who are individuals as well as the needs of businesses such as merchants and exchanges. We recognize that often the more people who use privacy protection technologies such as CoinJoin, the better protected we all are. * Privacy Bitcoin inherently makes the flow of money visible, however it does not require that flow to have real-world identities attached, or even for that matter, pseudonyms. We see this as an unfortunate flaw in the Bitcoin protocol that is to be corrected; the Satoshi whitepaper itself included one such correction by outlining how avoiding address re-use helped preserve privacy. ** Threat model We assume a worst-case sophisticated state-level attacker with the goal of deanonymizing and otherwise subverting Bitcoin users. Such an attacker can be assumed to control up to 100% of the Bitcoin relay network as well as have the ability to wiretap up to 100% of the node-to-node traffic. (for nodes that they do not control) Such attackers are however constrained by politics and budget. We assume they use their ability to conduct MITM attacks sparingly - for instance by subverting certificate authorities - due to the risk of detection. (note how such attackers may be more willing to use detectable attacks in the future now that their activities are public knowledge) We also assume that while their budgets for individual targets may be very large, the equally large number of targets required for en-mass survailance leads to relatively low budgets per target. In particular note how the 51% assumption assumes that the overall "economic value" of Bitcoin to its participants is greater than the attacker's budget by some margin. ** Address re-use Wallet software SHALL avoid address re-use. New addresses will be used for all change and users will be encouraged through the user-interface and other measures to use new addresses for every payment to the wallet. ** CoinJoin With CoinJoin the more users that make use of it, the larger the anonymity set and the better protected user privacy is. Thus we encourage wallet software to agressively make trade-offs between absolute privacy and usability; compromise is not a dirty word. Wallet software SHALL implement basic two-party mix functionality and MAY implement more sophisticated CoinJoin functionality such as n-party mixes. CoinJoin SHALL be the default way that all transactions are sent. Wallet authors are cautioned that more sophisticated functionality may be more secure in theory, but if users do not use it the functionality is wasted; focus on the general case first and only then try to improve. *** Two-Party Mixes The most basic form of CoinJoin is for two parties to author a transaction. A key distinction between a 2 party mix and an n-party mix is that in the two party case both parties automatically learn the other's inputs and outputs by simple elimination; sophisticated cryptographic blinding protocols are useless. To an external attacker each transaction doubles the size of the anonymity set: the coins may have come from one party or the other and the attacker has no way of knowing which. (modulo value analysis, which will be discussed later) *** n-party Mixes and Blinding If two parties can jointly author a transaction, n parties can too. Without special effort this has the disadvantage of revealing the input to output mapping to all parties. Various cryptographic blinding schemes have been proposed to fix this problem, either with multi-party computational techniques, or by making use of multiple communication channels along with a robust anti-DoS scheme. In either case, for now we reject such schemes as complex and inconvenient and prioritize robust two-party mixing. However we do take the existance of such schemes into account; note how a n-party mix can act as a single party in a two-party mix scheme. *** Four-stage two-party mix protocol *** Defeating value analysis Attackers can make good guesses at the mapping of inputs to outputs based on value. For instance with two inputs of 3 and 5, and fours outputs of 1.4, 1.6, 2.4 and 2.6 the attacker can easily map inputs to outputs based on what values match up, in this case 3 split into 1.6 and 1.4, and 5 split into 2.4 and 2.6 **** Value Matching Not all CoinJoin users need their transactions to have specific output amounts; some users simply need to move money from one place to another but do not need a specific amount moved or at a specific time. These users can assist users with more stringent requirements by matching the input or output values they request. As a general principle wallets SHOULD make these anonymity optimizations possible by allowing users to schedule transactions to complete by a specific time and/or allow users to specify that they do not wish the transaction to happen unless CoinJoin is used. With four-stage two-party mixes the Alice, who advertised a desire to do a transaction first, can easily do ths by picking the transaction output amounts only after Bob replies with his desired inputs and outputs, and picking those amounts so they match Bob's. (or some combination of Bob's outputs) **** Merge Avoidance Merge avoidance is the practice of avoiding the merging of multiple transaction inputs into a single new transaction output, thus implying a common relationship between those inputs. The most primitive form of merge avoidance is to create multiple individual transactions, each moving single transaction input to an output. (or perhaps some small number) This is of course inefficient, and appears to have only been proposed as a means to still allow for coin blacklists to function while preserving some financial privacy. Combined with CoinJoin however merge avoidance becomes much more powerful. For instance even in its most simple form multiple parties can combine their merge-avoiding transaction sets, giving even transactions without actual counterparties a useful measure of plausible deniability. In addition the underlyng features that make merge-avoidance possible - the ability of a recipient to designate they are willing to receive payments made to multiple addresses - synergisticly make very sophisticated value matching strategies possible. ***** Cut-thru payments Related to merge avoidance the idea of a cut-thru payment is that if an intermediary is both a debitor and a creditor, with sophisticated payment protocols they can request incoming payments to directly pay outgoing liabilities, skipping them as an intermediary. While premature to implement this feature now, it is worth thinking about for the future. ** Tor While Tor isn't perfect there is real-world evidence - specifically the Snowden leaks - that it works well enough to be considered a worthy adversary by state-level attackers. Wallets MUST suppoort the basic proxy options that allow the Tor proxy - or some other similar technology - to be used for privacy enhancement and SHOULD make use of Tor-specific features such as hidden services. * Decentralization ** Fees In a decentralized system distinguishing DoS attackers from legitimate users is at best difficult, at worst impossible. Wallets that do not provide users with the ability to set fees, both when a transaction is created initially and after initial broadcast, do their users a disservice by taking away a vital method of responding to an attack: outspending the attacker. Wallets MUST give users the ability to set the fee per KB they are willing to pay for their transactions. Wallets SHOULD allow users to change that fee after the fact via transction replacement. Wallets MAY additionally implement fee estimation techniques, such as watching what transactions in the mempool are finally mined, or using estimates provided by miners. However it must be recognized that such data is inherently unreliable, and this may become a problem in practice in the future; giving users robust ways to alter fees after the fact will make lying about fee data - perhaps to push fees upwards - less advantageous. Note that the current direction of the Bitcoin Foundation maintained reference implementation is weakly towards a pure estimation scheme; deployment of full nodes supporting replacement and support from miners is a precondition to doing things correctly. *** Fees and privacy Where there is a trade-off between fees and privacy - such as with merge avoidance strategies - users should be given options to specify how much extra they are willing to pay for extra privacy. Wallets SHOULD default to being willing to pay some extra, perhaps 25% more over the basic fee. ** SPV, full nodes and partial nodes Wallet software SHOULD whenever possible blur the distinctions between full UTXO set nodes, SPV nodes, and partial UTXO set nodes. In addition to those three basic categories there is also the question of whether or not a node stores archival blockchain data, something that all three categories of nodes can participate in. Instead how a node contributes back to the health of the network should be a function of what resources it has available to it. Of course in some cases, like a phone wallet, that won't be very much, but for desktop or business usage the resources available can be significant in both bandwidth and storage capacity. *** Relaying data **** Blocks and blockheaders Any node can safely relay blocks and block headers, where "safely" is defined as SPV-level security. Our threat model implies that we don't trust random peers on the network, thus we are not relying on them for block validity; as a SPV node we are relying on miners to do validity checking for us. In short feel free to relay data that you yourself would trust. **** Transactions Remember that relaying transactions has a DoS-attack risk; the Bitcoin model relies entirely on mining fees and/or priority as the limited resource to prevent DoS attacks. Thus at present nodes SHOULD NOT relay transactions if they do not have an up-to-date copy of the relevant parts of the UTXO set spent by the transaction. (relaying transactions spending only inputs in a partial UTXO set is acceptable): **** Block-header diversity Wallet software MUST make it possible to get block-header information =66rom a diverse set of sources. These sources SHOULD comprise more than just peers on a single P2P network. Remember that it is acceptable to use even centralized sources in addition to decentralized ones for blockheader data - knowing that a miner did the work required to create a block header is always valuable information. (for reasonable amounts of work) For instance the author's block headers over twitter project - while an April Fools joke - is equally a perfectly reasonable backup source of blockheader data. ** Updating wallets from blockchain data In an ideal world wallets wouldn't need to sync their state with blockchain data at all: pervasive use of payment protocols would have senders send txout proofs directly to recipients. But that's not the case. Instead wallet implementations sync themselves from the blockchain, and when bandwidth limited this becomes a tradeoff between bandwidth and privacy: your transactions hide in the anonymity set of the false positives matched by the filter. *** Bloom filters The current implementation for SPV nodes is to simply give peers a bloom filter; the false-positives make the anonymity set. For n peers this has O(n) cost when a new block comes in; Bloom filters are cheap to test against and this system works reasonably well. However, for archival blockchain data bloom filters are seriously flawed: every block has to be read from disk in full, the bloom filter matched, and some (potentially very small!) subset sent to the peer. n peers. The result is high IO load on the node relative to the client, enabling easy DoS attacks. Wallet software SHOULD NOT implement only Bloom filters, however using them when availalbe is acceptable. Note how the Bloom filter design has at best O(n^2) scaling ruling it out for large-blocksize future scenarios. *** Prefix filters TXO or UTXO data can be easily indexed by in radix trees with log2(k) lookup cost per query. We can take advantage of the fact that the query keys need not be provided in full by only providing partial keys. Because scriptPubKeys are randomly distributed a prefix n bits long has an anonymity set of roughly 1/2^n * # of transactions in total. Wallet software SHOULD implement prefix filters and SHOULD use them in preference to bloom filters whenever available. Wallet software that currently uses full-key filtering - e.g. Electrum - MUST be upgraded to support prefix filters in the future. Wallet software MUST NOT assume that matching anyting other than H(scriptPubkey) is possible. This applies to bloom filter matches as well. In the future miners may commit to either the TXO set in conjunction with per-block lookup trees, or possibly the full UTXO set. In either case many of the leading designs may be implemented with only H(scriptPubKey) lookup capability for reasons of scalability. * Security Bitcoin wallet software is unprecedented in how they provide attackers targets that are highly profitable to attack and highly liquid. (note the irony here!) A succesfull attack that injects malicious theft routines into either sourcecode or binaries can steal thousands of Bitcoins in one go, and the attacks target is you and your team. Following basic good practices for robust code is a start, but it's far =66rom enough. ** Source-code integrity Sourcecode MUST be maintained using a revision control system that provides strong integrity guarantees; git is recommended. Sourcecode MUST be PGP signed on a regular basis. Releases MUST be signed - in git this is accomplished by signing the release tag. Individual commits SHOULD be signed, particularly if source-code used in day-to-day development is kept on an untrusted server, e.g. github. Recovering from a server compromise is made significantly easier if every commit is securely signed. ** Binary integrity All things being equal it is better to use an interpreted language rather than a compiled one; auditing the former is significantly easier than the latter. Similarly, all things being equal, do not distribute binaries of your software - have end-users compile binaries themselves. Of course all things are not equal, and frequently compiled languages and distributing binaries is the correct choice. If that is the case deterministic build systems MUST be used when possible; if using them is not possible take great care with the process by which binaries are created and try to create long-term plans to move to a deterministic build system in the future. ** PGP Developers of wallet software MUST make use of PGP and participate in the web-of-trust. Developers MUST advertise their PGP fingerprint widely, for instance on personal websites, forum profiles, business cards etc. simultaneously. Multiple paths by which someone can find a fingerprint claimed to be of some developer make subterfuge easier to detect and more costly to carry out. When possible it is highly recommended to attach these advertisements to real-world, physical, actions. For instance the author has included his PGP fingerprint in highly public, videotaped, talks he has given at conferences. He has also created a videotaped statement of his PGP key that was timestamped in the Bitcoin blockchain. While it certainly is possible for such artifacts to be faked, doing so convincingly is expensive, labour intensive, and error prone. Developers SHOULD sign as much communication as practical. Sourcecode is one form; your emails to development lists and between each other are another. Signing both leaves a large body of widely distributed work, all tied to your identity. (it's highly unfortunate that nearly all publicly available mail archives do not make mail accessible to the public in such a way as to allow verification of PGP signatures; often even inline signatures are broken for various reasons) *** Increasing adoption of PGP Keep in mind that end-users very rarely verify PGP fingerprints at all, let alone correctly - the above advice with regard to PGP is currently mostly useful in allowing *other developers* the tools they need to verify the integrity of your code. For instance, in the event of a suspected compromise consistantly signed code allows anyone competent in the use of PGP to quickly evaluate the situation, and if warrented, inform less sophisticated users through traditional measures such as the media. While this is somewhat out of scope for this document the "DarkWallet effort" should include work to make PGP more user-friendly and a better experience. But that does *not* have to mean "making PGP easier for grama", right now "making PGP easier for Joe Wallet Developer" is a laudable goal. For instance understanding and using the web-of-trust sucks right now. How can we make that experience better for a user who understands the basics of cryptography? ** SSL/Certificate authorties While certificate authorities are notoriously bad at the job they are supposed to be doing the CA system is still better than nothing - use it where appropriate. For instance if you have a website advertising your software, use https rather than http. ** Multi-factor spend authorization, AKA multisig wallets Assuming any individual device is uncompromised is risky; wallet software SHOULD support some form of multi-factor protection of some or all wallet funds. Note that this is a weak "should"; mainly we want to ensure that users have options to keep large quantities of funds secure; accepting higher risks for smaller quantities is an acceptable trade-off. FIXME: go into more detail. *** P2SH Wallet software MUST support paying funds to P2SH addresses. ** Payment Integrity Multi-factor wallets protect your funds from being spent without your knowledge, but they provide no assurance about where those funds went; a Bitcoin address is not an identity. A payment protocol, such as BIP70, is needed. Wallet software SHOULD support BIP70. Yes, there are (justified) concerns about its current dependence on the certificate authority system, but those concerns should be addressed by a combination of fixing that system, and extending BIP70 with different and better identity verification options. However, remember that in the absense of multi-factor wallets the "know who you are paying" protections of BIP70 are actually pretty much useless; malware that defeats the payment protocol locally is not much different than malware that silently rewrites Bitcoin addresses. There are other motivations for the BIP70 version of the payment protocol, but whether or not they are actually interesting for users is an open question; it was not designed by user-experience experts. Thus wallet authors should consider supporting a low priority for now. --=20 'peter'[:-1]@petertodd.org 000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3 --G4iJoqBmSsgzjUCe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQGrBAEBCACVBQJSsvHRXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDA1NTY1NzE1ODE5MjcwNTU3ZjFiMDI4ZjVmZDYwMzBmZjc4 ZjRiNWJiZjdlZDlhMzkvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsY6ggApE8vqFcksSEFsuB9J2ECDcsR tSmR4xOGyhenfOpFM6TcID5C8Cj+JaqaynqYoM4WzXU8D5A+8e5/5cEWBvh3Momv UqSGcTj+hOshv/GKownKNySDUCP70SkN84HIE2LWlHfHnAH78bp4YZf0DZamCcSo IrulhIKUclpaPxLHG/UtoHTjvJbKWF13NlEgTeuYq6vfNnPsKj5eT3wtBLxW5uNG Os+KrVCrKSnmrHU0oyTZbeSkccGpj7c6m/CTY4OYgcBODcxEfY7j1TsnfXQhKuFi SxIFcfql8IMudGqWzT4qki9LEHZe3oTjcguogMSgXllY4D7IFQ9HxgvAUe/BMA== =MMAn -----END PGP SIGNATURE----- --G4iJoqBmSsgzjUCe--