12016-03-01T00:00:27  * Luke-Jr wonders if it is better to correct people in cases like this, or let them build up a negative reputation.
   22016-03-01T00:03:39  <gmaxwell> Kristov's answers were a bit off but not terrible there.
   32016-03-01T00:04:27  <belcher> gmaxwell they had been in contact with me about joinmarket a few months ago, nothing much came from it
   42016-03-01T00:05:35  <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.
   52016-03-01T00:05:56  *** Guyver2 has quit IRC
   62016-03-01T00:06:19  <gmaxwell> Though I wonder about thins like this:
   72016-03-01T00:06:21  <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)?
   82016-03-01T00:06:24  <gmaxwell> No, it just downloads the whole blockchain and performs local queries."
   92016-03-01T00:06:42  <gmaxwell> ... like are we being negatively marked here for doing the _only_ thing known to provide strong privacy?
  102016-03-01T00:07:06  <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.
  112016-03-01T00:07:10  <gmaxwell>  " wut?
  122016-03-01T00:08:24  *** aknix has joined #bitcoin-core-dev
  132016-03-01T00:11:04  <Luke-Jr> lol
  142016-03-01T00:15:00  <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.
  152016-03-01T00:16:36  *** BitcoinErrorLog has joined #bitcoin-core-dev
  162016-03-01T00:17:33  <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.
  172016-03-01T00:18:16  <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)
  182016-03-01T00:28:51  <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?
  192016-03-01T00:29:17  <molz> we're going to have HD core wallet in v13, right?
  202016-03-01T00:29:26  <sipa> if someone implements it, maybe
  212016-03-01T00:29:57  <gmaxwell> molz: I really doubt it. Also, thats irrelevant to privacy.
  222016-03-01T00:36:35  <randy-waterhouse> gmaxwell: are you asking about these guys http://www.openbitcoinprivacyproject.org/ ?
  232016-03-01T00:37:33  <aknix> oh no whats pistov-kristov doing now?
  242016-03-01T00:38:34  <aknix> oic
  252016-03-01T00:41:43  <petertodd> Luke-Jr: "improving it seems likely to result in their organisation gaining credibility" <- +1
  262016-03-01T00:42:01  *** pigeons_ is now known as pigeons
  272016-03-01T00:44:25  <aknix> I have some kristov chat logs...
  282016-03-01T00:44:33  <aknix> pms
  292016-03-01T00:44:43  <petertodd> aknix: oh yeah?
  302016-03-01T00:44:46  <aknix> yes
  312016-03-01T00:44:53  <aknix> i was IRL friends with him
  322016-03-01T00:45:10  <petertodd> aknix: interesting
  332016-03-01T00:45:24  <petertodd> aknix: now granted, PM's are meant to be private, so keep that in mind
  342016-03-01T00:45:27  <Luke-Jr> past tense?
  352016-03-01T00:46:03  <aknix> yes, I have been open minded. Also tried to reinstate conversation to no avail.
  362016-03-01T00:46:18  <aknix> he has me blocked on twitter which i find childish as well
  372016-03-01T00:46:25  <Luke-Jr> i c
  382016-03-01T00:46:40  <petertodd> aknix: well, I blocked him on twitter because he kept on being uncivil, unlike others who disagreed with me
  392016-03-01T00:46:41  <aknix> so my logs are gone from slack :(
  402016-03-01T00:46:51  <aknix> they were slack PMs
  412016-03-01T00:46:52  <Luke-Jr> aknix: yeah, problem with using slack..
  422016-03-01T00:47:08  <aknix> He made statement that CT will never happen
  432016-03-01T00:47:15  <Luke-Jr> it may not
  442016-03-01T00:47:21  <Luke-Jr> I think sipa is working on improving it though
  452016-03-01T00:47:24  <aknix> Im aware
  462016-03-01T00:47:38  <sipa> i'm working on CT?
  472016-03-01T00:47:43  <Luke-Jr> it's quite possible CT may not be necessary too
  482016-03-01T00:47:43  <aknix> But he said it cant and argued that type of thing cant ever happen
  492016-03-01T00:47:52  <petertodd> aknix: what was his rational?
  502016-03-01T00:47:52  <aknix> I really really did no expect that from him
  512016-03-01T00:48:02  <Luke-Jr> sipa: no?
  522016-03-01T00:48:05  <aknix> He didnt elaborate, it got hot quick after that.
  532016-03-01T00:48:11  <sipa> i don't believe that CT in its current form is acceptable for Bitcoin, due to its huge transactions and processing requirement
  542016-03-01T00:48:13  <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
  552016-03-01T00:48:36  <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
  562016-03-01T00:48:58  <sipa> adam thought he had a way to make it smaller, but i'm not convinced
  572016-03-01T00:49:05  <Luke-Jr> ah
  582016-03-01T00:49:08  <sipa> in any case; just small constant factorsa
  592016-03-01T00:49:14  <aknix> Hahhaha, molz I had met him right around that time.
  602016-03-01T00:49:46  <Luke-Jr> anyway, hopefully Lightning will make CT unnecessary
  612016-03-01T00:49:55  <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
  622016-03-01T00:50:06  * aknix prays to blockchain jesus
  632016-03-01T00:50:28  <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
  642016-03-01T00:50:48  <sipa> petertodd: tragedy of the commons
  652016-03-01T00:50:52  <aknix> petertodd, I said the same thing in slack today
  662016-03-01T00:50:55  <petertodd> sipa: that's true too
  672016-03-01T00:51:12  <petertodd> sipa: though with bc.i claiming to have 50% of all txs, we have a tragedy of the commons in other ways
  682016-03-01T00:52:26  <belcher> users do get a personal benefit from privacy, otherwise they wouldnt pay for mixers and coinjoins
  692016-03-01T00:52:50  <petertodd> belcher: yup, though their k-anonymity sets aren't as big as they could be
  702016-03-01T00:53:03  <sipa> belcher: for mixers to be useful, people who do not have anything to hide need to use them too
  712016-03-01T00:53:26  <petertodd> sipa: well, keep in mind that if you and I have different adversaries, a mixer can still be useful
  722016-03-01T00:53:38  <Luke-Jr> sipa: belcher's Joinmarket seems to incentivise them to, by giving them the fees
  732016-03-01T00:53:59  <belcher> to clarify, it incentives people who have nothing to hide to take part
  742016-03-01T00:53:59  <sipa> petertodd: fair enough
  752016-03-01T00:54:12  <petertodd> Luke-Jr: I assume Joinmarket is run by the FBI and act accordingly :) fortunately my adversaries are probably not the FBI!
  762016-03-01T00:54:37  <molz> lol
  772016-03-01T00:54:45  <petertodd> I use joinmarket all the time
  782016-03-01T00:54:55  * aknix hehheheehe bitcoin so hawt righ naow
  792016-03-01T00:55:03  <belcher> hopefully the FBI and CCP are not sharing information, my antics are safe in that case
  802016-03-01T00:55:38  <petertodd> belcher: hopefully your adversaries don't include Santa Claus, as he knows who is naughty or nice
  812016-03-01T00:55:43  *** frankenmint has quit IRC
  822016-03-01T00:57:09  <aknix> oh yay i found the kristove logs
  832016-03-01T00:57:13  <aknix> I did SS it
  842016-03-01T00:57:26  <petertodd> aknix: SS?
  852016-03-01T00:57:30  <aknix> screenshot
  862016-03-01T00:57:34  <petertodd> aknix: ah
  872016-03-01T00:57:40  *** rgrant has joined #bitcoin-core-dev
  882016-03-01T00:57:44  <sipa> this is probably not the right place for discussion that
  892016-03-01T00:57:49  <petertodd> sipa: +1
  902016-03-01T01:00:22  <aknix> Sorry just dont want to see OBPP used for populist agenda
  912016-03-01T01:00:53  <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.
  922016-03-01T01:01:01  *** catlasshrugged has joined #bitcoin-core-dev
  932016-03-01T01:01:06  <catlasshrugged> hello!
  942016-03-01T01:01:18  <aknix> Oh hey
  952016-03-01T01:01:23  <aknix> at long last
  962016-03-01T01:04:38  <catlasshrugged> kristov from obpp here
  972016-03-01T01:04:57  <catlasshrugged> someone mentioned people were discussing some concerns about our report here
  982016-03-01T01:06:09  <aknix> catlasshrugged, Thanks for pming me and clearing that up!
  992016-03-01T01:06:14  <gmaxwell> Hi, I also emailed you directly before the discussion here.
 1002016-03-01T01:06:44  <catlasshrugged> I saw that
 1012016-03-01T01:08:26  <catlasshrugged> just going to try to clear up a few points of confusion, either on my end or others'
 1022016-03-01T01:09:17  <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.
 1032016-03-01T01:09:53  <gmaxwell> Sweet.  -- FWIW, I think the whole idea of reviewing wallet privacy is a great one, even if I'm lost at your results.
 1042016-03-01T01:10:15  <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.
 1052016-03-01T01:10:51  <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.
 1062016-03-01T01:10:59  <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.
 1072016-03-01T01:12:07  <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.
 1082016-03-01T01:12:30  <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.
 1092016-03-01T01:13:03  <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.
 1102016-03-01T01:13:30  <catlasshrugged> the questionnaire is only half (or maybe less) of our criteria.
 1112016-03-01T01:13:52  <catlasshrugged> most of the data  was gathered by volunteers directly interacting with the wallets.
 1122016-03-01T01:14:19  <catlasshrugged> and answering TRUE/FALSE questions or counting # of clicks to perform certain actions according to the script that we prepared.
 1132016-03-01T01:14:28  <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?
 1142016-03-01T01:14:58  *** _alp_ has joined #bitcoin-core-dev
 1152016-03-01T01:15:04  <gmaxwell> many wallets you rated more highly for physical security are browser based and would have left identifying information in browser caches.
 1162016-03-01T01:15:08  <catlasshrugged> https://github.com/OpenBitcoinPrivacyProject/wallet-ratings/blob/master/report-02/threat%20model.wiki
 1172016-03-01T01:15:35  <catlasshrugged> scroll down to "physical adversary"
 1182016-03-01T01:16:33  <gmaxwell> ah this is useful at least.
 1192016-03-01T01:16:55  <catlasshrugged> We'll be revising our threat model soon for the next edition. Input extremely welcome!
 1202016-03-01T01:17:03  <catlasshrugged> I've been trying to solicit help for a long while now.
 1212016-03-01T01:17:26  <gmaxwell> I wasn't aware of this list-- I had seen your prior report.
 1222016-03-01T01:18:01  <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.
 1232016-03-01T01:18:03  <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.
 1242016-03-01T01:18:25  <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..
 1252016-03-01T01:19:29  <aknix> Also is providing a pseudo UI for a bitcoin wallet a good idea either?
 1262016-03-01T01:19:47  <aknix> idk some of this seems silly to me..
 1272016-03-01T01:19:52  <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
 1282016-03-01T01:20:03  <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.
 1292016-03-01T01:20:08  <catlasshrugged> some of them use bloom filters but those filters include effectively 0% of the blockchain, so they got a 0
 1302016-03-01T01:20:50  <catlasshrugged> kanzure: ...I don't know how to parse that statement.
 1312016-03-01T01:20:58  <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)
 1322016-03-01T01:21:00  *** Guest94923 has joined #bitcoin-core-dev
 1332016-03-01T01:21:33  <kanzure> catlasshrugged: i think the only relevant reply i can muster is "who is john galt?"
 1342016-03-01T01:21:54  *** Guest94923 is now known as [_smitty]
 1352016-03-01T01:21:58  <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.
 1362016-03-01T01:22:14  <catlasshrugged> alllllrighty
 1372016-03-01T01:22:28  <aknix> no need to do that anymore
 1382016-03-01T01:22:28  <gmaxwell> catlasshrugged: Ah, I follow your thinking now at least.
 1392016-03-01T01:22:39  <aknix> The .12 client syncs from scratch in only a few hours
 1402016-03-01T01:22:45  <gmaxwell> Yes, I should have responded that since 0.10 bootstraps are depricated.
 1412016-03-01T01:22:55  <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 :-)
 1422016-03-01T01:23:14  <catlasshrugged> Sorry, not sure why I said "my" ratings -- our ratings
 1432016-03-01T01:23:18  *** AaronvanW_ has joined #bitcoin-core-dev
 1442016-03-01T01:24:02  <catlasshrugged> "aknix: now granted, PM's are meant to be private, so keep that in mind" thanks petertodd :)
 1452016-03-01T01:24:04  <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...
 1462016-03-01T01:24:23  <aknix> catlasshrugged, I am watching you ;)
 1472016-03-01T01:24:29  <aknix> loljk
 1482016-03-01T01:24:51  <gmaxwell> I mean, you should be embarssed that your process resulted in rating this https://www.reddit.com/r/Bitcoin/comments/447s7c/samourai_is_the_most_private_and_anonymous/ over bitcoin core.
 1492016-03-01T01:24:59  <catlasshrugged> go on?
 1502016-03-01T01:25:11  <_alp_> lol samouri
 1512016-03-01T01:25:21  <aknix> ooooof
 1522016-03-01T01:25:28  <_alp_> but it supports BIP-PAYMENT-CODES!
 1532016-03-01T01:25:28  <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
 1542016-03-01T01:26:11  <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.
 1552016-03-01T01:26:37  <catlasshrugged> for the record, I do not appreciate being told that "I should be embarrassed." I don't deserve that.
 1562016-03-01T01:27:04  <gmaxwell> Sorry, let me retry that: I would be embarassed if it were me. I dunno about you.
 1572016-03-01T01:27:24  <catlasshrugged> that's not really less dickish...
 1582016-03-01T01:27:24  *** AaronvanW has quit IRC
 1592016-03-01T01:27:30  <catlasshrugged> the closed source state is in the threat model; they lost points for it.
 1602016-03-01T01:27:38  <gmaxwell> No, but it's honest.
 1612016-03-01T01:27:53  <catlasshrugged> Are you a practicer of "radical honesty" or something?
 1622016-03-01T01:28:05  <catlasshrugged> as I understand it, SW intend to open source in the future, but that's not relevant to their score this time around
 1632016-03-01T01:28:13  <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, ...
 1642016-03-01T01:28:27  * aknix would prefer being told the truth than anything else. I have always come to some bitcoin channel for that over the years ;)
 1652016-03-01T01:28:36  <pigeons> _alp_: i see a smiliar name on both the payment codes bip and the obpp
 1662016-03-01T01:29:00  <aknix> You should know this catlasshrugged, brutal honesty is always lurking in IRC
 1672016-03-01T01:29:10  <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.
 1682016-03-01T01:29:22  <catlasshrugged> source isn't closed to me :-)
 1692016-03-01T01:29:37  <pigeons> before the report you had the source?
 1702016-03-01T01:29:42  <aknix> not sure if better or worse
 1712016-03-01T01:29:56  <pigeons> before you rated them?
 1722016-03-01T01:30:00  <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
 1732016-03-01T01:30:39  <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.
 1742016-03-01T01:30:46  <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.
 1752016-03-01T01:31:03  <gmaxwell> catlasshrugged: thats not the only feedback you're getting here for sure.
 1762016-03-01T01:31:17  <catlasshrugged> we talked a couple weeks ago about full nodes
 1772016-03-01T01:31:24  <catlasshrugged> I think they are less important than you do
 1782016-03-01T01:31:28  <gmaxwell> catlasshrugged: all the more disappointing.
 1792016-03-01T01:31:52  <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
 1802016-03-01T01:32:48  <aknix> I think everyone is willing here, but you are really picking holes in areas that arent really realistic for most users.
 1812016-03-01T01:33:17  <aknix> granted it is a tough thing to do...
 1822016-03-01T01:33:32  <aknix> I would be willing to help revise guidelines for example.
 1832016-03-01T01:33:55  <catlasshrugged> we hold 100% open meetings and our mailing list is 100% open for participation
 1842016-03-01T01:34:08  <catlasshrugged> if you'd like to see any positive changes, this is really easy to do
 1852016-03-01T01:34:30  <catlasshrugged> ask anyone who has participated before, I haven't turned down a single person or contribution since we started the ratings project.
 1862016-03-01T01:35:37  <kanzure> then perhaps you should show them the logs from today in here
 1872016-03-01T01:35:46  <kanzure> it would save us time and be a generous olive branch
 1882016-03-01T01:37:14  <catlasshrugged> I will gladly post this log to our mailing list, though I am not sure what actionable feedback has been provided so far
 1892016-03-01T01:37:24  <gmaxwell> catlasshrugged: well I invested nearly an hour responding to your older questionare; I never saw it previously.  Time is obviously fairly limited.
 1902016-03-01T01:37:43  <gmaxwell> catlasshrugged: do you have a parallel wiki page with the actual scorings for those criteria?
 1912016-03-01T01:37:50  <kanzure> actional feedback like category and score and rating improvements, hmm not very actionable i guess
 1922016-03-01T01:38:02  <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"
 1932016-03-01T01:38:19  *** rgrant has left #bitcoin-core-dev
 1942016-03-01T01:39:00  <randy-waterhouse> actionable feedback into a nebulous, subjective process seems a bit pointless?
 1952016-03-01T01:39:08  <kanzure> there are many discussions about that
 1962016-03-01T01:39:42  <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
 1972016-03-01T01:39:48  <gmaxwell> e question the good faith involvement of everyone responsbile.
 1982016-03-01T01:39:51  <kanzure> randy-waterhouse: https://bitcoin.org/en/bitcoin-core/features/validation
 1992016-03-01T01:40:05  <kanzure> http://blog.sia.tech/2016/01/20/what-makes-bitcoin-special/
 2002016-03-01T01:40:09  <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
 2012016-03-01T01:40:11  <kanzure> http://bluematt.bitcoin.ninja/2015/01/14/decentralization/
 2022016-03-01T01:40:34  <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.
 2032016-03-01T01:40:58  <kanzure> https://www.reddit.com/r/bitcoinxt/comments/3vhn88/businesses_need_certainty_of_excess_capacity/cxo19r9
 2042016-03-01T01:41:00  <catlasshrugged> so... "private data" is pretty nebulous, speaking of nebulousness. there are different kinds of information
 2052016-03-01T01:41:29  <catlasshrugged> I would love to see some better PIR implementations!
 2062016-03-01T01:41:37  <gmaxwell> catlasshrugged: sure, but sending a list of the users addresses (or equivilently a HD master seed) home is not nebulus.
 2072016-03-01T01:41:38  <kanzure> catlasshrugged: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011671.html
 2082016-03-01T01:41:46  <catlasshrugged> ("better" compared to the not very successful bloom filter implementations to date)
 2092016-03-01T01:42:03  <kanzure> anyway, it should be obvious by now that "full nodes" aren't just a figment of gmaxwell's imagination
 2102016-03-01T01:42:11  <kanzure> if you need another pile of links just ask me i'll be happy to DoS you with links
 2112016-03-01T01:42:11  <gmaxwell> catlasshrugged: well bitcoin core has "PIR" in the naieve form: send everyone the whole database is PIR. :)
 2122016-03-01T01:42:56  <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.
 2132016-03-01T01:43:25  <kanzure> catlasshrugged: i think you should include disclaimers like "review by bitcoin core developers has said x about this rating scheme"
 2142016-03-01T01:43:25  <catlasshrugged> gmaxwell: yes :)
 2152016-03-01T01:43:36  <gmaxwell> kanzure: bleh
 2162016-03-01T01:43:39  *** proslogion has quit IRC
 2172016-03-01T01:43:41  <kanzure> and also you should send the logs to your group, i think it would be a useful disclosure for you to make
 2182016-03-01T01:44:03  <catlasshrugged> sure, I'll send the logs as soon as I wrap this up.
 2192016-03-01T01:44:08  <gmaxwell> catlasshrugged: what does ledger (for example) do for resistance to blockchain analysis that Bitcoin Core does not.
 2202016-03-01T01:44:09  <kanzure> gmaxwell: i don't have a better idea
 2212016-03-01T01:44:11  <gmaxwell> ?
 2222016-03-01T01:44:52  <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.
 2232016-03-01T01:44:57  <catlasshrugged> automatic selection of receiving addresses, HD wallet structure...
 2242016-03-01T01:45:32  <petertodd> catlasshrugged: maybe I missed something, but how are HD wallet's helping here?
 2252016-03-01T01:45:36  <gmaxwell> catlasshrugged: uh.. you know that it's externally undetectable to users if bitcoin core uses HD wallets; right?
 2262016-03-01T01:46:04  <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.
 2272016-03-01T01:46:14  <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).
 2282016-03-01T01:46:25  <catlasshrugged> An expert Bitcoin user can probably do everything and more with Bitcoin-Qt that he can do with Ledger.
 2292016-03-01T01:46:44  <gmaxwell> catlasshrugged: How is this useful for incentivizing users to not reuse addresses?
 2302016-03-01T01:47:24  <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.
 2312016-03-01T01:47:55  <catlasshrugged> gmaxwell: oops, you're right about the clicks -- Bitcoin-Qt got 0 clicks for that = full score
 2322016-03-01T01:48:02  <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.
 2332016-03-01T01:48:43  <catlasshrugged> it complicates the backup process
 2342016-03-01T01:49:08  <gmaxwell> catlasshrugged: users cannot escape that by reusing addresses in bitcoin core, due to change.
 2352016-03-01T01:49:12  <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...
 2362016-03-01T01:49:12  <catlasshrugged> I'm going to be writing some blog posts about the data set and hopefully highlighting strengths and weaknesses
 2372016-03-01T01:49:19  <gmaxwell> From a privacy perspective, I'm still not seeing your argument.
 2382016-03-01T01:49:21  <petertodd> catlasshrugged: yes, but that's not a privacy problem (and in some cases non-HD, 'bag of keys', wallets have better privacy)
 2392016-03-01T01:49:30  *** AaronvanW_ has quit IRC
 2402016-03-01T01:49:43  <_alp_> So I can't reuse addresses in electrum since its HD?  Strange, I do that all the time.
 2412016-03-01T01:49:48  <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
 2422016-03-01T01:49:56  <gmaxwell> E.g. if reusing addresses made backup easier I'd agree with you that points should be deducted there.
 2432016-03-01T01:50:12  <catlasshrugged> N.B. ***no one in this room is an average Bitcoin user.***
 2442016-03-01T01:50:14  <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
 2452016-03-01T01:50:31  *** gevs has quit IRC
 2462016-03-01T01:51:02  <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.
 2472016-03-01T01:51:05  <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
 2482016-03-01T01:51:11  <gmaxwell> ntal privacy flaw.
 2492016-03-01T01:51:13  <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
 2502016-03-01T01:51:35  <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)
 2512016-03-01T01:51:36  <aknix> Wow so there is a bunch of silly or unrealistic stuff in this list: https://github.com/OpenBitcoinPrivacyProject/wallet-ratings/blob/master/report-02/threat%20model.wiki
 2522016-03-01T01:51:38  <gmaxwell> er competent!
 2532016-03-01T01:51:43  <aknix> Deffinitely not for a regular wallet user
 2542016-03-01T01:51:50  <aknix> but you said otherwise?
 2552016-03-01T01:52:18  <pigeons> make like this https://www.eff.org/secure-messaging-scorecard
 2562016-03-01T01:52:20  <catlasshrugged> aknix: not all of them are weighted equally, see the weights.wiki doc for that
 2572016-03-01T01:52:21  <aknix> These rating criteria need refining
 2582016-03-01T01:52:35  <aknix> ahh ok that helps but a pseudo UI cmon
 2592016-03-01T01:53:00  <catlasshrugged> pigeons: what do you like about that one?
 2602016-03-01T01:53:19  <pigeons> it tells each thing being considered
 2612016-03-01T01:53:25  <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.
 2622016-03-01T01:54:06  <catlasshrugged> I'd be happy to send you a copy of the ratings for Bitcoin-Qt
 2632016-03-01T01:54:22  <catlasshrugged> last edition we posted them on GitHub, but no one noticed so I didn't bother this time aroun
 2642016-03-01T01:54:25  <catlasshrugged> d
 2652016-03-01T01:54:36  <pigeons> "pysical privacy" is much more nebulous than "sends addresses to third parties"
 2662016-03-01T01:54:42  <petertodd> catlasshrugged: I think you need to preserve raw data like that even if no-one seems to notice
 2672016-03-01T01:55:06  <petertodd> pigeons: yeah, once the attacker is standing next to you all bets are off anyway...
 2682016-03-01T01:55:08  <catlasshrugged> consider it "available upon request"
 2692016-03-01T01:55:27  <petertodd> pigeons: heck, I don't even put a pin on my trezor for that reason
 2702016-03-01T01:55:28  <aknix> hmm thats not very bitcoin like.
 2712016-03-01T01:55:28  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 2722016-03-01T01:55:33  <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)
 2732016-03-01T01:56:07  <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)
 2742016-03-01T01:56:36  *** frankenmint has joined #bitcoin-core-dev
 2752016-03-01T01:56:37  <catlasshrugged> gotcha
 2762016-03-01T01:56:53  <catlasshrugged> yeah, all wallets failed most of the criteria given that the top score was 50
 2772016-03-01T01:56:54  <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
 2782016-03-01T01:57:09  <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.
 2792016-03-01T01:57:12  <catlasshrugged> petertodd: that is absolutely what we did.
 2802016-03-01T01:57:23  <petertodd> catlasshrugged: did you do it in a way that's publicly reproducable?
 2812016-03-01T01:57:28  <catlasshrugged> I don't pretend that anyone would care about my opinion about a particular wallet
 2822016-03-01T01:57:54  <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.
 2832016-03-01T01:58:05  <catlasshrugged> petertodd: partially. we wrote down how much weight we assigned to various categories, but did not write down full English descriptions of why
 2842016-03-01T01:58:31  <petertodd> catlasshrugged: ok, so, publicly reproducable would be at minimum something like a tweet "the sha256 hash of our chosen weights is: xxx"
 2852016-03-01T01:58:36  <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.
 2862016-03-01T01:58:55  <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.
 2872016-03-01T01:58:56  <aknix> catlasshrugged, How can you not disclose the weights?
 2882016-03-01T01:58:56  <petertodd> gmaxwell: yeah, I'm very concerned about third-parties getting addresses myself
 2892016-03-01T01:59:03  <catlasshrugged> oh, I see. does anyone really think we modified our weights after the fact and are lying about it?
 2902016-03-01T01:59:15  <catlasshrugged> that is pretty uncharitable
 2912016-03-01T01:59:24  <gmaxwell> catlasshrugged: no no. but PT was suggesting a scheme that would prevent that, and I'm saying it's not a concern.
 2922016-03-01T01:59:28  <catlasshrugged> aknix: weights are in the weights.wiki file
 2932016-03-01T01:59:29  <gmaxwell> at least not right now.
 2942016-03-01T01:59:43  <aknix> catlasshrugged, Ahh thanks, i missed that
 2952016-03-01T01:59:49  <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.
 2962016-03-01T01:59:57  <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
 2972016-03-01T01:59:58  <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
 2982016-03-01T02:00:15  <catlasshrugged> fair enough. I'll consider that for next time
 2992016-03-01T02:00:21  <catlasshrugged> creating a github issue now...
 3002016-03-01T02:00:42  <aknix> catlasshrugged, Whoa cant we simplify this?
 3012016-03-01T02:00:47  <aknix> this is obtuse
 3022016-03-01T02:00:54  *** frankenmint has quit IRC
 3032016-03-01T02:01:11  <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
 3042016-03-01T02:01:58  <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.
 3052016-03-01T02:02:18  <petertodd> gmaxwell: agreed - they have a lot to overcome
 3062016-03-01T02:02:30  <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.
 3072016-03-01T02:02:34  <gmaxwell> the report is beautiful though, and the area is important for work.
 3082016-03-01T02:03:21  <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.
 3092016-03-01T02:03:52  <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
 3102016-03-01T02:04:01  <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.
 3112016-03-01T02:04:44  <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)
 3122016-03-01T02:04:47  <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
 3132016-03-01T02:05:09  <catlasshrugged> take-aways I am not looking to express: Ledger is better than Bitcoin-Qt; Bitcoin-Qt sucks!
 3142016-03-01T02:06:19  <gmaxwell> catlasshrugged: too bad, that isn't how the report presentation comes out.
 3152016-03-01T02:06:30  <gmaxwell> Esp with the ranked score on the first page. :)
 3162016-03-01T02:06:50  <gmaxwell> If you want that you should be counting the privacy fails instead, and enumerating the things they don't do.
 3172016-03-01T02:07:15  <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
 3182016-03-01T02:07:57  <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
 3192016-03-01T02:08:12  <catlasshrugged> what would that look like?
 3202016-03-01T02:08:28  *** Ylbam has quit IRC
 3212016-03-01T02:09:04  <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.
 3222016-03-01T02:09:04  <gmaxwell> I think my intuition is "Here is the list of the worst things wallets to wrong againt attacker X"
 3232016-03-01T02:09:12  <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
 3242016-03-01T02:09:24  <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.
 3252016-03-01T02:09:28  <catlasshrugged> how do I make that meaningful to the average Bitcoin user?
 3262016-03-01T02:09:48  <catlasshrugged> again, I'll remind you that #bitcoin-core-dev is not the primary target audience for these reports.
 3272016-03-01T02:09:54  <gmaxwell> catlasshrugged: if your message is that they all suck than your audience isn't an actual bitcoin user, it's the industry.
 3282016-03-01T02:09:55  <petertodd> catlasshrugged: seriously: get some graphics/storyboards done illustrating what those attackers can do and who they might be
 3292016-03-01T02:10:13  <petertodd> gmaxwell: +1
 3302016-03-01T02:10:23  <catlasshrugged> the industry generally does not give a flying fuck about my concerns ;-)
 3312016-03-01T02:10:26  <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.
 3322016-03-01T02:10:44  <gmaxwell> I'm not saying you _intend_ to say that, but thats what the report says to joe reader.
 3332016-03-01T02:10:45  <petertodd> catlasshrugged: journalists can help fix that
 3342016-03-01T02:10:49  <catlasshrugged> this is why Consumer Reports doesn't write letters of concern to the makers of products
 3352016-03-01T02:11:06  <petertodd> catlasshrugged: consumer reports deals in an industry where most people are doing things basically right
 3362016-03-01T02:11:37  <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 ;)
 3372016-03-01T02:11:42  <catlasshrugged> petertodd: I'm not clear on how that is relevant
 3382016-03-01T02:12:17  <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.
 3392016-03-01T02:13:18  <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
 3402016-03-01T02:13:20  <gmaxwell> catlasshrugged: How do you have access to that wallet's source code?
 3412016-03-01T02:13:38  <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
 3422016-03-01T02:14:01  <catlasshrugged> gmaxwell: the developers have shared it with me individually in the past.
 3432016-03-01T02:14:22  <catlasshrugged> that doesn't mean anything as far as vouching goes, I don't think
 3442016-03-01T02:14:27  <petertodd> catlasshrugged: while I'm not saying you're biased, be warned that using that kind of evidence as a basis invites suspicion
 3452016-03-01T02:14:51  <gmaxwell> catlasshrugged: Ah. I was wondering if you were involved with its development.
 3462016-03-01T02:14:57  <catlasshrugged> petertodd: I find that wallet providers are extremely aware of what they're doing wrong and why they're not addressing it.
 3472016-03-01T02:15:07  <catlasshrugged> I am not.
 3482016-03-01T02:16:04  <catlasshrugged> The only project I work on did not score highly in the report
 3492016-03-01T02:16:33  <gmaxwell> ::nods::
 3502016-03-01T02:16:35  <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.
 3512016-03-01T02:16:53  * gmaxwell ::shakes:: head
 3522016-03-01T02:16:57  <gmaxwell> I don't know how you can say that.
 3532016-03-01T02:17:02  <aknix> we all know how voting works ;)
 3542016-03-01T02:17:10  <catlasshrugged> doing things this way tremendously increased the amount of work I had to put in, btw
 3552016-03-01T02:17:14  <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 :)
 3562016-03-01T02:18:06  <catlasshrugged> consumer reports has years of credibility built up that I don't
 3572016-03-01T02:18:21  <catlasshrugged> it's quite reasonable to trust their reports more than you trust ones that I work one with a small number of people.
 3582016-03-01T02:18:30  <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
 3592016-03-01T02:18:36  <gmaxwell> le.
 3602016-03-01T02:18:40  <petertodd> gmaxwell: +1
 3612016-03-01T02:19:37  <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.
 3622016-03-01T02:19:38  <aknix> gmaxwell, +1
 3632016-03-01T02:20:02  <catlasshrugged> you don't work there, so I can see why it wouldn't be boring to you.
 3642016-03-01T02:20:31  <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.
 3652016-03-01T02:20:39  <catlasshrugged> example?
 3662016-03-01T02:20:56  <aknix> Sheesh
 3672016-03-01T02:21:09  <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.
 3682016-03-01T02:21:34  <aknix> Thats very likely the case but its stilla secuirty hole
 3692016-03-01T02:21:47  <catlasshrugged> it's definitely sub-optimal.
 3702016-03-01T02:21:47  <gmaxwell> catlasshrugged: e.g. https://bitcointalk.org/index.php?topic=131608.0
 3712016-03-01T02:21:59  <catlasshrugged> sometimes when you are a company that has $0 in funding, you have to bootstrap some shit.
 3722016-03-01T02:22:10  <gmaxwell> catlasshrugged: it also can be stored by cloudflare, even if it isn't being stored by bc.i.
 3732016-03-01T02:22:21  <aknix> "bootstrap" in that context sounds like magical numbers argument to me
 3742016-03-01T02:22:29  <gmaxwell> catlasshrugged: I wouldn't find it much better if it were their own server instead of bc.i.
 3752016-03-01T02:22:51  <gmaxwell> (if thats any consolation)
 3762016-03-01T02:22:52  <aknix> yeah i dont think anyone would really
 3772016-03-01T02:22:55  <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.
 3782016-03-01T02:23:08  <aknix> at least people in this room i guess
 3792016-03-01T02:23:24  <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?
 3802016-03-01T02:23:38  <catlasshrugged> so the majority of your problem with samourai wallet vs qt is client-server vs fullnode, which we talked about earlier.
 3812016-03-01T02:23:40  <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.
 3822016-03-01T02:24:02  <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)
 3832016-03-01T02:24:08  <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.
 3842016-03-01T02:24:18  <gmaxwell> catlasshrugged: what is the most important?
 3852016-03-01T02:24:40  <gmaxwell> Not reusing addresses?  Bitcoin core does as much as is possible there short of actually forbidding the users from doing it.
 3862016-03-01T02:24:57  <catlasshrugged> I think resistance to blockchain analysis is roughly 2x more important than network-level analysis based on speaking with many people in analytics.
 3872016-03-01T02:25:11  <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)
 3882016-03-01T02:25:37  <catlasshrugged> yeah, coinjoin capability is heavily weighted in our scoring IIRC
 3892016-03-01T02:25:42  <catlasshrugged> and yes, almost no one is currently doing it
 3902016-03-01T02:25:53  <catlasshrugged> I hope by the next report, JoinMarket's GUI will be ready to go
 3912016-03-01T02:25:58  <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?
 3922016-03-01T02:26:06  <catlasshrugged> and maybe we will just rate Qt+JoinMarket GUI rather than Qt by itself.
 3932016-03-01T02:26:11  <gmaxwell> er blockchain analytics rather.
 3942016-03-01T02:26:44  <catlasshrugged> I'll send you a list of things that one or a couple wallets got higher marks for
 3952016-03-01T02:26:52  <catlasshrugged> it will just take some time to put together.
 3962016-03-01T02:27:08  <gmaxwell> I would be really thankful for that.
 3972016-03-01T02:27:17  <catlasshrugged> oh, you asked about network analytics
 3982016-03-01T02:27:32  <gmaxwell> I ment blockchain.
 3992016-03-01T02:27:46  <catlasshrugged> I would not be surprised if Qt received the highest marks out of all wallets with regards to network stuff
 4002016-03-01T02:27:50  <catlasshrugged> ah, ok
 4012016-03-01T02:29:28  <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.
 4022016-03-01T02:29:30  <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
 4032016-03-01T02:29:36  <gmaxwell> y; or arguably 'stealth' addresses, but I can also argue that stealth addresses are of little value in the current climate today)
 4042016-03-01T02:30:36  <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.
 4052016-03-01T02:30:52  <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
 4062016-03-01T02:31:08  <gmaxwell> I think you do _devistating_ harm to the bitcoin ecosystem when you present privacy disaster personal data phone-homing lite wallets as _superior_.
 4072016-03-01T02:31:39  <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.
 4082016-03-01T02:31:45  <pigeons> catlasshrugged: i didnt ask about the "average bitcoin user" I asked about "new users seeking privacy with privacy needs"
 4092016-03-01T02:32:11  <catlasshrugged> pigeons: you're right, sorry. I didn't fully read your question when I went back to look at it.
 4102016-03-01T02:32:14  <gmaxwell> devastating*
 4112016-03-01T02:33:32  <catlasshrugged> gmaxwell: ok.
 4122016-03-01T02:34:22  *** p15 has quit IRC
 4132016-03-01T02:35:52  <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.
 4142016-03-01T02:36:23  <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. :)
 4152016-03-01T02:36:33  <aknix> How about we fix the weighting/section on physical adversarys to start ;)
 4162016-03-01T02:36:44  <catlasshrugged> sorry, what's wrong with it?
 4172016-03-01T02:36:57  <aknix> Its just unrealistic as all wallets will fail
 4182016-03-01T02:36:58  <pigeons> you rnk shoulder surfing a greater threat than address leakage
 4192016-03-01T02:37:08  <aknix> I mean cmon you recoomend a fake UI for a bitcoin wallet
 4202016-03-01T02:37:18  <aknix> what are you gonna do open tinder to use bitcoin?
 4212016-03-01T02:37:40  <aknix> this is not avergae user material
 4222016-03-01T02:37:52  <catlasshrugged> pigeons: nope, false. you're reading it wrong.
 4232016-03-01T02:38:16  <aknix> Other than that like i said before i thin k you are on the right track just weighting is goofy
 4242016-03-01T02:38:28  <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.
 4252016-03-01T02:38:55  <catlasshrugged> If you actually said something about HOW you think the weighting is goofy, I missed it.
 4262016-03-01T02:39:14  <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?
 4272016-03-01T02:39:19  <dirtynewshoes> catlasshrugged: Darkwallet in here at 4 is a bit confusing... I did not think it was at all really ready to be used.
 4282016-03-01T02:39:21  <aknix> Well if samourai was rated higher than qt should i bother?
 4292016-03-01T02:39:31  <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.
 4302016-03-01T02:40:04  <catlasshrugged> dirtynewshoes: it works, although it lost some points due to the fact that the coinjoin has little volume at the moment
 4312016-03-01T02:40:56  <dirtynewshoes> catlasshrugged: Would it be used by the average bitcoin user? (Stable enough?)
 4322016-03-01T02:41:37  <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.
 4332016-03-01T02:41:57  *** belcher has quit IRC
 4342016-03-01T02:42:00  <catlasshrugged> dirtynewshoes: when you download it, it comes with several warnings. I didn't actually have any significant issues with it.
 4352016-03-01T02:42:16  <catlasshrugged> aside from the fact that DW stealth addresses are not fully compatible with ArcBit stealth addresses
 4362016-03-01T02:42:21  <catlasshrugged> which is noted in the report.
 4372016-03-01T02:42:25  <petertodd> catlasshrugged: could you answer gmaxwell re: ledger vs core?
 4382016-03-01T02:42:33  <pigeons> coinjoin has more volume than samouri
 4392016-03-01T02:42:46  <aknix> petertodd, +1
 4402016-03-01T02:42:58  <pigeons> *joinmarket
 4412016-03-01T02:44:18  <catlasshrugged> not right now because I need to manually create the comparison
 4422016-03-01T02:44:35  <catlasshrugged> but I currently plan to send him the comparison. I would be happy to CC you, if you're interested.
 4432016-03-01T02:44:43  <petertodd> catlasshrugged: yes, please do
 4442016-03-01T02:44:53  <catlasshrugged> whats a good email address?
 4452016-03-01T02:44:56  <pigeons> catlasshrugged: what are ledger's blockchain analysis resistance features?
 4462016-03-01T02:44:58  <petertodd> catlasshrugged: pete@petertodd.org
 4472016-03-01T02:45:12  <catlasshrugged> ok
 4482016-03-01T02:45:22  <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?
 4492016-03-01T02:45:35  <catlasshrugged> nope, it doesn't
 4502016-03-01T02:45:38  <randy-waterhouse> an acknowledgements section might be appropriate?
 4512016-03-01T02:45:39  <catlasshrugged> expert users already know this
 4522016-03-01T02:45:55  <catlasshrugged> if you're not sure about this, please scroll up ;-)
 4532016-03-01T02:46:02  <gmaxwell> catlasshrugged: that doesn't make it okay to have a misleading report!
 4542016-03-01T02:46:24  <catlasshrugged> I don't think there's anything in the report that suggests that its primary audience is expert bitcoin users.
 4552016-03-01T02:46:44  <petertodd> catlasshrugged: you don't need to be an expert to run bitcoin core I'll note
 4562016-03-01T02:46:53  <catlasshrugged> there's no way to put out this report without pissing several people off about their favorite wallet(s).
 4572016-03-01T02:47:08  <aknix> I think its misleading in general because running QT is part of the secuirty model
 4582016-03-01T02:47:16  <petertodd> aknix: +1
 4592016-03-01T02:47:28  <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.
 4602016-03-01T02:47:29  <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
 4612016-03-01T02:47:36  <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
 4622016-03-01T02:47:55  <aknix> I understand that is a stretch but its relevant to newb
 4632016-03-01T02:47:57  <petertodd> sipa: Bitcoin Core is something non-experts can and do run mind you
 4642016-03-01T02:48:01  <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.
 4652016-03-01T02:48:12  <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?
 4662016-03-01T02:48:32  <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".
 4672016-03-01T02:48:55  <gmaxwell> (er totally busted due to X)
 4682016-03-01T02:48:56  <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.
 4692016-03-01T02:49:08  <catlasshrugged> bitcoin-qt is a wallet. I'm not going to exclude it.
 4702016-03-01T02:49:27  <sipa> catlasshrugged: then you should at least be able to give one aspect at which bitcoin-qt ranks lower than your #1
 4712016-03-01T02:49:38  <catlasshrugged> warren: as I mentioned before, I am completely underwhelmed by the "expose"
 4722016-03-01T02:50:02  <aknix> Wow, i am at a loss for words..
 4732016-03-01T02:50:14  <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".
 4742016-03-01T02:50:17  <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
 4752016-03-01T02:50:24  <aknix> warren +1
 4762016-03-01T02:50:58  <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
 4772016-03-01T02:50:59  <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
 4782016-03-01T02:51:11  <catlasshrugged> ok
 4792016-03-01T02:51:37  <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
 4802016-03-01T02:52:23  <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.
 4812016-03-01T02:52:31  <_alp_> I don't always alpha test, but when I do, I do on mainnet.
 4822016-03-01T02:52:42  <petertodd> catlasshrugged: equally, until samourai implements that _missing_ part of their wallet, we can't evaluate them
 4832016-03-01T02:52:52  <aknix> _alp_, :)
 4842016-03-01T02:53:20  <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.
 4852016-03-01T02:53:55  <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.
 4862016-03-01T02:53:56  <petertodd> catlasshrugged: if your threat model isn't covered by that expose, it's not a very good htreat model
 4872016-03-01T02:53:57  <warren> If you think that issue isn't important in your threat model, then your threat model is flawed.
 4882016-03-01T02:54:02  <catlasshrugged> sipa: what do you mean by "aspect"?
 4892016-03-01T02:54:08  <petertodd> hehe, three identical replies :)
 4902016-03-01T02:54:28  <catlasshrugged> bc.i does not log all user transactions and sell the results.
 4912016-03-01T02:54:31  <aknix> catlasshrugged, Man cmon I know you are smarter than this.
 4922016-03-01T02:54:42  <catlasshrugged> aknix: that is incredibly rude.
 4932016-03-01T02:54:47  <petertodd> catlasshrugged: what proof do you have of that?
 4942016-03-01T02:54:47  <pigeons> i am very suprised that anyone thinks that a user seeking any level of privacy would choose to reveal their addresses
 4952016-03-01T02:54:55  <gmaxwell> catlasshrugged: prove to me that it doesn't; moreover prove to me that it cannot?
 4962016-03-01T02:54:55  <aknix> Yeah well i am being honest
 4972016-03-01T02:55:18  <aknix> I also have vouched for you in the past
 4982016-03-01T02:55:26  <petertodd> catlasshrugged: indeed, why specifically do you think you have any way of knowing?
 4992016-03-01T02:55:36  <sipa> catlasshrugged: in what way is Bitcoin-Qt's privacy worse than Samurai's?
 5002016-03-01T02:55:38  <aknix> Im hurting myself by even commenting on this
 5012016-03-01T02:55:42  <catlasshrugged> just wondering guys, what do you hope to be the outcome of a bunch of you ganging up on me?
 5022016-03-01T02:55:46  <aknix> but its important
 5032016-03-01T02:56:05  <catlasshrugged> I thought we were making some traction on productive iterations before, but now :/
 5042016-03-01T02:56:07  <petertodd> catlasshrugged: would you mind answering the question?
 5052016-03-01T02:56:24  <petertodd> catlasshrugged: we're here to help you fix your report; that means we'll ask questions, not all of them easy to answer
 5062016-03-01T02:56:30  <petertodd> catlasshrugged: that's just how engineering reviews work
 5072016-03-01T02:56:44  <gmaxwell> catlasshrugged: sorry that it's turned a bit harsh.
 5082016-03-01T02:56:49  <aknix> catlasshrugged, Not trying to gang up, just trying to show you an other POV
 5092016-03-01T02:56:50  <sipa> catlasshrugged: I'm sorry if you feel ganged up; that is by no means my intention
 5102016-03-01T02:56:58  <aknix> I know that can be difficult to get.
 5112016-03-01T02:57:11  <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.
 5122016-03-01T02:57:25  <gmaxwell> I'll back off for now and give you some air. Sorry.
 5132016-03-01T02:57:36  <catlasshrugged> petertodd: I mean, I've done engineering reviews before, they are generally less unpleasant.
 5142016-03-01T02:58:00  *** sipa has left #bitcoin-core-dev
 5152016-03-01T02:58:23  <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.
 5162016-03-01T02:58:29  <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.
 5172016-03-01T02:58:32  <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
 5182016-03-01T02:58:39  <petertodd> catlasshrugged: easier in person for sure
 5192016-03-01T02:59:06  <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.
 5202016-03-01T02:59:45  <gmaxwell> catlasshrugged: I was responding to your question 'warren: please either explain how the reddit "expose" fits into our threat model'
 5212016-03-01T03:00:06  <catlasshrugged> concerning sipa's question, he can get some more insight into this once I send a comparison to gmax and petertodd
 5222016-03-01T03:00:45  <catlasshrugged> if you have suggestions about what it would look like, I welcome them. Currently I have absolutely no clue.
 5232016-03-01T03:01:05  <catlasshrugged> To re-iterate, the fact that balance lookups and transaction broadcasts are done through a server is considered in the threat model.
 5242016-03-01T03:01:12  <petertodd> catlasshrugged: so again, how do you know bc.i doesn't log queries?
 5252016-03-01T03:01:20  <catlasshrugged> I can't prove it.
 5262016-03-01T03:01:29  <petertodd> catlasshrugged: ok, so don't say it
 5272016-03-01T03:02:23  <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..."
 5282016-03-01T03:02:26  <petertodd> catlasshrugged: does bc.i even formally say they don't keep logs?
 5292016-03-01T03:02:37  <catlasshrugged> To the best of my knowledge, the threat model does include this possibility.
 5302016-03-01T03:02:51  <catlasshrugged> of course, it does not discriminate bc.i from any other provider
 5312016-03-01T03:03:07  <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.
 5322016-03-01T03:03:53  <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. :)
 5332016-03-01T03:03:54  <catlasshrugged> I don't think samourai ever claimed that they do not send traffic through bc.i
 5342016-03-01T03:04:09  <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
 5352016-03-01T03:04:11  <gmaxwell> they also don't claim to not send your private keys to Pirate40.
 5362016-03-01T03:04:19  <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.
 5372016-03-01T03:04:20  <petertodd> catlasshrugged: it certainly came as a surprise to many of their users
 5382016-03-01T03:04:39  <gmaxwell> At least for something claiming to be the most private it was rather shocking.
 5392016-03-01T03:04:55  <catlasshrugged> I'm not sure how to include "don't surprise people" in a threat model
 5402016-03-01T03:05:08  <gmaxwell> (and the thread on reddit seems to indicate an overwhelming majority of the commentin people agreed, for whatever thats worth)
 5412016-03-01T03:05:26  <petertodd> catlasshrugged: samourai was advertising itself as an SPV wallet, which implies to most people that there isn't a central server involved
 5422016-03-01T03:05:30  <catlasshrugged> I don't tend to look to reddit for my social cues
 5432016-03-01T03:05:48  <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.
 5442016-03-01T03:06:01  <catlasshrugged> I didn't know that, but I've never seen Samourai use the term "SPV" in their promotions
 5452016-03-01T03:06:23  <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
 5462016-03-01T03:06:41  <catlasshrugged> it's not a serious privacy leak
 5472016-03-01T03:06:42  <gmaxwell> "[–]SamouraiWallet 12 points 9 months ago*
 5482016-03-01T03:06:42  <gmaxwell> Samourai is an SPV mobile wallet that collects no information about you. "
 5492016-03-01T03:06:46  <catlasshrugged> it's sending transaction data to a server
 5502016-03-01T03:06:57  <warren> Do you at least agree that you should stop comparing apples to oranges?  (remove the full node wallets like Qt)
 5512016-03-01T03:06:58  <catlasshrugged> I don't particularly care whether you prefer the server they used
 5522016-03-01T03:07:06  <pigeons> without informing the user after leading the user to believe otherwise
 5532016-03-01T03:07:06  <petertodd> catlasshrugged: a server not controlled by Samourai, so how do they know no information is kept?
 5542016-03-01T03:07:29  <petertodd> catlasshrugged: Samourai can't make that promise
 5552016-03-01T03:08:00  <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.
 5562016-03-01T03:08:10  <petertodd> here's an example of Samourai claiming they are an SPV wallet: https://www.reddit.com/r/Bitcoin/comments/35bynz/samurai_wallet_some_interesting_privacy_features/cr32w75
 5572016-03-01T03:08:34  <gmaxwell> petertodd: not even bc.i could make that promise, though I'm looking and they don't... since their api goes through cloudflare.
 5582016-03-01T03:08:41  <petertodd> now, they correctly said they were using an API here, but that got repeated as SPV for sure
 5592016-03-01T03:08:51  <catlasshrugged> thanks. that's too bad that they weren't clear about their network topology.
 5602016-03-01T03:09:23  <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
 5612016-03-01T03:09:29  <catlasshrugged> do you know for a fact that Samourai doesn't have a relationship with bc.i?
 5622016-03-01T03:09:32  <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.
 5632016-03-01T03:10:01  <petertodd> catlasshrugged: until told otherwise, I'm not going to assume they do
 5642016-03-01T03:10:12  <catlasshrugged> aknix: can you remind me about your expertise in bitcoin privacy engineering?
 5652016-03-01T03:10:24  <catlasshrugged> petertodd: it appears that you're going to assume they don't.
 5662016-03-01T03:10:26  <aknix> catlasshrugged, Sure 6 years experience
 5672016-03-01T03:10:29  <aknix> ;)
 5682016-03-01T03:10:34  <catlasshrugged> aknix: go on...
 5692016-03-01T03:10:42  <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)
 5702016-03-01T03:10:45  <catlasshrugged> what bitcoin privacy engineering did you do during those 6 years?
 5712016-03-01T03:10:50  <warren> catlasshrugged: additionally, it might be wise for the authors of the report to disclose potential conflicts of interest
 5722016-03-01T03:10:54  *** wumpus has quit IRC
 5732016-03-01T03:11:02  <catlasshrugged> warren: go on?
 5742016-03-01T03:11:06  <aknix> catlasshrugged, email me i will send you my resume, Its pretty verbose
 5752016-03-01T03:11:11  <petertodd> catlasshrugged: so again, we're still back to the point where it appears that Samourai should not have been included in this review
 5762016-03-01T03:11:14  <aknix> or dm on twitter
 5772016-03-01T03:11:31  <petertodd> catlasshrugged: equally, not leaking this data at all to third parties is obviously highly valuable
 5782016-03-01T03:11:32  <catlasshrugged> it objectively should not have been included, or you would prefer that it wasn't included?
 5792016-03-01T03:11:32  <randy-waterhouse> catlasshrugged: I notice that arguably the best actual SPV wallet out there mSIGNA was not included
 5802016-03-01T03:11:48  <catlasshrugged> randy-waterhouse: I've never actually met someone who used mSIGNA
 5812016-03-01T03:11:57  *** wumpus has joined #bitcoin-core-dev
 5822016-03-01T03:12:11  <pigeons> is that criteria included on the guidelines page?
 5832016-03-01T03:12:12  <catlasshrugged> between the first and second report, we went with the wallets that had the highest demand
 5842016-03-01T03:12:16  <randy-waterhouse> catlasshrugged: that's hor private they are :)
 5852016-03-01T03:12:19  <aknix> catlasshrugged, I have documented proof of being involved in btc since mid 2010
 5862016-03-01T03:12:21  <aknix> ;)
 5872016-03-01T03:12:23  <catlasshrugged> the only request for mSIGNA that I received was from its CEO
 5882016-03-01T03:12:30  <catlasshrugged> randy-waterhouse: lol
 5892016-03-01T03:12:31  <aknix> at a techincal level
 5902016-03-01T03:12:43  <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.
 5912016-03-01T03:12:55  <petertodd> warren: +1
 5922016-03-01T03:13:00  <aknix> warren, +1
 5932016-03-01T03:13:02  <catlasshrugged> address ownership?
 5942016-03-01T03:13:34  <petertodd> catlasshrugged: queries to API services like bc.i, which leak info on who owns what addresses
 5952016-03-01T03:13:37  <catlasshrugged> hey warren
 5962016-03-01T03:13:51  <catlasshrugged> are you suggesting that bc.i stood to gain from this report?
 5972016-03-01T03:14:12  <petertodd> catlasshrugged: e.g., if I startup Samourai wallet, it'll query multiple addresses, which even through Tor links those addresses together
 5982016-03-01T03:14:29  <catlasshrugged> yup, just like most wallets do.
 5992016-03-01T03:14:32  <petertodd> catlasshrugged: you should make it clear to readers that you work for bc.i, given they may ask that question
 6002016-03-01T03:14:33  *** achow101 has quit IRC
 6012016-03-01T03:14:48  *** justanotheruser has quit IRC
 6022016-03-01T03:14:56  <petertodd> catlasshrugged: right, which is a huge privacy problem - the exact one coinjoin is meant to avoid. BTC Core completely avoids it
 6032016-03-01T03:15:02  <warren> I don't have reasons for or against.  That doesn't remove the wisdom of disclosures though.
 6042016-03-01T03:15:02  <catlasshrugged> man, I gotta say, that's just really annoying feedback to get.
 6052016-03-01T03:15:21  <gmaxwell> I don't think it's fair feedback in any case.
 6062016-03-01T03:15:38  <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
 6072016-03-01T03:16:03  <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. :(
 6082016-03-01T03:16:19  <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
 6092016-03-01T03:16:26  <gmaxwell> but that doesn't mean that there is any actual conflict of interest.
 6102016-03-01T03:16:53  <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.
 6112016-03-01T03:17:22  <petertodd> catlasshrugged: that's covered by your blockchain analysis, analysis. network analysis can be combined with that information in anti-privacy ways
 6122016-03-01T03:17:35  <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.
 6132016-03-01T03:17:50  <catlasshrugged> I don't find repeated claims about the importance of full nodes vs not full nodes helpful without evidence.
 6142016-03-01T03:18:05  <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
 6152016-03-01T03:18:08  *** justanotheruser has joined #bitcoin-core-dev
 6162016-03-01T03:18:21  <catlasshrugged> er, whose servers are you trusting if you use Electrum?
 6172016-03-01T03:18:37  <catlasshrugged> maybe bc.i runs all of the electrum servers
 6182016-03-01T03:18:46  <petertodd> catlasshrugged: yes, which is made very clear in the Electrum UI, and it's easy to get information on who runs those servers
 6192016-03-01T03:18:59  <aknix> petertodd, +1 +1
 6202016-03-01T03:19:04  <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.
 6212016-03-01T03:19:24  <catlasshrugged> it's also really easy to find out which API samourai uses, too
 6222016-03-01T03:19:32  <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
 6232016-03-01T03:19:32  <catlasshrugged> lol at "reverse engineering" and "expose"
 6242016-03-01T03:19:43  <petertodd> catlasshrugged: could you explain how you'd find that out?
 6252016-03-01T03:19:43  <gmaxwell> Yes, I think most people would agree that electrum has significantly worse privacy than bitcoin core due to the server model.
 6262016-03-01T03:19:59  <catlasshrugged> yes, point your android device at a web proxy and look at what domains pop up.
 6272016-03-01T03:20:05  <petertodd> catlasshrugged: especially as an average user? remember that the Samourai website doesn't say it uses an API
 6282016-03-01T03:20:23  <catlasshrugged> the average user is also not looking up who owns their Electrum server
 6292016-03-01T03:20:43  <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
 6302016-03-01T03:21:09  * Luke-Jr notes that trusting anonymous/random third parties is actually worse than trusting easily identified third parties
 6312016-03-01T03:21:25  <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.
 6322016-03-01T03:21:29  <petertodd> Luke-Jr: agreed, but not knowing you're trusting third parties is even worse
 6332016-03-01T03:21:37  <Luke-Jr> yes, no doubt
 6342016-03-01T03:21:46  <petertodd> Luke-Jr: informed consent!
 6352016-03-01T03:21:57  <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)
 6362016-03-01T03:22:11  <catlasshrugged> ^
 6372016-03-01T03:22:14  <aknix> Yeah i think I have to withdraw my pledge to help out with OBPP
 6382016-03-01T03:22:16  <gmaxwell> er electrum not armory! :P
 6392016-03-01T03:22:25  <molz> aknix: haha
 6402016-03-01T03:23:05  <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)
 6412016-03-01T03:23:19  <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.
 6422016-03-01T03:23:32  *** BCB has joined #bitcoin-core-dev
 6432016-03-01T03:23:44  <aknix> catlasshrugged, Your arguing this samurai wallet like its an estranged lover
 6442016-03-01T03:23:52  <petertodd> catlasshrugged: btw, I'll note that the 'expose' made it clear that it was visible via network queries in the first line: https://www.reddit.com/r/Bitcoin/comments/447s7c/samourai_is_the_most_private_and_anonymous/
 6452016-03-01T03:23:55  <aknix> Like electrum makes there model clear
 6462016-03-01T03:23:59  <aknix> samurai does not
 6472016-03-01T03:24:04  <aknix> pretty clear cut
 6482016-03-01T03:24:13  <petertodd> catlasshrugged: they did reverse engineer it, but they're not bragging about that
 6492016-03-01T03:24:14  <aknix> their*
 6502016-03-01T03:24:26  <petertodd> gmaxwell: seems reasonable
 6512016-03-01T03:24:33  <aknix> catlasshrugged, Have you used a disassembler?
 6522016-03-01T03:27:23  *** [_smitty] has quit IRC
 6532016-03-01T03:27:30  <aknix> You were laughing at reverse engineering it so just curious...
 6542016-03-01T03:27:56  <petertodd> alright, going to do some work, bbl
 6552016-03-01T03:28:33  *** BCB has quit IRC
 6562016-03-01T03:30:37  <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.
 6572016-03-01T03:31:31  <pigeons> luckily, he has the source
 6582016-03-01T03:32:33  <warren> catlasshrugged: Another dimension to analyze is how well each wallet discloses their own risks
 6592016-03-01T03:32:35  <gmaxwell> Luke-Jr: how the heck do I get lrelease on gentoo?
 6602016-03-01T03:33:03  <catlasshrugged> warren: I like that idea
 6612016-03-01T03:33:08  <warren> ok great
 6622016-03-01T03:33:30  <catlasshrugged> do you have any suggestions about how one could measure level of disclosure without it being terribly subjective?
 6632016-03-01T03:33:30  <gmaxwell> warren: why not go work on improving Bitcoin Core's privacy documentation? :) it's scattered in many places.
 6642016-03-01T03:33:53  <Luke-Jr> gmaxwell: for Qt4, it's part of dev-qt/qtcore; for Qt5, dev-qt/linguist-tools
 6652016-03-01T03:34:13  <aknix> gmaxwell, Yeah simple interface monitoring would have caught this
 6662016-03-01T03:34:28  <aknix> And thanks that does make more sense in context
 6672016-03-01T03:34:29  <pigeons> catlasshrugged: actually say "are addreseses sent to 3rd parties? Y/N? is this disclosed? Y/N
 6682016-03-01T03:34:52  <catlasshrugged> disclosed where and how?
 6692016-03-01T03:35:03  <pigeons> anywhere, like their website or the TOS
 6702016-03-01T03:35:31  <catlasshrugged> I think we can all agree that disclosing somewhere is better than nowhere, but surely there are better and worse ways
 6712016-03-01T03:35:36  <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
 6722016-03-01T03:35:40  <gmaxwell> pigeons: well if its burried in some TOS is that meaningful?
 6732016-03-01T03:35:49  <pigeons> yes but any discloseure is better than reddit discloses it for you
 6742016-03-01T03:36:00  <catlasshrugged> warren: yes, I support that for sure
 6752016-03-01T03:36:33  <catlasshrugged> however, I think presentation matters a lot
 6762016-03-01T03:36:41  <molz> how about trash that report and rewrite it?
 6772016-03-01T03:36:46  <gmaxwell> bitcoin.org has disclosure requirements, IIRC.
 6782016-03-01T03:36:49  <gmaxwell> molz: be nice.
 6792016-03-01T03:37:35  <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.
 6802016-03-01T03:37:45  <pigeons> yes you are correct, ok
 6812016-03-01T03:37:59  <gmaxwell> It would be better than not, but I agree that it doesn't pass the test.
 6822016-03-01T03:38:13  <catlasshrugged> molz: will try to make the next one better.
 6832016-03-01T03:38:19  <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.
 6842016-03-01T03:38:56  <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.
 6852016-03-01T03:39:01  <gmaxwell> One of the goals of disclosure is to reduce the risk that known-to-author privacy fails are not missed in review.
 6862016-03-01T03:39:03  <pigeons> its easier for most people to search a website than to reverse engineer a binary
 6872016-03-01T03:39:37  <catlasshrugged> probably true.
 6882016-03-01T03:39:57  <catlasshrugged> I would actually have an easier time looking at the behavior of the app, but that's unusual.
 6892016-03-01T03:40:23  <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.
 6902016-03-01T03:40:37  <catlasshrugged> right
 6912016-03-01T03:40:38  <gmaxwell> even if people are going to look at the behavior they could still miss something critical.
 6922016-03-01T03:40:47  <catlasshrugged> any suggested standards for how these things ought to be disclosed?
 6932016-03-01T03:41:01  <catlasshrugged> Yes/No is a good start, just wondering if anyone has any ideas for improvements at present.
 6942016-03-01T03:41:45  <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?
 6952016-03-01T03:42:17  <gmaxwell> the gold standard would be to document their threat models and list their limitations under them.
 6962016-03-01T03:42:29  <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.)
 6972016-03-01T03:42:36  <gmaxwell> I think bitcoin.org wallet criteria did some disclosure requirement stuff, I'm looking for it now.
 6982016-03-01T03:42:46  <catlasshrugged> thanks
 6992016-03-01T03:42:59  *** instagibbs has quit IRC
 7002016-03-01T03:44:53  *** wallet42 has quit IRC
 7012016-03-01T03:45:11  <gmaxwell> bleh, not finding it now. will look more later.
 7022016-03-01T03:47:19  <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)
 7032016-03-01T03:47:53  <catlasshrugged> thanks
 7042016-03-01T03:49:22  *** instagibbs has joined #bitcoin-core-dev
 7052016-03-01T03:50:14  <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
 7062016-03-01T03:52:03  <aknix> Hmm maybe there is an ISO like 17944:2002 that can be adopted. its pretty similar
 7072016-03-01T03:52:13  <Luke-Jr> O.o
 7082016-03-01T03:52:30  <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?
 7092016-03-01T03:52:40  <aknix> i can still troll right?
 7102016-03-01T03:53:25  * aknix lulz
 7112016-03-01T03:54:24  <Luke-Jr> catlasshrugged: I am personally unaware of such comment.
 7122016-03-01T03:54:32  <catlasshrugged> ok
 7132016-03-01T03:55:12  <randy-waterhouse> that would not be core related and should go elsewhere anyway
 7142016-03-01T03:55:52  <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.
 7152016-03-01T03:56:43  <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.
 7162016-03-01T03:57:29  <catlasshrugged> I want it to be an inclusive project that all experts can feel free to contribute to.
 7172016-03-01T03:58:12  <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.
 7182016-03-01T03:59:44  <btcdrak> shouldnt this conversation be in #bitcoin ?
 7192016-03-01T03:59:46  <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
 7202016-03-01T03:59:56  <aknix> btcdrak, +1
 7212016-03-01T03:59:57  <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".
 7222016-03-01T04:00:13  <btcdrak> This channel is for Bitcoin Core development discussion. please move to #bitcoin.
 7232016-03-01T04:00:27  <catlasshrugged> @btcdrak: no problem
 7242016-03-01T04:01:36  <molz> gmaxwell: sorry.. but that report got on my nerves
 7252016-03-01T04:02:30  <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
 7262016-03-01T04:19:39  *** Chris_Stewart_5 has quit IRC
 7272016-03-01T04:36:08  *** p15 has joined #bitcoin-core-dev
 7282016-03-01T05:22:03  *** baldur has quit IRC
 7292016-03-01T05:38:57  *** jtimon has quit IRC
 7302016-03-01T05:53:00  *** baldur has joined #bitcoin-core-dev
 7312016-03-01T06:21:51  *** baldur has quit IRC
 7322016-03-01T06:29:21  *** libertalis has quit IRC
 7332016-03-01T06:35:05  *** libertalis has joined #bitcoin-core-dev
 7342016-03-01T06:36:52  *** Cheeseo has quit IRC
 7352016-03-01T06:39:58  *** wallet42 has joined #bitcoin-core-dev
 7362016-03-01T06:54:22  *** catlasshrugged has quit IRC
 7372016-03-01T06:54:23  *** baldur has joined #bitcoin-core-dev
 7382016-03-01T06:55:16  *** Don_John has quit IRC
 7392016-03-01T06:57:29  <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
 7402016-03-01T06:57:54  <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.
 7412016-03-01T07:00:03  *** dermoth has quit IRC
 7422016-03-01T07:00:39  *** dermoth has joined #bitcoin-core-dev
 7432016-03-01T07:11:21  *** BashCo has quit IRC
 7442016-03-01T07:34:18  *** mesmer_ has joined #bitcoin-core-dev
 7452016-03-01T07:37:35  *** mesmer has quit IRC
 7462016-03-01T07:42:54  *** wallet421 has joined #bitcoin-core-dev
 7472016-03-01T07:47:00  *** wallet42 has quit IRC
 7482016-03-01T07:50:11  *** BashCo has joined #bitcoin-core-dev
 7492016-03-01T07:53:05  *** Thireus has quit IRC
 7502016-03-01T07:59:07  *** frankenmint has joined #bitcoin-core-dev
 7512016-03-01T08:00:56  <GitHub34> [bitcoin] jonasschnelli closed pull request #7560: [OSX] fix brew openssl detection (master...2016/02/osx_openssl) https://github.com/bitcoin/bitcoin/pull/7560
 7522016-03-01T08:04:32  *** frankenmint has quit IRC
 7532016-03-01T08:16:37  *** Ylbam has joined #bitcoin-core-dev
 7542016-03-01T08:31:23  *** cjcj has joined #bitcoin-core-dev
 7552016-03-01T08:32:55  *** slackircbridge has quit IRC
 7562016-03-01T08:33:09  *** slackircbridge has joined #bitcoin-core-dev
 7572016-03-01T08:36:41  *** Thireus has joined #bitcoin-core-dev
 7582016-03-01T08:44:29  *** AaronvanW_ has joined #bitcoin-core-dev
 7592016-03-01T09:04:27  *** rubensayshi has joined #bitcoin-core-dev
 7602016-03-01T09:15:17  *** paveljanik has quit IRC
 7612016-03-01T09:18:43  *** TZander has quit IRC
 7622016-03-01T09:40:17  *** ChillazZ has joined #bitcoin-core-dev
 7632016-03-01T09:40:41  *** ChillazZ is now known as Guest41724
 7642016-03-01T09:48:27  *** wallet421 has quit IRC
 7652016-03-01T09:49:39  *** jannes has joined #bitcoin-core-dev
 7662016-03-01T09:51:04  *** gevs has joined #bitcoin-core-dev
 7672016-03-01T09:52:24  *** wallet42 has joined #bitcoin-core-dev
 7682016-03-01T09:56:47  *** Guyver2 has joined #bitcoin-core-dev
 7692016-03-01T10:00:54  *** jouke_ has quit IRC
 7702016-03-01T10:00:56  *** frankenmint has joined #bitcoin-core-dev
 7712016-03-01T10:05:52  *** frankenmint has quit IRC
 7722016-03-01T10:19:38  *** Guyver2 has quit IRC
 7732016-03-01T10:21:33  *** proslogion has joined #bitcoin-core-dev
 7742016-03-01T10:39:31  *** randy-waterhouse has quit IRC
 7752016-03-01T10:47:31  *** cjcj has quit IRC
 7762016-03-01T10:53:04  *** proslogion has quit IRC
 7772016-03-01T11:03:17  *** frankenmint has joined #bitcoin-core-dev
 7782016-03-01T11:07:37  *** frankenmint has quit IRC
 7792016-03-01T11:15:53  *** cdecker has joined #bitcoin-core-dev
 7802016-03-01T11:18:01  *** BCBot has joined #bitcoin-core-dev
 7812016-03-01T11:18:10  *** wallet42 has quit IRC
 7822016-03-01T11:19:48  *** BCBot has quit IRC
 7832016-03-01T11:19:58  *** BCBot has joined #bitcoin-core-dev
 7842016-03-01T11:21:45  *** BCBot has quit IRC
 7852016-03-01T11:29:49  *** BCBot has joined #bitcoin-core-dev
 7862016-03-01T11:39:59  *** laurentmt has joined #bitcoin-core-dev
 7872016-03-01T11:42:33  *** laurentmt has quit IRC
 7882016-03-01T11:59:02  *** da2ce7 has quit IRC
 7892016-03-01T11:59:17  *** da2ce7 has joined #bitcoin-core-dev
 7902016-03-01T12:02:58  <GitHub148> [bitcoin] crowning- opened pull request #7624: [doc] Missing credit added (0.12...patch-2) https://github.com/bitcoin/bitcoin/pull/7624
 7912016-03-01T12:14:19  *** paveljanik has joined #bitcoin-core-dev
 7922016-03-01T12:14:19  *** paveljanik has joined #bitcoin-core-dev
 7932016-03-01T12:16:59  *** [Author] has joined #bitcoin-core-dev
 7942016-03-01T12:17:06  *** Guyver2 has joined #bitcoin-core-dev
 7952016-03-01T12:17:39  *** p15x has joined #bitcoin-core-dev
 7962016-03-01T12:29:23  *** jouke has joined #bitcoin-core-dev
 7972016-03-01T12:33:07  *** tr0nk has quit IRC
 7982016-03-01T12:36:54  *** gevs has quit IRC
 7992016-03-01T12:44:41  *** gevs has joined #bitcoin-core-dev
 8002016-03-01T12:47:12  *** [Author] has quit IRC
 8012016-03-01T12:47:13  <GitHub140> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/f5ecd0737130eed8daf9d76c5232dce7e40b7150
 8022016-03-01T12:47:13  <GitHub140> bitcoin/master f5ecd07 Wladimir J. van der Laan: doc: Add missing credit to 0.12.0 release notes...
 8032016-03-01T12:47:23  <GitHub104> [bitcoin] laanwj closed pull request #7624: [doc] Missing credit added (0.12...patch-2) https://github.com/bitcoin/bitcoin/pull/7624
 8042016-03-01T12:47:45  *** jtimon has joined #bitcoin-core-dev
 8052016-03-01T12:48:33  *** [Author] has joined #bitcoin-core-dev
 8062016-03-01T12:49:51  *** MarcoFalke has joined #bitcoin-core-dev
 8072016-03-01T12:51:51  *** p15 has quit IRC
 8082016-03-01T12:51:51  *** p15x has quit IRC
 8092016-03-01T12:52:33  <GitHub142> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/35af157641ddbf6090e86edff7533d45ee4fb990
 8102016-03-01T12:52:33  <GitHub142> bitcoin/0.12 35af157 Wladimir J. van der Laan: doc: Clean out release notes...
 8112016-03-01T12:55:12  *** [Author] has quit IRC
 8122016-03-01T12:58:39  *** [Author] has joined #bitcoin-core-dev
 8132016-03-01T13:04:02  *** frankenmint has joined #bitcoin-core-dev
 8142016-03-01T13:07:18  *** paveljanik has quit IRC
 8152016-03-01T13:08:19  *** frankenmint has quit IRC
 8162016-03-01T13:08:50  *** p15x has joined #bitcoin-core-dev
 8172016-03-01T13:12:02  *** zooko has joined #bitcoin-core-dev
 8182016-03-01T13:17:18  *** Giszmo has joined #bitcoin-core-dev
 8192016-03-01T13:17:51  *** p15x has quit IRC
 8202016-03-01T13:18:56  *** p15x has joined #bitcoin-core-dev
 8212016-03-01T13:29:45  *** fredrin has joined #bitcoin-core-dev
 8222016-03-01T13:30:39  *** laurentmt has joined #bitcoin-core-dev
 8232016-03-01T13:30:41  *** laurentmt has quit IRC
 8242016-03-01T13:33:50  *** dermoth_ has joined #bitcoin-core-dev
 8252016-03-01T13:36:03  *** dermoth has quit IRC
 8262016-03-01T13:36:04  *** zooko has quit IRC
 8272016-03-01T13:37:38  <MarcoFalke> wumpus, I think 7607 needs backport to .11 and .12 as well
 8282016-03-01T13:37:40  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 8292016-03-01T13:37:52  <MarcoFalke> Do you prefer a pull or just do it directly?
 8302016-03-01T13:39:41  <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
 8312016-03-01T13:39:53  <btcdrak> and link directly to http://dev.bitcoincore.org/
 8322016-03-01T13:41:08  <wumpus> btcdrak: the redirect works fine IMO, dev.bitcoincore.org is a temporary solution
 8332016-03-01T13:42:11  <wumpus> MarcoFalke: backporting a 0.10 pull is confusing me, is this in master already?
 8342016-03-01T13:42:21  <MarcoFalke> jup
 8352016-03-01T13:42:35  <MarcoFalke> I linked to the backport, so it's easier which commits I mean
 8362016-03-01T13:42:43  <MarcoFalke> (it was 3 separate pulls)
 8372016-03-01T13:43:07  <wumpus> I'll just cherry-pick to the other branches then
 8382016-03-01T13:43:25  <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)
 8392016-03-01T13:43:39  <wumpus> btcdrak: dev.bitcoin.org may go away any time
 8402016-03-01T13:43:55  <btcdrak> you mean the hosting server?
 8412016-03-01T13:43:57  <wumpus> yes
 8422016-03-01T13:44:09  <btcdrak> then what would be used as the fallback?
 8432016-03-01T13:44:11  <wumpus> I don't have commitment that it will stay up, or anyone will pay for the hosting, etc
 8442016-03-01T13:44:28  <btcdrak> dev.bitcoincore.org can always be pointed at any server, it's just a matter of changing DNS records.
 8452016-03-01T13:44:48  <wumpus> so I prefer ahving the redirects so we can move the fallbacks anywhere we want later on without any source change
 8462016-03-01T13:45:27  <wumpus> otherwise you're just moving the problem, you'd have to have a faux dev.bitcoincore.org with redirects to the actual location
 8472016-03-01T13:45:30  <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.
 8482016-03-01T13:46:09  <btcdrak> I'm already using another server to do the redirects..
 8492016-03-01T13:46:12  <wumpus> it's not broken due to the bitcoincore.org though
 8502016-03-01T13:46:21  <wumpus> the reason to move to curl is some other certificate failure
 8512016-03-01T13:46:41  <btcdrak> remember the fallback URL does not need to be https://
 8522016-03-01T13:46:56  <btcdrak> either way, you have to change it, but http:// is the right thing not https://
 8532016-03-01T13:46:58  <wumpus> which I didn't realy agree on either, but this was cheaper than fixing the certificate issue I guess... :p
 8542016-03-01T13:47:11  <btcdrak> http://dev fix is free
 8552016-03-01T13:47:40  <btcdrak> since we dont need SSL, since verification is done by hashes
 8562016-03-01T13:47:49  <wumpus> but the fallback URL is not beign changes in anything here
 8572016-03-01T13:47:54  <wumpus> being changed*
 8582016-03-01T13:48:45  <btcdrak> either way, it's broken until a change is made. it's a hard fork :-P
 8592016-03-01T13:49:06  <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?
 8602016-03-01T13:49:14  <wumpus> (with reasonable bandwidth, and limits)
 8612016-03-01T13:49:30  <btcdrak> I would guess a $60/yr VPS
 8622016-03-01T13:49:38  <wumpus> I don't want to babysit a VPS
 8632016-03-01T13:49:54  <wumpus> just host files
 8642016-03-01T13:49:55  <btcdrak> well there is also github large file hosting.
 8652016-03-01T13:51:15  <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
 8662016-03-01T13:51:20  <btcdrak> we could probably create a repository and just upload the sources using github's releases feature
 8672016-03-01T13:51:29  *** heath has joined #bitcoin-core-dev
 8682016-03-01T13:51:56  <wumpus> nice
 8692016-03-01T13:51:57  <btcdrak> for example: https://github.com/btcdrak/bitcoin/releases
 8702016-03-01T13:52:17  <btcdrak> that would be my preferred option. the URLs are predictable too iirc
 8712016-03-01T13:52:26  *** p15x has quit IRC
 8722016-03-01T13:52:45  *** p15x has joined #bitcoin-core-dev
 8732016-03-01T13:53:19  <btcdrak> let me experiment in a repository and get back to you
 8742016-03-01T13:53:21  <wumpus> in any case, if we have a redirect then we can change them to point at any location
 8752016-03-01T13:53:29  <Luke-Jr> fwiw, I have a terribly ugly hack for https://github.com/luke-jr/cross-binpkgs that could potentially work
 8762016-03-01T13:54:30  <wumpus> fallback location broken? just change the redirects and all old versions depends download will just keep working without code changes
 8772016-03-01T13:54:48  <Luke-Jr> +1
 8782016-03-01T13:55:15  <MarcoFalke> of which: Fetching boost...
 8792016-03-01T13:55:15  <MarcoFalke>   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
 8802016-03-01T13:55:15  <MarcoFalke>                                  Dload  Upload   Total   Spent    Left  Speed
 8812016-03-01T13:55:15  <MarcoFalke>   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
 8822016-03-01T13:55:15  <MarcoFalke> 100   639  100   639    0     0   2017      0 --:--:-- --:--:-- --:--:--  2017
 8832016-03-01T13:55:15  <MarcoFalke> sha256sum: WARNING: 1 computed checksum did NOT match
 8842016-03-01T13:55:33  *** zooko has joined #bitcoin-core-dev
 8852016-03-01T13:55:45  <MarcoFalke> https://travis-ci.org/bitcoin/bitcoin/jobs/112855470#L831
 8862016-03-01T13:58:25  <btcdrak> wumpus: look  https://github.com/btcdrak/sources/releases/tag/src
 8872016-03-01T13:58:29  <wumpus> it doesn't actually say what URL it had downloaded
 8882016-03-01T13:58:37  <btcdrak> so for example https://github.com/btcdrak/sources/releases/download/src/boost_1_59_0.tar.bz2
 8892016-03-01T13:58:50  <btcdrak> the fallback URL would be https://github.com/btcdrak/sources/releases/download/src/
 8902016-03-01T13:59:27  *** moli has joined #bitcoin-core-dev
 8912016-03-01T13:59:28  <btcdrak> so this could just be https://github.com/bitcoin-core/depends-fallback/releases/download/src/boost_1_59_0.tar.bz2
 8922016-03-01T13:59:41  <wumpus> boost hash wrong sounds like a pretty serious issue
 8932016-03-01T14:00:28  <MarcoFalke> maybe it's just travis-will-randomly-fail-tuesday
 8942016-03-01T14:02:42  *** molz has quit IRC
 8952016-03-01T14:03:47  <Luke-Jr> :/
 8962016-03-01T14:03:51  <btcdrak> so we could change the fallback URL to https://github.com/bitcoin-core/depends-fallback/releases/download/src/ but the best would be to setup a permanent redirect from dev.bitcoincore.org -> https://github.com/bitcoin-core/depends-fallbacks/releases/download/src/ then if for any reason the github repo changed you can just update the redirect and now we dont
 8972016-03-01T14:03:52  <btcdrak> need a hosting server for gitian fallback
 8982016-03-01T14:04:41  <wumpus> #7136 is already on 0.12
 8992016-03-01T14:05:09  <wumpus> btcdrak: but then why set up a dev.bitcoincore.org at all and just change the current redirect from bitcoincore.org?
 9002016-03-01T14:05:16  <wumpus> +not
 9012016-03-01T14:05:44  <GitHub127> [bitcoin] laanwj pushed 2 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/35af157641dd...a10da9aa4933
 9022016-03-01T14:05:44  <GitHub127> bitcoin/0.12 00d57b4 Luke Dashjr: Workaround Travis-side CI issues...
 9032016-03-01T14:05:45  <GitHub127> bitcoin/0.12 a10da9a MarcoFalke: [depends] builders: No need to set -L and --location for curl...
 9042016-03-01T14:08:11  <GitHub172> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/f5ecd0737130...732c01089601
 9052016-03-01T14:08:12  <GitHub172> bitcoin/master 5c70a6d Luke Dashjr: Bugfix: gitian: Add curl to packages (now needed for depends)
 9062016-03-01T14:08:12  <GitHub172> bitcoin/master e5daa2e Luke Dashjr: Merge branch 'master' into depends_curl
 9072016-03-01T14:08:13  <GitHub172> bitcoin/master 732c010 Wladimir J. van der Laan: Merge #7614: Bugfix: gitian: Add curl to packages (now needed for depends)...
 9082016-03-01T14:08:16  <GitHub49> [bitcoin] laanwj closed pull request #7614: Bugfix: gitian: Add curl to packages (now needed for depends) (master...depends_curl) https://github.com/bitcoin/bitcoin/pull/7614
 9092016-03-01T14:10:44  <GitHub64> [bitcoin] laanwj pushed 1 new commit to 0.10: https://github.com/bitcoin/bitcoin/commit/4e1134bdf1acff669c0f489934ac5f919c634d69
 9102016-03-01T14:10:44  <GitHub64> bitcoin/0.10 4e1134b Luke Dashjr: Bugfix: gitian: Add curl to packages (now needed for depends)...
 9112016-03-01T14:11:14  *** GAit has joined #bitcoin-core-dev
 9122016-03-01T14:13:44  <GitHub168> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/ca8f160af5a54d08f8dc73acd959b0a73a7b427c
 9132016-03-01T14:13:44  <GitHub168> bitcoin/0.12 ca8f160 Luke Dashjr: Bugfix: gitian: Add curl to packages (now needed for depends)...
 9142016-03-01T14:16:19  <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
 9152016-03-01T14:17:34  <GitHub73> [bitcoin] laanwj pushed 4 new commits to 0.11: https://github.com/bitcoin/bitcoin/compare/c40ec1421048...a0cfe3a9e6c5
 9162016-03-01T14:17:35  <GitHub73> bitcoin/0.11 7815cb6 Luke Dashjr: Bugfix: gitian: Add curl to packages (now needed for depends)...
 9172016-03-01T14:17:35  <GitHub73> bitcoin/0.11 a0e13f0 MarcoFalke: Fix url in .travis.yml...
 9182016-03-01T14:17:36  <GitHub73> bitcoin/0.11 77841d4 Luke Dashjr: Workaround Travis-side CI issues...
 9192016-03-01T14:20:21  *** GAit has quit IRC
 9202016-03-01T14:23:58  *** Chris_Stewart_5 has quit IRC
 9212016-03-01T14:28:06  *** GAit has joined #bitcoin-core-dev
 9222016-03-01T14:30:04  *** treehug88 has joined #bitcoin-core-dev
 9232016-03-01T14:34:09  *** frankenmint has joined #bitcoin-core-dev
 9242016-03-01T14:37:18  *** p15x has quit IRC
 9252016-03-01T14:38:05  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 9262016-03-01T14:41:27  *** Cheeseo has joined #bitcoin-core-dev
 9272016-03-01T14:41:56  *** Cheeseo has quit IRC
 9282016-03-01T14:42:47  *** Cheeseo has joined #bitcoin-core-dev
 9292016-03-01T14:42:48  *** Cheeseo has joined #bitcoin-core-dev
 9302016-03-01T14:58:59  *** bsm1175321 has quit IRC
 9312016-03-01T15:12:17  *** gavinandresen has joined #bitcoin-core-dev
 9322016-03-01T15:14:19  *** TZander has joined #bitcoin-core-dev
 9332016-03-01T15:20:52  *** laurentmt has joined #bitcoin-core-dev
 9342016-03-01T15:29:39  *** laurentmt has quit IRC
 9352016-03-01T15:34:08  *** GAit has quit IRC
 9362016-03-01T15:39:17  *** GAit has joined #bitcoin-core-dev
 9372016-03-01T15:47:59  *** BashCo has quit IRC
 9382016-03-01T15:51:06  <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?
 9392016-03-01T15:52:07  <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
 9402016-03-01T15:52:38  *** arlisk has joined #bitcoin-core-dev
 9412016-03-01T15:52:50  <arlisk> opaa
 9422016-03-01T15:53:57  *** arlisk has left #bitcoin-core-dev
 9432016-03-01T15:54:04  <wumpus> and if the fallback logic isn't working, the last thing we should be worrying about is where its files are hosted :p
 9442016-03-01T15:57:34  *** Thireus has quit IRC
 9452016-03-01T15:58:46  <wumpus> ok just downloaded http://sourceforge.net/projects/boost/files/boost/1.59.0/boost_1_59_0.tar.bz2 and it still has the same sha256sum, 727a932322d94287b62abb1bd2d41723eec4356a7728909e38adb65ca25241ca. It maybe that the file is corrupted on one of SF's mirrors, ofc.
 9462016-03-01T15:59:12  <btcdrak> or tampered with...
 9472016-03-01T15:59:32  <btcdrak> it wouldnt be the first time sf filedownloads have been compromised
 9482016-03-01T16:00:37  *** GAit has joined #bitcoin-core-dev
 9492016-03-01T16:01:44  <wumpus> could be, though I think it's unlikely someone would mess with an old boost download
 9502016-03-01T16:01:57  <wumpus> not impossible ofcourse
 9512016-03-01T16:11:58  *** tronDat has joined #bitcoin-core-dev
 9522016-03-01T16:14:36  *** BashCo has joined #bitcoin-core-dev
 9532016-03-01T16:30:16  <GitHub162> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/732c01089601...639ec582d0f3
 9542016-03-01T16:30:16  <GitHub162> bitcoin/master fafe446 MarcoFalke: [depends] Delete unused patches...
 9552016-03-01T16:30:17  <GitHub162> bitcoin/master 639ec58 Wladimir J. van der Laan: Merge #7616:  [depends] Delete unused patches...
 9562016-03-01T16:30:26  <GitHub177> [bitcoin] laanwj closed pull request #7616:  [depends] Delete unused patches  (master...Mf1602-boost155) https://github.com/bitcoin/bitcoin/pull/7616
 9572016-03-01T16:33:51  *** paveljanik has joined #bitcoin-core-dev
 9582016-03-01T16:37:25  *** Chris_Stewart_5 has quit IRC
 9592016-03-01T16:38:16  *** GAit has quit IRC
 9602016-03-01T16:53:35  *** GAit has joined #bitcoin-core-dev
 9612016-03-01T16:55:07  *** GAit has quit IRC
 9622016-03-01T16:56:24  *** Squidicuz has joined #bitcoin-core-dev
 9632016-03-01T16:58:11  *** Don_John has joined #bitcoin-core-dev
 9642016-03-01T16:58:28  <gmaxwell> wumpus: well an old boost download we use?
 9652016-03-01T16:58:51  <wumpus> yes but as the download process detects it, doing it just for us is pointless
 9662016-03-01T17:00:10  <wumpus> tho would be kind of funny if someone invested a lot in an attack that they didn't even test locally :p
 9672016-03-01T17:03:15  *** CyrusV has joined #bitcoin-core-dev
 9682016-03-01T17:08:58  *** zooko has quit IRC
 9692016-03-01T17:16:35  *** Guest41724 has quit IRC
 9702016-03-01T17:17:14  *** ChillazZ has joined #bitcoin-core-dev
 9712016-03-01T17:17:38  *** ChillazZ is now known as Guest30748
 9722016-03-01T17:18:37  *** murch has joined #bitcoin-core-dev
 9732016-03-01T17:33:27  <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?
 9742016-03-01T17:34:01  <Luke-Jr> Giszmo: uh, you can't use segwit like that
 9752016-03-01T17:34:12  <Luke-Jr> segwit is tied to the address
 9762016-03-01T17:34:22  <Luke-Jr> a 1… address can never be segwit
 9772016-03-01T17:34:37  <Luke-Jr> only 3…
 9782016-03-01T17:35:06  *** Thireus has joined #bitcoin-core-dev
 9792016-03-01T17:39:40  <GitHub111> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/639ec582d0f3...e5121eb951c4
 9802016-03-01T17:39:41  <GitHub111> bitcoin/master fa06ce0 MarcoFalke: Fix doxygen comment for payTxFee
 9812016-03-01T17:39:42  <GitHub111> bitcoin/master fa97f95 MarcoFalke: [doc] Fix markdown
 9822016-03-01T17:39:42  <GitHub111> bitcoin/master fa26652 MarcoFalke: Make sure LogPrintf strings are line-terminated
 9832016-03-01T17:39:53  <GitHub37> [bitcoin] laanwj closed pull request #7617: [doc/log] Fix markdown syntax and line terminate LogPrint (master...Mf1602-trivial9) https://github.com/bitcoin/bitcoin/pull/7617
 9842016-03-01T17:40:03  <Giszmo> Thanks Luke. Back to study the bips ...
 9852016-03-01T17:41:56  *** murch has quit IRC
 9862016-03-01T17:47:26  *** ebfull has joined #bitcoin-core-dev
 9872016-03-01T18:31:24  *** NicolasDorier_ has joined #bitcoin-core-dev
 9882016-03-01T18:32:26  *** _alp_ has quit IRC
 9892016-03-01T18:32:35  *** tronDat has quit IRC
 9902016-03-01T18:34:08  *** tronDat has joined #bitcoin-core-dev
 9912016-03-01T18:36:35  *** GAit has joined #bitcoin-core-dev
 9922016-03-01T18:37:29  *** NicolasDorier has quit IRC
 9932016-03-01T18:37:32  *** NicolasDorier_ is now known as NicolasDorier
 9942016-03-01T18:44:30  *** GAit has quit IRC
 9952016-03-01T18:47:54  *** jcorgan has quit IRC
 9962016-03-01T18:48:01  *** Arnavion has quit IRC
 9972016-03-01T18:48:05  *** Arnavion3 has joined #bitcoin-core-dev
 9982016-03-01T18:48:09  *** Arnavion3 is now known as Arnavion
 9992016-03-01T18:48:31  *** nkuttler has quit IRC
