1 2015-05-04 00:02:44 <hulkhogan_> sipa: thanks for your help earlier, refactor was far easier than expected
  2 2015-05-04 00:05:37 <hulkhogan_> cfields_: i think the refactor is better now, contexts are passed around in java via a long reference (instead of reinitalized per-operation)- would appreciate any review you can do!
  3 2015-05-04 00:09:03 <hulkhogan_> stepping away but i left a commment on the PR in case anyone misses the fix
  4 2015-05-04 00:44:15 <kanzure> gavinandresen: did you have any objections to the "try a smaller max block size, first" plan?
  5 2015-05-04 00:44:16 <kanzure> gavinandresen: did you have any objections to the "try a smaller max block size, first" plan?
  6 2015-05-04 00:50:18 <hulkhogan_> im curious, is 'libfortuna' ever going to happen? (ref pr 5885)
  7 2015-05-04 00:50:48 <gmaxwell> hulkhogan_: why do you ask?
  8 2015-05-04 00:52:19 <hulkhogan_> gmaxwell: heh well specifically... because i was working on the testing for that on and off lately, i'm making progress although slowly- i suppose asking out of a shared curiosity
  9 2015-05-04 00:53:16 <hulkhogan_> the last bit i was working on isolating fortuna from the bitcoin code, which i made a small victory in, but there's still loads for me to figure out how to actually inject test vectors and stuff
 10 2015-05-04 00:53:36 <hulkhogan_> also generating said vectors (todo)
 11 2015-05-04 00:54:44 <hulkhogan_> if there are nits or other aspects (i need to know more about prngs) that would be neat to look into, that could be a side path as well
 12 2015-05-04 00:55:29 <hulkhogan_> failing that i would like to just have tests for it, in terms of my vision for 'libfortuna'
 13 2015-05-04 00:55:53 <hulkhogan_> (i dont care if its not called that, of course..)
 14 2015-05-04 00:55:56 <esso> hulkhogan_, gmaxwell, jonasschnelli, sipa: Sorry to interrupt guys, but I'm finishing up my write up on the user experience of Bitcoin Core and was wondering if any of you would be willing to take a look before I send it out tomorrow?
 15 2015-05-04 00:56:16 <hulkhogan_> esso: sure
 16 2015-05-04 00:57:38 <esso> hulkhogan_: Thanks! Do you have an email I could send it to?
 17 2015-05-04 00:58:07 <hulkhogan_> hm, are you willing to post it here? nobody will notice
 18 2015-05-04 00:58:24 <hulkhogan_> ill have to find something
 19 2015-05-04 00:58:36 <esso> I can post a link here no prob
 20 2015-05-04 00:58:51 <hulkhogan_> you might get more eyes too :)
 21 2015-05-04 01:00:28 <esso> hulkhogan_: The more the merrier! Here it is: https://docs.google.com/document/d/1NZm1XaKFDUVg7zYmtPVuT4isHAfdSadF-mA4ODvCqS0/edit?usp=sharing
 22 2015-05-04 01:02:22 <hulkhogan_> thats a really good idea ie. linking to comments where users have complained before
 23 2015-05-04 01:02:50 <hulkhogan_> its a strong argument for rethinking those aspects where users have had trouble and actually said something (as opposed to those who just dont and hit X)
 24 2015-05-04 01:03:17 <esso> Yea I think it helps get the point across, but I only have links for the first section so I think I may try to find more.
 25 2015-05-04 01:04:57 <hulkhogan_> hmm yea, i need to fire up -qt as well
 26 2015-05-04 01:06:50 <hulkhogan_> so, i was a bit confused by the statements about showing the most recent txes, because somehow i didn't understand how that compares to the current build where it shows the most recent ones on the right
 27 2015-05-04 01:08:23 <hulkhogan_> i think also, in your point about there needing to be more sections on the overview, you could talk more about what you would add, how it fits with the theme of that page being the 'birds-eye' of your wallet
 28 2015-05-04 01:08:24 <gmaxwell> hulkhogan_: we wanted to make it a totally seperate library; but there is some lack of clarity about how to safely handle concurrency because synchronization primitives are not portable; and unlike libsecp256k1 it's less justified to just punt on concurrency here... as it's quite hard for the caller to get concurrency right as every RNG call mutates its state.
 29 2015-05-04 01:08:25 <gmaxwell> hulkhogan_: we wanted to make it a totally seperate library; but there is some lack of clarity about how to safely handle concurrency because synchronization primitives are not portable; and unlike libsecp256k1 it's less justified to just punt on concurrency here... as it's quite hard for the caller to get concurrency right as every RNG call mutates its state.
 30 2015-05-04 01:09:42 <hulkhogan_> hmm interesting gmaxwell, the sheer amount of arch-specific code in that PR was already giving me nightmares, that there are more non-portable things that i didn't see is somehow not all that surprising
 31 2015-05-04 01:09:45 <esso> hulkhogan_: Do you mind elaborating on where you're confused? I'm not sure I follow.
 32 2015-05-04 01:10:49 <hulkhogan_> esso: i might not be explaining it right, then. under 'Overview' -> 'Recent transactions' , is that not a list of improvements as a proposal? I wa
 33 2015-05-04 01:11:06 <andytoshi> (btw this is one case where rust's concurrency is -not- sufficient https://github.com/rust-lang/rust/issues/16799 )
 34 2015-05-04 01:11:19 <esso> Now that I think about, would you recommend I add every solution I have in mind to this.
 35 2015-05-04 01:11:20 <esso> Now that I think about, would you recommend I add every solution I have in mind to this.
 36 2015-05-04 01:11:28 <hulkhogan_> oops, *I was commenting trying to understand the proposed scheme there, adding more transactions, making it more clear I think would help
 37 2015-05-04 01:11:45 <hulkhogan_> esso: Well
 38 2015-05-04 01:11:46 <hulkhogan_> esso: Well
 39 2015-05-04 01:12:04 <esso> Yea I'll make it much more clear in the intro
 40 2015-05-04 01:12:56 <hulkhogan_> i think i just misunderstood the format of the paper, i see now everything before 'issues with.. ' is a explaination of the current state
 41 2015-05-04 01:12:57 <hulkhogan_> i think i just misunderstood the format of the paper, i see now everything before 'issues with.. ' is a explaination of the current state
 42 2015-05-04 01:13:51 <esso> I'll try to make the format clearer
 43 2015-05-04 01:13:53 <hulkhogan_> but for example, with 'issues with overview' your case would be bolstered by providing examples of what exactly you would add, and why you feel its a pain point (specifically keeping it under 2 might be seen as a feature to some, who favor simplicity in their Uis)
 44 2015-05-04 01:14:34 <fanquake> ;;blocks
 45 2015-05-04 01:14:35 <gribble> 354863
 46 2015-05-04 01:14:45 <esso> I was planning on making some mock ups and another write up throughout the week as solutions to the issues in this writeup. Do you think I should combine the two.
 47 2015-05-04 01:14:46 <esso> I was planning on making some mock ups and another write up throughout the week as solutions to the issues in this writeup. Do you think I should combine the two.
 48 2015-05-04 01:14:46 <hulkhogan_> the margins point might actually be a quick fix, depending on if its a bug or not
 49 2015-05-04 01:14:55 <hulkhogan_> Yea mockups
 50 2015-05-04 01:15:27 <esso> I do see the advantage to having the two write ups combined.
 51 2015-05-04 01:15:59 <hulkhogan_> I would focus (this is my suggestion and it might be terrible) on one or two areas and really try to present your case as to why the change (any change) may be needed and the possible audience that might benefit, what do you think..
 52 2015-05-04 01:16:41 <hulkhogan_> So for example, you take the overview, and show some doctored screenshots, with the margins reduced, and the original, to make your case really crystal clear for the audience
 53 2015-05-04 01:18:53 <hulkhogan_> I think also, you might want to remove the summarizations of the current UI, since you might assume that the list already has some idea of what the current version looks like (eh, this may not be true but presenting issues alongside your detailed arguments seems more compelling to me, for some reason)
 54 2015-05-04 01:19:32 <esso> So instead of tackling the entirety of all the issues focus on improving let's say just the overview?
 55 2015-05-04 01:19:33 <esso> So instead of tackling the entirety of all the issues focus on improving let's say just the overview?
 56 2015-05-04 01:19:57 <hulkhogan_> pick 2, maybe 3 sections, the whole ui is a very large surface area
 57 2015-05-04 01:20:10 <hulkhogan_> it helps to stay concentrated :)
 58 2015-05-04 01:20:26 <esso> I agree the summary of the current UI/UX could be a bit redundant. UI/UX issues with the solutions would be best.
 59 2015-05-04 01:20:49 <hulkhogan_> solutions and mockups, yes
 60 2015-05-04 01:21:12 <esso> That's what I think I'll do know.
 61 2015-05-04 01:21:29 <hulkhogan_> if you have dev experience, i notice some of these could be labeled [bug] such as 'issues w/ send' point 1
 62 2015-05-04 01:22:05 <hulkhogan_> and those might actually get an 'ok' for actual github issues later, depending on severity which you could extrapolate on in comments
 63 2015-05-04 01:22:13 <fanquake> Have you guys seen jonasschnelli's core pulse mock up? Probably worth looking at if your thinking of doing some UI work
 64 2015-05-04 01:22:30 <hulkhogan_> haven't.. could be good to share a link
 65 2015-05-04 01:22:36 <fanquake> https://github.com/bitcoin/bitcoin/pull/5896
 66 2015-05-04 01:22:51 <esso> After reading through it or at least scanning. What do you think would be good sections to choose the 2-3 from. I'm thinking the overview page, rpc console, and addresses.
 67 2015-05-04 01:23:31 <esso> fanquake: Thanks!
 68 2015-05-04 01:23:32 <esso> fanquake: Thanks!
 69 2015-05-04 01:23:52 <hulkhogan_> interesting! it might be a good area to chekc for dedups^^
 70 2015-05-04 01:24:56 <hulkhogan_> esso: it depends, i think if you have more reddit linkages, those sections would be the most compelling to build your argument on, because getting user feedback is tough, but if it already exists it provides a starting point for something that a user has definitely struggled with prior
 71 2015-05-04 01:25:19 <esso> That's an excellent point
 72 2015-05-04 01:25:29 <hulkhogan_> so syncing for sure
 73 2015-05-04 01:26:22 <hulkhogan_> i would stay away from send and recieve since those are not the easiest to reason about without feedback, as well
 74 2015-05-04 01:27:06 <hulkhogan_> but it depends on where you want to spend time really, every page could easily be a several month long research project if you ask me ;p
 75 2015-05-04 01:27:07 <hulkhogan_> but it depends on where you want to spend time really, every page could easily be a several month long research project if you ask me ;p
 76 2015-05-04 01:27:40 <hulkhogan_> collecting feedback, aggregating results, formulating conclusions and so on
 77 2015-05-04 01:27:50 <hulkhogan_> (possibly writing code..)
 78 2015-05-04 01:27:58 <esso> I don't have very much dev experience as you can probably tell and if you think some of these could be labeled as bugs what do you recommend doing?
 79 2015-05-04 01:28:21 <esso> I'm going to have some time to blow soon so I'm willing to put in the time.
 80 2015-05-04 01:28:59 <hulkhogan_> well so the best thing is to collect feedback because marking a bug as a bug when it isnt perceived as a bug would not be ideal
 81 2015-05-04 01:29:00 <hulkhogan_> well so the best thing is to collect feedback because marking a bug as a bug when it isnt perceived as a bug would not be ideal
 82 2015-05-04 01:29:18 <esso> I'm going to familiarize myself with the qt framework so I could make a mock wallet or something people could download for testing.
 83 2015-05-04 01:29:31 <hulkhogan_> there are possible bugs in here that i notice but i wouldnt fixate so much on whats a bug as much as i would on collecting data so the actual pain points can be found
 84 2015-05-04 01:30:06 <hulkhogan_> yea hehe that could also help, perhaps jonasschnelli might be someone to get in touch with, maybe
 85 2015-05-04 01:30:31 <hulkhogan_> since he seems to have done orthogonal work and gotten some positiev feedback there:)
 86 2015-05-04 01:31:26 <esso> If you see something that's could really be a bug and should be brought up go a head and make the issue.
 87 2015-05-04 01:31:28 <hulkhogan_> i think he mentioned wanting to help, too
 88 2015-05-04 01:31:58 <esso> He offered to help me out last night so I definitely will be sending him an email
 89 2015-05-04 01:32:18 <hulkhogan_> lets be conservative actually, since there are lots of ways to perceive bugs in the UI that are actually specifcally designed
 90 2015-05-04 01:32:24 <hulkhogan_> ah
 91 2015-05-04 01:33:15 <hulkhogan_> i have done ui work in the past and i could not tell you how many 'bugs' i was getting reported that were actually just , aspects of the UI... (perhaps i didnt put myself in the user's shoes enough, too)
 92 2015-05-04 01:33:36 <esso> Yea it's really hard to actually define what a UI bug.
 93 2015-05-04 01:34:10 <hulkhogan_> so forgive me a bit of being suspicious of what i just told you about marking down bugs... that might just cause the paper to lose focus
 94 2015-05-04 01:34:22 <hulkhogan_> yea
 95 2015-05-04 01:35:02 <esso> I'll be focusing on issues and solutions I don't plan on making anything appear as a true bug
 96 2015-05-04 01:36:23 <hulkhogan_> and also, necessarily there isn't a requirement to present solutions per-se, its nice to have, but having a concrete case for there being a true UI painpoint might even be the (unstated?) goal of your work
 97 2015-05-04 01:37:12 <hulkhogan_> finding real problems that real users have is pretty hard, since there is a lot of underreporting going on
 98 2015-05-04 01:37:34 <hulkhogan_> (peopel quit/get frustrated, move on, etc.)
 99 2015-05-04 01:37:46 <hulkhogan_> use a web wallet, etc etc
100 2015-05-04 01:39:21 <esso> Yea that's all very true. Maybe I'll make a few issues of github for things that I can find to be a true pain point, like the syncing issue.
101 2015-05-04 01:41:30 <esso> It could help some devs become more open to revising the UI once they see there are actual issues
102 2015-05-04 01:42:30 <phantomcircuit> esso, nobody is opposed to revising the UI
103 2015-05-04 01:42:49 <phantomcircuit> it's simply that nobody is a ui expert
104 2015-05-04 01:42:56 <phantomcircuit> and/or interested in making changes
105 2015-05-04 01:44:51 <esso> phatomcircuit: This is something I'll definitely be doing then. I just always feel that whenever someone changes the way something looks like there are always people who object.
106 2015-05-04 01:46:48 <phantomcircuit> esso, you're going to want to start with ui renders or something
107 2015-05-04 01:46:54 <phantomcircuit> instead of wasting time on implementing first
108 2015-05-04 01:48:04 <esso> Yea that seems like the best bet.
109 2015-05-04 01:53:35 <hulkhogan_> yea, and probably chat with jonasschnelli a bit about his direction, i think probably some overlap of motivations there :)
110 2015-05-04 01:56:45 <gmaxwell> esso: dunno, prior UI changes only required small amounts of twiddling based on feedback.
111 2015-05-04 02:00:30 <hulkhogan_> gmaxwell: i wanted to ask earlier, regarding synching and state, are there any possible options to mitigate that for a possible fix? even if the fix is more drawn out and elaborate
112 2015-05-04 02:00:43 <hulkhogan_> for libfortuna
113 2015-05-04 02:00:54 <hulkhogan_> or whatever it will be called..
114 2015-05-04 02:00:56 <gmaxwell> It's certantly possible to make changes people would oppose but the opposition would reasons  ("This design will force users to reuse addresses" or "this design makes it easy to make irreversable error X") ...  So long as someone making the change is mentally prepared to put in N-fold more effort navigating compromise (like _any other_ contribution) then it should go fine.
115 2015-05-04 02:01:50 <hulkhogan_> Haha, document under assumptions? ;p
116 2015-05-04 02:02:05 <hulkhogan_> "contributors, be prepared (mentally) to put in ..."
117 2015-05-04 02:03:59 <gmaxwell> hulkhogan_: sure: Use some kind of synchronization primitatives internally. It's just a lot of work; because taking a boost dependency for libfortuna would be incredibly unfortunate (would basically promise almost nothing but us uses it, which would defeat the point-- e.g. I don't know another example of OSS security critical software that uses boost off the top of my head); and not taking a boost (o
118 2015-05-04 02:04:05 <gmaxwell> r similar) dependency means dealing with the non-portability of synchronization primitives in some way.
119 2015-05-04 02:04:25 <hulkhogan_> hmm
120 2015-05-04 02:04:47 <hulkhogan_> yea i see the issue now
121 2015-05-04 02:04:55 <esso> gmaxwell: why do you think there haven't been many UI changes if it's just a matter of feedback? Do you think people would go for a more "modern" design?
122 2015-05-04 02:04:56 <esso> gmaxwell: why do you think there haven't been many UI changes if it's just a matter of feedback? Do you think people would go for a more "modern" design?
123 2015-05-04 02:05:19 <hulkhogan_> well what about coming up with a synch library that is specific to Core? i mean, we need in-house solns for a lot of things, esp for consensus critical code (ref BDB-2013)
124 2015-05-04 02:05:20 <hulkhogan_> well what about coming up with a synch library that is specific to Core? i mean, we need in-house solns for a lot of things, esp for consensus critical code (ref BDB-2013)
125 2015-05-04 02:05:43 <hulkhogan_> that library *wouldnt* depend on boost, of course
126 2015-05-04 02:06:44 <hulkhogan_> then again, in house stuff is risky, hot potato, patato
127 2015-05-04 02:09:09 <hulkhogan_> i think non portability is a serious issue, but there is room for fallbacks in those arches that we dont support, and for those we do, we have a superior mechanism
128 2015-05-04 02:09:39 <hulkhogan_> (that is, the theorhetical in house library with our own synchronization primitives.)
129 2015-05-04 03:41:35 <hulkhogan_> regardless, i think its a good idea
130 2015-05-04 03:41:53 <hulkhogan_> *still
131 2015-05-04 06:00:18 <wumpus> esso: mostly due to low developer interest in the ui
132 2015-05-04 06:01:04 <wumpus> esso: before jonasschnelli there wasn't anyone doing much work on it anymore
133 2015-05-04 06:01:05 <wumpus> esso: before jonasschnelli there wasn't anyone doing much work on it anymore
134 2015-05-04 06:01:40 <wumpus> (except diapolo, but he tends to make small, hardly visible changes)
135 2015-05-04 06:13:10 <wumpus> and indeed, no one is a ui expert (certainly not one that can program c++ as well), so many changes ended up in a fight between opinions instead of a clear movement forward
136 2015-05-04 06:20:19 <wumpus> I'm all for a "more modern" design, I only have the technical requirement that it should not involve anything with javascript or browsers, and preferably stick with Qt as that's the devil we know
137 2015-05-04 06:21:18 <gmaxwell> I liked tcatm's restructuring that he posted mockups of a long time back and wish they got turned into code
138 2015-05-04 06:21:19 <gmaxwell> I liked tcatm's restructuring that he posted mockups of a long time back and wish they got turned into code
139 2015-05-04 06:22:51 <gmaxwell> ultimately I don't care much so long as it doesn't violate technical criteria (like requring inherently insecure software e.g. the browser stuff), doesn't become frustrating to power users, or encourage unsafe practices, yadda yadda.  I believe and hope that any of the things I'd ask for could be met by virtually any design approach.
140 2015-05-04 06:23:19 <gmaxwell> (well okay perhaps not if you expressed the user interface as an emulation of the tetris video game)
141 2015-05-04 06:23:42 <wumpus> or a 3d flythrough like jurassic park's 'unix' hehe
142 2015-05-04 06:23:52 <gmaxwell> primary deference would be to whomeever was actually doing the work, particularly to the extent that they were taking the time to do a thoughtful job of it.
143 2015-05-04 06:24:04 <gmaxwell> "I know this ... it's a bitcoin wallet!"
144 2015-05-04 06:24:16 <fanquake> gmaxwell Any chance you've got a link to tcatm's mockups?
145 2015-05-04 06:24:24 <gmaxwell> I wonder if sipa has seen that movie. :)
146 2015-05-04 06:24:41 <wumpus> yes, like always with open source it's mainly up to the person or people that actually do the work
147 2015-05-04 06:25:26 <gmaxwell> fanquake: found in logs, seeing if the links work...
148 2015-05-04 06:25:27 <gmaxwell> fanquake: found in logs, seeing if the links work...
149 2015-05-04 06:25:27 <gmaxwell> nope.
150 2015-05-04 06:25:28 <gmaxwell> nope.
151 2015-05-04 06:26:14 <gmaxwell> some of the relevant links were
152 2015-05-04 06:26:15 <gmaxwell> 09:58 < tcatm> saivann: WIP http://eu1.bitcoincharts.com/stuff/btcwip2.png
153 2015-05-04 06:26:15 <gmaxwell> 10:34 < tcatm> Samuel: http://188.138.99.157/stuff/qtvert17.png
154 2015-05-04 06:26:15 <gmaxwell> 15:54 < tcatm> http://eu1.bitcoincharts.com/stuff/btcwip.png Thoughts?