< GitHub130>
[bitcoin] luke-jr opened pull request #7625: Bugfix: Check for bench_bitcoin being enabled where needed, and skip UniValue dependency when unused (master...bugfix_bench_checks) https://github.com/bitcoin/bitcoin/pull/7625
< GitHub168>
bitcoin/0.12 ca8f160 Luke Dashjr: Bugfix: gitian: Add curl to packages (now needed for depends)...
< gmaxwell>
mostly unchanged over the last several years" --- kristov claimed this to me in #bitcoin several weeks ago, and I refuted it at list listing pages of features.
< gmaxwell>
I wonder if anyone connected to OBPP ever ran bitcoin core, their screenshot is four years old. It's especially disappointing that it claims "the Qt client has remained
< btcdrak>
This channel is for Bitcoin Core development discussion. please move to #bitcoin.
< randy-waterhouse>
except the report is NOT for experts ... I might be the most paranoid bitcoin user out there (of the ones i know of), I use only core and that report seems to come to highly erroneous conclusions
< btcdrak>
shouldnt this conversation be in #bitcoin ?
< gmaxwell>
catlasshrugged: some people are. I am, and I had one person in here contact me privately and suggest that the report attacked bitcoin core specifically for political reasons related to blocksize drama (citing comments by you and other OBPP) folks. For what its worth, I told them that I didn't think that was the case here.
< catlasshrugged>
I really appreciate any help people can put forth, especially with improvements to the threat model, the way that different attacks are weighted, and the correct modeling of full node clients like Bitcoin-Qt
< gmaxwell>
I think bitcoin.org wallet criteria did some disclosure requirement stuff, I'm looking for it now.
< gmaxwell>
bitcoin.org has disclosure requirements, IIRC.
< gmaxwell>
warren: why not go work on improving Bitcoin Core's privacy documentation? :) it's scattered in many places.
< gmaxwell>
in any case, catlasshrugged offered to go break out some of the analysis on Bitcoin Core. I think that would be super useful to us--- and much better a use of time then the circular argument now.
< gmaxwell>
Luke-Jr: and electrum is accordingly ranked lower than bitcoin core for privacy. I'd agree. (I think the armory developers would agree too)
< gmaxwell>
Yes, I think most people would agree that electrum has significantly worse privacy than bitcoin core due to the server model.
< gmaxwell>
catlasshrugged: many people have been basically begging you to substantiate placing many of these wallets that phone home the users addresses over bitcoin core. You haven't. Perhaps it will take you some research to do that-- I understand you didn't make this report all yourself--... probably you should go do that and we can continue discussions later.
< catlasshrugged>
NEWS FLASH: Everyone has access to a massive information that could be used to denanonymize a large % of all bitcoin addresses -- it's called the blockchain and Google
< petertodd>
catlasshrugged: right now bc.i as an example has access to a massive amount of information that could be used to deanonymise a large % of all bitcoin addresses - lets be clear on that
< catlasshrugged>
what bitcoin privacy engineering did you do during those 6 years?
< catlasshrugged>
aknix: can you remind me about your expertise in bitcoin privacy engineering?
< catlasshrugged>
as you've pointed out a billion times in public, it's easy to sybil the bitcoin network anyway, so it's not like SPV wallets are a lot better off
< sipa>
catlasshrugged: in what way is Bitcoin-Qt's privacy worse than Samurai's?
< dirtynewshoes>
I do not believe the goal of bitcoin-qt is not to be easy privacy for the average user.. but to be a solid foundation that works well
< warren>
Your report would be better to exclude Bitcoin-Qt entirely, then you're at least comparing apples to apples, or "of the lite wallets which is least bad for privacy".
< sipa>
catlasshrugged: then you should at least be able to give one aspect at which bitcoin-qt ranks lower than your #1
< catlasshrugged>
bitcoin-qt is a wallet. I'm not going to exclude it.
< catlasshrugged>
petertodd: that's relatively true, though when I wrote about the use of Bitcoin-Qt in a book, I found that people desperately needed the directions. Especially setting connecting it to Tor, etc.
< petertodd>
sipa: Bitcoin Core is something non-experts can and do run mind you
< sipa>
If expert bitcoin users is not the audience, perhaps you should exclude Bitcoin Core and say you consider it out of scope, instead of ranking it lower than others without any argument for doing so
< petertodd>
catlasshrugged: you don't need to be an expert to run bitcoin core I'll note
< catlasshrugged>
I don't think there's anything in the report that suggests that its primary audience is expert bitcoin users.
< randy-waterhouse>
"If they are expert users who know their way around Bitcoin-Qt, they don't need the report." ... perhaps this caveat needs to be displayed prominently somewhere in the front of the report?
< catlasshrugged>
pigeons: no. the best information that I have available (unresolved objections notwithstanding) is that users would be well served to make decisions based on the report. If they are expert users who know their way around Bitcoin-Qt, they don't need the report.
< dirtynewshoes>
catlasshrugged: Would it be used by the average bitcoin user? (Stable enough?)
< gmaxwell>
I'm still hoping to hear of _any_ blockchain analysis resistance features implemented by, say, ledger that are lacking in Bitcoin Core. I may not agree with the relative ranking of these two critical areas, but ... I don't think bitcoin-core should fair poorly vs the other available wallets even when blockchain analysis is ranked much more highly than network facing privacy.
< aknix>
I mean cmon you recoomend a fake UI for a bitcoin wallet
< aknix>
what are you gonna do open tinder to use bitcoin?
< pigeons>
catlasshrugged: i didnt ask about the "average bitcoin user" I asked about "new users seeking privacy with privacy needs"
< gmaxwell>
I think you do _devistating_ harm to the bitcoin ecosystem when you present privacy disaster personal data phone-homing lite wallets as _superior_.
< gmaxwell>
catlasshrugged: I would arugue, and I think I would bury you in a public debate that in terms of practical privacy Bitcoin QT (or other FN wallets like armory) are strictly superior in actually delivered privacy; and-- their vastyly superior privacy is a primary reason why a user should want to use them.
< gmaxwell>
I think you're underemphasicing network; esp since the primary purpose of the current analysis companies are tying addresses to identities and geographies which cannot be done without a network component; but .. I don't think we need to resolve that weighing disagreement, because I think that Bitcoin Core does at least as well as almost everyone else in both. (ignoring e.g. coinjoin functionalit
< catlasshrugged>
pigeons: practically speaking, I am not concerned at all about the average bitcoin user deciding not to use Qt based on the report. The average Bitcoin user simply isn't using Qt, full stop. That's not a knock on Qt, just a statement of fact about market share.
< gmaxwell>
catlasshrugged: great, now, for all the things in the list that aren't doing coinjoin; what network analytics protection do they do better than Bitcoin Core?
< gmaxwell>
Not reusing addresses? Bitcoin core does as much as is possible there short of actually forbidding the users from doing it.
< gmaxwell>
catlasshrugged: yes, virtually all of the wallets you've reviewed send deanonmizing data to third parties. Bitcoin Core does not. Too bad it's ranked way down on your list.
< gmaxwell>
You just recommended to end users that to preserve their privacy they should run https://www.reddit.com/r/Bitcoin/comments/447s7c/samourai_is_the_most_private_and_anonymous/ If you can't acknoweldge that something is _seriously_ wrong that your process caused you to do that, or even make an _attempt_ to convince someone here that this was justfied than I don't see how futher progress is possib
< gmaxwell>
If you're saying the user is the target audience then you're currently telling them to run samouri wallet over bitcoin core; a closed source wallet that phones home the users addresses.
< gmaxwell>
catlasshrugged: if your message is that they all suck than your audience isn't an actual bitcoin user, it's the industry.
< catlasshrugged>
how do I make that meaningful to the average Bitcoin user?
< catlasshrugged>
again, I'll remind you that #bitcoin-core-dev is not the primary target audience for these reports.
< catlasshrugged>
take-aways I am not looking to express: Ledger is better than Bitcoin-Qt; Bitcoin-Qt sucks!
< gmaxwell>
I do think the comparison is a false dichotomy though; your highest rated wallet _I think_ does nothing better than bitcoin core for blockchain analysis resistance, but it's far weaker to 'network' and 'server' analysis resistance.
< catlasshrugged>
I mention the blockchain analysis vs network stuff as probably the primary determinant of Bitcoin-Qt's rank relative to other wallets. Getting the weights is the hardest part, but I want it to be the absolute best we can make it.
< gmaxwell>
petertodd: it doesn't help that many of the names on the project have been very adversarial towards Bitcoin Core in the past, work for wallets included in the report etc.
< gmaxwell>
petertodd: it's not like anyone involved failed to know that if you rank "doesn't send your address info to third parties" very highly the result will be to put armory and bitcoin core very highly.
< gmaxwell>
petertodd: I don't know that this has much value though; after all, I was arguing with catlasshrugged in #bitcoin a few weeks ao about the importance of not sending your address information to third parties.
< catlasshrugged>
primarily what I think the bitcoin core team would want to nitpick on would be our weights.wiki page (which unfortunately does not give good detail about why we chose the weights, I'd like to improve that next edition)
< aknix>
hmm thats not very bitcoin like.
< catlasshrugged>
I'd be happy to send you a copy of the ratings for Bitcoin-Qt
< gmaxwell>
catlasshrugged: where are the actual ratings for the wallet? I'd like to make for myself a list of things that your process rated other wallets higher than bitcoin core... both for a mixture of nitpicking and improvement.
< petertodd>
catlasshrugged: yes, my way of using Bitcoin Core is definitely not an average user's way - but all the same, it's not a *negative* for privacy
< gmaxwell>
catlasshrugged: well it would be, I'm not saying that I would be surprised that bitcoin core wasn't rated top or whatever, rather that things that were rated about it were ones that phone home the users addresses... thats horrifying to me. And I'd like to know what in particular you think these half dozen other wallets did better to justify the higher rating than core while they had that fundime
< petertodd>
catlasshrugged: e.g. I personally use bitcoin core as a day-to-day spending wallet, and then delete my wallet.dat files regularly to prevent making mistakes that accidentally combine inputs I don't want combined
< catlasshrugged>
N.B. ***no one in this room is an average Bitcoin user.***
< catlasshrugged>
I would consider doing a point-by-point comparison between Ledger and Bitcoin-Qt, although I am seriously wondering whether this will be an invitation to be nitpicked to death
< gmaxwell>
catlasshrugged: users cannot escape that by reusing addresses in bitcoin core, due to change.
< catlasshrugged>
gmaxwell: oops, you're right about the clicks -- Bitcoin-Qt got 0 clicks for that = full score
< gmaxwell>
E.g. Bitcoin core displays no static "wallet adresse", to get an address you hit a button which always gives you a fresh one.
< catlasshrugged>
An expert Bitcoin user can probably do everything and more with Bitcoin-Qt that he can do with Ledger.
< gmaxwell>
Bitcoin Core almost forces users to not reuse addresses, to get an old address you need several clicks (I think one is a right click).
< catlasshrugged>
HD wallets are hugely useful for incentivizing users to not reuse addresses. Keep in mind, this review is focused on the average Bitcoin user largely, and not expert users.
< gmaxwell>
catlasshrugged: uh.. you know that it's externally undetectable to users if bitcoin core uses HD wallets; right?
< gmaxwell>
catlasshrugged: what does ledger (for example) do for resistance to blockchain analysis that Bitcoin Core does not.
< kanzure>
catlasshrugged: i think you should include disclaimers like "review by bitcoin core developers has said x about this rating scheme"
< gmaxwell>
catlasshrugged: well bitcoin core has "PIR" in the naieve form: send everyone the whole database is PIR. :)
< catlasshrugged>
I would love to get some input from Bitcoin-Qt devs on this, but at the moment I'm not really clear on how to form a working relationship here
< * aknix>
would prefer being told the truth than anything else. I have always come to some bitcoin channel for that over the years ;)
< catlasshrugged>
"... like are we being negatively marked here for doing the _only_ thing known to provide strong privacy?" nope, only Bitcoin-Qt and armory got points for this criteria, all other wallets got 0
< aknix>
Also is providing a pseudo UI for a bitcoin wallet a good idea either?
< aknix>
"Unless the user explicitly requests for them to be displayed, do not display Bitcoin addresses in text or QR code form, or transaction hashes" - This seems a bit cumbersome, I dont think people would treat this much differently than a check anyway..
< catlasshrugged>
"onsidering those questionare answers which were mostly privacy positive (BIP 69 where kristov gave a misleading answer-- I don't think we should implement BIP69, it doesn't improve privacy and could hurt it); it's remarkable to me that they rated Bitcoin-QT poorly if thats where their information was coming from." the only criteria relevant Bitcoin-Qt received full marks for for random sorting of outputs.
< catlasshrugged>
"Likewise, they rated Bitcoin-Qt at 0 for physical security;" nope, Bitcoin-Qt got a zero for physical privacy. I know there is overlap, but this wasn't a security-focused assessment. It's all 100% driven by our threat model.
< * aknix>
hehheheehe bitcoin so hawt righ naow
< sipa>
i don't believe that CT in its current form is acceptable for Bitcoin, due to its huge transactions and processing requirement
< gmaxwell>
Considering those questionare answers which were mostly privacy positive (BIP 69 where kristov gave a misleading answer-- I don't think we should implement BIP69, it doesn't improve privacy and could hurt it); it's remarkable to me that they rated Bitcoin-QT poorly if thats where their information was coming from.
2016-02-29
< gmaxwell>
Likewise, they rated Bitcoin-Qt at 0 for physical security; when I believe it's the only wallet software in their test which is hardned against timing and RF sidechannels (some of the hardware wallets, like ledger are). Most of their wallets in their test do not implement meaningful KDFs for wallet encryption, thouh Bitcoin Core does.
< gmaxwell>
The reports is quite ... remarkable. For example, it places "Samourai" wallet ahead of Bitcoin-QT.... this wallet was recently in some reddit controversy when someone reverse engineered their closed source binaries and found that they were, without disclosure, sending all the user's addresses to BC.i.
< gmaxwell>
Was anyone here ever contacted by a group called the "Bitcoin Privacy Project"? They just put out a report that said that we did not respond to repeated contact attempts.
< go1111111>
a bit of friction for new devs that it might be worth it to avoid: on linux if i follow the build instructions all tests pass except for zmq_test.py, because python-zmq isn't on the build dependency list. on one hand this is fine, because it's not needed for non-devs. on the other hand, it'd be nice if tests passed after following build instructions. worth it to submit a PR like this? https://github.com/elliotolds/bitcoin/commit/bc48a5b89e1
< GitHub72>
[bitcoin] laanwj closed pull request #7537: wallet: Warn on unexpected EOF while salvaging wallet (master...2016_02_salvage_unexpected_eof) https://github.com/bitcoin/bitcoin/pull/7537
< GitHub183>
bitcoin/master 78e81b0 Wladimir J. van der Laan: Merge #7537: wallet: Warn on unexpected EOF while salvaging wallet...
< GitHub183>
bitcoin/master ca8fb59 Wladimir J. van der Laan: wallet: Warn on unexpected EOF while salvaging wallet...
< GitHub173>
[bitcoin] laanwj closed pull request #7606: [depends] builders: No need to set -L and --location for curl (master...Mf1602-curl) https://github.com/bitcoin/bitcoin/pull/7606
< GitHub24>
bitcoin/master b53d201 Wladimir J. van der Laan: Merge #7606: [depends] builders: No need to set -L and --location for curl...
< GitHub24>
bitcoin/master fa7a5c5 MarcoFalke: [depends] builders: No need to set -L and --location for curl
< GitHub116>
[bitcoin] MarcoFalke opened pull request #7617: [doc] Minor corrections to release notes and links (master...Mf1602-trivial9) https://github.com/bitcoin/bitcoin/pull/7617
< GitHub56>
[bitcoin] MarcoFalke opened pull request #7616: Revert "depends: fix Boost 1.55 build on GCC 5" (master...Mf1602-boost155) https://github.com/bitcoin/bitcoin/pull/7616
< GitHub93>
[bitcoin] MarcoFalke opened pull request #7615: [wallet] Couple MIN_CHANGE with minimum relay fee (master...Mf1602-walletMinChange) https://github.com/bitcoin/bitcoin/pull/7615
< GitHub146>
[bitcoin] luke-jr opened pull request #7614: Bugfix: gitian: Add curl to packages (now needed for depends) (master...depends_curl) https://github.com/bitcoin/bitcoin/pull/7614
< GitHub148>
[bitcoin] AliceWonderMiscreations opened pull request #7609: All files related to my RPM spec file project in one commit (master...master) https://github.com/bitcoin/bitcoin/pull/7609
< GitHub131>
[bitcoin] MarcoFalke opened pull request #7608: [wallet] Move hardcoded file name out of log messages (master...Mf1602-walletFileName) https://github.com/bitcoin/bitcoin/pull/7608
< GitHub138>
[bitcoin] MarcoFalke opened pull request #7606: [depends] builders: No need to set -L and --location for curl (master...Mf1602-curl) https://github.com/bitcoin/bitcoin/pull/7606
< GitHub172>
[bitcoin] jonasschnelli opened pull request #7605: Remove openssl info from init/log and from Qt debug window (master...2016/02/rm_openssl_log) https://github.com/bitcoin/bitcoin/pull/7605
< jtimon>
petertodd: in any case, github/bitcoin/jtimon/bip9-0.12.99-bip113-just-in-case should be easy to rebase on top of both #7575 and #7566
< GitHub136>
[bitcoin] sdaftuar opened pull request #7600: [WIP] Mining: Select transactions using feerate-with-ancestors (master...ancestor-mining) https://github.com/bitcoin/bitcoin/pull/7600
< zooko>
In current Bitcoin core.
< zooko>
Great, so no matter how badly screwed up this new openssl announcement is, openssl isn't being given the opportunity to touch Bitcoin signing keys.
< jtimon>
btcdrak: fwiw all my consensus PRs merged since 0.12 's fork are already backported (with anything that would make the rebase less clean) in https://github.com/jtimon/bitcoin/tree/backports-0.12 in case they were necessary for backporting SF functionality
< zooko>
Does the payment protocol use Bitcoin private (signing) keys?
< petertodd>
gmaxwell: interesting question re: PP - does the average install of Bitcoin Core's qt wallet actually let people click on a PP link and have their wallet pop up? if not, strongly suggests it isn't being used much
< petertodd>
btcdrak: well, so long as we can co-ordinate that with the bitcoin core release schedule - which admittedly is much easier if we continue to do that in minor version releases
< gmaxwell>
Hello. Welcome to today's meeting (bot is broken in #bitcoin-dev. Topics?
< GitHub178>
[bitcoin] morcos opened pull request #7598: Refactor CreateNewBlock to be a method of the BlockAssembler class (master...BlockAssembler) https://github.com/bitcoin/bitcoin/pull/7598
< GitHub53>
[bitcoin] jonasschnelli opened pull request #7586: [Qt] fix for building against LibreSSL (master...2016/02/fix_openssl_libressl) https://github.com/bitcoin/bitcoin/pull/7586
< kanzure>
instagibbs: slack notifications for bitcoin irc mentions is pretty cool, it works.
< kanzure>
zooko: it's manual, sadly. the mailing list that moderated emails are sent to is configured to only allow email from bitcoin-dev-owner@lists.linuxfoundation.org, that's the only configuration detail. when rejecting email, the moderator has to type bitcoin-dev-moderation@lists.ozlabs.org into the bitcoin-dev moderation queue interface.
< zooko>
How was the bitcoin-dev mailing list GNU Mailman configured to hold all postings for moderation?
< GitHub72>
[bitcoin] jonasschnelli opened pull request #7579: [Qt] show network/chain errors in the GUI (master...2016/02/gui_alert) https://github.com/bitcoin/bitcoin/pull/7579
< GitHub137>
[bitcoin] jtimon opened pull request #7566: WIP: Implement BIP9 and get BIP113 to be deployed with it as an example (master...bip9-0.12.99) https://github.com/bitcoin/bitcoin/pull/7566
< GitHub137>
[bitcoin] jtimon opened pull request #7564: libconsensus-p2a: Preparations to decouple libconsensus from coins.o (master...libconsensus-p2a-coins-cpp-interface-0.12.99) https://github.com/bitcoin/bitcoin/pull/7564
< GitHub61>
[bitcoin] jtimon opened pull request #7563: libconsensus-p2a: Decouple pow.o from chain.o and move it to the consensus package (master...libconsensus-p2a-chain-cpp-interface-0.12.99) https://github.com/bitcoin/bitcoin/pull/7563
< wumpus>
not sure it's fair to talk of a bus factor here. In principle someone else could sign, he doesn't have the one golden key that blocks bitcoin releases forever
< wumpus>
cfields signs, I upload the bins to bitcoin.org, good to not have one person do both
< midnightmagic>
(just for tor though, the bitcoin stuff is unchanged)
< midnightmagic>
yeah, the tor stuff also verifies tag signatures, so as part of my modifications to get it co-existing with bitcoin gitian I have to maintain a minor fork. gitian doesn't play nice with itself.
< GitHub54>
[bitcoin] morcos opened pull request #7556: Some cleanup work for mempool and policy estimator (master...cleanupMempool) https://github.com/bitcoin/bitcoin/pull/7556