< * Luke-Jr>
wonders if it is better to correct people in cases like this, or let them build up a negative reputation.
< gmaxwell>
Kristov's answers were a bit off but not terrible there.
< belcher>
gmaxwell they had been in contact with me about joinmarket a few months ago, nothing much came from it
< 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.
< gmaxwell>
Though I wonder about thins like this:
< gmaxwell>
" 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)?
< gmaxwell>
No, it just downloads the whole blockchain and performs local queries."
< gmaxwell>
... like are we being negatively marked here for doing the _only_ thing known to provide strong privacy?
< gmaxwell>
"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.
< gmaxwell>
" wut?
< Luke-Jr>
lol
< gmaxwell>
In any case, it's important people try to improve this. I'll go follow up with that old questionare-- it's unfortunate that it was sent when I wasn't following the list and no one picked it up. I'll advise them to create an issue in the future.
< Luke-Jr>
gmaxwell: improving it seems likely to result in their organisation gaining credibility without having anyone actually competent producing the future reports. so they may then be subtley problematic in the future and yet have a reputation of being accurate due to corrections made now.
< Luke-Jr>
(it'd be one thing if they held back on making reports until they had properly figured out the facts to a reasonable degree, but that doesn't appear to be the case)
< molz>
gmaxwell: hm.. so that was the reason kristov wanted to discuss with you about the wallet a few weeks ago, but he didn't say he was writing a report on it?
< molz>
we're going to have HD core wallet in v13, right?
< sipa>
if someone implements it, maybe
< gmaxwell>
molz: I really doubt it. Also, thats irrelevant to privacy.
< petertodd>
Luke-Jr: "improving it seems likely to result in their organisation gaining credibility" <- +1
< aknix>
I have some kristov chat logs...
< aknix>
pms
< petertodd>
aknix: oh yeah?
< aknix>
yes
< aknix>
i was IRL friends with him
< petertodd>
aknix: interesting
< petertodd>
aknix: now granted, PM's are meant to be private, so keep that in mind
< Luke-Jr>
past tense?
< aknix>
yes, I have been open minded. Also tried to reinstate conversation to no avail.
< aknix>
he has me blocked on twitter which i find childish as well
< Luke-Jr>
i c
< petertodd>
aknix: well, I blocked him on twitter because he kept on being uncivil, unlike others who disagreed with me
< aknix>
so my logs are gone from slack :(
< aknix>
they were slack PMs
< Luke-Jr>
aknix: yeah, problem with using slack..
< aknix>
He made statement that CT will never happen
< Luke-Jr>
it may not
< Luke-Jr>
I think sipa is working on improving it though
< aknix>
Im aware
< sipa>
i'm working on CT?
< Luke-Jr>
it's quite possible CT may not be necessary too
< aknix>
But he said it cant and argued that type of thing cant ever happen
< petertodd>
aknix: what was his rational?
< aknix>
I really really did no expect that from him
< Luke-Jr>
sipa: no?
< aknix>
He didnt elaborate, it got hot quick after that.
< sipa>
i don't believe that CT in its current form is acceptable for Bitcoin, due to its huge transactions and processing requirement
< molz>
well i have very little opinion of kristov because he was hired to give darkcoin a review on their code and he didn't find a hole in darksend until later someone who doesn't claim to be an expert discovered the flaw in darksend
< Luke-Jr>
sipa: I thought I heard you had a way to make it smaller, or something (but I agree with that assessment of the Elements state of CT
< sipa>
adam thought he had a way to make it smaller, but i'm not convinced
< Luke-Jr>
ah
< sipa>
in any case; just small constant factorsa
< aknix>
Hahhaha, molz I had met him right around that time.
< Luke-Jr>
anyway, hopefully Lightning will make CT unnecessary
< petertodd>
sipa: I was talking to adam about that actually, and he (or was it me?) made the point that the overhead of CT vs. less efficient mixing may make CT overall the better tradeoff
< * aknix>
prays to blockchain jesus
< sipa>
petertodd: agree, but privacy of a blockchain/currency is a common good, and i don't believe you can actually get the benefit without forcing CT
< sipa>
petertodd: tragedy of the commons
< aknix>
petertodd, I said the same thing in slack today
< petertodd>
sipa: that's true too
< petertodd>
sipa: though with bc.i claiming to have 50% of all txs, we have a tragedy of the commons in other ways
< belcher>
users do get a personal benefit from privacy, otherwise they wouldnt pay for mixers and coinjoins
< petertodd>
belcher: yup, though their k-anonymity sets aren't as big as they could be
< sipa>
belcher: for mixers to be useful, people who do not have anything to hide need to use them too
< petertodd>
sipa: well, keep in mind that if you and I have different adversaries, a mixer can still be useful
< Luke-Jr>
sipa: belcher's Joinmarket seems to incentivise them to, by giving them the fees
< belcher>
to clarify, it incentives people who have nothing to hide to take part
< sipa>
petertodd: fair enough
< petertodd>
Luke-Jr: I assume Joinmarket is run by the FBI and act accordingly :) fortunately my adversaries are probably not the FBI!
< molz>
lol
< petertodd>
I use joinmarket all the time
< * aknix>
hehheheehe bitcoin so hawt righ naow
< belcher>
hopefully the FBI and CCP are not sharing information, my antics are safe in that case
< petertodd>
belcher: hopefully your adversaries don't include Santa Claus, as he knows who is naughty or nice
< aknix>
oh yay i found the kristove logs
< aknix>
I did SS it
< petertodd>
aknix: SS?
< aknix>
screenshot
< petertodd>
aknix: ah
< sipa>
this is probably not the right place for discussion that
< petertodd>
sipa: +1
< aknix>
Sorry just dont want to see OBPP used for populist agenda
< gmaxwell>
I responded to that old survey on the list. Corrected a few things. Kristov's answers were generally okay; though.. I dunno the idea that you could compare the privacy of a webwallet that sends a server all it's addresses and a full node, is kind of bonkers to me.
< catlasshrugged>
hello!
< aknix>
Oh hey
< aknix>
at long last
< catlasshrugged>
kristov from obpp here
< catlasshrugged>
someone mentioned people were discussing some concerns about our report here
< aknix>
catlasshrugged, Thanks for pming me and clearing that up!
< gmaxwell>
Hi, I also emailed you directly before the discussion here.
< catlasshrugged>
I saw that
< catlasshrugged>
just going to try to clear up a few points of confusion, either on my end or others'
< catlasshrugged>
"4.Does your application fully implement BIP 62? <-- lol?" sorry this question was worded poorly, we were trying to determine whether wallets were doing their crypto in a fingerprintable way, and implementing all of the anti-malleability checks in BIP 62 was one short-hand way to do it.
< gmaxwell>
Sweet. -- FWIW, I think the whole idea of reviewing wallet privacy is a great one, even if I'm lost at your results.
< gmaxwell>
catlasshrugged: I kinda figured that. In any case, non-issue now-- thanks to changes in 0.11.2 wallets that don't are no longer transacting.
< 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.
< gmaxwell>
I didn't realize you were asking that earlier-- funny that both armory and electrum (among others) were still not producing lowS signatures when 0.11.2 came out.
< gmaxwell>
catlasshrugged: the only other wallet which recieved that rating was darkwallet. I'm not finding anything in the questionare that helps me understand that.
< catlasshrugged>
see the section of the threat model that mentions physical surveillance to see how scores are derived for that section. I wouldn't mind adding the RF timing attacks, although I don't think it would affect any wallet's score much as the attack is extremely unlikely and not scalable.
< catlasshrugged>
whereas "grabbing qr codes from mobile screens" is at least vaguely scalable attack, though still representing a very small % of the overall score we awarded.
< catlasshrugged>
the questionnaire is only half (or maybe less) of our criteria.
< catlasshrugged>
most of the data was gathered by volunteers directly interacting with the wallets.
< catlasshrugged>
and answering TRUE/FALSE questions or counting # of clicks to perform certain actions according to the script that we prepared.
< gmaxwell>
catlasshrugged: Other than wallets which remotely send their address information to third parties instead of storing it locally, what mecneisms for 'physical' security are you counting here?
< gmaxwell>
many wallets you rated more highly for physical security are browser based and would have left identifying information in browser caches.
< catlasshrugged>
scroll down to "physical adversary"
< gmaxwell>
ah this is useful at least.
< catlasshrugged>
We'll be revising our threat model soon for the next edition. Input extremely welcome!
< catlasshrugged>
I've been trying to solicit help for a long while now.
< gmaxwell>
I wasn't aware of this list-- I had seen your prior report.
< 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.
< gmaxwell>
catlasshrugged: I'm not sure how to handle things like "The user can easily erase the application and all its metadata if the decide to stop using the wallet or device" --- on modern OS's and disks, its not actually possible to do this in an application, nothing short of a secure erase does this.
< 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..
< aknix>
Also is providing a pseudo UI for a bitcoin wallet a good idea either?
< aknix>
idk some of this seems silly to me..
< 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
< kanzure>
"attack is unlikely and not scalable" unlikely attacks should still be defended against; especially if you are explicitly saying it is your job to communicate this to your readers.
< catlasshrugged>
some of them use bloom filters but those filters include effectively 0% of the blockchain, so they got a 0
< catlasshrugged>
kanzure: ...I don't know how to parse that statement.
< gmaxwell>
kanzure: I agree that from a purely privacy specific perspective sidechannels is not a dominating concern; (though I think I'd put it at least as important as having a boss key)
< kanzure>
catlasshrugged: i think the only relevant reply i can muster is "who is john galt?"
< catlasshrugged>
""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." This wasn't figured into my ratings, but I was observing that some adversaries could correlate the download of a bootstrap.dat file with a node that starts downloading blocks exactly where the bootstrap.dat file leaves off.
< catlasshrugged>
alllllrighty
< aknix>
no need to do that anymore
< gmaxwell>
catlasshrugged: Ah, I follow your thinking now at least.
< aknix>
The .12 client syncs from scratch in only a few hours
< gmaxwell>
Yes, I should have responded that since 0.10 bootstraps are depricated.
< catlasshrugged>
"gmaxwell: improving it seems likely to result in their organisation gaining credibility without having anyone actually competent producing the future reports." hey luke, just letting you know I read this :-)
< catlasshrugged>
Sorry, not sure why I said "my" ratings -- our ratings
< catlasshrugged>
"aknix: now granted, PM's are meant to be private, so keep that in mind" thanks petertodd :)
< gmaxwell>
catlasshrugged: well, to be fair; I think your result is shocking. And it's a open question if I'd be doing the ecosystem a greater favor to contribute to improving the process, or instead to draw attention to how broken it is...
< catlasshrugged>
I am not sure how to include "I didn't like the way these guys acted on Reddit" into my privacy threat model, but I'm all ears
< gmaxwell>
catlasshrugged: not even a question of acting, closed source wallet that secretly phoned a third party and gave it's users addresses up. Ouch.
< catlasshrugged>
for the record, I do not appreciate being told that "I should be embarrassed." I don't deserve that.
< gmaxwell>
Sorry, let me retry that: I would be embarassed if it were me. I dunno about you.
< catlasshrugged>
that's not really less dickish...
< catlasshrugged>
the closed source state is in the threat model; they lost points for it.
< gmaxwell>
No, but it's honest.
< catlasshrugged>
Are you a practicer of "radical honesty" or something?
< catlasshrugged>
as I understand it, SW intend to open source in the future, but that's not relevant to their score this time around
< gmaxwell>
even ignoring their behavior, wallets that are telling third parties users addresses should be massively lower in privacy baseline. Being unclear/deceptive about the privacy model should be it's own thing too; but the whole idea that a wallet is meaningfully providing privacy at all when it's phoning home addresses, ...
< * aknix>
would prefer being told the truth than anything else. I have always come to some bitcoin channel for that over the years ;)
< pigeons>
_alp_: i see a smiliar name on both the payment codes bip and the obpp
< aknix>
You should know this catlasshrugged, brutal honesty is always lurking in IRC
< gmaxwell>
catlasshrugged: I don't know why you included a closed source wallet at all? -- e.g. how can its properties be evaluated? the discovery that it's sending the users address info upstream required reverse engineering the binary.
< catlasshrugged>
source isn't closed to me :-)
< pigeons>
before the report you had the source?
< aknix>
not sure if better or worse
< pigeons>
before you rated them?
< catlasshrugged>
a related question is "why include an alpha wallet". those are valid concerns, but overall I don't think it's a very interesting feature of the report
< catlasshrugged>
if someone busts their ass to look in depth at 20 different wallets and your only response is "I don't like that you included this wallet," that's not feedback I care hugely about.
< gmaxwell>
catlasshrugged: in any case, my concern wasn't that it was closed source (I think that should outright preclude it even ignoring privacy); but I think the scoring must be busted if you're raking wallets who send all the users addresses to a member of the blockchain allance over a full node.
< gmaxwell>
catlasshrugged: thats not the only feedback you're getting here for sure.
< catlasshrugged>
we talked a couple weeks ago about full nodes
< catlasshrugged>
I think they are less important than you do
< gmaxwell>
catlasshrugged: all the more disappointing.
< 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>
I think everyone is willing here, but you are really picking holes in areas that arent really realistic for most users.
< aknix>
granted it is a tough thing to do...
< aknix>
I would be willing to help revise guidelines for example.
< catlasshrugged>
we hold 100% open meetings and our mailing list is 100% open for participation
< catlasshrugged>
if you'd like to see any positive changes, this is really easy to do
< catlasshrugged>
ask anyone who has participated before, I haven't turned down a single person or contribution since we started the ratings project.
< kanzure>
then perhaps you should show them the logs from today in here
< kanzure>
it would save us time and be a generous olive branch
< catlasshrugged>
I will gladly post this log to our mailing list, though I am not sure what actionable feedback has been provided so far
< gmaxwell>
catlasshrugged: well I invested nearly an hour responding to your older questionare; I never saw it previously. Time is obviously fairly limited.
< gmaxwell>
catlasshrugged: do you have a parallel wiki page with the actual scorings for those criteria?
< kanzure>
actional feedback like category and score and rating improvements, hmm not very actionable i guess
< catlasshrugged>
for example, if people believe that having a full copy of the blockchain is of the ultimate importance, there has to be a discussion about that. I can't just say "citation: gmaxwell"
< randy-waterhouse>
actionable feedback into a nebulous, subjective process seems a bit pointless?
< kanzure>
there are many discussions about that
< gmaxwell>
kanzure: actualble would be that I can't really repect this project while-- absent any severe privacy goofs-- it continues to rate full node (or things with equivilent privacy properties) below other kinds of wallets.-- that your effort would rate things that litterally stream users private data to third parties who will exploit that data commercially, is just astonishing, and it really makes m
< gmaxwell>
e question the good faith involvement of everyone responsbile.
< catlasshrugged>
randy-waterhouse: oh, do you have a proposal for a clearer, less subjective process? I am very interested in such proposals, though generally find that people who have said things like that so far haven't actually bothered to go to github.com and read ours
< gmaxwell>
catlasshrugged: having a full copy isn't what I'd consider important: not leaking the users private data to third parties is... and right now the only ways we can do that are sending the whole chain or PIR and no one has implemented PIR for this yet.
< catlasshrugged>
("better" compared to the not very successful bloom filter implementations to date)
< kanzure>
anyway, it should be obvious by now that "full nodes" aren't just a figment of gmaxwell's imagination
< kanzure>
if you need another pile of links just ask me i'll be happy to DoS you with links
< gmaxwell>
catlasshrugged: well bitcoin core has "PIR" in the naieve form: send everyone the whole database is PIR. :)
< catlasshrugged>
kanzure: thanks. I've read that, though, and doesn't change my opinion about the importance of having a full node vs resistance to blockchain analysis.
< kanzure>
catlasshrugged: i think you should include disclaimers like "review by bitcoin core developers has said x about this rating scheme"
< catlasshrugged>
gmaxwell: yes :)
< gmaxwell>
kanzure: bleh
< kanzure>
and also you should send the logs to your group, i think it would be a useful disclosure for you to make
< catlasshrugged>
sure, I'll send the logs as soon as I wrap this up.
< gmaxwell>
catlasshrugged: what does ledger (for example) do for resistance to blockchain analysis that Bitcoin Core does not.
< kanzure>
gmaxwell: i don't have a better idea
< gmaxwell>
?
< gmaxwell>
kanzure: catlasshrugged is saying that he'd like to improve the process, improving it is better than leaving it unimproved and crapping on it from afar.
< catlasshrugged>
automatic selection of receiving addresses, HD wallet structure...
< petertodd>
catlasshrugged: maybe I missed something, but how are HD wallet's helping here?
< gmaxwell>
catlasshrugged: uh.. you know that it's externally undetectable to users if bitcoin core uses HD wallets; right?
< 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>
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>
An expert Bitcoin user can probably do everything and more with Bitcoin-Qt that he can do with Ledger.
< gmaxwell>
catlasshrugged: How is this useful for incentivizing users to not reuse addresses?
< 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>
gmaxwell: oops, you're right about the clicks -- Bitcoin-Qt got 0 clicks for that = full score
< gmaxwell>
I wouldn't be surprised if a typical non-advanced user was actually unable to reuse addresses, short of writing them down outside of the application.
< catlasshrugged>
it complicates the backup process
< gmaxwell>
catlasshrugged: users cannot escape that by reusing addresses in bitcoin core, due to change.
< aknix>
catlasshrugged, Wow this for regular users? Really? This way too much for your average banker off the street to handle, and they handle a bunch...
< catlasshrugged>
I'm going to be writing some blog posts about the data set and hopefully highlighting strengths and weaknesses
< gmaxwell>
From a privacy perspective, I'm still not seeing your argument.
< petertodd>
catlasshrugged: yes, but that's not a privacy problem (and in some cases non-HD, 'bag of keys', wallets have better privacy)
< _alp_>
So I can't reuse addresses in electrum since its HD? Strange, I do that all the time.
< 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>
E.g. if reusing addresses made backup easier I'd agree with you that points should be deducted there.
< catlasshrugged>
N.B. ***no one in this room is an average Bitcoin user.***
< 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>
I'd be interested in discussing the privacy effects of HD wallets some more some time, but I actually don't want to get into it right now.
< 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
< gmaxwell>
ntal privacy flaw.
< 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>
I only brought up ledger to try to get a specific list of (mis)features; I'm sure ledger is great. (the ledger folks strike me as supremely confident)
< catlasshrugged>
aknix: not all of them are weighted equally, see the weights.wiki doc for that
< aknix>
These rating criteria need refining
< aknix>
ahh ok that helps but a pseudo UI cmon
< catlasshrugged>
pigeons: what do you like about that one?
< pigeons>
it tells each thing being considered
< 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.
< catlasshrugged>
I'd be happy to send you a copy of the ratings for Bitcoin-Qt
< catlasshrugged>
last edition we posted them on GitHub, but no one noticed so I didn't bother this time aroun
< catlasshrugged>
d
< pigeons>
"pysical privacy" is much more nebulous than "sends addresses to third parties"
< petertodd>
catlasshrugged: I think you need to preserve raw data like that even if no-one seems to notice
< petertodd>
pigeons: yeah, once the attacker is standing next to you all bets are off anyway...
< catlasshrugged>
consider it "available upon request"
< petertodd>
pigeons: heck, I don't even put a pin on my trezor for that reason
< aknix>
hmm thats not very bitcoin like.
< gmaxwell>
catlasshrugged: well what would be most useful for non-nitpicking is a list of criteria that other things rated higher in. I mean, I don't care about your boss key criteria at all if almost everything else failed it too. :) (I don't think it's an important privacy feature, though I do at least agree it is a privacy feature)
< 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)
< catlasshrugged>
gotcha
< catlasshrugged>
yeah, all wallets failed most of the criteria given that the top score was 50
< petertodd>
catlasshrugged: re: weights, I'd suggest you try to decide on them first, make a commitment to those weights, and only then evaluate wallets against the weights - good way to respond to accusations of bias
< gmaxwell>
catlasshrugged: I do think that my complainin here probably does reduce to weighing.. but in terms of places where we could improve or where we're actually doing better than your process realizes, just knowing criteria where other things were higher would be helpful.
< catlasshrugged>
petertodd: that is absolutely what we did.
< petertodd>
catlasshrugged: did you do it in a way that's publicly reproducable?
< catlasshrugged>
I don't pretend that anyone would care about my opinion about a particular wallet
< 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>
petertodd: partially. we wrote down how much weight we assigned to various categories, but did not write down full English descriptions of why
< petertodd>
catlasshrugged: ok, so, publicly reproducable would be at minimum something like a tweet "the sha256 hash of our chosen weights is: xxx"
< catlasshrugged>
so for example we might have said that blockchain analytics are 10 times more dangerous than physical surveillance, but didn't specify why we thought so.
< 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.
< aknix>
catlasshrugged, How can you not disclose the weights?
< petertodd>
gmaxwell: yeah, I'm very concerned about third-parties getting addresses myself
< catlasshrugged>
oh, I see. does anyone really think we modified our weights after the fact and are lying about it?
< catlasshrugged>
that is pretty uncharitable
< gmaxwell>
catlasshrugged: no no. but PT was suggesting a scheme that would prevent that, and I'm saying it's not a concern.
< catlasshrugged>
aknix: weights are in the weights.wiki file
< gmaxwell>
at least not right now.
< aknix>
catlasshrugged, Ahh thanks, i missed that
< gmaxwell>
catlasshrugged: it's sometimes an issue though, when you have 1001 criteria you can sometimes change the weights slightly to really rig the outcome.
< petertodd>
catlasshrugged: it is, but it's an easy thing to prevent people from thinking - the same kind of process is done all the time in big physics experiements to prevent bias
< randy-waterhouse>
the privacy criteria should end up identical to a design spec. for a high privacy product or else it's just game playing 'weightings' with features
< catlasshrugged>
fair enough. I'll consider that for next time
< catlasshrugged>
creating a github issue now...
< aknix>
catlasshrugged, Whoa cant we simplify this?
< aknix>
this is obtuse
< petertodd>
catlasshrugged: thanks! you can point out you're using the same process that cern uses :) you can probably dig up a press release or something describing it to explain to the general public
< 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.
< petertodd>
gmaxwell: agreed - they have a lot to overcome
< catlasshrugged>
I really would welcome a discussion about the comparative importance of blockchain analysis countermeasures vs network privacy leaks, perhaps that could take place over a mailing list or a Google Hangout some time.
< gmaxwell>
the report is beautiful though, and the area is important for work.
< 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.
< petertodd>
catlasshrugged: I doubt we're going to know what the comparative importance really is until we get the snowden of chainalysis... but I strongly suspect network privacy is a big issue, given how easily it can corrolate all your addresses
< 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.
< gmaxwell>
So even if we don't know how to weigh one vs another; we can agree both are very important for privacy. (I think we do)
< catlasshrugged>
Primary take-aways I would like from the report are: Privacy protections still weak, everyone needs to do better | Some clear trends for winners and losers (e.g. custodial vs non) | some of the best funded providers are not doing the best at privacy
< catlasshrugged>
take-aways I am not looking to express: Ledger is better than Bitcoin-Qt; Bitcoin-Qt sucks!
< gmaxwell>
catlasshrugged: too bad, that isn't how the report presentation comes out.
< gmaxwell>
Esp with the ranked score on the first page. :)
< gmaxwell>
If you want that you should be counting the privacy fails instead, and enumerating the things they don't do.
< catlasshrugged>
If you have any thoughts on how to improve, I welcome them. I don't know how to make the process not utterly subjective without subjective the wallets to some standardized rating system based on systemic analysis
< petertodd>
catlasshrugged: it'd be less subjective if it wasn't ranked, but rather, you talked about what kinds of attackers wallets were vulnerable too
< catlasshrugged>
what would that look like?
< catlasshrugged>
we do want to provide comparative analysis that is easily consumed to provide competitive pressure. I'm sure that you've noticed that, in the absence of competitive pressure, things haven't improved much lately.
< gmaxwell>
I think my intuition is "Here is the list of the worst things wallets to wrong againt attacker X"
< petertodd>
catlasshrugged: start with some descriptions of those attackers, then have a big check box matrix for which wallets are and are not vulnerable to each attacker
< gmaxwell>
And then you list the criteria that are done wrong by the most wallets, with then a list of which wallets did them wrong.
< 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.
< gmaxwell>
catlasshrugged: if your message is that they all suck than your audience isn't an actual bitcoin user, it's the industry.
< petertodd>
catlasshrugged: seriously: get some graphics/storyboards done illustrating what those attackers can do and who they might be
< petertodd>
gmaxwell: +1
< catlasshrugged>
the industry generally does not give a flying fuck about my concerns ;-)
< 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>
I'm not saying you _intend_ to say that, but thats what the report says to joe reader.
< petertodd>
catlasshrugged: journalists can help fix that
< catlasshrugged>
this is why Consumer Reports doesn't write letters of concern to the makers of products
< petertodd>
catlasshrugged: consumer reports deals in an industry where most people are doing things basically right
< aknix>
catlasshrugged, I think you are close to having a very good report here. just need simplify a bit you are on the right track. Just need to simplify and refine oh and not be biased ;)
< catlasshrugged>
petertodd: I'm not clear on how that is relevant
< catlasshrugged>
I worked pretty hard to eliminate bias. I think we could do better in the future, but could not have reasonably done better in the past.
< petertodd>
catlasshrugged: in the field consumer reports is dealing with, there are standards already in place, so companies that don't adhere to those standards are just cutting corners knowingly, or simply screwed up and accidentally released a lemon
< gmaxwell>
catlasshrugged: How do you have access to that wallet's source code?
< petertodd>
catlasshrugged: we're in a field where there isn't yet general acceptance of how to do things right, and what the downsides of doing things wrong is
< catlasshrugged>
gmaxwell: the developers have shared it with me individually in the past.
< catlasshrugged>
that doesn't mean anything as far as vouching goes, I don't think
< petertodd>
catlasshrugged: while I'm not saying you're biased, be warned that using that kind of evidence as a basis invites suspicion
< gmaxwell>
catlasshrugged: Ah. I was wondering if you were involved with its development.
< catlasshrugged>
petertodd: I find that wallet providers are extremely aware of what they're doing wrong and why they're not addressing it.
< catlasshrugged>
I am not.
< catlasshrugged>
The only project I work on did not score highly in the report
< gmaxwell>
::nods::
< catlasshrugged>
That said, dozens of people got to review the scores and all of the wallets were rated by multiple people, so there's not a lot of room for hijinks.
< * gmaxwell>
::shakes:: head
< gmaxwell>
I don't know how you can say that.
< aknix>
we all know how voting works ;)
< catlasshrugged>
doing things this way tremendously increased the amount of work I had to put in, btw
< petertodd>
catlasshrugged: what can I say, I have a bit more faith in them that you, at least at an upper management level - this is quite different than something like automobiles where there are detailed government standards for everything :)
< catlasshrugged>
consumer reports has years of credibility built up that I don't
< catlasshrugged>
it's quite reasonable to trust their reports more than you trust ones that I work one with a small number of people.
< 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>
le.
< petertodd>
gmaxwell: +1
< catlasshrugged>
the argument about the "blockchain alliance" thing is quite boring to me. I work for the company whose API samourai chose to bootstrap with. they don't do anything with the data.
< aknix>
gmaxwell, +1
< catlasshrugged>
you don't work there, so I can see why it wouldn't be boring to you.
< gmaxwell>
catlasshrugged: The company you work for has been caught lying in the past with what it does with private data provided to it. Even if it does not misuse it now, it might begin at ay time in the future--- and could probably be doing so without your knoweldge.
< catlasshrugged>
example?
< aknix>
Sheesh
< catlasshrugged>
that's true, I can't tell what the data could be used for in the future, though I am fairly confident it simply isn't being stored at the moment.
< aknix>
Thats very likely the case but its stilla secuirty hole
< catlasshrugged>
sometimes when you are a company that has $0 in funding, you have to bootstrap some shit.
< gmaxwell>
catlasshrugged: it also can be stored by cloudflare, even if it isn't being stored by bc.i.
< aknix>
"bootstrap" in that context sounds like magical numbers argument to me
< gmaxwell>
catlasshrugged: I wouldn't find it much better if it were their own server instead of bc.i.
< gmaxwell>
(if thats any consolation)
< aknix>
yeah i dont think anyone would really
< catlasshrugged>
ok, well at least if it were their own server, it would be operating the way that most of the wallets that we reviewed operate.
< aknix>
at least people in this room i guess
< pigeons>
catlasshrugged: are you concerned currently that new users seeking privacy with privacy needs might choose a wallet that leaks all of the addresses based on reading the current report?
< catlasshrugged>
so the majority of your problem with samourai wallet vs qt is client-server vs fullnode, which we talked about earlier.
< gmaxwell>
But at least their own server could have a stronger systematic protection; e.g. published documentation for how it's operated, keys not in any third party hands, etc; no past bad track record... but I'd consider that small.
< catlasshrugged>
(full node is definitely far better than client-server, I just don't think it's the most important out of all categories of attacks)
< 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>
catlasshrugged: what is the most important?
< gmaxwell>
Not reusing addresses? Bitcoin core does as much as is possible there short of actually forbidding the users from doing it.
< catlasshrugged>
I think resistance to blockchain analysis is roughly 2x more important than network-level analysis based on speaking with many people in analytics.
< gmaxwell>
Integrated coinjoin? doesn't have that, but nor do virtually any of the others-- in our case it's partially because decenteralized coinjoin is pratically an unsolved problem (if not theoretically)
< catlasshrugged>
yeah, coinjoin capability is heavily weighted in our scoring IIRC
< catlasshrugged>
and yes, almost no one is currently doing it
< catlasshrugged>
I hope by the next report, JoinMarket's GUI will be ready to go
< 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?
< catlasshrugged>
and maybe we will just rate Qt+JoinMarket GUI rather than Qt by itself.
< gmaxwell>
er blockchain analytics rather.
< catlasshrugged>
I'll send you a list of things that one or a couple wallets got higher marks for
< catlasshrugged>
it will just take some time to put together.
< gmaxwell>
I would be really thankful for that.
< catlasshrugged>
oh, you asked about network analytics
< gmaxwell>
I ment blockchain.
< catlasshrugged>
I would not be surprised if Qt received the highest marks out of all wallets with regards to network stuff
< catlasshrugged>
ah, ok
< 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>
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
< gmaxwell>
y; or arguably 'stealth' addresses, but I can also argue that stealth addresses are of little value in the current climate today)
< 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.
< petertodd>
catlasshrugged: market share isn't relevant here - if a little-used solution provides far better privacy, then people who know what they are missing
< 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>
indeed, running a FN wallet has costs, but the superior privacy is one of the reasons a privacy conscious user should pay those costs.
< pigeons>
catlasshrugged: i didnt ask about the "average bitcoin user" I asked about "new users seeking privacy with privacy needs"
< catlasshrugged>
pigeons: you're right, sorry. I didn't fully read your question when I went back to look at it.
< gmaxwell>
devastating*
< catlasshrugged>
gmaxwell: ok.
< catlasshrugged>
if anyone is interested in presenting carefully reasoned arguments about the relative merits of blockchain vs network attacks, I am extremely eager to hear them and incorporate that insight into our model for the next report.
< catlasshrugged>
I think you will find that you have underestimated the level of thought I've put into the topic, but of course I may be wrong. :)
< aknix>
How about we fix the weighting/section on physical adversarys to start ;)
< catlasshrugged>
sorry, what's wrong with it?
< aknix>
Its just unrealistic as all wallets will fail
< pigeons>
you rnk shoulder surfing a greater threat than address leakage
< aknix>
I mean cmon you recoomend a fake UI for a bitcoin wallet
< aknix>
what are you gonna do open tinder to use bitcoin?
< aknix>
this is not avergae user material
< catlasshrugged>
pigeons: nope, false. you're reading it wrong.
< aknix>
Other than that like i said before i thin k you are on the right track just weighting is goofy
< catlasshrugged>
I'm not all that motivated to remove attacks and countermeasures from the threat model. I prefer to add to them, and weight appropriately.
< catlasshrugged>
If you actually said something about HOW you think the weighting is goofy, I missed it.
< pigeons>
catlasshrugged: are you concerned currently that new users seeking privacy with privacy needs might choose a wallet that leaks all of the addresses based on reading the current report?
< dirtynewshoes>
catlasshrugged: Darkwallet in here at 4 is a bit confusing... I did not think it was at all really ready to be used.
< aknix>
Well if samourai was rated higher than qt should i bother?
< 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.
< catlasshrugged>
dirtynewshoes: it works, although it lost some points due to the fact that the coinjoin has little volume at the moment
< dirtynewshoes>
catlasshrugged: Would it be used by the average bitcoin user? (Stable enough?)
< 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.
< catlasshrugged>
dirtynewshoes: when you download it, it comes with several warnings. I didn't actually have any significant issues with it.
< catlasshrugged>
aside from the fact that DW stealth addresses are not fully compatible with ArcBit stealth addresses
< catlasshrugged>
which is noted in the report.
< petertodd>
catlasshrugged: could you answer gmaxwell re: ledger vs core?
< pigeons>
coinjoin has more volume than samouri
< aknix>
petertodd, +1
< pigeons>
*joinmarket
< catlasshrugged>
not right now because I need to manually create the comparison
< catlasshrugged>
but I currently plan to send him the comparison. I would be happy to CC you, if you're interested.
< petertodd>
catlasshrugged: yes, please do
< catlasshrugged>
whats a good email address?
< pigeons>
catlasshrugged: what are ledger's blockchain analysis resistance features?
< petertodd>
catlasshrugged: pete@petertodd.org
< catlasshrugged>
ok
< 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>
nope, it doesn't
< randy-waterhouse>
an acknowledgements section might be appropriate?
< catlasshrugged>
expert users already know this
< catlasshrugged>
if you're not sure about this, please scroll up ;-)
< gmaxwell>
catlasshrugged: that doesn't make it okay to have a misleading report!
< catlasshrugged>
I don't think there's anything in the report that suggests that its primary audience is expert bitcoin users.
< petertodd>
catlasshrugged: you don't need to be an expert to run bitcoin core I'll note
< catlasshrugged>
there's no way to put out this report without pissing several people off about their favorite wallet(s).
< aknix>
I think its misleading in general because running QT is part of the secuirty model
< petertodd>
aknix: +1
< gmaxwell>
Lets imagine bob is a technical user with a serious need for privacy, he looks at your report, and doesn't even bother looking at a full node wallet whats there is burried in it; even though it would provide him seriously better privacy than many of the higher rated things in your report; at least as far as I can tell from your responses here.
< 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
< aknix>
it should be at least noted that by choosing not to run a "full node" that the SAME level of secuirty can not be obtained
< aknix>
I understand that is a stretch but its relevant to newb
< petertodd>
sipa: Bitcoin Core is something non-experts can and do run mind you
< 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.
< warren>
catlasshrugged: It's one thing to weigh things differently, it's another to mislead about facts. For example, the Samurai exposé is pretty damning yet there is no mention of it in the report?
< gmaxwell>
It's just inconcievable to me that you're ranking wallets that PHONE HOME ALL THE USERS ADDRESSES over a wallet that doesn't; without smoking gun reasons like "due to this bug, QT's privacy is totally busted".
< gmaxwell>
(er totally busted due to X)
< catlasshrugged>
sipa: this is my best estimation, along with various other people who helped, of which wallets are best for the privacy of the median user.
< catlasshrugged>
bitcoin-qt is a wallet. I'm not going to exclude it.
< sipa>
catlasshrugged: then you should at least be able to give one aspect at which bitcoin-qt ranks lower than your #1
< catlasshrugged>
warren: as I mentioned before, I am completely underwhelmed by the "expose"
< aknix>
Wow, i am at a loss for words..
< 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".
< catlasshrugged>
I thought the poster who brought up the "expose" was a complete dick about it, and I'm sad that people were not sympathetic to the completely unpaid and hard working samourai devs
< aknix>
warren +1
< 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
< petertodd>
catlasshrugged: on that basis, samourai should be removed for being alpha software - the excuse given was samourai is alpha software and that part hadn't been developed yet
< catlasshrugged>
ok
< petertodd>
catlasshrugged: it's a reasonable excuse, but it's one that's only reasonable if the walelt isn't used for anything but alpha-level testing
< warren>
catlasshrugged: There's an army of people being a complete dick and not sympathetic to the completely unpaid and hard working core devs, yet that is not a valid argument in any question of security or privacy which analyzed using objective criteria.
< _alp_>
I don't always alpha test, but when I do, I do on mainnet.
< petertodd>
catlasshrugged: equally, until samourai implements that _missing_ part of their wallet, we can't evaluate them
< aknix>
_alp_, :)
< catlasshrugged>
warren: please either explain how the reddit "expose" fits into our threat model, or how our threat model could add such a thing. otherwise, this is not relevant to my interests.
< gmaxwell>
catlasshrugged: if your threat model doesn't include bc.i logging all the users transactions and selling the results; then you need to stop calling your report a report on privacy.
< petertodd>
catlasshrugged: if your threat model isn't covered by that expose, it's not a very good htreat model
< warren>
If you think that issue isn't important in your threat model, then your threat model is flawed.
< catlasshrugged>
sipa: what do you mean by "aspect"?
< petertodd>
hehe, three identical replies :)
< catlasshrugged>
bc.i does not log all user transactions and sell the results.
< aknix>
catlasshrugged, Man cmon I know you are smarter than this.
< catlasshrugged>
aknix: that is incredibly rude.
< petertodd>
catlasshrugged: what proof do you have of that?
< pigeons>
i am very suprised that anyone thinks that a user seeking any level of privacy would choose to reveal their addresses
< gmaxwell>
catlasshrugged: prove to me that it doesn't; moreover prove to me that it cannot?
< aknix>
Yeah well i am being honest
< aknix>
I also have vouched for you in the past
< petertodd>
catlasshrugged: indeed, why specifically do you think you have any way of knowing?
< sipa>
catlasshrugged: in what way is Bitcoin-Qt's privacy worse than Samurai's?
< aknix>
Im hurting myself by even commenting on this
< catlasshrugged>
just wondering guys, what do you hope to be the outcome of a bunch of you ganging up on me?
< aknix>
but its important
< catlasshrugged>
I thought we were making some traction on productive iterations before, but now :/
< petertodd>
catlasshrugged: would you mind answering the question?
< petertodd>
catlasshrugged: we're here to help you fix your report; that means we'll ask questions, not all of them easy to answer
< petertodd>
catlasshrugged: that's just how engineering reviews work
< gmaxwell>
catlasshrugged: sorry that it's turned a bit harsh.
< aknix>
catlasshrugged, Not trying to gang up, just trying to show you an other POV
< sipa>
catlasshrugged: I'm sorry if you feel ganged up; that is by no means my intention
< aknix>
I know that can be difficult to get.
< gmaxwell>
catlasshrugged: Your position is somewhat inexplicable to me, and you're not really answering the questions people are trying to ask to make it explicable.
< gmaxwell>
I'll back off for now and give you some air. Sorry.
< catlasshrugged>
petertodd: I mean, I've done engineering reviews before, they are generally less unpleasant.
< aknix>
And catlasshrugged I have 2 times said I like the structure so far and think it has promise, i just think there is uneeded bias.
< catlasshrugged>
ok, to answer gmax's question: the possibility of blockchain or any other provider doing something bad with data as a result of transaction broadcasts and balance lookups is included.
< petertodd>
catlasshrugged: I used to work in a field where some stuff was safety critical - our reviews were often like this, and you simply learned that it wasn't personal
< petertodd>
catlasshrugged: easier in person for sure
< catlasshrugged>
you may take exception with the way that we weighted this consideration -- please *CAREFULLY* review how we actually weighted it, and if you have constructive feedback you'd like to provide about it, please do that.
< gmaxwell>
catlasshrugged: I was responding to your question 'warren: please either explain how the reddit "expose" fits into our threat model'
< catlasshrugged>
concerning sipa's question, he can get some more insight into this once I send a comparison to gmax and petertodd
< catlasshrugged>
if you have suggestions about what it would look like, I welcome them. Currently I have absolutely no clue.
< catlasshrugged>
To re-iterate, the fact that balance lookups and transaction broadcasts are done through a server is considered in the threat model.
< petertodd>
catlasshrugged: so again, how do you know bc.i doesn't log queries?
< catlasshrugged>
I can't prove it.
< petertodd>
catlasshrugged: ok, so don't say it
< catlasshrugged>
I would not have mentioned if instead gmax said: "if your threat model doesn't include ++the possibility of ++ bc.i logging all the users..."
< petertodd>
catlasshrugged: does bc.i even formally say they don't keep logs?
< catlasshrugged>
To the best of my knowledge, the threat model does include this possibility.
< catlasshrugged>
of course, it does not discriminate bc.i from any other provider
< gmaxwell>
catlasshrugged: Sorry, I was just at a loss as to why you were saying the reverse engineering analysis had nothing to do with your threat model.
< gmaxwell>
Since what it turned up was that the wallet was, without disclosure, sending the user's addresses to bc.i (to a not documented API, in fact). Which would be part of your threat model unless you were totally ignoring sending private data to bc.i in it. :)
< catlasshrugged>
I don't think samourai ever claimed that they do not send traffic through bc.i
< pigeons>
also how and whether the user is informed of information sharing and what is shared and with whom would be something to measure in the report
< gmaxwell>
they also don't claim to not send your private keys to Pirate40.
< catlasshrugged>
I'm not sure why you would expect them to "disclose" this in advance any more than any wallet would "disclose" the boring details of how their server-client interaction works.
< petertodd>
catlasshrugged: it certainly came as a surprise to many of their users
< gmaxwell>
At least for something claiming to be the most private it was rather shocking.
< catlasshrugged>
I'm not sure how to include "don't surprise people" in a threat model
< gmaxwell>
(and the thread on reddit seems to indicate an overwhelming majority of the commentin people agreed, for whatever thats worth)
< petertodd>
catlasshrugged: samourai was advertising itself as an SPV wallet, which implies to most people that there isn't a central server involved
< catlasshrugged>
I don't tend to look to reddit for my social cues
< gmaxwell>
I'm not talking about the surprise, I'm talking about the serious privacy leak which was only publically known due to the reverse engineering.
< catlasshrugged>
I didn't know that, but I've never seen Samourai use the term "SPV" in their promotions
< 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
< gmaxwell>
Samourai is an SPV mobile wallet that collects no information about you. "
< catlasshrugged>
it's sending transaction data to a server
< warren>
Do you at least agree that you should stop comparing apples to oranges? (remove the full node wallets like Qt)
< catlasshrugged>
I don't particularly care whether you prefer the server they used
< pigeons>
without informing the user after leading the user to believe otherwise
< petertodd>
catlasshrugged: a server not controlled by Samourai, so how do they know no information is kept?
< petertodd>
catlasshrugged: Samourai can't make that promise
< catlasshrugged>
warren: I refuse to stop including FN wallets, but I welcome suggestions on how to clarify the differences between them. They're not so different that they're like comparing apples and oranges, unless in this analogy I helped to create a Fruit Report.
< gmaxwell>
petertodd: not even bc.i could make that promise, though I'm looking and they don't... since their api goes through cloudflare.
< petertodd>
now, they correctly said they were using an API here, but that got repeated as SPV for sure
< catlasshrugged>
thanks. that's too bad that they weren't clear about their network topology.
< petertodd>
catlasshrugged: to be clear, I have some symapthy for Samorai here, but again, that sympathy is based on them not being used for antyhing but alpah testing
< catlasshrugged>
do you know for a fact that Samourai doesn't have a relationship with bc.i?
< aknix>
catlasshrugged, This what i mean your defensive instead of taking the criticism or even being critical in return, instead your defensive as if... IDK i had the impression you were very honest to others and also true to yourself. I dont mean to speak outside of techincals again, i just honestly think you need to approach this chat with a bit more of an open mind. I hope I don't sound like a dick or like im insulting you. Just trying to inform you.
< petertodd>
catlasshrugged: until told otherwise, I'm not going to assume they do
< catlasshrugged>
aknix: can you remind me about your expertise in bitcoin privacy engineering?
< catlasshrugged>
petertodd: it appears that you're going to assume they don't.
< aknix>
catlasshrugged, Sure 6 years experience
< aknix>
;)
< catlasshrugged>
aknix: go on...
< gmaxwell>
catlasshrugged: so far, not a single suggestion of things to improve in core has come out of this discussion (except perhaps coinjoin suppport; which I brought up, and noted that we don't have it largely today because it's provided externally and there isn't a really decenteralized version of it yet)
< catlasshrugged>
what bitcoin privacy engineering did you do during those 6 years?
< warren>
catlasshrugged: additionally, it might be wise for the authors of the report to disclose potential conflicts of interest
< catlasshrugged>
warren: go on?
< aknix>
catlasshrugged, email me i will send you my resume, Its pretty verbose
< petertodd>
catlasshrugged: so again, we're still back to the point where it appears that Samourai should not have been included in this review
< aknix>
or dm on twitter
< petertodd>
catlasshrugged: equally, not leaking this data at all to third parties is obviously highly valuable
< catlasshrugged>
it objectively should not have been included, or you would prefer that it wasn't included?
< randy-waterhouse>
catlasshrugged: I notice that arguably the best actual SPV wallet out there mSIGNA was not included
< catlasshrugged>
randy-waterhouse: I've never actually met someone who used mSIGNA
< pigeons>
is that criteria included on the guidelines page?
< catlasshrugged>
between the first and second report, we went with the wallets that had the highest demand
< randy-waterhouse>
catlasshrugged: that's hor private they are :)
< aknix>
catlasshrugged, I have documented proof of being involved in btc since mid 2010
< aknix>
;)
< catlasshrugged>
the only request for mSIGNA that I received was from its CEO
< catlasshrugged>
randy-waterhouse: lol
< aknix>
at a techincal level
< warren>
catlasshrugged: The technical experts here are surprised by your disregard for address ownership that is absolute (like in the Samurai wallet case) as being unimportant to your threat model, meanwhile you say you work for the service which is queried in that example.
< petertodd>
warren: +1
< aknix>
warren, +1
< catlasshrugged>
address ownership?
< petertodd>
catlasshrugged: queries to API services like bc.i, which leak info on who owns what addresses
< catlasshrugged>
hey warren
< catlasshrugged>
are you suggesting that bc.i stood to gain from this report?
< petertodd>
catlasshrugged: e.g., if I startup Samourai wallet, it'll query multiple addresses, which even through Tor links those addresses together
< catlasshrugged>
yup, just like most wallets do.
< petertodd>
catlasshrugged: you should make it clear to readers that you work for bc.i, given they may ask that question
< petertodd>
catlasshrugged: right, which is a huge privacy problem - the exact one coinjoin is meant to avoid. BTC Core completely avoids it
< warren>
I don't have reasons for or against. That doesn't remove the wisdom of disclosures though.
< catlasshrugged>
man, I gotta say, that's just really annoying feedback to get.
< gmaxwell>
I don't think it's fair feedback in any case.
< 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
< gmaxwell>
Kind of crappy that the guy that works for the centeralized API provider doesn't see centeralized APIs as a smoking hot privacy issue and all the rest of us do though. :(
< 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
< gmaxwell>
but that doesn't mean that there is any actual conflict of interest.
< petertodd>
catlasshrugged: it's also important if you do take that risk that you know who you are trusting with that data - e.g. in electrum, it's pretty clear which servers you are using. Samourai didn't give users that information.
< petertodd>
catlasshrugged: that's covered by your blockchain analysis, analysis. network analysis can be combined with that information in anti-privacy ways
< catlasshrugged>
I am not going to repeat this point again tonight: There was an opportunity for everyone to participate in the process deciding how things were weighted. You decided not to. If you would like to see changes, I am welcoming you to argue for them.
< catlasshrugged>
I don't find repeated claims about the importance of full nodes vs not full nodes helpful without evidence.
< petertodd>
catlasshrugged: well, that's fine, but I'd rather see the report fixed rather than us have to argue in public that the report is misleading
< catlasshrugged>
er, whose servers are you trusting if you use Electrum?
< catlasshrugged>
maybe bc.i runs all of the electrum servers
< petertodd>
catlasshrugged: yes, which is made very clear in the Electrum UI, and it's easy to get information on who runs those servers
< aknix>
petertodd, +1 +1
< 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>
it's also really easy to find out which API samourai uses, too
< petertodd>
catlasshrugged: similar to how Tor makes it easy for users to get information on who runs the Tor servers they are trusting, and in turn, who signs the Tor consensus they are trusting
< catlasshrugged>
lol at "reverse engineering" and "expose"
< petertodd>
catlasshrugged: could you explain how you'd find that out?
< gmaxwell>
Yes, I think most people would agree that electrum has significantly worse privacy than bitcoin core due to the server model.
< catlasshrugged>
yes, point your android device at a web proxy and look at what domains pop up.
< petertodd>
catlasshrugged: especially as an average user? remember that the Samourai website doesn't say it uses an API
< catlasshrugged>
the average user is also not looking up who owns their Electrum server
< petertodd>
catlasshrugged: maybe they won't, but they definitely know they are trusting one, it's made absolutely clear in the UI. Same as darkwallet
< * Luke-Jr>
notes that trusting anonymous/random third parties is actually worse than trusting easily identified third parties
< warren>
catlasshrugged: I personally don't feel great about helping a project like yours when your arguments in response to technical feedback appeal to emotion. When it comes to security or privacy it should be evaluated only on objective criteria. Your feelings should play no part in this. I'm sorry if this seems difficult, it's just the truth when it comes to technical issues.
< petertodd>
Luke-Jr: agreed, but not knowing you're trusting third parties is even worse
< Luke-Jr>
yes, no doubt
< petertodd>
Luke-Jr: informed consent!
< 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)
< catlasshrugged>
^
< aknix>
Yeah i think I have to withdraw my pledge to help out with OBPP
< gmaxwell>
er electrum not armory! :P
< molz>
aknix: haha
< petertodd>
gmaxwell: yeah, I've had discussions with the Electrum authors on this point, and they're totally clear about their privacy model, and want to improve it with techniques like prefix filters (maybe implemented now? haven't checked recently)
< 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.
< aknix>
catlasshrugged, Your arguing this samurai wallet like its an estranged lover
< petertodd>
catlasshrugged: they did reverse engineer it, but they're not bragging about that
< aknix>
their*
< petertodd>
gmaxwell: seems reasonable
< aknix>
catlasshrugged, Have you used a disassembler?
< aknix>
You were laughing at reverse engineering it so just curious...
< petertodd>
alright, going to do some work, bbl
< gmaxwell>
aknix: I think the comment there was just "reverse engineering" was more than was required-- though not clear, without looking at the rest of the software it might have been hard to tell if it was sending private info vs just using it as a third party reference for the best blockchain tip, or something minimially privacy harming.
< pigeons>
luckily, he has the source
< warren>
catlasshrugged: Another dimension to analyze is how well each wallet discloses their own risks
< gmaxwell>
Luke-Jr: how the heck do I get lrelease on gentoo?
< catlasshrugged>
warren: I like that idea
< warren>
ok great
< catlasshrugged>
do you have any suggestions about how one could measure level of disclosure without it being terribly subjective?
< gmaxwell>
warren: why not go work on improving Bitcoin Core's privacy documentation? :) it's scattered in many places.
< Luke-Jr>
gmaxwell: for Qt4, it's part of dev-qt/qtcore; for Qt5, dev-qt/linguist-tools
< aknix>
gmaxwell, Yeah simple interface monitoring would have caught this
< aknix>
And thanks that does make more sense in context
< pigeons>
catlasshrugged: actually say "are addreseses sent to 3rd parties? Y/N? is this disclosed? Y/N
< catlasshrugged>
disclosed where and how?
< pigeons>
anywhere, like their website or the TOS
< catlasshrugged>
I think we can all agree that disclosing somewhere is better than nowhere, but surely there are better and worse ways
< warren>
catlasshrugged: wallets describe themselves for marketing reasons, they should be truthful about how they operate and the potential risks so users can make informed decisions
< gmaxwell>
pigeons: well if its burried in some TOS is that meaningful?
< pigeons>
yes but any discloseure is better than reddit discloses it for you
< catlasshrugged>
warren: yes, I support that for sure
< catlasshrugged>
however, I think presentation matters a lot
< molz>
how about trash that report and rewrite it?
< gmaxwell>
bitcoin.org has disclosure requirements, IIRC.
< gmaxwell>
molz: be nice.
< catlasshrugged>
for example, if Samourai a few months ago put up a TOS on some corner of their website and wrote: "We use the world's most popular API, Blockchain.info, to look up balance information." I'm not sure that would helpfully communicate risk to the average user.
< pigeons>
yes you are correct, ok
< gmaxwell>
It would be better than not, but I agree that it doesn't pass the test.
< catlasshrugged>
molz: will try to make the next one better.
< gmaxwell>
The reason that it's better than not is because other people would be more likely to find that that no comment at all, and share the knoweldge.
< catlasshrugged>
I get that people are quite upset about Qt's treatment in the second report, but aside from its non-inclusion in the first report, I think you would find that there were many improvements between the first and second reports.
< gmaxwell>
One of the goals of disclosure is to reduce the risk that known-to-author privacy fails are not missed in review.
< pigeons>
its easier for most people to search a website than to reverse engineer a binary
< catlasshrugged>
probably true.
< catlasshrugged>
I would actually have an easier time looking at the behavior of the app, but that's unusual.
< gmaxwell>
engineering reality means that there will always be limitations, but one of the ways we can distinguish thing like intentional backdoors is by requiring that limitations be disclosed.
< catlasshrugged>
right
< gmaxwell>
even if people are going to look at the behavior they could still miss something critical.
< catlasshrugged>
any suggested standards for how these things ought to be disclosed?
< catlasshrugged>
Yes/No is a good start, just wondering if anyone has any ideas for improvements at present.
< catlasshrugged>
I guess I would also wonder what kinds of information they should disclose. Explaining that the user will use another service to lookup balance info is important to disclose, but what else?
< gmaxwell>
the gold standard would be to document their threat models and list their limitations under them.
< catlasshrugged>
(N.B. we would rely on wallet providers to answer this in our questionnaire, because we can't prove a negative ourselves without the wallet provider.)
< gmaxwell>
I think bitcoin.org wallet criteria did some disclosure requirement stuff, I'm looking for it now.
< catlasshrugged>
thanks
< gmaxwell>
bleh, not finding it now. will look more later.
< Luke-Jr>
(btw, for the record, I take back what I said earlier about not wanting to help improve the report, in light of the effort made on the ML that unfortunately apparently nobody noticed)
< catlasshrugged>
thanks
< 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
< aknix>
Hmm maybe there is an ISO like 17944:2002 that can be adopted. its pretty similar
< Luke-Jr>
O.o
< catlasshrugged>
just wondering, anyone present who is familiar with comments I or other OBPP folks have made concerning the scaling debates that colors their perception of OBPP?
< aknix>
i can still troll right?
< * aknix>
lulz
< Luke-Jr>
catlasshrugged: I am personally unaware of such comment.
< catlasshrugged>
ok
< randy-waterhouse>
that would not be core related and should go elsewhere anyway
< 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 don't know how much people will discount my word, but I want to state categorically that the report was not modified or shaped in any way to attack Core.
< catlasshrugged>
I want it to be an inclusive project that all experts can feel free to contribute to.
< gmaxwell>
It is the case that many of the names on your thanks are ones that stand out to me as people who have been antagonistic towards core in the past, and a few who I'd rather not work with.
< btcdrak>
shouldnt this conversation be in #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
< aknix>
btcdrak, +1
< gmaxwell>
But I think it's fair to say that the response you've seen here is just on the result, esp rating Samourai higher than QT offends many of our senses... beyond the normal expected levels of "priorities differ".
< btcdrak>
This channel is for Bitcoin Core development discussion. please move to #bitcoin.
< catlasshrugged>
@btcdrak: no problem
< molz>
gmaxwell: sorry.. but that report got on my nerves
< molz>
catlasshrugged: core wallet is adopted by another altcoin which i used a lot, it can use some improvements but it's totally my favorite
< 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
< 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.
< GitHub142>
bitcoin/0.12 35af157 Wladimir J. van der Laan: doc: Clean out release notes...
< MarcoFalke>
wumpus, I think 7607 needs backport to .11 and .12 as well
< MarcoFalke>
Do you prefer a pull or just do it directly?
< btcdrak>
if we have to change these we should also take the opportunity to change the fallback URL as well since it's until the curl change,it's already broken
< wumpus>
btcdrak: the redirect works fine IMO, dev.bitcoincore.org is a temporary solution
< wumpus>
MarcoFalke: backporting a 0.10 pull is confusing me, is this in master already?
< MarcoFalke>
jup
< MarcoFalke>
I linked to the backport, so it's easier which commits I mean
< MarcoFalke>
(it was 3 separate pulls)
< wumpus>
I'll just cherry-pick to the other branches then
< btcdrak>
wumpus: the redirects are very awkward creating tight coupling that is more liable to break someday. This would make a nice transition without breaking anything. At the end of the day, there will always be a URL, better if it's a separate subdomain that's also being used for something else (website)
< wumpus>
btcdrak: dev.bitcoin.org may go away any time
< btcdrak>
you mean the hosting server?
< wumpus>
yes
< btcdrak>
then what would be used as the fallback?
< wumpus>
I don't have commitment that it will stay up, or anyone will pay for the hosting, etc
< btcdrak>
dev.bitcoincore.org can always be pointed at any server, it's just a matter of changing DNS records.
< wumpus>
so I prefer ahving the redirects so we can move the fallbacks anywhere we want later on without any source change
< wumpus>
otherwise you're just moving the problem, you'd have to have a faux dev.bitcoincore.org with redirects to the actual location
< btcdrak>
right now, it's broken anyway until the wget is changed to curl, so it;s the perfect time to change the name. It isnt fixed to the server, it's just a dns record.
< btcdrak>
I'm already using another server to do the redirects..
< wumpus>
it's not broken due to the bitcoincore.org though
< wumpus>
the reason to move to curl is some other certificate failure
< btcdrak>
remember the fallback URL does not need to be https://
< btcdrak>
either way, you have to change it, but http:// is the right thing not https://
< wumpus>
which I didn't realy agree on either, but this was cheaper than fixing the certificate issue I guess... :p
< btcdrak>
since we dont need SSL, since verification is done by hashes
< wumpus>
but the fallback URL is not beign changes in anything here
< wumpus>
being changed*
< btcdrak>
either way, it's broken until a change is made. it's a hard fork :-P
< wumpus>
<btcdrak> then what would be used as the fallback? <- that's a good question, what is the cheapest way to host http-downloadable files?
< wumpus>
(with reasonable bandwidth, and limits)
< btcdrak>
I would guess a $60/yr VPS
< wumpus>
I don't want to babysit a VPS
< wumpus>
just host files
< btcdrak>
well there is also github large file hosting.
< wumpus>
anyhow these are three separate pulls, we can do a fallback location change later if that's necessary, there's notneed to correlate it to this
< btcdrak>
we could probably create a repository and just upload the sources using github's releases feature
< GitHub168>
bitcoin/0.12 ca8f160 Luke Dashjr: Bugfix: gitian: Add curl to packages (now needed for depends)...
< 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
< GitHub73>
bitcoin/0.11 7815cb6 Luke Dashjr: Bugfix: gitian: Add curl to packages (now needed for depends)...
< GitHub73>
bitcoin/0.11 a0e13f0 MarcoFalke: Fix url in .travis.yml...
< GitHub73>
bitcoin/0.11 77841d4 Luke Dashjr: Workaround Travis-side CI issues...
< wumpus>
I don't think the fallback logic is working properly, if boost really changed their tarball (or something else goes wrong), shouldn't it be trying to get it from the alternate URL?
< wumpus>
this was the same for libqrcode in the original problem, it was failing the download on ssl cert, but it didn't try the fallback
< arlisk>
opaa
< wumpus>
and if the fallback logic isn't working, the last thing we should be worrying about is where its files are hosted :p
< gmaxwell>
wumpus: well an old boost download we use?
< wumpus>
yes but as the download process detects it, doing it just for us is pointless
< wumpus>
tho would be kind of funny if someone invested a lot in an attack that they didn't even test locally :p
< Giszmo>
Looking into bip142 I wonder if there is a schema to optionally allow segWit that would be compatible with bip21? some bitcoin:1....?amount=12&segWitAllowed=true kind of downwards compatible style we could use in mycelium to leave it to the sender if he wants to use segwit?
< Luke-Jr>
Giszmo: uh, you can't use segwit like that
< gmaxwell>
Is it just me or has openssl missed their announced window?
< gmaxwell>
oh they haven't just nothing to their announce list. :(
< GitHub106>
[bitcoin] pstratem opened pull request #7629: Order CTxMemPool::queryHashes result by feerate including descendents. (master...2016-03-01-queryhashes) https://github.com/bitcoin/bitcoin/pull/7629
< phantomcircuit>
sdaftuar, do i have that correct that using the descendent modified fee index in reverse order will produce a stream of transactions with no orphans
< phantomcircuit>
?
< sdaftuar>
phantomcircuit: was just going to comment on the PR
< sdaftuar>
phantomcircuit: no, you need to walk the ancestors
< phantomcircuit>
descendants are the things which depend on the transaction right?
< sdaftuar>
this is slightly tricky to write efficiently actually
< phantomcircuit>
ie children not the parent
< sdaftuar>
yes that's right
< sdaftuar>
however the highest scoring thing might have ancestors with low fee
< sdaftuar>
there's no direct relationship between any of the feerate scores and a "no orphan" order
< phantomcircuit>
but for any given tree of transactions the parent transaction(s) are going to have a higher descendent fee total ... oh right feerate
< sdaftuar>
see my PR for a "CPFP" mining algorithm,
< sdaftuar>
i think i solve the exact problem you're trying to solve
< sdaftuar>
#7600
< sdaftuar>
is there a reason to prefer descendant fee rate over ancestor fee rate here?
< sdaftuar>
the latter is much closer to being in sync with what is valuable to miners
< sdaftuar>
(though at the low end, descendant fee rate score is more accurate for what gets evicted from the mempool)
< phantomcircuit>
sdaftuar, the descendant tracking essentially answer the question, if i removed this transaction what would the net effect be while ancestor tracking answers the question if i added this transaction and all of it's parents what would the net effect be
< phantomcircuit>
the descendant tracking can get you the same result as ancestor tracking if you start out with the full mempool and simulate reducing the mempool limit to the size of block you're trying to build
< phantomcircuit>
(i think)
< sdaftuar>
i don't disagree with what you wrote (well not sure i fully follow but what you wrote sounds right). if you're trying to communicate the most valuable transactions, ancestor feerate should capture that
< sdaftuar>
if you're trying to communicate the least valuable transactions, i think the worst descendant fee rate captures that
< phantomcircuit>
yeah that's what i was saying basically
< sdaftuar>
ok, so i'm still not sure exactly how you plan to use this but you might want to check out the SortForBlock code in #7600
< sdaftuar>
basically if you want to take a tx and communicate it in a no-orphan way
< sdaftuar>
you call CalculateMemPoolAncestors on it
< sdaftuar>
and then sort by nCountWithAncestors
< sdaftuar>
(this will be trickier if you are looking at descendant fee rate, in which case you presumably want to communicate the descendants of a tx)
< phantomcircuit>
sdaftuar, i think you're right that using ancestor feerate is better
< sdaftuar>
i have to run now, family time. back in a couple hours...