--- Day changed Mon Feb 29 2016 00:05 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Read error: Connection reset by peer] 00:06 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev 00:06 -!- mesmer_ [~mesmer@unaffiliated/mesmer] has joined #bitcoin-core-dev 00:09 -!- mesmer [~mesmer@unaffiliated/mesmer] has quit [Ping timeout: 268 seconds] 00:10 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] 00:12 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:19 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev 00:24 < GitHub147> [bitcoin] laanwj closed pull request #7607: [0.10] Fix .travis.yml (0.10...Mf1602-010travis) https://github.com/bitcoin/bitcoin/pull/7607 00:24 < GitHub44> [bitcoin] laanwj pushed 4 new commits to 0.10: https://github.com/bitcoin/bitcoin/compare/b0c97ce31a93...12a0c0b3aac4 00:24 < GitHub44> bitcoin/0.10 dc9ae4c MarcoFalke: Fix url in .travis.yml... 00:24 < GitHub44> bitcoin/0.10 6bf4884 Luke Dashjr: Workaround Travis-side CI issues... 00:24 < GitHub44> bitcoin/0.10 6164639 MarcoFalke: [depends] builders: No need to set -L and --location for curl... 00:30 < GitHub63> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/18b3f1b7f625...f39819140c30 00:30 < GitHub63> bitcoin/master ff2be40 Alfie John: [doc] Typo fix... 00:30 < GitHub63> bitcoin/master f398191 Wladimir J. van der Laan: Merge #7612: [doc] Typo fix... 00:30 < GitHub129> [bitcoin] laanwj closed pull request #7612: [doc] Typo fix (master...master) https://github.com/bitcoin/bitcoin/pull/7612 00:41 < GitHub61> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f39819140c30...354b03dee188 00:41 < GitHub61> bitcoin/master 3d19193 Chris Moore: Remove spurious dollar sign. Fixes #7189. 00:41 < GitHub61> bitcoin/master 354b03d Wladimir J. van der Laan: Merge #7604: build: Remove spurious dollar sign. Fixes #7189.... 00:41 < GitHub134> [bitcoin] laanwj closed pull request #7604: build: Remove spurious dollar sign. Fixes #7189. (master...fix_qt4_failback) https://github.com/bitcoin/bitcoin/pull/7604 00:51 < GitHub24> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/354b03dee188...b53d201eab6d 00:51 < GitHub24> bitcoin/master fa7a5c5 MarcoFalke: [depends] builders: No need to set -L and --location for curl 00:51 < GitHub24> bitcoin/master b53d201 Wladimir J. van der Laan: Merge #7606: [depends] builders: No need to set -L and --location for curl... 00:51 < GitHub173> [bitcoin] laanwj closed pull request #7606: [depends] builders: No need to set -L and --location for curl (master...Mf1602-curl) https://github.com/bitcoin/bitcoin/pull/7606 00:52 < GitHub17> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b53d201eab6d...f06af574fbb8 00:52 < GitHub17> bitcoin/master 8c5a5fb Jonathan Cross: Improving wording related to Boost library requirements [updated]... 00:52 < GitHub17> bitcoin/master f06af57 Wladimir J. van der Laan: Merge #7590: Improving wording related to Boost library requirements [updated]... 00:53 < GitHub31> [bitcoin] laanwj closed pull request #7590: Improving wording related to Boost library requirements [updated] (master...patch-3) https://github.com/bitcoin/bitcoin/pull/7590 01:05 < GitHub183> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f06af574fbb8...78e81b0bc554 01:05 < GitHub183> bitcoin/master ca8fb59 Wladimir J. van der Laan: wallet: Warn on unexpected EOF while salvaging wallet... 01:05 < GitHub183> bitcoin/master 78e81b0 Wladimir J. van der Laan: Merge #7537: wallet: Warn on unexpected EOF while salvaging wallet... 01:05 < GitHub72> [bitcoin] laanwj closed pull request #7537: wallet: Warn on unexpected EOF while salvaging wallet (master...2016_02_salvage_unexpected_eof) https://github.com/bitcoin/bitcoin/pull/7537 01:08 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 01:12 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev 01:14 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Remote host closed the connection] 01:14 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev 01:44 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 01:45 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection] 01:51 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 01:54 -!- ChillazZ [~ChillazZ@194.97.152.20] has joined #bitcoin-core-dev 01:54 -!- ChillazZ is now known as Guest28524 01:57 -!- go1111111 [~go1111111@104.200.154.24] has quit [Quit: Leaving] 01:58 -!- go1111111 [~go1111111@104.200.154.24] has joined #bitcoin-core-dev 02:09 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:15 -!- proslogion [~proslogio@90.209.31.108] has joined #bitcoin-core-dev 02:23 < MarcoFalke> wumpus, I was more thinking about a wrapper for LogPrint[f] which adds the new line as default. But I don't know enough CPP to get this working 02:24 < wumpus> that'd be too much diff impact 02:24 < wumpus> we want to avoid chaning every single line with LogPrint(f) 02:25 < MarcoFalke> Keep the name but instead of using the #define LogPrintf, use an actual function 02:25 < wumpus> in retrospect, sure, defaulting to adding \n, and having a special function to build incomplete lines would have been better 02:26 < MarcoFalke> and then have this function somehow use the macro. But I don't know how to do this in cpp 02:26 < wumpus> then again it's not important enough to warrant changes over the code everywhere, breaking every single patch 02:26 < wumpus> (we have been extremely conservative with LogPrintf/LogPrint changes before, which is also why the functions are still so similarly named, which is a trap in itself...) 02:31 < wumpus> a RAII approach I've seen in other sw, log::debug("mempool") << "Rejecting transaction " << tx.GetHash.ToString(); - where going out-of-scope of the object returned from log::debug automatically generates a newline would probably have been better, in all cases it needs to be terminated with newline eventually. Then again, too much impact to change all of them now. 02:42 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 02:43 < go1111111> a bit of friction for new devs that it might be worth it to avoid: on linux if i follow the build instructions all tests pass except for zmq_test.py, because python-zmq isn't on the build dependency list. on one hand this is fine, because it's not needed for non-devs. on the other hand, it'd be nice if tests passed after following build instructions. worth it to submit a PR like this? https://github.com/elliotolds/bitcoin/commit/bc48a5b89e1 02:43 < go1111111> e502b1914504b7272ae3581fe1b6a. or if you think I should add it elsewhere let me know 02:46 < MarcoFalke> Did you set `ENABLE_ZMQ`? 02:50 < MarcoFalke> Oh, is it enabled by default... 02:50 < go1111111> I didn't set anything, just followed the build instructions exactly then tried to run the tests as described in the docs. 02:50 < go1111111> ah, maybe it used to be disabled and that's the issue? 02:51 < go1111111> (by default) 02:52 < MarcoFalke> You could create a pull to disable it instead: https://github.com/bitcoin/bitcoin/pull/6103/files#r38071295 03:00 < Luke-Jr> imo just make the error friendly 03:00 < Luke-Jr> or maybe get the test harness to explicitly "SKIP" it 03:06 -!- gevs [~greg@unaffiliated/gevs] has quit [Ping timeout: 246 seconds] 03:07 < wumpus> that's strange, the test should be automatically skipped if ZMQ is disabled 03:08 < wumpus> that's what qa/pull-tester/tests_config.py.in is about 03:09 < wumpus> ohh, python-zmq! no, we don't check for that 03:09 < wumpus> so if you have the zmq library installed it will enable ZMQ, and run the test against it 03:10 < wumpus> the test should probably be skipped if python-zmq is not enabled 03:10 < wumpus> installed* 03:10 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev 03:13 < go1111111> ok, I will attempt that tomorrow. if someone knows of an existing place in the codebase where a test is skipped if a python library isn't installed, let me know 03:14 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Read error: No route to host] 03:19 < wumpus> in tests_config.py something like try: import BLA except ImportError: zmq_installed=False else: zmq_installed=True 03:19 < wumpus> may print a warning if so too 03:19 < wumpus> (at least if zmq is enabled) 03:24 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 03:33 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds] 03:45 -!- cjcj [82ebca3a@gateway/web/freenode/ip.130.235.202.58] has quit [Ping timeout: 252 seconds] 03:47 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:54 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Remote host closed the connection] 03:59 -!- tr0nk [~tr0nk@50.153.149.119] has quit [Ping timeout: 250 seconds] 04:09 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] 04:16 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev 04:18 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev 04:19 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit] 04:22 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 04:25 -!- gevs [~greg@unaffiliated/gevs] has quit [Quit: bye] 04:26 -!- gevs [~greg@62.235.21.144] has joined #bitcoin-core-dev 04:26 -!- gevs [~greg@62.235.21.144] has quit [Changing host] 04:26 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev 05:07 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 276 seconds] 05:10 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.] 05:11 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 05:15 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Remote host closed the connection] 05:15 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev 05:17 -!- tr0nk [~tr0nk@155.42.172.114] has joined #bitcoin-core-dev 05:30 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has joined #bitcoin-core-dev 05:38 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has quit [Ping timeout: 268 seconds] 05:38 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 05:41 -!- dirtynewshoes [~dirtynews@sydnns0115w-142162196038.dhcp-dynamic.FibreOp.ns.bellaliant.net] has quit [Quit: WeeChat 0.3.8] 05:45 -!- dirtynewshoes [~dirtynews@sydnns0115w-142162196038.dhcp-dynamic.FibreOp.ns.bellaliant.net] has joined #bitcoin-core-dev 05:46 < jtimon> I think it would still be nice to mention python-zmq in build-unix.md 05:46 < btcdrak> jtimon: +1 05:52 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 06:02 < jonasschnelli> jtimon, btcdrak: do we also mention the other python modules required for running the tests? 06:03 < jonasschnelli> Stuff like: "from binascii import unhexlify" 06:04 < jtimon> jonasschnelli: I don't see why not, it can be a couple of lines below libqrencode-dev 06:05 < jonasschnelli> IMO it has nothing to do with the build itself... i think it should go here: https://github.com/bitcoin/bitcoin/blob/master/qa/rpc-tests/README.md 06:05 < jtimon> jonasschnelli: well, it can certainly go somewhere else 06:06 < jtimon> jonasschnelli: yeah, actually that seems like a better place 06:10 -!- mesmer_ is now known as mesmer 06:21 -!- tr0nk [~tr0nk@155.42.172.114] has quit [Ping timeout: 260 seconds] 06:30 -!- helo_ is now known as helo 06:31 -!- tr0nk [~tr0nk@155.42.172.114] has joined #bitcoin-core-dev 06:45 -!- Cheeseo [~x@c-71-58-178-138.hsd1.pa.comcast.net] has joined #bitcoin-core-dev 06:45 -!- Cheeseo [~x@c-71-58-178-138.hsd1.pa.comcast.net] has quit [Changing host] 06:45 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev 06:47 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev 07:02 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt] 07:07 -!- zooko [~user@173-162-76-165-miami.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 07:08 -!- p15x [~p15x@123.118.86.86] has quit [Quit: Textual IRC Client: www.textualapp.com] 07:18 < btcdrak> jonasschnelli: yes, we need to correctly list all dependencies else it's a real pest for new developers setting up 07:19 < btcdrak> jonasschnelli: well the build.md should at least make reference to RPC docs. 07:23 < jtimon> sipa: can you take a look at #7566 's latest version? 07:39 -!- zooko [~user@173-162-76-165-miami.hfc.comcastbusiness.net] has quit [Ping timeout: 248 seconds] 08:06 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .] 08:08 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev 08:17 -!- dermoth [~thomas@dsl-216-221-33-158.mtl.aei.ca] has joined #bitcoin-core-dev 08:19 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 08:21 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds] 08:22 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 08:22 < GitHub91> [bitcoin] MarcoFalke opened pull request #7620: [travis] Only run check-doc.py once (master...patch-1) https://github.com/bitcoin/bitcoin/pull/7620 08:25 -!- bsm1175321 [~mcelrath@38.121.165.30] has quit [Ping timeout: 276 seconds] 08:36 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.] 08:38 -!- Guest50611 [~socrates1@li175-104.members.linode.com] has quit [Changing host] 08:38 -!- Guest50611 [~socrates1@unaffiliated/socrates1024] has joined #bitcoin-core-dev 08:38 -!- Guest50611 is now known as amiller 08:41 -!- Eliel_ [~jojkaart@91-159-8-128.elisa-laajakaista.fi] has joined #bitcoin-core-dev 08:46 -!- Netsplit *.net <-> *.split quits: Eliel 08:51 -!- tr0nk [~tr0nk@155.42.172.114] has quit [Ping timeout: 268 seconds] 08:59 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev 09:07 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 09:16 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 09:28 -!- cj__ is now known as cj 09:42 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-core-dev 09:42 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host] 09:42 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 09:45 -!- bsm1175321 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev 10:31 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev 10:34 -!- Don_John [~Don@249-223-114-134.nat.resnet.nau.edu] has joined #bitcoin-core-dev 10:45 < GitHub49> [bitcoin] mrbandrews opened pull request #7621: Fixes ZMQ startup with bad arguments. (master...ba-fix-zmq) https://github.com/bitcoin/bitcoin/pull/7621 10:46 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Quit: leaving] 10:50 < GitHub192> [bitcoin] TazeTSchnitzel opened pull request #7622: Increase DEFAULT_BLOCK_MAX_SIZE to 1MB (master...increaseDefaultBlockSize) https://github.com/bitcoin/bitcoin/pull/7622 10:52 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt] 10:56 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev 11:01 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] 11:03 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 11:11 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Read error: Connection reset by peer] 11:11 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev 11:20 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds] 11:20 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 11:21 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev 11:39 -!- gevs [~greg@unaffiliated/gevs] has quit [Remote host closed the connection] 11:48 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev 11:50 < morcos> sdaftuar and i have question about the new standardness rules for version 2 txs 11:50 < morcos> hmm 11:51 < morcos> is it ok if txs with nsequence bits which are still undefined are still standard 11:51 < morcos> i think we answered our own question, its ok. b/c if you want to further impart meaning to the nsequence field you'd increase tx version again 11:53 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev 11:53 < btcdrak> yes 11:58 -!- Eliel_ is now known as Eliel 12:12 -!- MrHodl [~fuc@ns5001457.ip-192-95-32.net] has joined #bitcoin-core-dev 13:12 < GitHub41> [bitcoin] vlamer opened pull request #7623: newcomer can think bitcoincore.org is Bitcoin homepage. (master...master) https://github.com/bitcoin/bitcoin/pull/7623 13:12 -!- tr0nk [~tr0nk@155.42.172.114] has joined #bitcoin-core-dev 13:16 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Ping timeout: 240 seconds] 13:19 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection] 13:21 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev 13:29 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.] 13:29 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 13:33 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 13:46 -!- tr0nk [~tr0nk@155.42.172.114] has quit [Ping timeout: 248 seconds] 14:05 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 276 seconds] 14:11 -!- dermoth_ [~thomas@dsl-66-36-145-145.mtl.aei.ca] has joined #bitcoin-core-dev 14:11 -!- dermoth [~thomas@dsl-216-221-33-158.mtl.aei.ca] has quit [Ping timeout: 248 seconds] 14:11 -!- dermoth_ is now known as dermoth 14:14 -!- Guest28524 [~ChillazZ@194.97.152.20] has quit [Ping timeout: 240 seconds] 14:28 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev 14:32 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 14:42 -!- libertalis [~libertali@95.211.172.70] has joined #bitcoin-core-dev 14:42 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Quit: Leaving] 14:47 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 14:49 -!- Guest85079 [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev 14:50 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has joined #bitcoin-core-dev 14:55 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev 14:59 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 15:22 < CodeShark> On a plane heading back home. I think the roundtable went really well. 15:23 < gmaxwell> Which I knew something about it. 15:24 < sipa> Wish? Witch? s/it//? 15:24 < petertodd> morcos: please make sure undefined nSequence bits are standard... 15:24 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Remote host closed the connection] 15:25 < petertodd> morcos: may need them for voting schemes 15:30 < sipa> i believe that's the case 15:31 -!- tr0nk [~tr0nk@c-73-17-239-115.hsd1.vt.comcast.net] has joined #bitcoin-core-dev 15:43 < GitHub133> [bitcoin] vlamer closed pull request #7623: newcomer can think bitcoincore.org is Bitcoin homepage. (master...master) https://github.com/bitcoin/bitcoin/pull/7623 15:48 -!- Cheeseo [~x@c-71-58-178-138.hsd1.pa.comcast.net] has joined #bitcoin-core-dev 15:48 -!- Cheeseo [~x@c-71-58-178-138.hsd1.pa.comcast.net] has quit [Changing host] 15:48 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev 15:55 < gmaxwell> Was anyone here ever contacted by a group called the "Bitcoin Privacy Project"? They just put out a report that said that we did not respond to repeated contact attempts. 15:56 < gmaxwell> The reports is quite ... remarkable. For example, it places "Samourai" wallet ahead of Bitcoin-QT.... this wallet was recently in some reddit controversy when someone reverse engineered their closed source binaries and found that they were, without disclosure, sending all the user's addresses to BC.i. 15:57 < gmaxwell> ( https://www.reddit.com/r/Bitcoin/comments/447s7c/samourai_is_the_most_private_and_anonymous/ ) 15:57 < AaronvanW> gmaxwell: that's interesting because I think kristiv atlas (bc.i) co-authored the report 15:57 < sipa> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010006.html 15:57 < sipa> that? 15:58 < Luke-Jr> 4. Does your application fully implement BIP 62? <-- lol? 15:59 < sipa> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-January/007152.html 15:59 < gmaxwell> Likewise, they rated Bitcoin-Qt at 0 for physical security; when I believe it's the only wallet software in their test which is hardned against timing and RF sidechannels (some of the hardware wallets, like ledger are). Most of their wallets in their test do not implement meaningful KDFs for wallet encryption, thouh Bitcoin Core does. 16:00 * Luke-Jr wonders if it is better to correct people in cases like this, or let them build up a negative reputation. 16:03 < gmaxwell> Kristov's answers were a bit off but not terrible there. 16:04 < belcher> gmaxwell they had been in contact with me about joinmarket a few months ago, nothing much came from it 16:05 < 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. 16:05 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection] 16:06 < gmaxwell> Though I wonder about thins like this: 16:06 < 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)? 16:06 < gmaxwell> No, it just downloads the whole blockchain and performs local queries." 16:06 < gmaxwell> ... like are we being negatively marked here for doing the _only_ thing known to provide strong privacy? 16:07 < 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. 16:07 < gmaxwell> " wut? 16:08 -!- aknix [~aknix@65.78.54.2] has joined #bitcoin-core-dev 16:11 < Luke-Jr> lol 16:15 < 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. 16:16 -!- BitcoinErrorLog [~bitcoiner@c-71-203-187-87.hsd1.fl.comcast.net] has joined #bitcoin-core-dev 16:17 < 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. 16:18 < 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) 16:28 < 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? 16:29 < molz> we're going to have HD core wallet in v13, right? 16:29 < sipa> if someone implements it, maybe 16:29 < gmaxwell> molz: I really doubt it. Also, thats irrelevant to privacy. 16:36 < randy-waterhouse> gmaxwell: are you asking about these guys http://www.openbitcoinprivacyproject.org/ ? 16:37 < aknix> oh no whats pistov-kristov doing now? 16:38 < aknix> oic 16:41 < petertodd> Luke-Jr: "improving it seems likely to result in their organisation gaining credibility" <- +1 16:42 -!- pigeons_ is now known as pigeons 16:44 < aknix> I have some kristov chat logs... 16:44 < aknix> pms 16:44 < petertodd> aknix: oh yeah? 16:44 < aknix> yes 16:44 < aknix> i was IRL friends with him 16:45 < petertodd> aknix: interesting 16:45 < petertodd> aknix: now granted, PM's are meant to be private, so keep that in mind 16:45 < Luke-Jr> past tense? 16:46 < aknix> yes, I have been open minded. Also tried to reinstate conversation to no avail. 16:46 < aknix> he has me blocked on twitter which i find childish as well 16:46 < Luke-Jr> i c 16:46 < petertodd> aknix: well, I blocked him on twitter because he kept on being uncivil, unlike others who disagreed with me 16:46 < aknix> so my logs are gone from slack :( 16:46 < aknix> they were slack PMs 16:46 < Luke-Jr> aknix: yeah, problem with using slack.. 16:47 < aknix> He made statement that CT will never happen 16:47 < Luke-Jr> it may not 16:47 < Luke-Jr> I think sipa is working on improving it though 16:47 < aknix> Im aware 16:47 < sipa> i'm working on CT? 16:47 < Luke-Jr> it's quite possible CT may not be necessary too 16:47 < aknix> But he said it cant and argued that type of thing cant ever happen 16:47 < petertodd> aknix: what was his rational? 16:47 < aknix> I really really did no expect that from him 16:48 < Luke-Jr> sipa: no? 16:48 < aknix> He didnt elaborate, it got hot quick after that. 16:48 < sipa> i don't believe that CT in its current form is acceptable for Bitcoin, due to its huge transactions and processing requirement 16:48 < 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 16:48 < 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 16:48 < sipa> adam thought he had a way to make it smaller, but i'm not convinced 16:49 < Luke-Jr> ah 16:49 < sipa> in any case; just small constant factorsa 16:49 < aknix> Hahhaha, molz I had met him right around that time. 16:49 < Luke-Jr> anyway, hopefully Lightning will make CT unnecessary 16:49 < 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 16:50 * aknix prays to blockchain jesus 16:50 < 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 16:50 < sipa> petertodd: tragedy of the commons 16:50 < aknix> petertodd, I said the same thing in slack today 16:50 < petertodd> sipa: that's true too 16:51 < petertodd> sipa: though with bc.i claiming to have 50% of all txs, we have a tragedy of the commons in other ways 16:52 < belcher> users do get a personal benefit from privacy, otherwise they wouldnt pay for mixers and coinjoins 16:52 < petertodd> belcher: yup, though their k-anonymity sets aren't as big as they could be 16:53 < sipa> belcher: for mixers to be useful, people who do not have anything to hide need to use them too 16:53 < petertodd> sipa: well, keep in mind that if you and I have different adversaries, a mixer can still be useful 16:53 < Luke-Jr> sipa: belcher's Joinmarket seems to incentivise them to, by giving them the fees 16:54 < belcher> to clarify, it incentives people who have nothing to hide to take part 16:54 < sipa> petertodd: fair enough 16:54 < petertodd> Luke-Jr: I assume Joinmarket is run by the FBI and act accordingly :) fortunately my adversaries are probably not the FBI! 16:54 < molz> lol 16:54 < petertodd> I use joinmarket all the time 16:54 * aknix hehheheehe bitcoin so hawt righ naow 16:55 < belcher> hopefully the FBI and CCP are not sharing information, my antics are safe in that case 16:55 < petertodd> belcher: hopefully your adversaries don't include Santa Claus, as he knows who is naughty or nice 16:55 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection] 16:57 < aknix> oh yay i found the kristove logs 16:57 < aknix> I did SS it 16:57 < petertodd> aknix: SS? 16:57 < aknix> screenshot 16:57 < petertodd> aknix: ah 16:57 -!- rgrant [~user@unaffiliated/rgrant] has joined #bitcoin-core-dev 16:57 < sipa> this is probably not the right place for discussion that 16:57 < petertodd> sipa: +1 17:00 < aknix> Sorry just dont want to see OBPP used for populist agenda 17:00 < 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. 17:01 -!- catlasshrugged [423790bc@gateway/web/freenode/ip.66.55.144.188] has joined #bitcoin-core-dev 17:01 < catlasshrugged> hello! 17:01 < aknix> Oh hey 17:01 < aknix> at long last 17:04 < catlasshrugged> kristov from obpp here 17:04 < catlasshrugged> someone mentioned people were discussing some concerns about our report here 17:06 < aknix> catlasshrugged, Thanks for pming me and clearing that up! 17:06 < gmaxwell> Hi, I also emailed you directly before the discussion here. 17:06 < catlasshrugged> I saw that 17:08 < catlasshrugged> just going to try to clear up a few points of confusion, either on my end or others' 17:09 < 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. 17:09 < gmaxwell> Sweet. -- FWIW, I think the whole idea of reviewing wallet privacy is a great one, even if I'm lost at your results. 17:10 < 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. 17:10 < 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. 17:11 < 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. 17:12 < 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. 17:12 < 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. 17:13 < 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. 17:13 < catlasshrugged> the questionnaire is only half (or maybe less) of our criteria. 17:13 < catlasshrugged> most of the data was gathered by volunteers directly interacting with the wallets. 17:14 < catlasshrugged> and answering TRUE/FALSE questions or counting # of clicks to perform certain actions according to the script that we prepared. 17:14 < 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? 17:14 -!- _alp_ [~alp@104-54-235-28.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-core-dev 17:15 < gmaxwell> many wallets you rated more highly for physical security are browser based and would have left identifying information in browser caches. 17:15 < catlasshrugged> https://github.com/OpenBitcoinPrivacyProject/wallet-ratings/blob/master/report-02/threat%20model.wiki 17:15 < catlasshrugged> scroll down to "physical adversary" 17:16 < gmaxwell> ah this is useful at least. 17:16 < catlasshrugged> We'll be revising our threat model soon for the next edition. Input extremely welcome! 17:17 < catlasshrugged> I've been trying to solicit help for a long while now. 17:17 < gmaxwell> I wasn't aware of this list-- I had seen your prior report. 17:18 < 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. 17:18 < 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. 17:18 < 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.. 17:19 < aknix> Also is providing a pseudo UI for a bitcoin wallet a good idea either? 17:19 < aknix> idk some of this seems silly to me.. 17:19 < 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 17:20 < 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. 17:20 < catlasshrugged> some of them use bloom filters but those filters include effectively 0% of the blockchain, so they got a 0 17:20 < catlasshrugged> kanzure: ...I don't know how to parse that statement. 17:20 < 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) 17:21 -!- Guest94923 [~chatzilla@97-90-24-187.dhcp.mtpk.ca.charter.com] has joined #bitcoin-core-dev 17:21 < kanzure> catlasshrugged: i think the only relevant reply i can muster is "who is john galt?" 17:21 -!- Guest94923 is now known as [_smitty] 17:21 < 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. 17:22 < catlasshrugged> alllllrighty 17:22 < aknix> no need to do that anymore 17:22 < gmaxwell> catlasshrugged: Ah, I follow your thinking now at least. 17:22 < aknix> The .12 client syncs from scratch in only a few hours 17:22 < gmaxwell> Yes, I should have responded that since 0.10 bootstraps are depricated. 17:22 < 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 :-) 17:23 < catlasshrugged> Sorry, not sure why I said "my" ratings -- our ratings 17:23 -!- AaronvanW_ [~ewout@x5ce3e9a6.dyn.telefonica.de] has joined #bitcoin-core-dev 17:24 < catlasshrugged> "aknix: now granted, PM's are meant to be private, so keep that in mind" thanks petertodd :) 17:24 < 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... 17:24 < aknix> catlasshrugged, I am watching you ;) 17:24 < aknix> loljk 17:24 < 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. 17:25 < catlasshrugged> go on? 17:25 < _alp_> lol samouri 17:25 < aknix> ooooof 17:25 < _alp_> but it supports BIP-PAYMENT-CODES! 17:25 < 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 17:26 < 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. 17:26 < catlasshrugged> for the record, I do not appreciate being told that "I should be embarrassed." I don't deserve that. 17:27 < gmaxwell> Sorry, let me retry that: I would be embarassed if it were me. I dunno about you. 17:27 < catlasshrugged> that's not really less dickish... 17:27 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds] 17:27 < catlasshrugged> the closed source state is in the threat model; they lost points for it. 17:27 < gmaxwell> No, but it's honest. 17:27 < catlasshrugged> Are you a practicer of "radical honesty" or something? 17:28 < catlasshrugged> as I understand it, SW intend to open source in the future, but that's not relevant to their score this time around 17:28 < 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, ... 17:28 * aknix would prefer being told the truth than anything else. I have always come to some bitcoin channel for that over the years ;) 17:28 < pigeons> _alp_: i see a smiliar name on both the payment codes bip and the obpp 17:29 < aknix> You should know this catlasshrugged, brutal honesty is always lurking in IRC 17:29 < 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. 17:29 < catlasshrugged> source isn't closed to me :-) 17:29 < pigeons> before the report you had the source? 17:29 < aknix> not sure if better or worse 17:29 < pigeons> before you rated them? 17:30 < 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 17:30 < 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. 17:30 < 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. 17:31 < gmaxwell> catlasshrugged: thats not the only feedback you're getting here for sure. 17:31 < catlasshrugged> we talked a couple weeks ago about full nodes 17:31 < catlasshrugged> I think they are less important than you do 17:31 < gmaxwell> catlasshrugged: all the more disappointing. 17:31 < 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 17:32 < aknix> I think everyone is willing here, but you are really picking holes in areas that arent really realistic for most users. 17:33 < aknix> granted it is a tough thing to do... 17:33 < aknix> I would be willing to help revise guidelines for example. 17:33 < catlasshrugged> we hold 100% open meetings and our mailing list is 100% open for participation 17:34 < catlasshrugged> if you'd like to see any positive changes, this is really easy to do 17:34 < catlasshrugged> ask anyone who has participated before, I haven't turned down a single person or contribution since we started the ratings project. 17:35 < kanzure> then perhaps you should show them the logs from today in here 17:35 < kanzure> it would save us time and be a generous olive branch 17:37 < catlasshrugged> I will gladly post this log to our mailing list, though I am not sure what actionable feedback has been provided so far 17:37 < gmaxwell> catlasshrugged: well I invested nearly an hour responding to your older questionare; I never saw it previously. Time is obviously fairly limited. 17:37 < gmaxwell> catlasshrugged: do you have a parallel wiki page with the actual scorings for those criteria? 17:37 < kanzure> actional feedback like category and score and rating improvements, hmm not very actionable i guess 17:38 < 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" 17:38 -!- rgrant [~user@unaffiliated/rgrant] has left #bitcoin-core-dev [] 17:39 < randy-waterhouse> actionable feedback into a nebulous, subjective process seems a bit pointless? 17:39 < kanzure> there are many discussions about that 17:39 < 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 17:39 < gmaxwell> e question the good faith involvement of everyone responsbile. 17:39 < kanzure> randy-waterhouse: https://bitcoin.org/en/bitcoin-core/features/validation 17:40 < kanzure> http://blog.sia.tech/2016/01/20/what-makes-bitcoin-special/ 17:40 < 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 17:40 < kanzure> http://bluematt.bitcoin.ninja/2015/01/14/decentralization/ 17:40 < 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. 17:40 < kanzure> https://www.reddit.com/r/bitcoinxt/comments/3vhn88/businesses_need_certainty_of_excess_capacity/cxo19r9 17:41 < catlasshrugged> so... "private data" is pretty nebulous, speaking of nebulousness. there are different kinds of information 17:41 < catlasshrugged> I would love to see some better PIR implementations! 17:41 < gmaxwell> catlasshrugged: sure, but sending a list of the users addresses (or equivilently a HD master seed) home is not nebulus. 17:41 < kanzure> catlasshrugged: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011671.html 17:41 < catlasshrugged> ("better" compared to the not very successful bloom filter implementations to date) 17:42 < kanzure> anyway, it should be obvious by now that "full nodes" aren't just a figment of gmaxwell's imagination 17:42 < kanzure> if you need another pile of links just ask me i'll be happy to DoS you with links 17:42 < gmaxwell> catlasshrugged: well bitcoin core has "PIR" in the naieve form: send everyone the whole database is PIR. :) 17:42 < 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. 17:43 < kanzure> catlasshrugged: i think you should include disclaimers like "review by bitcoin core developers has said x about this rating scheme" 17:43 < catlasshrugged> gmaxwell: yes :) 17:43 < gmaxwell> kanzure: bleh 17:43 -!- proslogion [~proslogio@90.209.31.108] has quit [Ping timeout: 276 seconds] 17:43 < kanzure> and also you should send the logs to your group, i think it would be a useful disclosure for you to make 17:44 < catlasshrugged> sure, I'll send the logs as soon as I wrap this up. 17:44 < gmaxwell> catlasshrugged: what does ledger (for example) do for resistance to blockchain analysis that Bitcoin Core does not. 17:44 < kanzure> gmaxwell: i don't have a better idea 17:44 < gmaxwell> ? 17:44 < 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. 17:44 < catlasshrugged> automatic selection of receiving addresses, HD wallet structure... 17:45 < petertodd> catlasshrugged: maybe I missed something, but how are HD wallet's helping here? 17:45 < gmaxwell> catlasshrugged: uh.. you know that it's externally undetectable to users if bitcoin core uses HD wallets; right? 17:46 < 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. 17:46 < 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). 17:46 < catlasshrugged> An expert Bitcoin user can probably do everything and more with Bitcoin-Qt that he can do with Ledger. 17:46 < gmaxwell> catlasshrugged: How is this useful for incentivizing users to not reuse addresses? 17:47 < 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. 17:47 < catlasshrugged> gmaxwell: oops, you're right about the clicks -- Bitcoin-Qt got 0 clicks for that = full score 17:48 < 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. 17:48 < catlasshrugged> it complicates the backup process 17:49 < gmaxwell> catlasshrugged: users cannot escape that by reusing addresses in bitcoin core, due to change. 17:49 < 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... 17:49 < catlasshrugged> I'm going to be writing some blog posts about the data set and hopefully highlighting strengths and weaknesses 17:49 < gmaxwell> From a privacy perspective, I'm still not seeing your argument. 17:49 < petertodd> catlasshrugged: yes, but that's not a privacy problem (and in some cases non-HD, 'bag of keys', wallets have better privacy) 17:49 -!- AaronvanW_ [~ewout@x5ce3e9a6.dyn.telefonica.de] has quit [Ping timeout: 276 seconds] 17:49 < _alp_> So I can't reuse addresses in electrum since its HD? Strange, I do that all the time. 17:49 < 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 17:49 < gmaxwell> E.g. if reusing addresses made backup easier I'd agree with you that points should be deducted there. 17:50 < catlasshrugged> N.B. ***no one in this room is an average Bitcoin user.*** 17:50 < 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 17:50 -!- gevs [~greg@unaffiliated/gevs] has quit [Remote host closed the connection] 17:51 < 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. 17:51 < 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 17:51 < gmaxwell> ntal privacy flaw. 17:51 < 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 17:51 < 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) 17:51 < 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 17:51 < gmaxwell> er competent! 17:51 < aknix> Deffinitely not for a regular wallet user 17:51 < aknix> but you said otherwise? 17:52 < pigeons> make like this https://www.eff.org/secure-messaging-scorecard 17:52 < catlasshrugged> aknix: not all of them are weighted equally, see the weights.wiki doc for that 17:52 < aknix> These rating criteria need refining 17:52 < aknix> ahh ok that helps but a pseudo UI cmon 17:53 < catlasshrugged> pigeons: what do you like about that one? 17:53 < pigeons> it tells each thing being considered 17:53 < 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. 17:54 < catlasshrugged> I'd be happy to send you a copy of the ratings for Bitcoin-Qt 17:54 < catlasshrugged> last edition we posted them on GitHub, but no one noticed so I didn't bother this time aroun 17:54 < catlasshrugged> d 17:54 < pigeons> "pysical privacy" is much more nebulous than "sends addresses to third parties" 17:54 < petertodd> catlasshrugged: I think you need to preserve raw data like that even if no-one seems to notice 17:55 < petertodd> pigeons: yeah, once the attacker is standing next to you all bets are off anyway... 17:55 < catlasshrugged> consider it "available upon request" 17:55 < petertodd> pigeons: heck, I don't even put a pin on my trezor for that reason 17:55 < aknix> hmm thats not very bitcoin like. 17:55 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has joined #bitcoin-core-dev 17:55 < 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) 17:56 < 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) 17:56 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev 17:56 < catlasshrugged> gotcha 17:56 < catlasshrugged> yeah, all wallets failed most of the criteria given that the top score was 50 17:56 < 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 17:57 < 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. 17:57 < catlasshrugged> petertodd: that is absolutely what we did. 17:57 < petertodd> catlasshrugged: did you do it in a way that's publicly reproducable? 17:57 < catlasshrugged> I don't pretend that anyone would care about my opinion about a particular wallet 17:57 < 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. 17:58 < catlasshrugged> petertodd: partially. we wrote down how much weight we assigned to various categories, but did not write down full English descriptions of why 17:58 < petertodd> catlasshrugged: ok, so, publicly reproducable would be at minimum something like a tweet "the sha256 hash of our chosen weights is: xxx" 17:58 < 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. 17:58 < 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. 17:58 < aknix> catlasshrugged, How can you not disclose the weights? 17:58 < petertodd> gmaxwell: yeah, I'm very concerned about third-parties getting addresses myself 17:59 < catlasshrugged> oh, I see. does anyone really think we modified our weights after the fact and are lying about it? 17:59 < catlasshrugged> that is pretty uncharitable 17:59 < gmaxwell> catlasshrugged: no no. but PT was suggesting a scheme that would prevent that, and I'm saying it's not a concern. 17:59 < catlasshrugged> aknix: weights are in the weights.wiki file 17:59 < gmaxwell> at least not right now. 17:59 < aknix> catlasshrugged, Ahh thanks, i missed that 17:59 < 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. 17:59 < 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 17:59 < 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 18:00 < catlasshrugged> fair enough. I'll consider that for next time 18:00 < catlasshrugged> creating a github issue now... 18:00 < aknix> catlasshrugged, Whoa cant we simplify this? 18:00 < aknix> this is obtuse 18:00 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 246 seconds] 18:01 < 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 18:01 < 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. 18:02 < petertodd> gmaxwell: agreed - they have a lot to overcome 18:02 < 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. 18:02 < gmaxwell> the report is beautiful though, and the area is important for work. 18:03 < 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. 18:03 < 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 18:04 < 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. 18:04 < 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) 18:04 < 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 18:05 < catlasshrugged> take-aways I am not looking to express: Ledger is better than Bitcoin-Qt; Bitcoin-Qt sucks! 18:06 < gmaxwell> catlasshrugged: too bad, that isn't how the report presentation comes out. 18:06 < gmaxwell> Esp with the ranked score on the first page. :) 18:06 < gmaxwell> If you want that you should be counting the privacy fails instead, and enumerating the things they don't do. 18:07 < 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 18:07 < 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 18:08 < catlasshrugged> what would that look like? 18:08 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-tihcqpobwfjzohhl] has quit [Quit: Connection closed for inactivity] 18:09 < 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. 18:09 < gmaxwell> I think my intuition is "Here is the list of the worst things wallets to wrong againt attacker X" 18:09 < 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 18:09 < 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. 18:09 < catlasshrugged> how do I make that meaningful to the average Bitcoin user? 18:09 < catlasshrugged> again, I'll remind you that #bitcoin-core-dev is not the primary target audience for these reports. 18:09 < gmaxwell> catlasshrugged: if your message is that they all suck than your audience isn't an actual bitcoin user, it's the industry. 18:09 < petertodd> catlasshrugged: seriously: get some graphics/storyboards done illustrating what those attackers can do and who they might be 18:10 < petertodd> gmaxwell: +1 18:10 < catlasshrugged> the industry generally does not give a flying fuck about my concerns ;-) 18:10 < 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. 18:10 < gmaxwell> I'm not saying you _intend_ to say that, but thats what the report says to joe reader. 18:10 < petertodd> catlasshrugged: journalists can help fix that 18:10 < catlasshrugged> this is why Consumer Reports doesn't write letters of concern to the makers of products 18:11 < petertodd> catlasshrugged: consumer reports deals in an industry where most people are doing things basically right 18:11 < 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 ;) 18:11 < catlasshrugged> petertodd: I'm not clear on how that is relevant 18:12 < 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. 18:13 < 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 18:13 < gmaxwell> catlasshrugged: How do you have access to that wallet's source code? 18:13 < 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 18:14 < catlasshrugged> gmaxwell: the developers have shared it with me individually in the past. 18:14 < catlasshrugged> that doesn't mean anything as far as vouching goes, I don't think 18:14 < petertodd> catlasshrugged: while I'm not saying you're biased, be warned that using that kind of evidence as a basis invites suspicion 18:14 < gmaxwell> catlasshrugged: Ah. I was wondering if you were involved with its development. 18:14 < catlasshrugged> petertodd: I find that wallet providers are extremely aware of what they're doing wrong and why they're not addressing it. 18:15 < catlasshrugged> I am not. 18:16 < catlasshrugged> The only project I work on did not score highly in the report 18:16 < gmaxwell> ::nods:: 18:16 < 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. 18:16 * gmaxwell ::shakes:: head 18:16 < gmaxwell> I don't know how you can say that. 18:17 < aknix> we all know how voting works ;) 18:17 < catlasshrugged> doing things this way tremendously increased the amount of work I had to put in, btw 18:17 < 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 :) 18:18 < catlasshrugged> consumer reports has years of credibility built up that I don't 18:18 < catlasshrugged> it's quite reasonable to trust their reports more than you trust ones that I work one with a small number of people. 18:18 < 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 18:18 < gmaxwell> le. 18:18 < petertodd> gmaxwell: +1 18:19 < 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. 18:19 < aknix> gmaxwell, +1 18:20 < catlasshrugged> you don't work there, so I can see why it wouldn't be boring to you. 18:20 < 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. 18:20 < catlasshrugged> example? 18:20 < aknix> Sheesh 18:21 < 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. 18:21 < aknix> Thats very likely the case but its stilla secuirty hole 18:21 < catlasshrugged> it's definitely sub-optimal. 18:21 < gmaxwell> catlasshrugged: e.g. https://bitcointalk.org/index.php?topic=131608.0 18:22 < catlasshrugged> sometimes when you are a company that has $0 in funding, you have to bootstrap some shit. 18:22 < gmaxwell> catlasshrugged: it also can be stored by cloudflare, even if it isn't being stored by bc.i. 18:22 < aknix> "bootstrap" in that context sounds like magical numbers argument to me 18:22 < gmaxwell> catlasshrugged: I wouldn't find it much better if it were their own server instead of bc.i. 18:22 < gmaxwell> (if thats any consolation) 18:22 < aknix> yeah i dont think anyone would really 18:22 < 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. 18:23 < aknix> at least people in this room i guess 18:23 < 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? 18:23 < catlasshrugged> so the majority of your problem with samourai wallet vs qt is client-server vs fullnode, which we talked about earlier. 18:23 < 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. 18:24 < 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) 18:24 < 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. 18:24 < gmaxwell> catlasshrugged: what is the most important? 18:24 < gmaxwell> Not reusing addresses? Bitcoin core does as much as is possible there short of actually forbidding the users from doing it. 18:24 < catlasshrugged> I think resistance to blockchain analysis is roughly 2x more important than network-level analysis based on speaking with many people in analytics. 18:25 < 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) 18:25 < catlasshrugged> yeah, coinjoin capability is heavily weighted in our scoring IIRC 18:25 < catlasshrugged> and yes, almost no one is currently doing it 18:25 < catlasshrugged> I hope by the next report, JoinMarket's GUI will be ready to go 18:25 < 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? 18:26 < catlasshrugged> and maybe we will just rate Qt+JoinMarket GUI rather than Qt by itself. 18:26 < gmaxwell> er blockchain analytics rather. 18:26 < catlasshrugged> I'll send you a list of things that one or a couple wallets got higher marks for 18:26 < catlasshrugged> it will just take some time to put together. 18:27 < gmaxwell> I would be really thankful for that. 18:27 < catlasshrugged> oh, you asked about network analytics 18:27 < gmaxwell> I ment blockchain. 18:27 < catlasshrugged> I would not be surprised if Qt received the highest marks out of all wallets with regards to network stuff 18:27 < catlasshrugged> ah, ok 18:29 < 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. 18:29 < 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 18:29 < gmaxwell> y; or arguably 'stealth' addresses, but I can also argue that stealth addresses are of little value in the current climate today) 18:30 < 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. 18:30 < 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 18:31 < gmaxwell> I think you do _devistating_ harm to the bitcoin ecosystem when you present privacy disaster personal data phone-homing lite wallets as _superior_. 18:31 < 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. 18:31 < pigeons> catlasshrugged: i didnt ask about the "average bitcoin user" I asked about "new users seeking privacy with privacy needs" 18:32 < catlasshrugged> pigeons: you're right, sorry. I didn't fully read your question when I went back to look at it. 18:32 < gmaxwell> devastating* 18:33 < catlasshrugged> gmaxwell: ok. 18:34 -!- p15 [~p15@96.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 260 seconds] 18:35 < 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. 18:36 < 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. :) 18:36 < aknix> How about we fix the weighting/section on physical adversarys to start ;) 18:36 < catlasshrugged> sorry, what's wrong with it? 18:36 < aknix> Its just unrealistic as all wallets will fail 18:36 < pigeons> you rnk shoulder surfing a greater threat than address leakage 18:37 < aknix> I mean cmon you recoomend a fake UI for a bitcoin wallet 18:37 < aknix> what are you gonna do open tinder to use bitcoin? 18:37 < aknix> this is not avergae user material 18:37 < catlasshrugged> pigeons: nope, false. you're reading it wrong. 18:38 < aknix> Other than that like i said before i thin k you are on the right track just weighting is goofy 18:38 < 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. 18:38 < catlasshrugged> If you actually said something about HOW you think the weighting is goofy, I missed it. 18:39 < 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? 18:39 < dirtynewshoes> catlasshrugged: Darkwallet in here at 4 is a bit confusing... I did not think it was at all really ready to be used. 18:39 < aknix> Well if samourai was rated higher than qt should i bother? 18:39 < 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. 18:40 < catlasshrugged> dirtynewshoes: it works, although it lost some points due to the fact that the coinjoin has little volume at the moment 18:40 < dirtynewshoes> catlasshrugged: Would it be used by the average bitcoin user? (Stable enough?) 18:41 < 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. 18:41 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving] 18:42 < catlasshrugged> dirtynewshoes: when you download it, it comes with several warnings. I didn't actually have any significant issues with it. 18:42 < catlasshrugged> aside from the fact that DW stealth addresses are not fully compatible with ArcBit stealth addresses 18:42 < catlasshrugged> which is noted in the report. 18:42 < petertodd> catlasshrugged: could you answer gmaxwell re: ledger vs core? 18:42 < pigeons> coinjoin has more volume than samouri 18:42 < aknix> petertodd, +1 18:42 < pigeons> *joinmarket 18:44 < catlasshrugged> not right now because I need to manually create the comparison 18:44 < catlasshrugged> but I currently plan to send him the comparison. I would be happy to CC you, if you're interested. 18:44 < petertodd> catlasshrugged: yes, please do 18:44 < catlasshrugged> whats a good email address? 18:44 < pigeons> catlasshrugged: what are ledger's blockchain analysis resistance features? 18:44 < petertodd> catlasshrugged: pete@petertodd.org 18:45 < catlasshrugged> ok 18:45 < 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? 18:45 < catlasshrugged> nope, it doesn't 18:45 < randy-waterhouse> an acknowledgements section might be appropriate? 18:45 < catlasshrugged> expert users already know this 18:45 < catlasshrugged> if you're not sure about this, please scroll up ;-) 18:46 < gmaxwell> catlasshrugged: that doesn't make it okay to have a misleading report! 18:46 < catlasshrugged> I don't think there's anything in the report that suggests that its primary audience is expert bitcoin users. 18:46 < petertodd> catlasshrugged: you don't need to be an expert to run bitcoin core I'll note 18:46 < catlasshrugged> there's no way to put out this report without pissing several people off about their favorite wallet(s). 18:47 < aknix> I think its misleading in general because running QT is part of the secuirty model 18:47 < petertodd> aknix: +1 18:47 < 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. 18:47 < 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 18:47 < 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 18:47 < aknix> I understand that is a stretch but its relevant to newb 18:47 < petertodd> sipa: Bitcoin Core is something non-experts can and do run mind you 18:48 < 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. 18:48 < 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? 18:48 < 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". 18:48 < gmaxwell> (er totally busted due to X) 18:48 < 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. 18:49 < catlasshrugged> bitcoin-qt is a wallet. I'm not going to exclude it. 18:49 < sipa> catlasshrugged: then you should at least be able to give one aspect at which bitcoin-qt ranks lower than your #1 18:49 < catlasshrugged> warren: as I mentioned before, I am completely underwhelmed by the "expose" 18:50 < aknix> Wow, i am at a loss for words.. 18:50 < 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". 18:50 < 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 18:50 < aknix> warren +1 18:50 < 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 18:51 < 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 18:51 < catlasshrugged> ok 18:51 < 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 18:52 < 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. 18:52 < _alp_> I don't always alpha test, but when I do, I do on mainnet. 18:52 < petertodd> catlasshrugged: equally, until samourai implements that _missing_ part of their wallet, we can't evaluate them 18:52 < aknix> _alp_, :) 18:53 < 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. 18:53 < 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. 18:53 < petertodd> catlasshrugged: if your threat model isn't covered by that expose, it's not a very good htreat model 18:53 < warren> If you think that issue isn't important in your threat model, then your threat model is flawed. 18:54 < catlasshrugged> sipa: what do you mean by "aspect"? 18:54 < petertodd> hehe, three identical replies :) 18:54 < catlasshrugged> bc.i does not log all user transactions and sell the results. 18:54 < aknix> catlasshrugged, Man cmon I know you are smarter than this. 18:54 < catlasshrugged> aknix: that is incredibly rude. 18:54 < petertodd> catlasshrugged: what proof do you have of that? 18:54 < pigeons> i am very suprised that anyone thinks that a user seeking any level of privacy would choose to reveal their addresses 18:54 < gmaxwell> catlasshrugged: prove to me that it doesn't; moreover prove to me that it cannot? 18:54 < aknix> Yeah well i am being honest 18:55 < aknix> I also have vouched for you in the past 18:55 < petertodd> catlasshrugged: indeed, why specifically do you think you have any way of knowing? 18:55 < sipa> catlasshrugged: in what way is Bitcoin-Qt's privacy worse than Samurai's? 18:55 < aknix> Im hurting myself by even commenting on this 18:55 < catlasshrugged> just wondering guys, what do you hope to be the outcome of a bunch of you ganging up on me? 18:55 < aknix> but its important 18:56 < catlasshrugged> I thought we were making some traction on productive iterations before, but now :/ 18:56 < petertodd> catlasshrugged: would you mind answering the question? 18:56 < petertodd> catlasshrugged: we're here to help you fix your report; that means we'll ask questions, not all of them easy to answer 18:56 < petertodd> catlasshrugged: that's just how engineering reviews work 18:56 < gmaxwell> catlasshrugged: sorry that it's turned a bit harsh. 18:56 < aknix> catlasshrugged, Not trying to gang up, just trying to show you an other POV 18:56 < sipa> catlasshrugged: I'm sorry if you feel ganged up; that is by no means my intention 18:56 < aknix> I know that can be difficult to get. 18:57 < 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. 18:57 < gmaxwell> I'll back off for now and give you some air. Sorry. 18:57 < catlasshrugged> petertodd: I mean, I've done engineering reviews before, they are generally less unpleasant. 18:58 -!- sipa [~pw@unaffiliated/sipa1024] has left #bitcoin-core-dev ["I'll make it easier for you!"] 18:58 < 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. 18:58 < 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. 18:58 < 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 18:58 < petertodd> catlasshrugged: easier in person for sure 18:59 < 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. 18:59 < gmaxwell> catlasshrugged: I was responding to your question 'warren: please either explain how the reddit "expose" fits into our threat model' 19:00 < catlasshrugged> concerning sipa's question, he can get some more insight into this once I send a comparison to gmax and petertodd 19:00 < catlasshrugged> if you have suggestions about what it would look like, I welcome them. Currently I have absolutely no clue. 19:01 < catlasshrugged> To re-iterate, the fact that balance lookups and transaction broadcasts are done through a server is considered in the threat model. 19:01 < petertodd> catlasshrugged: so again, how do you know bc.i doesn't log queries? 19:01 < catlasshrugged> I can't prove it. 19:01 < petertodd> catlasshrugged: ok, so don't say it 19:02 < 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..." 19:02 < petertodd> catlasshrugged: does bc.i even formally say they don't keep logs? 19:02 < catlasshrugged> To the best of my knowledge, the threat model does include this possibility. 19:02 < catlasshrugged> of course, it does not discriminate bc.i from any other provider 19:03 < 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. 19:03 < 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. :) 19:03 < catlasshrugged> I don't think samourai ever claimed that they do not send traffic through bc.i 19:04 < 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 19:04 < gmaxwell> they also don't claim to not send your private keys to Pirate40. 19:04 < 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. 19:04 < petertodd> catlasshrugged: it certainly came as a surprise to many of their users 19:04 < gmaxwell> At least for something claiming to be the most private it was rather shocking. 19:04 < catlasshrugged> I'm not sure how to include "don't surprise people" in a threat model 19:05 < gmaxwell> (and the thread on reddit seems to indicate an overwhelming majority of the commentin people agreed, for whatever thats worth) 19:05 < petertodd> catlasshrugged: samourai was advertising itself as an SPV wallet, which implies to most people that there isn't a central server involved 19:05 < catlasshrugged> I don't tend to look to reddit for my social cues 19:05 < 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. 19:06 < catlasshrugged> I didn't know that, but I've never seen Samourai use the term "SPV" in their promotions 19:06 < 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 19:06 < catlasshrugged> it's not a serious privacy leak 19:06 < gmaxwell> "[–]SamouraiWallet 12 points 9 months ago* 19:06 < gmaxwell> Samourai is an SPV mobile wallet that collects no information about you. " 19:06 < catlasshrugged> it's sending transaction data to a server 19:06 < warren> Do you at least agree that you should stop comparing apples to oranges? (remove the full node wallets like Qt) 19:06 < catlasshrugged> I don't particularly care whether you prefer the server they used 19:07 < pigeons> without informing the user after leading the user to believe otherwise 19:07 < petertodd> catlasshrugged: a server not controlled by Samourai, so how do they know no information is kept? 19:07 < petertodd> catlasshrugged: Samourai can't make that promise 19:08 < 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. 19:08 < 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 19:08 < gmaxwell> petertodd: not even bc.i could make that promise, though I'm looking and they don't... since their api goes through cloudflare. 19:08 < petertodd> now, they correctly said they were using an API here, but that got repeated as SPV for sure 19:08 < catlasshrugged> thanks. that's too bad that they weren't clear about their network topology. 19:09 < 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 19:09 < catlasshrugged> do you know for a fact that Samourai doesn't have a relationship with bc.i? 19:09 < 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. 19:10 < petertodd> catlasshrugged: until told otherwise, I'm not going to assume they do 19:10 < catlasshrugged> aknix: can you remind me about your expertise in bitcoin privacy engineering? 19:10 < catlasshrugged> petertodd: it appears that you're going to assume they don't. 19:10 < aknix> catlasshrugged, Sure 6 years experience 19:10 < aknix> ;) 19:10 < catlasshrugged> aknix: go on... 19:10 < 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) 19:10 < catlasshrugged> what bitcoin privacy engineering did you do during those 6 years? 19:10 < warren> catlasshrugged: additionally, it might be wise for the authors of the report to disclose potential conflicts of interest 19:10 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 260 seconds] 19:11 < catlasshrugged> warren: go on? 19:11 < aknix> catlasshrugged, email me i will send you my resume, Its pretty verbose 19: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 19:11 < aknix> or dm on twitter 19:11 < petertodd> catlasshrugged: equally, not leaking this data at all to third parties is obviously highly valuable 19:11 < catlasshrugged> it objectively should not have been included, or you would prefer that it wasn't included? 19:11 < randy-waterhouse> catlasshrugged: I notice that arguably the best actual SPV wallet out there mSIGNA was not included 19:11 < catlasshrugged> randy-waterhouse: I've never actually met someone who used mSIGNA 19:11 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev 19:12 < pigeons> is that criteria included on the guidelines page? 19:12 < catlasshrugged> between the first and second report, we went with the wallets that had the highest demand 19:12 < randy-waterhouse> catlasshrugged: that's hor private they are :) 19:12 < aknix> catlasshrugged, I have documented proof of being involved in btc since mid 2010 19:12 < aknix> ;) 19:12 < catlasshrugged> the only request for mSIGNA that I received was from its CEO 19:12 < catlasshrugged> randy-waterhouse: lol 19:12 < aknix> at a techincal level 19:12 < 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. 19:12 < petertodd> warren: +1 19:13 < aknix> warren, +1 19:13 < catlasshrugged> address ownership? 19:13 < petertodd> catlasshrugged: queries to API services like bc.i, which leak info on who owns what addresses 19:13 < catlasshrugged> hey warren 19:13 < catlasshrugged> are you suggesting that bc.i stood to gain from this report? 19:14 < petertodd> catlasshrugged: e.g., if I startup Samourai wallet, it'll query multiple addresses, which even through Tor links those addresses together 19:14 < catlasshrugged> yup, just like most wallets do. 19:14 < petertodd> catlasshrugged: you should make it clear to readers that you work for bc.i, given they may ask that question 19:14 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has quit [Quit: Leaving] 19:14 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer] 19:14 < petertodd> catlasshrugged: right, which is a huge privacy problem - the exact one coinjoin is meant to avoid. BTC Core completely avoids it 19:15 < warren> I don't have reasons for or against. That doesn't remove the wisdom of disclosures though. 19:15 < catlasshrugged> man, I gotta say, that's just really annoying feedback to get. 19:15 < gmaxwell> I don't think it's fair feedback in any case. 19:15 < 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 19:16 < 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. :( 19:16 < 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 19:16 < gmaxwell> but that doesn't mean that there is any actual conflict of interest. 19:16 < 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. 19:17 < petertodd> catlasshrugged: that's covered by your blockchain analysis, analysis. network analysis can be combined with that information in anti-privacy ways 19:17 < 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. 19:17 < catlasshrugged> I don't find repeated claims about the importance of full nodes vs not full nodes helpful without evidence. 19:18 < 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 19:18 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 19:18 < catlasshrugged> er, whose servers are you trusting if you use Electrum? 19:18 < catlasshrugged> maybe bc.i runs all of the electrum servers 19:18 < petertodd> catlasshrugged: yes, which is made very clear in the Electrum UI, and it's easy to get information on who runs those servers 19:19 < aknix> petertodd, +1 +1 19:19 < 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. 19:19 < catlasshrugged> it's also really easy to find out which API samourai uses, too 19:19 < 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 19:19 < catlasshrugged> lol at "reverse engineering" and "expose" 19:19 < petertodd> catlasshrugged: could you explain how you'd find that out? 19:19 < gmaxwell> Yes, I think most people would agree that electrum has significantly worse privacy than bitcoin core due to the server model. 19:19 < catlasshrugged> yes, point your android device at a web proxy and look at what domains pop up. 19:20 < petertodd> catlasshrugged: especially as an average user? remember that the Samourai website doesn't say it uses an API 19:20 < catlasshrugged> the average user is also not looking up who owns their Electrum server 19:20 < 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 19:21 * Luke-Jr notes that trusting anonymous/random third parties is actually worse than trusting easily identified third parties 19:21 < 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. 19:21 < petertodd> Luke-Jr: agreed, but not knowing you're trusting third parties is even worse 19:21 < Luke-Jr> yes, no doubt 19:21 < petertodd> Luke-Jr: informed consent! 19:21 < 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) 19:22 < catlasshrugged> ^ 19:22 < aknix> Yeah i think I have to withdraw my pledge to help out with OBPP 19:22 < gmaxwell> er electrum not armory! :P 19:22 < molz> aknix: haha 19:23 < 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) 19:23 < 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. 19:23 -!- BCB [4241870d@gateway/web/freenode/ip.66.65.135.13] has joined #bitcoin-core-dev 19:23 < aknix> catlasshrugged, Your arguing this samurai wallet like its an estranged lover 19:23 < 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/ 19:23 < aknix> Like electrum makes there model clear 19:23 < aknix> samurai does not 19:24 < aknix> pretty clear cut 19:24 < petertodd> catlasshrugged: they did reverse engineer it, but they're not bragging about that 19:24 < aknix> their* 19:24 < petertodd> gmaxwell: seems reasonable 19:24 < aknix> catlasshrugged, Have you used a disassembler? 19:27 -!- [_smitty] [~chatzilla@97-90-24-187.dhcp.mtpk.ca.charter.com] has quit [Quit: ChatZilla 0.9.92 [SeaMonkey 2.39/20151103191810]] 19:27 < aknix> You were laughing at reverse engineering it so just curious... 19:27 < petertodd> alright, going to do some work, bbl 19:28 -!- BCB [4241870d@gateway/web/freenode/ip.66.65.135.13] has quit [Quit: Page closed] 19:30 < 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. 19:31 < pigeons> luckily, he has the source 19:32 < warren> catlasshrugged: Another dimension to analyze is how well each wallet discloses their own risks 19:32 < gmaxwell> Luke-Jr: how the heck do I get lrelease on gentoo? 19:33 < catlasshrugged> warren: I like that idea 19:33 < warren> ok great 19:33 < catlasshrugged> do you have any suggestions about how one could measure level of disclosure without it being terribly subjective? 19:33 < gmaxwell> warren: why not go work on improving Bitcoin Core's privacy documentation? :) it's scattered in many places. 19:33 < Luke-Jr> gmaxwell: for Qt4, it's part of dev-qt/qtcore; for Qt5, dev-qt/linguist-tools 19:34 < aknix> gmaxwell, Yeah simple interface monitoring would have caught this 19:34 < aknix> And thanks that does make more sense in context 19:34 < pigeons> catlasshrugged: actually say "are addreseses sent to 3rd parties? Y/N? is this disclosed? Y/N 19:34 < catlasshrugged> disclosed where and how? 19:35 < pigeons> anywhere, like their website or the TOS 19:35 < catlasshrugged> I think we can all agree that disclosing somewhere is better than nowhere, but surely there are better and worse ways 19:35 < 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 19:35 < gmaxwell> pigeons: well if its burried in some TOS is that meaningful? 19:35 < pigeons> yes but any discloseure is better than reddit discloses it for you 19:36 < catlasshrugged> warren: yes, I support that for sure 19:36 < catlasshrugged> however, I think presentation matters a lot 19:36 < molz> how about trash that report and rewrite it? 19:36 < gmaxwell> bitcoin.org has disclosure requirements, IIRC. 19:36 < gmaxwell> molz: be nice. 19:37 < 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. 19:37 < pigeons> yes you are correct, ok 19:37 < gmaxwell> It would be better than not, but I agree that it doesn't pass the test. 19:38 < catlasshrugged> molz: will try to make the next one better. 19:38 < 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. 19:38 < 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. 19:39 < gmaxwell> One of the goals of disclosure is to reduce the risk that known-to-author privacy fails are not missed in review. 19:39 < pigeons> its easier for most people to search a website than to reverse engineer a binary 19:39 < catlasshrugged> probably true. 19:39 < catlasshrugged> I would actually have an easier time looking at the behavior of the app, but that's unusual. 19:40 < 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. 19:40 < catlasshrugged> right 19:40 < gmaxwell> even if people are going to look at the behavior they could still miss something critical. 19:40 < catlasshrugged> any suggested standards for how these things ought to be disclosed? 19:41 < catlasshrugged> Yes/No is a good start, just wondering if anyone has any ideas for improvements at present. 19:41 < 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? 19:42 < gmaxwell> the gold standard would be to document their threat models and list their limitations under them. 19:42 < 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.) 19:42 < gmaxwell> I think bitcoin.org wallet criteria did some disclosure requirement stuff, I'm looking for it now. 19:42 < catlasshrugged> thanks 19:43 -!- instagibbs [~instagibb@pool-100-15-114-5.washdc.fios.verizon.net] has quit [Ping timeout: 260 seconds] 19:44 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Ping timeout: 250 seconds] 19:45 < gmaxwell> bleh, not finding it now. will look more later. 19:47 < 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) 19:47 < catlasshrugged> thanks 19:49 -!- instagibbs [~instagibb@pool-100-15-114-5.washdc.fios.verizon.net] has joined #bitcoin-core-dev 19:50 < 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 19:52 < aknix> Hmm maybe there is an ISO like 17944:2002 that can be adopted. its pretty similar 19:52 < Luke-Jr> O.o 19:52 < 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? 19:52 < aknix> i can still troll right? 19:53 * aknix lulz 19:54 < Luke-Jr> catlasshrugged: I am personally unaware of such comment. 19:54 < catlasshrugged> ok 19:55 < randy-waterhouse> that would not be core related and should go elsewhere anyway 19:55 < 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. 19:56 < 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. 19:57 < catlasshrugged> I want it to be an inclusive project that all experts can feel free to contribute to. 19:58 < 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. 19:59 < btcdrak> shouldnt this conversation be in #bitcoin ? 19:59 < 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 19:59 < aknix> btcdrak, +1 19:59 < 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". 20:00 < btcdrak> This channel is for Bitcoin Core development discussion. please move to #bitcoin. 20:00 < catlasshrugged> @btcdrak: no problem 20:01 < molz> gmaxwell: sorry.. but that report got on my nerves 20:02 < 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 20:19 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has quit [Ping timeout: 276 seconds] 20:36 -!- p15 [~p15@80.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev 21:22 -!- baldur [~baldur@pool-173-52-43-219.nycmny.fios.verizon.net] has quit [Ping timeout: 276 seconds] 21:38 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 276 seconds] 21:53 -!- baldur [~baldur@pool-108-30-43-254.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 22:21 -!- baldur [~baldur@pool-108-30-43-254.nycmny.fios.verizon.net] has quit [Ping timeout: 276 seconds] 22:29 -!- libertalis [~libertali@95.211.172.70] has quit [Ping timeout: 246 seconds] 22:35 -!- libertalis [~libertali@95.211.172.70] has joined #bitcoin-core-dev 22:36 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Ping timeout: 240 seconds] 22:39 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev 22:54 -!- catlasshrugged [423790bc@gateway/web/freenode/ip.66.55.144.188] has quit [Quit: Page closed] 22:54 -!- baldur [~baldur@pool-72-69-12-130.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 22:55 -!- Don_John [~Don@249-223-114-134.nat.resnet.nau.edu] has quit [Read error: Connection reset by peer] 22:57 < 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 22:57 < 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. 23:00 -!- dermoth [~thomas@dsl-66-36-145-145.mtl.aei.ca] has quit [Read error: Connection reset by peer] 23:00 -!- dermoth [~thomas@dsl-66-36-145-145.mtl.aei.ca] has joined #bitcoin-core-dev 23:11 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 23:34 -!- mesmer_ [~mesmer@unaffiliated/mesmer] has joined #bitcoin-core-dev 23:37 -!- mesmer [~mesmer@unaffiliated/mesmer] has quit [Ping timeout: 268 seconds] 23:42 -!- wallet421 [~wallet42@172.58.33.249] has joined #bitcoin-core-dev 23:47 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Ping timeout: 276 seconds] 23:50 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 23:53 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.] 23:59 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev