[unSYSTEM] DarkWallet Best Practices [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2013-12-20T17:32:57+00:00


Summary:

In a discussion about the problems associated with reusing Bitcoin addresses, it was suggested that generating fresh addresses from public extended keys could be a solution that would also enhance user privacy. Instead of exchanging single addresses, the exchange of extended public keys could benefit non-merchant use of Payment Protocol. The challenge lies in how to push the extended public key down to the wallet itself. There are options such as developing services to facilitate this exchange or having wallet software communicate directly through various channels like Bluetooth, AirDrop, email, BitMessage, etc. Another idea mentioned was using extended public keys from bip 32 to share multiple addresses at once, enabling regular payments without needing further addresses and assisting with P2SH where the public key is required. Implementing these ideas has the potential to improve the efficiency and security of Bitcoin transactions.The debate over whether or not to sign every commit has been extensively covered. Linus Torvalds advises against signing each commit, but Peter Todd argues that per-commit signatures are necessary due to reliance on third-party sites like Github within the Bitcoin community. The Linux development model differs from Bitcoin's, using mailing lists and trusted maintainers committing to personal trees on secure computers. Eventually, patches are merged into a release tag, which is signed. Bitcoin developers often get code directly from Github and rely on per-commit signatures for authenticity. Todd believes the focus should be on the messaging layer, suggesting the use of OpenPGP and SSL certificate authorities instead of creating new identity systems that increase the risk of MITM attacks.In an email correspondence, Mike suggests splitting multi-sig and multi-factor authentication into two separate categories. He emphasizes the value of multi-factor user authentication and distinguishes it from multi-factor signing, which adds another level of complexity. Mike proposes that wallets should require multi-factor authentication before granting access and before signing a transaction. Regarding multi-factor signing, he acknowledges that it may be too early to define but suggests that wallets should not create two keys on a single host or device and provide a way to import external public keys for use in P2SH addresses. Mike also brings up a small word-choice nit, mentioning that he had to look up the meaning of "SHALL" (which he now knows is the same as MUST). In an unrelated topic, Drak mentions that Linus advises against signing each commit and suggests incorporating his recommendation for signing tags with `git tag -s` into the spec as a MUST.On December 19, 2013, Amir Taaki shared a link about signing each commit. Linus had advised against it, but upon reading the link, it was found that his advice did not make sense. However, Drak's response suggests that Linus's recommendation for signing tags with `git tag -s` should be included in the spec as a MUST.


Updated on: 2023-08-01T06:52:57.327609+00:00