10002016-03-01T18:48:49  *** dirtynewshoes has quit IRC
10012016-03-01T18:49:54  *** nkuttler has joined #bitcoin-core-dev
10022016-03-01T18:50:22  *** dgenr8 has quit IRC
10032016-03-01T18:50:22  *** lecusemble has quit IRC
10042016-03-01T18:50:33  *** go1111111 has quit IRC
10052016-03-01T18:50:40  *** dgenr8 has joined #bitcoin-core-dev
10062016-03-01T18:50:48  *** lecusemble has joined #bitcoin-core-dev
10072016-03-01T18:51:25  *** jouke has quit IRC
10082016-03-01T18:51:30  *** go1111111 has joined #bitcoin-core-dev
10092016-03-01T18:51:36  *** gribble has quit IRC
10102016-03-01T18:53:21  *** jouke has joined #bitcoin-core-dev
10112016-03-01T18:56:08  *** GAit has joined #bitcoin-core-dev
10122016-03-01T18:58:07  *** GAit has quit IRC
10132016-03-01T19:01:53  *** gribble has joined #bitcoin-core-dev
10142016-03-01T19:06:17  *** dirtynewshoes has joined #bitcoin-core-dev
10152016-03-01T19:12:14  *** mkarrer_ has joined #bitcoin-core-dev
10162016-03-01T19:12:16  *** pavel_ has joined #bitcoin-core-dev
10172016-03-01T19:13:16  *** pavel_ has quit IRC
10182016-03-01T19:13:26  *** pavel_ has joined #bitcoin-core-dev
10192016-03-01T19:14:35  *** pavel_ has joined #bitcoin-core-dev
10202016-03-01T19:14:41  *** paveljanik has quit IRC
10212016-03-01T19:14:42  *** mkarrer has quit IRC
10222016-03-01T19:14:48  *** pavel_ is now known as paveljanik
10232016-03-01T19:15:21  *** Squidicuz has quit IRC
10242016-03-01T19:16:01  *** tronDat has quit IRC
10252016-03-01T19:16:04  *** tronDat_ has joined #bitcoin-core-dev
10262016-03-01T19:16:54  *** AtashiCon has quit IRC
10272016-03-01T19:17:13  <michagogo> AIUI increasing the prune limit just pauses it until the new threshold is hit. Why not go back and fetch the old data?
10282016-03-01T19:17:31  <michagogo> I mean, we still have the header chain, right?
10292016-03-01T19:17:40  <sdaftuar> michagogo: download old blocks, just to store them?
10302016-03-01T19:17:48  <michagogo> Oh. Wait.
10312016-03-01T19:18:02  <michagogo> Forgot about the undo data.
10322016-03-01T19:18:08  <michagogo> Never mind…
10332016-03-01T19:18:38  <GitHub82> [bitcoin] ericshawlinux opened pull request #7628: QT: Add 'copy full transaction details' option (master...master) https://github.com/bitcoin/bitcoin/pull/7628
10342016-03-01T19:22:39  *** wallet42 has joined #bitcoin-core-dev
10352016-03-01T19:23:29  *** AtashiCon has joined #bitcoin-core-dev
10362016-03-01T19:23:59  *** bsm1175321 has joined #bitcoin-core-dev
10372016-03-01T19:24:36  *** bsm1175321 is now known as bsm117532
10382016-03-01T19:25:42  *** jonasschnelli has quit IRC
10392016-03-01T19:25:43  *** ibrightly has quit IRC
10402016-03-01T19:31:29  *** ibrightly has joined #bitcoin-core-dev
10412016-03-01T19:31:30  *** jonasschnelli has joined #bitcoin-core-dev
10422016-03-01T19:56:15  *** zooko` has joined #bitcoin-core-dev
10432016-03-01T19:59:36  *** GAit has joined #bitcoin-core-dev
10442016-03-01T20:14:21  *** Tasoshi has joined #bitcoin-core-dev
10452016-03-01T20:16:59  *** Tasoshi_ has quit IRC
10462016-03-01T20:35:53  *** GAit has quit IRC
10472016-03-01T20:36:22  *** GAit has joined #bitcoin-core-dev
10482016-03-01T20:37:12  *** jannes has quit IRC
10492016-03-01T20:38:13  *** GAit has quit IRC
10502016-03-01T20:39:42  *** GAit has joined #bitcoin-core-dev
10512016-03-01T20:46:15  *** zooko` has quit IRC
10522016-03-01T20:46:26  *** zooko has joined #bitcoin-core-dev
10532016-03-01T20:48:11  *** treehug88 has quit IRC
10542016-03-01T21:07:16  *** MarcoFalke has quit IRC
10552016-03-01T21:09:37  *** achow101 has joined #bitcoin-core-dev
10562016-03-01T21:14:43  *** zooko has quit IRC
10572016-03-01T21:42:58  *** laurentmt has joined #bitcoin-core-dev
10582016-03-01T21:43:25  *** laurentmt has quit IRC
10592016-03-01T21:53:34  *** otium has joined #bitcoin-core-dev
10602016-03-01T21:58:57  *** belcher has joined #bitcoin-core-dev
10612016-03-01T22:03:12  *** GAit has quit IRC
10622016-03-01T22:09:51  <gmaxwell> Is it just me or has openssl missed their announced window?
10632016-03-01T22:10:11  <gmaxwell> oh they haven't just nothing to their announce list. :(
10642016-03-01T22:10:23  <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
10652016-03-01T22:10:59  <sdaftuar> https://www.openssl.org/news/secadv/20160301.txt
10662016-03-01T22:13:43  *** GAit has joined #bitcoin-core-dev
10672016-03-01T22:16:11  *** Guyver2 has quit IRC
10682016-03-01T22:20:41  <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
10692016-03-01T22:20:42  <phantomcircuit> ?
10702016-03-01T22:20:52  <sdaftuar> phantomcircuit: was just going to comment on the PR
10712016-03-01T22:20:58  <sdaftuar> phantomcircuit: no, you need to walk the ancestors
10722016-03-01T22:21:20  <phantomcircuit> descendants are the things which depend on the transaction right?
10732016-03-01T22:21:20  <sdaftuar> this is slightly tricky to write efficiently actually
10742016-03-01T22:21:28  <phantomcircuit> ie children not the parent
10752016-03-01T22:21:35  <sdaftuar> yes that's right
10762016-03-01T22:21:43  <sdaftuar> however the highest scoring thing might have ancestors with low fee
10772016-03-01T22:22:35  <sdaftuar> there's no direct relationship between any of the feerate scores and a "no orphan" order
10782016-03-01T22:22:51  <phantomcircuit> but for any given tree of transactions the parent transaction(s) are going to have a higher descendent fee total ... oh right feerate
10792016-03-01T22:23:10  <sdaftuar> see my PR for a "CPFP" mining algorithm,
10802016-03-01T22:23:17  <sdaftuar> i think i solve the exact problem you're trying to solve
10812016-03-01T22:23:28  <sdaftuar> #7600
10822016-03-01T22:24:50  <sdaftuar> is there a reason to prefer descendant fee rate over ancestor fee rate here?
10832016-03-01T22:25:21  <sdaftuar> the latter is much closer to being in sync with what is valuable to miners
10842016-03-01T22:26:09  <sdaftuar> (though at the low end, descendant fee rate score is more accurate for what gets evicted from the mempool)
10852016-03-01T22:27:45  *** tronDat_ has quit IRC
10862016-03-01T22:27:52  <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
10872016-03-01T22:28:42  <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
10882016-03-01T22:29:05  <phantomcircuit> (i think)
10892016-03-01T22:29:31  <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
10902016-03-01T22:29:45  <sdaftuar> if you're trying to communicate the least valuable transactions, i think the worst descendant fee rate captures that
10912016-03-01T22:30:08  <phantomcircuit> yeah that's what i was saying basically
10922016-03-01T22:30:43  <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
10932016-03-01T22:31:01  <sdaftuar> basically if you want to take a tx and communicate it in a no-orphan way
10942016-03-01T22:31:11  <sdaftuar> you call CalculateMemPoolAncestors on it
10952016-03-01T22:31:27  <sdaftuar> and then sort by nCountWithAncestors
10962016-03-01T22:31:58  <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)
10972016-03-01T22:32:18  <phantomcircuit> sdaftuar, i think you're right that using ancestor feerate is better
10982016-03-01T22:32:30  <sdaftuar> i have to run now, family time.  back in a couple hours...
10992016-03-01T22:37:30  *** tronDat has joined #bitcoin-core-dev
11002016-03-01T22:42:21  *** randy-waterhouse has joined #bitcoin-core-dev
11012016-03-01T22:42:38  *** dirtynewshoes has quit IRC
11022016-03-01T22:43:13  *** dirtynewshoes has joined #bitcoin-core-dev
11032016-03-01T22:44:14  *** zooko has joined #bitcoin-core-dev
11042016-03-01T22:53:06  *** neha has quit IRC
11052016-03-01T23:00:15  *** otium has left #bitcoin-core-dev
11062016-03-01T23:06:06  *** zooko has quit IRC
11072016-03-01T23:07:12  *** amiller has quit IRC
11082016-03-01T23:15:36  *** gevs has quit IRC
11092016-03-01T23:24:10  *** wallet42 has quit IRC
11102016-03-01T23:37:14  *** amiller has joined #bitcoin-core-dev
11112016-03-01T23:37:30  *** amiller is now known as Guest72772