[Bitcoin-development] DarkWallet Best Practices
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 on the wiki *** 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.
Re: [Bitcoin-development] DarkWallet Best Practices
On 19 December 2013 13:17, Peter Todd p...@petertodd.org wrote: ** Fees 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. Can you add a part about SHOULD/MUST warn users if the fee is unusually high to avoid sob-stories of people sending 20BTC fees with for the 0.002BTC sandwich. 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 SHOULD be cryptographically signed I assume. ** 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. Once could make efforts to publish (maybe even as signed commits in the git repo etc the current valid certificate fingerprints and which CA signed it). This would go some way to exposing MITM either by CA or in workplaces where browsers are loaded with bogus CAs for the purpose of deep packet inspection. ** Multi-factor spend authorization, AKA multisig wallets mainly discussed at the conference in terms of multiple individuals controlling funds, which is out of scope for this document 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 According to RFC 2119 http://www.ietf.org/rfc/rfc2119.txt language, you might be better using the word RECOMMENDED or MAY over SHOULD here. Additionally, at the beginning of the spec I would put : The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119http://www.ietf.org/rfc/rfc2119.txt . Regards Drak -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [unSYSTEM] DarkWallet Best Practices
On 19 December 2013 16:04, Amir Taaki gen...@riseup.net wrote: About signing each commit, Linus advises against it: http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html Yeah, it makes no sense after reading it. Nice catch. However, his recommendation for signing tags with `git tag -s` should probably be incorporated into the spec as a MUST. Drak -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DarkWallet Best Practices
On Thu, Dec 19, 2013 at 04:04:17PM -, Amir Taaki wrote: Looks like for this to actually go to the email lists they need to be in the To: field. About signing each commit, Linus advises against it: http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html Btw, there's a final reason, and probably the really real one. Signing each commit is totally stupid. It just means that you automate it, and you make the signature worth less. It also doesn't add any real value, since the way the git DAG-chain of SHA1's work, you only ever need _one_ signature to make all the commits reachable from that one be effectively covered by that one. So signing each commit is simply missing the point. What do you reckon? His point is valid, but it's valid in the context of how Linux development is done, not Bitcoin. The key difference being that Linus and other kernel developers have a model where code is passed around on mailing lists and between developers rather than stored on untrustworthy third-parties like github. For instance typically someone will submit a patch to the kernel development mailing list, example: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg558841.html That patch isn't signed, and the email itself doesn't have to be PGP signed either. However a trusted maintainer of the relevant subsystem will (in theory) look over the patch carefully and commit it to their personal tree on a secure computer. (in theory) At some point the maintainer will create a *signed* tag on a commit with one or more patches, often many patches, another another maintainer higher in the hierarchy (maybe even Linus) will *merge* that tag into their tree, hopefully checking the signature first! Modern versions of git actually include the tag signature in the merge commit, so the result is signed by the original maintainer; note how this contradicts Linus's email with regard to the idea of separable signatures. Eventually multiple such groups of patches build up and the result is tagged as a release, and that release tag is signed. Accountability in this model rests with maintainers, and source-code stays on a multitude of personal, secure, locations. (in theory) However since we like to use github and tend to get code directly from it our main risk is github (or similar) being compromised. Given that I think we're much better off using per-commit signatures, and in effect continually making the statement Yes, this commit/merge was really produced by me on my machine, although I may have made a mistake and might not have looked at the code as thoroughly as I maybe should have. The statement *is* weaker than Linus's model of This signature is Really Official and Stuff and I've carefully checked everything. but I think we're much more interested in getting a strong guarantee on who made the commit than some strong statement about its actual contents - humans are fallible anyway. Also do you approve of the other link I sent you? https://wiki.unsystem.net/index.php/DarkWallet/Negotiation I think you're conflating identities with the messaging layer; focus on the latter and use off-the-shelf identity systems like OpenPGP and SSL certificate authorities. Remember that every new identity system that gets involved is another way for an attacker to MITM attack you; you're better off using whatever the user is using already. -- 'peter'[:-1]@petertodd.org 00016a442255c6d15cd6e085991c1efffc9caeff5fc6da14368a signature.asc Description: Digital signature -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP proposal: Authenticated prefix trees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello fellow bitcoin developers. Included below is the first draft of a BIP for a new Merkle-compressed data structure. The need for this data structure arose out of the misnamed Ultimate blockchain compression project, but it has since been recognized to have many other applications. In addition to this BIP I am preparing three additional BIPs describing the use of this data structure in stateless validation mining, the UBC address index for SPV+ operating modes, document timestamping and merged mining. A Python implementation of this data structure is available here: https://github.com/monetizeio/python-bitcoin A C++ implementation is being worked on. As per the BIP-1 procedure, I am submitting this rough draft to the community for discussion. I welcome all comments and criticisms of both form and content. - -Mark ==Abstract== This BIP describes a [http://en.wikipedia.org/wiki/Hash_tree Merkle hash tree] variant of the [http://en.wikipedia.org/wiki/Trie prefix-tree data structure], ideally suited for encoding key-value indices which support memory-efficient proofs. ==Motivation== There are a number of applications which would benefit from having a data structure with the following properties: * '''Arbitrary mapping of keys to values.''' A ''key'' can be any bytestring, and its ''value'' any other bytestring. * '''Duplicate keys disallowed.''' Every key has one, and only one value associated with it. Some applications demand assurance that no key value is reused, and that this constraint can be checked without requiring access to the entire data structure. * '''Efficient look-up by key.''' The data structure should support sub-linear lookup operations with respect to the number of keys in the mapping. Logarithmic time or linear with respect to the length of the key should be achievable and would be sufficient for realistic applications. * '''Merkle compression of mapping structure.''' It should be possible to produce a reduced description of the tree consisting of a single root hash value which is deterministically calculated from the mapping structure. * '''Efficient proofs of inclusion.''' It should be possible to extract a proof of key/value mapping which is limited in size and verification time by the length of the key in the worst case. * '''Computation of updates using local information.''' Given a set of inclusion proofs, it should be possible to calculate adjustments to the local mapping structure (update or deletion of included mappings, or insertion between two included mappings which are adjacent in the global structure). Such applications include committed validation indices which enable stateless mining nodes, committed wallet indices which enable trust-less querying of the unspent transaction output set by codescriptPubKey/code, efficient document time-stamping, and secure efficient merged mining. This BIP describes an authenticated prefix tree which has the above properties, but leaves the myriad applications to be formalized in future BIPs. ==Data structure== This BIP defines a binary prefix tree. Such a structure provides a mapping of bitstrings (the ''keys'') to bytestrings (the ''values''). It is an acyclic binary tree which implicitly encodes keys within the traversal path -- a left branch is a 0, and a right branch is a 1. Each node is reachable by only one unique path, and reading off the branches taken (0 for each left, 1 for each right) as one follows the path from root to target yields the node's key. The particular binary prefix tree defined by this BIP is a hybrid PATRICIA / de la Brandais tree structure. [http://en.wikipedia.org/wiki/Radix_tree PATRICIA trees] compress a long sequence of non-branching nodes into a single interior node with a per-branch ''skip prefix''. This achieves significant savings in storage space, root hash calculation, and traversal time. A de la Brandais trie achieves compression by only storing branches actually taken in a node. The space savings are minimal for a binary tree, but place the serialized size of a non-branching interior node under the SHA-256 block size, thereby reducing the number of hash operations required to perform updates and validate proofs. This BIP describes the authenticated prefix tree and its many variations in terms of its serialized representation. Additional BIPs describe the application of authenticated prefix trees to such applications as committed indices, document time-stamping, and merged mining. ==Serialization format== As a hierarchical structure, the serialization of an entire tree is the serialization of its root node. A serialized node is the concatenation of five structures: node := flags || VARCHAR(extra) || value || left || right The codeflags/code is a single byte field whose composite values determine the bytes that follow. flags = (left_flags 0) | (right_flags 2) | (has_value4) |
Re: [Bitcoin-development] DarkWallet Best Practices
Amazingly thorough, Peter. Thanks so much! -wendell hivewallet.com | twitter.com/hivewallet | pgp: B7179FA88C498718 On Dec 19, 2013, at 8:17 AM, Peter Todd wrote: 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 on the wiki *** 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
[Bitcoin-development] bitcoin-qt
maybe make it so bitcoin.conf settings can be edited with in the app instead of external editor, and make it easier to enable rpc server mode... -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
