1 2015-01-09 00:28:44 <cfields> michagogo: thanks
  2 2015-01-09 00:29:19 <cfields> michagogo: i've been experimenting with a trivial tree and work-flow, i think i've arrived at something semi-workable
  3 2015-01-09 00:29:31 <kanzure> anyone have a huge list of obscure transactions suitalbe for fuzz testing weird edge cases?
  4 2015-01-09 00:29:34 <cfields> paveljanik: ^^
  5 2015-01-09 00:29:37 <kanzure> *suitable
  6 2015-01-09 00:29:58 <sipa> kanzure: see src/test/data/script_valid.json
  7 2015-01-09 00:30:11 <kanzure> actually i'm not doing validity, i don't know if that influences your answer
  8 2015-01-09 00:30:42 <sipa> there's also script_invalid.json
  9 2015-01-09 00:30:51 <sipa> together they do go over many known edge cases
 10 2015-01-09 00:41:29 <kanzure> any examples of txid collision?
 11 2015-01-09 06:24:08 <petertodd> gmaxwell: fwiw there are some tools out there that use the github api to grab all pull-req, etc. data off of github for archiving
 12 2015-01-09 06:24:33 <petertodd> gmaxwell: wouldn't be a bad idea to run that frequently and dump it into a git repo
 13 2015-01-09 06:26:52 <phantomcircuit> petertodd, yo dawg...
 14 2015-01-09 06:26:57 <petertodd> phantomcircuit: yo
 15 2015-01-09 06:27:12 <phantomcircuit> there's an api for that but iirc it's annoying
 16 2015-01-09 06:27:40 <petertodd> phantomcircuit: indeed - IIRC the tools need to be run by the repo owner due to API limits
 17 2015-01-09 06:28:59 <phantomcircuit> petertodd, iirc you can cheat by "watching" the repo and then abusing the rss feed
 18 2015-01-09 06:29:07 <phantomcircuit> but yes it's easier to just do it right
 19 2015-01-09 06:29:38 <petertodd> knowing github they might be storing it all in a git repo on the backend anyway... :P
 20 2015-01-09 06:29:55 <phantomcircuit> petertodd, https://developer.github.com/webhooks/#services
 21 2015-01-09 06:29:56 <phantomcircuit> dat
 22 2015-01-09 06:30:15 <iwilcox> petertodd: Know the names of any of them?  Poked around superficially but perhaps my keyword-fu is weak.
 23 2015-01-09 06:30:37 <petertodd> iwilcox: nah sorry, I last looked into this stuff a year and a half ago if not more
 24 2015-01-09 06:31:50 <petertodd> hmm... I'll bet you a MVP for this would be to scrap the entire set of "repo events" and dump it into a big file with no parsing... parse it later
 25 2015-01-09 06:32:18 <iwilcox> I'd be surprised if bitcoin's level of activity needed repo owner API keys.  Just being signed in gives you 5000/hour I think.
 26 2015-01-09 06:32:47 <iwilcox> Plus if you're sane with checking last-modified/ETag, they don't count the request against that.
 27 2015-01-09 06:33:18 <petertodd> ah good!
 28 2015-01-09 06:34:49 <iwilcox> If tools exist and work against the current API (I see references to API changes having broken stuff previously) then great.
 29 2015-01-09 06:51:55 <iwilcox> github-backup looks comprehensive but lacks label support, notes-on-commits support, and appears it could do a smarter job with avoiding re-downloading.
 30 2015-01-09 06:53:22 <iwilcox> Plus it's in Haskell.  I don't have anything against Haskell but it's not widely known enough that I'd want to rely on it.
 31 2015-01-09 06:54:21 <petertodd> ugh
 32 2015-01-09 06:55:10 <petertodd> heck, I just had a conversation with a company that other day that wrote some backend software in scala: "Hey, do you know scala? Do you know anyone who knows scala? Please?"
 33 2015-01-09 06:55:24 <sipa> haha
 34 2015-01-09 06:56:05 <iwilcox> I expect overall it improves the quality of hires when you /do/ find them, but for OSS already struggling for contributors, not so great.
 35 2015-01-09 06:56:57 <petertodd> iwilcox: at one point I knew Haskell, but that was a few years back and I've mostly forgotten it - could pick it up soonish, but who's going to do that just to contribute to an OSS project?
 36 2015-01-09 06:57:23 <iwilcox> Worse, it's apparently a pig to learn in the first place.  Steep learning curve, I hear.
 37 2015-01-09 06:58:02 <petertodd> iwilcox: oh, and that leads to an interesting point: In my experience learning Haskell is like learning how to fly a plane, not ride a bicycle. Your skills atrophy because it's so unlike how people (usually!) naturally think.
 38 2015-01-09 06:58:24 <phantomcircuit> petertodd, i know people who know scala
 39 2015-01-09 06:58:57 <phantomcircuit> they all write toy software
 40 2015-01-09 06:58:59 <wumpus> someone actually wrote something practical in haskell? *ducks*
 41 2015-01-09 06:59:04 <petertodd> phantomcircuit: ha
 42 2015-01-09 06:59:07 <phantomcircuit> worst case some webpage renders wrong
 43 2015-01-09 06:59:26 <iwilcox> petertodd: Still, a regular invocation of even an opaque tool that mostly works would be a vast improvement over "we have no plan B"
 44 2015-01-09 06:59:29 <sipa> wumpus: the hedgewars server software is written in it!
 45 2015-01-09 07:00:14 <petertodd> iwilcox: yeah, of course, I'm increasingly liking my "just scrape the events log" idea - figure out how to parse it later only if needed
 46 2015-01-09 07:00:30 <petertodd> iwilcox: if that opaque tool breaks, would be even notice?
 47 2015-01-09 07:01:00 <iwilcox> petertodd: Not so keen on that.  Two problems being addressed here: 1) access to the issues etc if there's a github outage (dump is useless) 2) losing comments on commit fragments over rebases (scrape helps not a bit)
 48 2015-01-09 07:01:29 <iwilcox> I guess it helps with 3) Github kicks bitcoin for weeks owing to silly misunderstanding
 49 2015-01-09 07:01:32 <petertodd> iwilcox: it should help re: comments, so long as the comments end up in the log
 50 2015-01-09 07:01:56 <iwilcox> Only if they're accessible within a reasonable timeframe after Github disappears though, right?
 51 2015-01-09 07:02:11 <wumpus> sipa: wow okay, usually my experience is that people write haskell because it's such an elegant language, but then stop when they require all the masochistic execises to do I/O to the real world
 52 2015-01-09 07:02:18 <petertodd> iwilcox: now, I'm not going to say you *shouldn't* run a more complex tool, just saying having a direct copy of the events feed would be what'd be safest
 53 2015-01-09 07:03:06 <petertodd> wumpus: yeah, my reply to that company was something along the lines of I mainly write funtional-style Python code if I have the choice
 54 2015-01-09 07:03:09 <wumpus> sipa: or, maintaining the project and say having to add a parameter (or god forbid, state) somewhere, which means changing it everywhere in the entire program
 55 2015-01-09 07:03:51 <iwilcox> I didn't mean the Haskell thing to turn into a languages discussion, really.  Was just a "Bitcoin isn't a Haskell-friendly shop" thing.
 56 2015-01-09 07:03:58 <wumpus> petertodd: yes, functional style python is very powerful (so is haskell, but doing practical things is very hard)
 57 2015-01-09 07:04:28 <wumpus> petertodd: python is a nice mix in that, at least for quickly writing tools
 58 2015-01-09 07:04:39 <sipa> i love haskell, but i end up not using it mostly because i care too much about performance for things where performance matters
 59 2015-01-09 07:04:42 <petertodd> wumpus: don't forget how hard debugging haskell can be for normal programmers (though I didn't find that so bad as most of my programming experience at the time was on embedded systems w/o debugging tools)
 60 2015-01-09 07:05:03 <wumpus> performance of haskell should be  pretty good?
 61 2015-01-09 07:05:17 <sipa> and for things where it doesn't, perl or python are easier as quick hacking tool
 62 2015-01-09 07:05:28 <sinetek> does python do tail recursion yet?
 63 2015-01-09 07:05:32 <petertodd> it's often very hard to predict if your haskell code will perform well - difficult to be sure that it'll compile to good code
 64 2015-01-09 07:05:50 <petertodd> sinetek: it *delibrately* doesn't because tail recursion isn't an optimization, it's a language design choice
 65 2015-01-09 07:05:52 <wumpus> petertodd: yes, debugging someone elses's code in haskell is also an execise in itself
 66 2015-01-09 07:05:58 <sinetek> bleh.
 67 2015-01-09 07:06:33 <wumpus> petertodd: that's true, to know how to write optimized haskell code you need to know and the language, and the compiler in depth
 68 2015-01-09 07:07:00 <petertodd> wumpus: yup, and getting to that point is very non-trivial
 69 2015-01-09 07:07:14 <wumpus> petertodd: which kind of defeats the niceness of writing lazy expressions and such in the first place
 70 2015-01-09 07:07:20 <phantomcircuit> BURN THE HASKELL LOVER!
 71 2015-01-09 07:07:24 <phantomcircuit> 
ACTION flees

 72 2015-01-09 07:07:46 <wumpus> petertodd: I had a similar experience with prolog in the 90's, it's all nice until you get to tree pruning and other hacks, so I'm kind of wary
 73 2015-01-09 07:07:54 <phantomcircuit> ffs
 74 2015-01-09 07:07:54 <phantomcircuit> ../libcrypto.a: error adding symbols: Success
 75 2015-01-09 07:08:11 <petertodd> sinetek: keep in mind, the main usage of python is actually "semi" programmers - hugely popular in scientific, engineering, etc. fields that don't hang out on news.ycombinator.com
 76 2015-01-09 07:08:14 <phantomcircuit> error: Success
 77 2015-01-09 07:08:52 <petertodd> wumpus: and small changes to the code can easily break the ability of the compiler to optimize, leading to sudden performance regressions - in bitcoin this could even be a consensus issue
 78 2015-01-09 07:08:59 <sinetek> petertodd: sounds like ycombinator to me actually. you rarely see a positive comment wrt C++ on HN
 79 2015-01-09 07:09:20 <wumpus> petertodd: yes, it's kind of the new basic, especially for scientists and such. My sister (which studies neurology) never did programming, until she learned python
 80 2015-01-09 07:09:34 <wumpus> *had to learn python for her reseach
 81 2015-01-09 07:09:43 <sipa> ah, it's python now
 82 2015-01-09 07:10:04 <petertodd> wumpus: yup, I know multiple people with fine arts degrees who have learned python for various reasons
 83 2015-01-09 07:10:05 <sipa> until a few years ago several scientific fields used perl
 84 2015-01-09 07:10:55 <petertodd> sipa: some parts of the electronic design automation field use TCL oddly enough
 85 2015-01-09 07:11:35 <wumpus> perl is used too, but its syntax is intimidating to a lot of people, it's not considered as friendly as python
 86 2015-01-09 07:11:37 <sinetek> afaik javaschools are moving to python
 87 2015-01-09 07:11:41 <sinetek> so it's CS too now.
 88 2015-01-09 07:12:32 <wumpus> petertodd: and language/compiler research still uses a lot of ocaml
 89 2015-01-09 07:12:47 <petertodd> sinetek: yup, apparently a common approach is python first, then C/toy assembler/microprocessor assembler
 90 2015-01-09 07:13:47 <phantomcircuit> petertodd, it's pretty easy to teach people python
 91 2015-01-09 07:13:58 <wumpus> ocaml (and similar languages) are considered 'practical FP languages', seemingly it's good if you do a lot of tree matching
 92 2015-01-09 07:14:35 <petertodd> wumpus: interesting, never tried it myself
 93 2015-01-09 07:22:34 <sipa> wumpus: i used ocaml for a while, can't say i liked it much
 94 2015-01-09 07:23:40 <sinetek> i'm going back to pre-ANSI C
 95 2015-01-09 07:24:26 <sinetek> too much syntactic sugar makes you syntactically fat
 96 2015-01-09 07:24:56 <sipa> dude
 97 2015-01-09 07:25:02 <wumpus> sipa: I never got into it deeply, mostly had to use the toolchains and such to compile other people's code
 98 2015-01-09 07:25:08 <sipa> use a magnetized needle and a steady hand please
 99 2015-01-09 07:25:09 <petertodd> programming languages are fundementally user interfaces between you and machine code - they damn well should be designed for humans
100 2015-01-09 07:25:39 <petertodd> sipa: yeah, I got this really nice magnetized needle is a great ergonomic handle and a stabalizing system
101 2015-01-09 07:30:12 <sinetek> human language is fundamentally ambiguous
102 2015-01-09 07:34:48 <wumpus> because it relies on interactive communication
103 2015-01-09 07:35:16 <petertodd> sinetek: it is, which is why designing programming languages is tricky. A case in point is python, which decided to reduce human-level ambiguity by making the clever design choice to use whitespace as syntax.
104 2015-01-09 07:35:48 <petertodd> wumpus: and lots of meat https://www.youtube.com/watch?v=7tScAyNaRdQ
105 2015-01-09 07:36:27 <sinetek> fair enough. in my opinion the language is quite bland. no interesting recursion as in haskell, and nothing powerful from C either
106 2015-01-09 07:36:59 <sinetek> It's in the same category as Java I guess.
107 2015-01-09 07:37:05 <petertodd> sinetek: "quite bland" <- I think you just summed up Guido van Rossum's design philosophy :)
108 2015-01-09 07:37:52 <petertodd> sinetek: re: "power" the C-extension API for Python is excellent - very well documented and easy to use
109 2015-01-09 07:39:00 <sinetek> like, you can learn python as first language, but you will be missing important concepts such as pointers, and more purely functional things, both of which are the basis of everything else :p
110 2015-01-09 07:39:09 <sinetek> Maybe. Idk
111 2015-01-09 07:39:15 <wumpus> and there's always ctypes. Nice about python is that you can interface to about everything, in most cases packages already exist, and if not it's easy to write them. It's perfect for glue code and tooing.
112 2015-01-09 07:39:19 <sinetek> Obviously you don't fall in that category :D
113 2015-01-09 07:39:57 <petertodd> sinetek: sure, which is why curriculums are often following up Python with C/assembler - equally Python *does* use pointers all over the place in the form of references
114 2015-01-09 07:40:34 <sipa> wumpus: google decided at some point to discourage new python projects though
115 2015-01-09 07:40:35 <petertodd> wumpus: "glue code" is a funny concept, given how in practice the glue is 95% of the work these days
116 2015-01-09 07:40:58 <wumpus> sipa: google probably has something better internally
117 2015-01-09 07:41:16 <wumpus> petertodd: yup, exactly my point
118 2015-01-09 07:41:39 <petertodd> wumpus: with sufficient funding and good people you can certainly do better than Python... but without that you can do a lot worse not using Python
119 2015-01-09 07:43:55 <sipa> wumpus: go
120 2015-01-09 07:44:08 <wumpus> sipa: also it took a lot of time for them to get to that conclusion, after all they hired Guido for a while, it makes me think it's more of a large-corporation-politics thing
121 2015-01-09 07:44:31 <petertodd> wumpus: maybe the right analogy for glue code is to describe it as model building: sure 99% of the mass is plastic, but that's highly engineered mass-produced stuff pumped out by industrial molds, 99% of the actual man hours is figuring out how to glue the plastic parts together
122 2015-01-09 07:48:56 <petertodd> ^ you know, the above is so blindingly obvious I think I need to find some coffee... bbl
123 2015-01-09 07:49:10 <sinetek> hehe
124 2015-01-09 07:49:14 <wumpus> petertodd: yes, the analogy makes sense, in the case of software it's mostly the same
125 2015-01-09 07:50:04 <petertodd> wumpus: lol, I think somewhere my non-caffinated brain simply had never heard anyone *actually* explain the analogy completely :)
126 2015-01-09 07:52:25 <sipa> "$1 for the chalk mark, $9999 for knowing where to put it"
127 2015-01-09 07:54:08 <petertodd> sipa: one of the most awesome moments I had in my last job was demoing a SQUID controller I was working on to some investors - it wasn't syncing up properly, so I (quite obviously to the investors) waved my hand around the right part of the unshielded circuit to make it work again
128 2015-01-09 07:54:47 <phantomcircuit> petertodd, it's actually really difficult to find people who are competent
129 2015-01-09 07:55:07 <phantomcircuit> it's slightly less difficult to find people who can build something competent in python
130 2015-01-09 07:56:36 <petertodd> phantomcircuit: ugh, tell me about it... not only are they rare, but I've also found that the competent people often can't be hired no matter how much money you throw at them (which doesn't surprise me at all because I do that too)
131 2015-01-09 07:59:23 <sinetek> I wish more programmers did it. Would fix the environments quite a bit
132 2015-01-09 08:03:41 <wumpus> not the least because programming without a deeper interest in the subject matter, just for money, is an awful job
133 2015-01-09 08:04:27 <slick2> agree
134 2015-01-09 08:04:54 <petertodd> wumpus: I suspect that's true of basically ever creative thought-intensive job - forcing yourself to concentrate on stuff you aren't interested is miserable and ineffective
135 2015-01-09 08:05:49 <moa> zen and the art of motorcycle maintenance
136 2015-01-09 08:07:31 <sipa> wumpus, petertodd: ever saw that rsa animate video about what motivates people?
137 2015-01-09 08:07:54 <petertodd> sipa: beingo
138 2015-01-09 08:07:56 <petertodd> *bingo
139 2015-01-09 08:08:01 <jonasschnelli> What about bots in this channel? Any freenode concerns when bringing bots to #bitcoin-dev?
140 2015-01-09 08:08:04 <sinetek> link please?
141 2015-01-09 08:08:20 <sipa> RSA Animate - The Surprising Truth About What Mot…: http://youtu.be/q_y-Wjz1h3s
142 2015-01-09 08:08:37 <petertodd> sipa: having gone to art school, that video wasn't surprising at all...
143 2015-01-09 08:09:05 <sipa> in retrospect, i don't find it hard to believe at all either
144 2015-01-09 08:09:15 <sipa> but it was still interesting to see
145 2015-01-09 08:09:42 <jonasschnelli> just thought it would maybe useful to have a simple github bot here. Post new PRs/Issues. Possibility of simple queries. Like PULL #5540 (would get title and github link), etc.
146 2015-01-09 08:09:47 <petertodd> sipa: yeah, good thing to send people who aren't from that background
147 2015-01-09 08:10:24 <wumpus> petertodd: yes that's very true
148 2015-01-09 08:10:25 <sipa> jonasschnelli: #bitfoin-commits
149 2015-01-09 08:10:33 <wumpus> jonasschnelli: no bots here please
150 2015-01-09 08:11:07 <wumpus> sipa jonasschnelli or #bitcoin-core-dev
151 2015-01-09 08:11:12 <petertodd> sipa: something missing from that video IIRC was more discussion about the social aspects of work - often there are situations where work has a significant positive/negative cost due to peer group approval/disapproval
152 2015-01-09 08:11:19 <jonasschnelli> wumpus, sipa ah. didn't new that. Nice. thanks.
153 2015-01-09 08:12:24 <wumpus> sipa: didn't know that video yet
154 2015-01-09 08:12:34 <petertodd> sipa: concrete example: I've frequently been asked to find people to audit php/java libraries, which in the crypto peer group is damn near impossible because the stigma of working with those languages is huge
155 2015-01-09 08:13:14 <petertodd> sipa: I literally have gotten responses along the lines of "actually I do know php, but please don't tell anyone"
156 2015-01-09 08:13:33 <sinetek> Michael Ochurch has an excellent blog on the subject
157 2015-01-09 08:13:36 <wumpus> petertodd: especially php, it has such a  stigma, you wouldn't want to give your stamp of approval to any php project
158 2015-01-09 08:14:10 <petertodd> wumpus: indeed, yet you can *also* find people for whome working in php is part of their identity - "I'm not some stuck up academic"
159 2015-01-09 08:14:22 <wumpus> petertodd: I'm ambivalent about java, it's boring, but also straightforward and has very little foot-shooting possibilities
160 2015-01-09 08:14:44 <sipa> petertodd: i wrote a latex parser in php, shut up
161 2015-01-09 08:14:46 <wumpus> petertodd: (javascript on the other hand.... )
162 2015-01-09 08:15:00 <petertodd> sipa: yeah, but you're so badass doing shit like that goes with the flow
163 2015-01-09 08:15:09 <sipa> lol
164 2015-01-09 08:15:45 <petertodd> wumpus: javascript is an awesome example, because of how it's getting "rebranded" as Lets Bring Crypto To The Masses Fuck The NSA is some circles
165 2015-01-09 08:16:48 <sinetek> hey, let's reinterpret your balance as a boolean!
166 2015-01-09 08:17:19 <sinetek> or maybe it was a string?
167 2015-01-09 08:17:30 <wumpus> petertodd: haha yes, conveniently forgetting the fractal of attack surface that running everyone's untrusted code on the web brings to you in the first place, and how easy it is to screw your code up with slight syntactical problems that don't get caught at either compile and runtime
168 2015-01-09 08:17:48 <sinetek> your balance is -30495.34 BTC!
169 2015-01-09 08:18:56 <wumpus> petertodd: I'm sure the NSA is laughing that one out :-)
170 2015-01-09 08:20:17 <petertodd> wumpus: ha, probably! but sadly the social aspects alone of how easy it is to have people using your code are a huge pressure in javascript's favor
171 2015-01-09 08:20:38 <jonasschnelli> BE: ./autogen.sh on MIPS don't run through... any clue?
172 2015-01-09 08:21:01 <wumpus> jonasschnelli: worked fine for me, I compiled and run bitcoind on both BE and LE mips
173 2015-01-09 08:21:14 <wumpus> jonasschnelli: do you have more specifics?
174 2015-01-09 08:21:21 <sinetek> is there a way to run the raspberry pi in BE mode?
175 2015-01-09 08:21:31 <sinetek> Sorry, I should really RTFM that
176 2015-01-09 08:21:37 <wumpus> sinetek: if other ARM systems are anything to go by: bi
177 2015-01-09 08:21:42 <wumpus> s/bi/no
178 2015-01-09 08:21:48 <jonasschnelli> sinetek, would be, but you need a rpi BE debian edition... i assume this don't exists
179 2015-01-09 08:22:04 <sinetek> Yeah, just wondering why.
180 2015-01-09 08:22:08 <sinetek> ARM is biendian.
181 2015-01-09 08:22:18 <wumpus> in theory, yes
182 2015-01-09 08:22:21 <moa> now that most of core devs are doing bitcoin coding as paid jobs I wonder what they'll be getting up to in their 'free' time?
183 2015-01-09 08:22:24 <wumpus> in practice no one uses BE ARM
184 2015-01-09 08:22:27 <sinetek> (like PPC?)
185 2015-01-09 08:22:33 <petertodd> moa: hookers and blow myself
186 2015-01-09 08:22:36 <jonasschnelli> wumpus, last things i got in the output: hrtimer: interrupt took 74704999 ns ... and then some GZIP_ENV and distcleanckeck infos...
187 2015-01-09 08:22:41 <jonasschnelli> but no makefile
188 2015-01-09 08:22:56 <wumpus> petertodd: yes, the social aspects tend to push in favor of javascript, and mobile apps...
189 2015-01-09 08:23:01 <lewellyn> sinetek: arm is bi-endian, not "big-endian" :)
190 2015-01-09 08:23:10 <jonasschnelli> arm can both
191 2015-01-09 08:23:14 <sinetek> sure, but it can go both ways
192 2015-01-09 08:23:16 <sinetek> is the point :p
193 2015-01-09 08:23:21 <lewellyn> hence bi :)
194 2015-01-09 08:23:43 <wumpus> moa: free time? what? :)
195 2015-01-09 08:24:04 <jonasschnelli> moa, there are still some code lover that code like zen-monks without any need for money. :)
196 2015-01-09 08:24:07 <moa> you know, to do the stuff you really love ... lol
197 2015-01-09 08:24:08 <jonasschnelli> that/they
198 2015-01-09 08:24:14 <petertodd> wumpus: along those lines a nice trick w/ python-bitcoinlib that I use all the time is to put the library into your projects as a subtree, so git clone ; ./run-project works instantly with no installation
199 2015-01-09 08:24:41 <petertodd> wumpus: pip install python-bitcoinlib is a huge point of friction
200 2015-01-09 08:25:40 <wumpus> petertodd: good point, I always do that for python dependencies, I don't like installing things site-wide or messing with virtualenv
201 2015-01-09 08:25:53 <sinetek> http://code.google.com/p/raspberrypi-openwrt/source/browse/toolchain/gcc/patches/llvm/800-arm-bigendian.patch?name=master&r=3ff79f2c45157f92d00066bbdcd02e8dbad36c5e
202 2015-01-09 08:26:08 <sinetek> this is the nerd equivalent of customized phone cases.
203 2015-01-09 08:26:20 <petertodd> wumpus: for consensus code it also helps make it explicit what exactly the behavior is
204 2015-01-09 08:33:20 <jonasschnelli> sinetek, the llvm patch won't help you to get a BE kernel running on your rpi
205 2015-01-09 08:33:21 <wumpus> moa: well for fun I mostly play around with obscure computing experiments, so yes my hobbies involve programming too, I also read a book sometimes
206 2015-01-09 08:34:23 <sinetek> the bootloader apparently doesn't know how to play nice with a BE kernel
207 2015-01-09 08:35:01 <jonasschnelli> sinetek i try no to emulate MIPS with qemu. Horrible slow.
208 2015-01-09 08:35:19 <petertodd> moa: seriously speaking the lines between fun and work are very badly blurred for me; billing clients is just this annoying thing I have to do to pay rent
209 2015-01-09 08:36:12 <petertodd> moa: put another way, aspects of my hobbies feel *equally* as much as "work" as aspects of bitcoin does to me
210 2015-01-09 08:37:15 <wumpus> "billing clients is just this annoying thing I have to do to pay rent" haha indeed
211 2015-01-09 08:38:58 <petertodd> wumpus: I honestly don't know off the top of my head how much money I made last year; I have all the records for taxes, but I haven't actually put it into a spreadsheet yet
212 2015-01-09 08:39:54 <wumpus> jonasschnelli: emulating mips BE is also lots slower than emulating mips LE, still I synced the entire testnet chain as well as a large part of the mainnet chain that way
213 2015-01-09 08:40:20 <jonasschnelli> wumpus, qemu?
214 2015-01-09 08:40:29 <wumpus> jonasschnelli: yes
215 2015-01-09 08:40:38 <jonasschnelli> wumpus, ubuntu MIPS?
216 2015-01-09 08:40:40 <sinetek> what other archs have been tried? microblaze perhaps?
217 2015-01-09 08:41:35 <sinetek> i would test the raspberry pi BE mode, but I don't have the proper DVI cable
218 2015-01-09 08:41:38 <wumpus> sinetek: no, I haven't tried microblaze yet
219 2015-01-09 08:42:02 <wumpus> sinetek: my last focus was on compiliing for moxie
220 2015-01-09 08:42:09 <jonasschnelli> sinetek, for rip, do you have a BE os ready for the pi?
221 2015-01-09 08:42:09 <wumpus> jonasschnelli: qemu-user
222 2015-01-09 08:42:15 <wumpus> jonasschnelli: not full system emulation
223 2015-01-09 08:42:45 <sinetek> jonasschnelli: I do not, just getting the kernel running should suffice for proof of concept though
224 2015-01-09 08:42:47 <wumpus> sinetek: apart from that I've tried armhf, aarch64, and mipsbe/mipsle
225 2015-01-09 08:42:57 <jonasschnelli> wumpus, hm.. because qemu-system-mips64 let me run into timer interrupts... even with 1GB ram.
226 2015-01-09 08:43:06 <sinetek> Ok.
227 2015-01-09 08:52:26 <wumpus> sinetek: phantomcircuit IIRC was running secp256k1 on AVR, but didn't get as far as bitcoind
228 2015-01-09 08:53:19 <sinetek> that could come in pretty handy in fact
229 2015-01-09 08:55:16 <wumpus> was too slow to be practical
230 2015-01-09 09:21:16 <sinetek> petertodd: do you have a novena perhaps?
231 2015-01-09 09:28:47 <phantomcircuit> wumpus, midnightmagic wasdoing that
232 2015-01-09 09:28:58 <wumpus> phantomcircuit: ah yes, sorry
233 2015-01-09 09:29:06 <phantomcircuit> but yeah it was lol slow
234 2015-01-09 09:35:04 <paveljanik> is there any usecase in our tree for negative CAmount at all? What is the reason for signed CAmount?
235 2015-01-09 09:36:14 <wumpus> paveljanik: some uses in e.g. the wallet use negative numbers
236 2015-01-09 09:36:58 <wumpus> also paradoxally in many cases it is *harder* to be robust against underflows and such if you have unsigned numbers
237 2015-01-09 09:37:31 <wumpus> e.g. if((a-b)<0) constructions will no longer work
238 2015-01-09 09:39:32 <paveljanik> thanks for explanation.
239 2015-01-09 09:39:53 <paveljanik> class CAmount then?
240 2015-01-09 09:40:14 <paveljanik> a<b?
241 2015-01-09 09:40:16 <paveljanik> ;-)
242 2015-01-09 09:40:20 <paveljanik> much more readable...
243 2015-01-09 09:40:34 <wumpus> it was just an example, actual cases are much more tricky.
244 2015-01-09 09:40:39 <paveljanik> yup
245 2015-01-09 09:41:05 <wumpus> yes in retrospect using a number class that explicitly traps overflows and underflows would have been desirable
246 2015-01-09 09:41:14 <wumpus> but it's not acceptable to just change it in the consensus code now
247 2015-01-09 09:41:36 <paveljanik> I think wallet should not use "our" CAmount anyway...
248 2015-01-09 09:41:49 <wumpus> but it does.
249 2015-01-09 09:41:54 <paveljanik> now. yes.
250 2015-01-09 09:42:44 <wumpus> but indeed, I've also proposed using a different amount representation inside and outside the consensus implementation at times
251 2015-01-09 09:42:59 <wumpus> (well not different representation, but different type)
252 2015-01-09 09:43:41 <wumpus> that's kind of what stranded jtimon's CAmount changes - he wanted to use it everywhere, also in consensus code
253 2015-01-09 09:45:30 <wumpus> in wallet code (and other financial or interface code), a type that traps on underflows and overflows could avoid a lot of potential bugs
254 2015-01-09 09:47:13 <paveljanik> +1
255 2015-01-09 09:47:41 <paveljanik> "CAmount" should reflect the protocol type
256 2015-01-09 09:48:33 <paveljanik> thanks for valuable discussion
257 2015-01-09 10:31:04 <jonasschnelli> wumpus, needs GUI tag: https://github.com/bitcoin/bitcoin/issues/5625
258 2015-01-09 10:37:22 <paveljanik> jonasschnelli, while you are at it, can you have a look why the clock icon at https://cloud.githubusercontent.com/assets/178464/5678305/42cdae68-97f1-11e4-9f23-1817ea301db5.png is not displayed completely? Resize dialog a bit?
259 2015-01-09 10:37:32 <paveljanik> nice anyway :-)
260 2015-01-09 10:37:43 <jonasschnelli> paveljanik, yes. already addressing that
261 2015-01-09 10:37:54 <jonasschnelli> the "+" icon is also to big
262 2015-01-09 10:37:56 <paveljanik> :-) Thank you :-)
263 2015-01-09 11:28:36 <bedeho> Is the lock_time field in the transactions presently used? and is it used as one would expect, i.e. transaction cannot be mined in block with earlier timestamp/block number?
264 2015-01-09 11:32:36 <paveljanik> jonasschnelli, your OS X icons look a bit smaller than mine...
265 2015-01-09 11:37:01 <jonasschnelli> paveljanik, hmm... how do you build? Qt4?
266 2015-01-09 11:37:44 <paveljanik> yes
267 2015-01-09 11:38:12 <wumpus> on macosx it is really advised to use qt5
268 2015-01-09 11:39:19 <paveljanik> hmm, ok. I'll try to update
269 2015-01-09 11:39:49 <wumpus> qt4 is supported, as in it should not crash or fail to compile or such, but you'll get a subpar GUI
270 2015-01-09 11:40:48 <paveljanik> 
ACTION checking his notes...

271 2015-01-09 11:41:00 <paveljanik> I use macports and https://trac.macports.org/ticket/44204 was the reason why I downgraded...
272 2015-01-09 11:59:01 <petertodd> sinetek: I got my novena last week; haven't had a chance to try it out yet
273 2015-01-09 12:00:10 <petertodd> bedeho: not only is nLockTime used, it's used in production by greenaddress.it, among others
274 2015-01-09 12:00:54 <petertodd> bedeho: also v0.10 uses nLockTime for *all* transactions to discourage miners from trying to reorganize the chain to collect fees (not an issue yet, but may become one in the future)
275 2015-01-09 12:01:13 <jonasschnelli> paveljanik, Qt4 doesn't support retina as far as i know
276 2015-01-09 12:01:40 <wumpus> jonasschnelli: indeed
277 2015-01-09 12:02:18 <bedeho> petertodd: thanks, and is it also the case that you can update transactions with nliktime > 0 by altering the sequence number of outputs? is that presently used?
278 2015-01-09 12:02:19 <petertodd> speaking of, blockchain.info now shows information on nLockTime: https://blockchain.info/tx/ac7a8c04c20142cbdfa233dfdc01f74708d1fc53ae3d19e2445dd4fa62e8dc8d https://blockchain.info/tx/dc2d3daa696fde09cb09092d139034c13751eb54d354410792532f180a9a6641
279 2015-01-09 12:02:19 <wumpus> that was the reason for the switch to qt5 in the first place
280 2015-01-09 12:02:26 <paveljanik> then I have to wait for macports to fix it...
281 2015-01-09 12:02:36 <petertodd> bedeho: nope, that feature was never secure so it's been removed permanently
282 2015-01-09 12:02:43 <bedeho> ok
283 2015-01-09 12:03:22 <petertodd> bedeho: of course, you can change the nSequence value to whatever you want - maybe useful for some protocols - but it has no meaning to Bitcoin Core other than enabling/disabling nLockTime
284 2015-01-09 12:03:41 <bedeho> petertodd: while I have your attention, what about your replace by fee scheme, does that work for updating transactions?
285 2015-01-09 12:03:53 <petertodd> bedeho: yes, and it's "secure" in the sense that it is incentive-compatible
286 2015-01-09 12:04:35 <bedeho> by does it work, I mean, is it actually used by the present version of core?
287 2015-01-09 12:05:21 <petertodd> bedeho: github.com/bitcoin/bitcoin does not implement replace-by-fee, however I have a fork that does; it does work right now in a slightly more limited sense in that it can be used to get higher fee transactions to miners easily
288 2015-01-09 12:05:47 <petertodd> bedeho: in terms of double-spending resistance right now we have the worst of all worlds: double-spending is really easy, yet replacing transactions is annoying
289 2015-01-09 12:07:58 <bedeho> petertodd: right, just so I understand, replace by fee makes it possible to deterr double spends by spending the invalidated transaction to a new transaction which has a higher fee than the double spending transaction?
290 2015-01-09 12:08:44 <sipa> petertodd: i may be missing something, but why do you need a way to encode invalid signatures?
291 2015-01-09 12:08:46 <petertodd> bedeho: mostly correct: with replace-by-fee + a fairly advanced child-pays-for-parent, you can do that with any transaction, with just replace-by-fee you can do that if the sending wallet supports it
292 2015-01-09 12:09:13 <sipa> petertodd: in checkmultisig, if any of the passed sigs is invalid for every pubkey, the checksig fails
293 2015-01-09 12:09:26 <petertodd> sipa: BIP19 is an example; the scriptSig can contain invalid signatures if less keys are needed
294 2015-01-09 12:10:29 <sipa> i must be misunderstanding checkmultisig
295 2015-01-09 12:10:48 <petertodd> sipa: this isn't for checkmultisig, this is for more complex scripts
296 2015-01-09 12:10:56 <sipa> ah
297 2015-01-09 12:11:16 <petertodd> sipa: BIP19 is stuff like   {pubkey} OP_CHECKSIG OP_SWAP {pubkey} OP_CHECKSIG OP_ADD OP_SWAP {pubkey} OP_CHECKSIG OP_ADD {n} OP_EQUAL
298 2015-01-09 12:11:57 <petertodd> sipa: so in that case, I can make it a 1-of-3 by setting {n} to 1, and then providing OP_0 for the other two pubkeys
299 2015-01-09 12:12:06 <sipa> oh yes
300 2015-01-09 12:12:11 <petertodd> sipa: saves having to put in a whole bunch of IF ENDIF's
301 2015-01-09 12:12:15 <sipa> sorry, just waking up
302 2015-01-09 12:13:51 <bedeho> petertodd: child-pays-for-parent is already in production?
303 2015-01-09 12:13:51 <petertodd> Luke-Jr: reminds me, it's a pity we don't have OP_MUL, or BIP19 could do different weights for different keys easily :)
304 2015-01-09 12:14:38 <petertodd> bedeho: it's not included in bitcoin core, although Luke-Jr maintains a patch that does it. Also just child-pays-for-parent isn't quite enough: you need to be able to tell peers to evaluate a whole chain of transactions for potential inclusion
305 2015-01-09 12:15:09 <Luke-Jr> bedeho: it's been live on Eligius for years (and a few others since then)
306 2015-01-09 12:15:27 <petertodd> bedeho: much easier is to have special wallet support for scorched-earth payments and sign your transactions with SIGHASH_ANYONECANPAY - probably better too as normal wallets can't be trusted not to doublespend on occasion
307 2015-01-09 12:16:55 <jonasschnelli> paveljanik, use brew there you can have multiple version of Qt installed and do a nice auto-switching (with a symlink backend)
308 2015-01-09 12:19:48 <paveljanik> I'll try to fix macports bug first ;-)
309 2015-01-09 12:21:35 <petertodd> sipa: BTW I seem to remember you having some code already to track nLockTime usage - might be a good graph to watch v0.10 adoption
310 2015-01-09 12:25:41 <Luke-Jr> or at least compare transaction-volume-adoption vs listening-node-adoption
311 2015-01-09 12:26:09 <petertodd> Luke-Jr: true - mainly curious how many people use v0.10 as a wallet
312 2015-01-09 12:36:37 <bedeho> petertodd: What is the difference between a micropayment channel as documented on the bitcoin wiki, and a jeremy spillmans approach?
313 2015-01-09 12:38:32 <jonasschnelli> cfields, would it be hard to include a bold warning when compiling on OSX with < Qt5?
314 2015-01-09 12:38:47 <petertodd> bedeho: should be the same, but the bitcoin wiki incorrectly says nSequence will be enabled in the future last I checked
315 2015-01-09 12:38:53 <jonasschnelli> because it breaks user experience significant
316 2015-01-09 12:39:18 <bedeho> petertodd: yes, that always threw me off, good to hear
317 2015-01-09 12:39:51 <petertodd> bedeho: yeah, that's written by mike hearn, who has vies on nSequence that aren't shared by others
318 2015-01-09 12:39:55 <petertodd> *views
319 2015-01-09 12:41:43 <jonasschnelli> I like to test the bip70 stuff in Qt. Never had a look at it. What a easy way to create payment requests?
320 2015-01-09 12:41:56 <jonasschnelli> s/What a/Whats an
321 2015-01-09 12:42:48 <petertodd> jonasschnelli: I've never tried it myself, but someone contributed a bip70 example to python-bitcoinlib: https://github.com/petertodd/python-bitcoinlib/blob/master/examples/bip-0070-payment-protocol.py
322 2015-01-09 12:42:54 <bedeho> ok, well I am not sure I understand why they are needed, even if they were safe? I mean there is no way of knowing, after the fact, that the highest sequence number was indeed included in a block?
323 2015-01-09 12:43:17 <jonasschnelli> petertodd, hu. nice. thanks
324 2015-01-09 12:43:50 <petertodd> bedeho: you mean, no way of ensuring that - the design depends on mempools around the network being synchronized, which is kinda nuts...
325 2015-01-09 12:45:32 <petertodd> bedeho: now, an interesting possibility is to use a micropayment channel with repalce-by-fee scorched earth: post-confirmation, the escrow keeps the micropayment channel secure, prior to the first confirmation, you can use scorched earth to make it statistically unprofitable to double-spend
326 2015-01-09 12:46:31 <petertodd> bedeho: also, someone posted a bi-directional micropayment scheme with CHECKLOCKTIMEVERIFY to the mailing list today: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06677.html
327 2015-01-09 12:46:42 <petertodd> bedeho: haven't thought through it fully, but it looks like it works
328 2015-01-09 12:46:50 <bedeho> petertodd: but the contract funds are in a multisig output, so as the receiver you cannot create a new transaction which spends the multisig all to miners?
329 2015-01-09 12:47:35 <petertodd> bedeho: see "replace-by-fee scorched-earth without child-pays-for-parent" http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg05211.html
330 2015-01-09 12:50:25 <petertodd> reminds me: a nice addition to this stuff would be to have the right opcodes to be able to evaluate arbitrary signatures, which would let the scorched-earth part be contingent on the sender fradulently creating a double-spend
331 2015-01-09 12:59:56 <jonasschnelli> petertodd, im a python greenhorn: how do i link to https://github.com/bitcoin/bips/blob/master/bip-0070/paymentrequest.proto? I always get "ImportError: No module named 'payments_pb2'"
332 2015-01-09 13:03:00 <michagogo> Gah
333 2015-01-09 13:03:04 <michagogo> Stupid config files
334 2015-01-09 13:03:25 <michagogo> I left an Ubuntu VM on overnight to upgrade from precise to trusty
335 2015-01-09 13:03:39 <jonasschnelli> petertodd, nevermind. succeeded with ./protoc
336 2015-01-09 13:04:02 <michagogo> But at some point it stopped, waiting me to tell it whether or not I wanted to keep my changes to sudoers -_-
337 2015-01-09 13:04:17 <michagogo> Need to shut down within an hour or two :-/
338 2015-01-09 13:23:25 <jonasschnelli> which port does the payment server in Qt uses? couldn't find out.
339 2015-01-09 13:24:09 <gmaxwell> 0_o payment server? there is a payment server?!
340 2015-01-09 13:24:59 <jonasschnelli> from the master code: PaymentServer::PaymentServer(QObject* parent, bool startLocalServer) :
341 2015-01-09 13:26:58 <Luke-Jr> jonasschnelli: that'll be platform-specific
342 2015-01-09 13:27:53 <wumpus> jonasschnelli: it uses a local pipe
343 2015-01-09 13:28:37 <wumpus> gmaxwell: yes, to pass bitcoin: URIs to the running bitcoin process
344 2015-01-09 13:29:47 <wumpus> jonasschnelli: see http://qt-project.org/doc/qt-4.8/qlocalserver.html
345 2015-01-09 13:30:00 <jonasschnelli> just reading that page. :)
346 2015-01-09 13:31:35 <gmaxwell> wumpus: ohhh
347 2015-01-09 13:31:50 <gmaxwell> okay, I thought he meant a https server for handling payment requests to outside payees.
348 2015-01-09 13:32:03 <jonasschnelli> me either
349 2015-01-09 13:32:27 <wumpus> no, no hidden http servers in bitcoin, you can breathe again :)
350 2015-01-09 13:32:36 <hearn> just the non-hidden ones ;)
351 2015-01-09 13:33:07 <wumpus> yes just the locally-restricted RPC one
352 2015-01-09 13:33:13 <wumpus> if enabled
353 2015-01-09 13:33:15 <jonasschnelli> so how can i test a bip70? to where i need to send a payment request?
354 2015-01-09 13:34:02 <wumpus> jonasschnelli: you can open it from a local file, from the File menu and open URI
355 2015-01-09 13:34:42 <wumpus> jonasschnelli: alternatively, put a bitcoin URI (that refers to a payment request) on a site and click it, of course given that your browser is passing them to bitcoin-qt
356 2015-01-09 13:36:40 <jonasschnelli> wumpus, okay. Now i see. I have to use a bip72 uri
357 2015-01-09 13:39:11 <jonasschnelli> there is no activity-indication during fetchRequest()... hmm...
358 2015-01-09 13:51:06 <michagogo> aaand now my Ubuntu VM is broken :-/
359 2015-01-09 13:51:33 <michagogo> Right on login, three "System program problem detected"s
360 2015-01-09 13:51:52 <UukGoblin> what software would you guys recommend for doing a send-to-many off of cold storage?
361 2015-01-09 13:51:56 <michagogo> 
ACTION wonders why the upgrade process is so broken whenever he tries it

362 2015-01-09 13:52:05 <UukGoblin> I probably don't want to faff around with building raw transactions...
363 2015-01-09 13:55:11 <gdm85> michagogo: why not start from a fresh 14.04?
364 2015-01-09 13:55:24 <michagogo> gdm85: I could do that
365 2015-01-09 13:55:30 <michagogo> and I think at this point I probably need to
366 2015-01-09 13:55:43 <michagogo> I mean, I don't know if anything actually is broken
367 2015-01-09 13:55:58 <gdm85> if not, can help at identifying what is your working space. probably /home/$USER is enough if you want to carry it to next VM
368 2015-01-09 13:55:59 <michagogo> but it might be...
369 2015-01-09 13:56:21 <gdm85> michagogo: normally you can recover it 100%, but it might take some work and some troubleshooting - depending on what didn't get through properly
370 2015-01-09 13:57:04 <michagogo> gdm85: yeah, I'm pretty sure there are all kinds of system config file changes I've made
371 2015-01-09 13:57:09 <michagogo> At least sudoers and rc.local
372 2015-01-09 13:57:20 <gdm85> mmh..you might want to keep your etc around for reference
373 2015-01-09 13:57:53 <michagogo> I mean, I don't really know if anything functional is actually broken
374 2015-01-09 13:58:36 <michagogo> I g2g for now, maybe tomorrow night or Sunday I'll try a gbuild and see if everything works
375 2015-01-09 13:59:36 <gdm85> michagogo: (shameless plug): with these containers I've pretty much made reproducible builds reproducible ;) https://github.com/gdm85/tenku/tree/master/docker/gitian-bitcoin-host
376 2015-01-09 14:20:41 <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/4122 needs close
377 2015-01-09 14:22:06 <sipa> done
378 2015-01-09 14:22:55 <jonasschnelli> thanks
379 2015-01-09 14:24:13 <jonasschnelli> need remove of GUI tag: https://github.com/bitcoin/bitcoin/pull/5266
380 2015-01-09 14:25:12 <sipa> done
381 2015-01-09 14:25:47 <jonasschnelli> thanks
382 2015-01-09 14:27:40 <Luke-Jr> jonasschnelli: I'd prefer to see this have some way to make a useful backup. Backing up to the local filesystem isn't very useful since it is likely to get lost with the original copy
383 2015-01-09 14:28:21 <Luke-Jr> eg, perhaps a prompt "please mount your USB drive", and putting off the backup until it's actually needed
384 2015-01-09 14:28:46 <jonasschnelli> Luke-Jr, yes. agreed. local backups lowers the risk of bdb corruption, etc. but external backups would be better
385 2015-01-09 14:29:34 <jonasschnelli> Luke-Jr, with pull 5266 you could even backup to you local dropbox folder *duck*
386 2015-01-09 14:29:35 <Luke-Jr> so I'd expect to get prompted to make a backup every 100 transactions
387 2015-01-09 14:30:04 <jonasschnelli> Luke-Jr, hmm... 100 transaction... okay. But i prefer to do a backup when the keypool gets refilled.
388 2015-01-09 14:30:16 <Luke-Jr> I guess you'd get that if you simply don't refill the keypool until needed
389 2015-01-09 14:30:27 <sipa> can you, uhm... get rid of the keypool for starters and use bip32? :p
390 2015-01-09 14:30:28 <Luke-Jr> jonasschnelli: keypool gets refilled every single tx
391 2015-01-09 14:30:34 <Luke-Jr> sipa: +1
392 2015-01-09 14:30:48 <jonasschnelli> sipa, clown. :)
393 2015-01-09 14:30:48 <sipa> (even in very totally minimal form where there is a single stored master key from which keys are derived)
394 2015-01-09 14:30:52 <sipa> ?
395 2015-01-09 14:31:07 <Luke-Jr> that's a good point; as soon as BIP32 is implemented, backups are inherently untied from the keypool
396 2015-01-09 14:31:15 <jonasschnelli> i would love! but bip32 is just to far away from me...
397 2015-01-09 14:31:18 <Luke-Jr> only metadata matters then, and the backup strategy needs to be different
398 2015-01-09 14:31:28 <Luke-Jr> jonasschnelli: most of the code is in there already, just unused
399 2015-01-09 14:31:34 <sipa> jonasschnelli: all the code for the derivation is already there
400 2015-01-09 14:31:47 <jonasschnelli> sipa, hu... didn't noticed.
401 2015-01-09 14:31:55 <sipa> unit tests and all
402 2015-01-09 14:32:09 <jonasschnelli> jonasschnelli, the ut i saw... but implementation i did not recognize..
403 2015-01-09 14:32:27 <sipa> CExtPubKey CExtKey etc
404 2015-01-09 14:32:43 <jonasschnelli> yes. Bp32 would mean to have a different backup strategy then supposed in #5266
405 2015-01-09 14:33:21 <jonasschnelli> My priority list currently is: logdb (rm bdb), SPV, Bip32, Multiwalet...
406 2015-01-09 14:33:29 <jonasschnelli> s/walet/wallet
407 2015-01-09 14:33:39 <jonasschnelli> maybe i'm finished in 2018
408 2015-01-09 14:33:39 <Luke-Jr> logdb and BIP32 kinda go hand-in-hand IMO
409 2015-01-09 14:33:47 <sipa> Luke-Jr: i don't see how
410 2015-01-09 14:33:51 <sipa> they're totally orthogonal
411 2015-01-09 14:34:13 <Luke-Jr> well, logdb without BIP32 means supporting the keypool etc
412 2015-01-09 14:34:24 <sipa> logdb is just a drop-in replacement for bdb
413 2015-01-09 14:34:43 <sipa> it doesn't care about what key-value pairs are stored, that code already exists
414 2015-01-09 14:35:19 <jonasschnelli> but for bip32 we still need to store the keys... (sorry i'm not familiar with HD wallets)
415 2015-01-09 14:35:47 <sipa> jonasschnelli: basically you add a record that stores the master key and how many keys of it are used already
416 2015-01-09 14:35:50 <Luke-Jr> jonasschnelli: no, BIP32 means you have a single seed from which all keys are generated on demand
417 2015-01-09 14:36:07 <sipa> and when generating a new key, you use privkey derivation to calculate it
418 2015-01-09 14:36:10 <sipa> nothing else has to change
419 2015-01-09 14:36:25 <sipa> further changes are possible where you don't store full keys/addresses anymore and they're recomputed on the fly
420 2015-01-09 14:36:33 <jonasschnelli> so logdb would still fit the bip32 needs?
421 2015-01-09 14:36:34 <sipa> but that's not necessary for correct operation
422 2015-01-09 14:36:36 <sipa> yes
423 2015-01-09 14:36:51 <sipa> as i said, they're orthogonal
424 2015-01-09 14:36:58 <sipa> logdb/bdb just store key-value pairs, that's it
425 2015-01-09 14:37:13 <jonasschnelli> for me logdb is more a maintainability thing. bdb is a overhead and will create more and more compile and run issue
426 2015-01-09 14:37:15 <sipa> what keys are stored is application logic, and can implement a keypool or deterministic derivation
427 2015-01-09 14:37:24 <jonasschnelli> and of course it's a good starting point for me to dive into the code
428 2015-01-09 14:37:36 <hearn> jonasschnelli: this might sound like a troll question, but why not help out on bitcoinj instead? it's already spv, bip32 + multisig capable
429 2015-01-09 14:37:37 <jonasschnelli> (that's how we learn things, touch, turn and press)
430 2015-01-09 14:37:45 <hearn> jonasschnelli: is there some fundamental feature of the Core wallet you need?
431 2015-01-09 14:38:20 <Luke-Jr> 
ACTION would imagine logdb would have more (justified) overhead than bdb

432 2015-01-09 14:38:21 <hearn> (well, we need a logdb style disk format too)
433 2015-01-09 14:38:23 <jonasschnelli> hearn, bitcoinj is good and stable. But i never could get warm with java
434 2015-01-09 14:38:35 <hearn> you prefer c++?
435 2015-01-09 14:38:40 <jonasschnelli> hearn, yes
436 2015-01-09 14:39:09 <jonasschnelli> hearn, IMO (even if other say the opposite) i think c++ is nowadays more portable
437 2015-01-09 14:39:38 <hearn> a year or two ago i played with a rather clever java-to-c++11 transpiler
438 2015-01-09 14:39:51 <jonasschnelli> and i'd like to strength the bitcoin implementation and people should trust in the reference client.
439 2015-01-09 14:39:52 <hearn> it produced remarkably clean C++ i must say. guy who wrote it is skilled as hell.
440 2015-01-09 14:40:06 <jonasschnelli> hearn, auto-translation will never work out well... that's my exp.
441 2015-01-09 14:40:08 <hearn> you dropped in the boehm gc and off you go. biggest problem: it didn't generate array bounds checked
442 2015-01-09 14:40:24 <Luke-Jr> jonasschnelli: note the wallet should be split off from the reference/node code at some point
443 2015-01-09 14:40:39 <apeiron> hi there folks. I'm trying to run a mostly offline wallet using bitcoinjs. I can generate addresses on the testnet that can receive coins, which is \o/. but what I'd like to know is if it's possible to have a node connected to the network that only submits transactions--I don't want or need the whole blockchain, and just want something small that does the minimal possible for sending coins
444 2015-01-09 14:40:39 <Luke-Jr> not that I would discourage you from improving it - it's still far better than anything BitcoinJ-based ;)
445 2015-01-09 14:41:12 <hearn> jonasschnelli: could be! but depends portable to what
446 2015-01-09 14:41:38 <apeiron> so, ultimately, question is: can I put a node on the network that just submits transactions? or is there a protocol requirement to do other things? if so, what are those other things? and is there some docs I can look at for this?
447 2015-01-09 14:41:39 <jonasschnelli> Luke-Jr, the wallet could split of. I just think there should be a reference-wallet-implementation from a core team... to build up trust in the first place
448 2015-01-09 14:42:01 <hearn> apeiron: you can indeed just write transactions to the network and not do other things
449 2015-01-09 14:42:11 <hearn> apeiron: not sure about bitcoinjs. i think bitcore can do that (it's also js)
450 2015-01-09 14:42:16 <Luke-Jr> apeiron: to spend coins, you need some wallet somewhere that knows what coins exist; nodes don't otherwise need to do anything special for the p2p link
451 2015-01-09 14:42:26 <apeiron> hearn, I know bitcoinjs does not support that
452 2015-01-09 14:42:27 <jonasschnelli> hearn, example: iOS helds a signification portion of the "possible-bitcoin-clients-market"...
453 2015-01-09 14:42:43 <apeiron> Luke-Jr, yes, of course; the code I'm working on will be storing the wallets and their private keys, so it can generate + sign transactions to publish
454 2015-01-09 14:42:43 <Luke-Jr> apeiron: you can do the former with SPV mode as well
455 2015-01-09 14:42:53 <hearn> jonasschnelli: you can run java on iOS, check out robovm.
456 2015-01-09 14:42:57 <apeiron> or rather, storing the addresses
457 2015-01-09 14:43:00 <hearn> jonasschnelli: though aaron has written an objective-c client
458 2015-01-09 14:43:06 <jonasschnelli> hearn, yes. you could... but is it worth?
459 2015-01-09 14:43:18 <hearn> jonasschnelli: why not? robovm still lets you use cocoa for the ui layer.
460 2015-01-09 14:43:21 <Luke-Jr> apeiron: the private keys are not enough
461 2015-01-09 14:43:24 <hearn> jonasschnelli: depends what your goals are, doesn't it
462 2015-01-09 14:43:38 <hearn> it's just a programming language, stdlib + runtime at the end of the day.
463 2015-01-09 14:43:48 <hearn> but don't let me put you off improving the Core wallet :)
464 2015-01-09 14:43:49 <apeiron> what else do I need, then?
465 2015-01-09 14:43:52 <hearn> if you have your reasons, okie dokie
466 2015-01-09 14:44:16 <Luke-Jr> apeiron: the UTXO identifiers (a hash and index)
467 2015-01-09 14:44:18 <apeiron> the example on the bitcoinjs page shows that I can go from key + address to signed transaction that I can submit to various services pretty easily
468 2015-01-09 14:44:57 <wumpus> hearn stop trying to poach contributors from us :p
469 2015-01-09 14:44:59 <Luke-Jr> apeiron: you need to create a transaction, before you can sign it
470 2015-01-09 14:45:07 <Luke-Jr> apeiron: the key is sufficient to sign, but not to create
471 2015-01-09 14:45:11 <apeiron> Luke-Jr, right, and the example on the bitcoinjs page does that
472 2015-01-09 14:45:14 <jonasschnelli> hearn, the reason is that i never got warm with java.... even if its modern and all that.
473 2015-01-09 14:45:19 <jonasschnelli> i like to stay close to my cpu. :)
474 2015-01-09 14:45:28 <Luke-Jr> apeiron: well, I don't know anything about bitcoinjs, just how Bitcoin works ;)
475 2015-01-09 14:46:16 <apeiron> ... except actually submittin git
476 2015-01-09 14:46:16 <apeiron> Luke-Jr, sure. what I'm saying is that the API *appears* to do everything that's needed to generate a hex representation of the transaction.
477 2015-01-09 14:46:16 <jonasschnelli> if the wallet once split of. Is there a plan for a reference bitcoin core wallet?
478 2015-01-09 14:46:16 <Luke-Jr> jonasschnelli: don't understand the question
479 2015-01-09 14:46:19 <apeiron> or submitting it
480 2015-01-09 14:46:28 <apeiron> no version controlled coins here!
481 2015-01-09 14:46:33 <Luke-Jr> apeiron: it's impossible to create a transaction without knowing your inputs
482 2015-01-09 14:46:43 <apeiron> Luke-Jr, I understand that
483 2015-01-09 14:46:52 <hearn> hehe sorry wumpus
484 2015-01-09 14:46:55 <Luke-Jr> that's all I'm talking about
485 2015-01-09 14:46:59 <apeiron> ok
486 2015-01-09 14:47:17 <apeiron> My app will have the source and destination addresses supplied to it
487 2015-01-09 14:47:25 <Luke-Jr> there is no such thing as a source address
488 2015-01-09 14:47:34 <apeiron> input and output, then?
489 2015-01-09 14:47:39 <Luke-Jr> inputs are not addresses
490 2015-01-09 14:47:49 <jonasschnelli> Luke-Jr, hmm... i mean is the long term goal that the core devs. are renounce themselves from a possible wallet built on top of bitcoin-core?
491 2015-01-09 14:47:56 <Luke-Jr> they are a 256-bit hash and an index, not at all related to any address
492 2015-01-09 14:48:09 <apeiron> okay, I see
493 2015-01-09 14:48:27 <Luke-Jr> jonasschnelli: more like split the wallet to a separate project, and continue to contribute to it there
494 2015-01-09 14:49:02 <wumpus> jonasschnelli: some of them, maybe. *Personally* I don't have the cognitive resources to maintain bitcoin infrastructure as well as a wallet, but don't let that prevent you from working on it.
495 2015-01-09 14:49:04 <Luke-Jr> apeiron: see https://en.bitcoin.it/wiki/Protocol_specification#tx
496 2015-01-09 14:49:06 <apeiron> Luke-Jr, at any rate, I will know the output address, and I now understand how to get the input
497 2015-01-09 14:49:15 <wumpus> jonasschnelli: more people can handle more work
498 2015-01-09 14:49:35 <Luke-Jr> apeiron: I don't understand how you understand to get the input, but ok :P
499 2015-01-09 14:49:58 <wumpus> jonasschnelli: the problem with bitcoin-qt's wallet has always been lack of interest and lack of contributors, but that appears to be changing for the better
500 2015-01-09 14:50:42 <jonasschnelli> what are the opinions of a SPV mode for bitcoin-qt?
501 2015-01-09 14:50:54 <wumpus> jonasschnelli: that's clearly the future
502 2015-01-09 14:51:08 <Luke-Jr> jonasschnelli: needs a SPV lib first
503 2015-01-09 14:51:22 <Luke-Jr> but yes, please do go that direction
504 2015-01-09 14:51:22 <wumpus> jonasschnelli: would be pretty easy now that headers-first is merged, I think
505 2015-01-09 14:51:26 <jonasschnelli> I guess many users could come (back) from multibit and co.
506 2015-01-09 14:51:54 <wumpus> jonasschnelli: a mix would also work: start in SPV mode, then backfill as full node
507 2015-01-09 14:52:00 <jonasschnelli> Luke-Jr, why a SPV lib? I mean of course it would need significant changes in the core to support a cmd arg -spv mode
508 2015-01-09 14:52:10 <jonasschnelli> wumpus, i also though that
509 2015-01-09 14:52:23 <jonasschnelli> wumpus, a SPVchain could be held parallel to the full node ldv
510 2015-01-09 14:52:28 <wumpus> jonasschnelli: yes, unless the user would only want spv
511 2015-01-09 14:52:29 <jonasschnelli> s/ldv/ldb
512 2015-01-09 14:52:35 <Luke-Jr> jonasschnelli: to be properly modularised: people should be able to fork the wallet without needing to maintain the SPV logic
513 2015-01-09 14:52:38 <wumpus> jonasschnelli: yes, should be an option
514 2015-01-09 14:53:31 <apeiron> Luke-Jr, if I have the transactions that assigned BTC to the addresses that I have generated, then I have the data to fill the tx_in inputs, no?
515 2015-01-09 14:53:32 <Luke-Jr> I mean, ideally I'd see the wallet as a daemon, the SPV node as a lib, and the GUI as a remote client for the wallet :P
516 2015-01-09 14:53:47 <jonasschnelli> Luke-Jr, yes. that would be a good point. But separation would be needed first. bitcoin-core must be transformed first into a well defined library with clear interfaces
517 2015-01-09 14:54:03 <Luke-Jr> apeiron: bitcoins do not get assigned to addresses, but otherwise yes
518 2015-01-09 14:54:25 <Luke-Jr> jonasschnelli: yes, I'm thinking long-term
519 2015-01-09 14:54:35 <wumpus> jonasschnelli: sure that's the longer-term goal anyway
520 2015-01-09 14:55:06 <wumpus> jonasschnelli: although IMO the concensus code needs to be isolated first before really large scale refactoring can be done
521 2015-01-09 14:55:31 <jonasschnelli> to honor bitcoinj, it has a very well defined API... a bitcoin core spv library could be similar
522 2015-01-09 14:56:08 <Luke-Jr> I'm sure a similar API would help other wallets port off BitcoinJ, but probably would target what makes the most sense
523 2015-01-09 14:56:20 <Luke-Jr> the little I've seen of BitcoinJ's API did not seem very well-designed
524 2015-01-09 14:56:29 <wumpus> making other wallets 'port off BitcoinJ' is not a goal
525 2015-01-09 14:56:43 <bedeho> In a multisig output script, do all signatures have to share the same signature hash type?
526 2015-01-09 14:56:47 <wumpus> let's respect other projects and not try to duplicate too much work
527 2015-01-09 14:57:11 <jonasschnelli> wumpus, yes truly.
528 2015-01-09 14:57:18 <Luke-Jr> wumpus: right, that's why I'm saying it'd be the only benefit to a similar API, and it's better to target what makes sense over BitcoinJ compat
529 2015-01-09 14:57:37 <jonasschnelli> wumpus, i just would like to see the more-or-less proven bitcoin-qt client running in a SPV mode
530 2015-01-09 14:58:09 <hearn> api compatibility wouldn't really make much sense, imo
531 2015-01-09 14:58:22 <hearn> it's not easy to port an app that's written for the JVM to something with a big, complicated C++ API
532 2015-01-09 14:58:43 <wumpus> gcj? *ducks*
533 2015-01-09 14:58:44 <hearn> also by now bitcoinj based wallets expect things like BIP32, they use custom wallet extensions, some of them have custom coin selectors, etc
534 2015-01-09 14:58:47 <Luke-Jr> aren't some written in C++, and have to go to effort to use BitcoinJ right now?
535 2015-01-09 14:58:54 <hearn> no, not that i'm aware of.
536 2015-01-09 14:59:02 <hearn> oh, hive is written in objective-c
537 2015-01-09 14:59:10 <Luke-Jr> ah, that may be what I was thinking of
538 2015-01-09 14:59:21 <hearn> maybe you're thinking of that. but they don't use the API directly from objective-c (though they could, i think)
539 2015-01-09 14:59:41 <hearn> they have a "wallety bit" which is written in java, and a "gui bit" that's in objective-C, and then the obj-c side just upcalls via JNI to the wallet-y bit
540 2015-01-09 14:59:47 <Luke-Jr> in any case, I think everyone agrees trying to make the API similar isn't a good idea
541 2015-01-09 14:59:49 <hearn> so they have an internal API for things like "send X coins to address Y"
542 2015-01-09 15:12:05 <jonasschnelli> wumpus, could get merged IMO: https://github.com/bitcoin/bitcoin/pull/5489
543 2015-01-09 15:25:11 <wumpus> jonasschnelli: ACK, some of those savings are quite nice, ie add.png goes from 15199 to 640 bytes(!)
544 2015-01-09 15:25:47 <Luke-Jr> :o
545 2015-01-09 15:25:51 <jonasschnelli> wumpus, yes. Unnecessary color profiles needs lots of space for no reason.. :)
546 2015-01-09 15:30:37 <wumpus> (and yes, I've checked that the image content is still exactly the same)
547 2015-01-09 15:31:28 <wumpus> jonasschnelli: though this one is weird src/qt/res/icons/bitcoin.png                | Bin 350390 -> 355037 bytes
548 2015-01-09 15:31:47 <jonasschnelli> hmm.....
549 2015-01-09 15:31:58 <jonasschnelli> let me hex-cmp this file
550 2015-01-09 15:35:43 <wumpus> not a big deal, that 5kB is easily compensated by the savings on all the other images, but it kind of stuck out
551 2015-01-09 15:36:02 <jonasschnelli> wumpus, i know why. bitcoin.png was saved by Photoshop. It has a more optimized way as it looks. Touching it again with imagemagicks convert will increase the file size
552 2015-01-09 15:36:18 <sipa> use pngcrush too
553 2015-01-09 15:36:22 <wumpus> does it use the max optimization level?
554 2015-01-09 15:36:30 <wumpus> s/optimization/compression
555 2015-01-09 15:36:33 <wumpus> or that
556 2015-01-09 15:37:01 <jonasschnelli> wumpus, no clue... but adding pngcrush to the script would be a good approach IMO. thanks sipa
557 2015-01-09 15:39:02 <jonasschnelli> pngcrush -brute is cool. ha.
558 2015-01-09 15:39:26 <sipa> -brrute is brutal
559 2015-01-09 15:42:41 <gmaxwell> optipng -o9 is also recommended
560 2015-01-09 15:43:04 <gmaxwell> sometimes pngcrush is better but usually optipng beats it
561 2015-01-09 15:43:18 <gmaxwell> pngcrush though can remove uneeded hunks. -rem:alla or something like that.
562 2015-01-09 15:53:15 <jonasschnelli> gmaxwell, optipng sounds also nice. But i just went for pngcrush. The differences seems minimal in our scope.
563 2015-01-09 16:45:29 <gmaxwell> If possible, I need to determine which miner created block 00000000000000001b02953d79004a6e9da88fd4fe8e76ca7c58d69eb85f8ad9 at height 322083 on 2014-09-22.
564 2015-01-09 16:50:27 <petertodd> gmaxwell: you probably should specify that you know "MegaBigPower" isn't it
565 2015-01-09 16:55:42 <gmaxwell> I am unsure.
566 2015-01-09 16:56:08 <gmaxwell> bc.i says thats the 'relayed by' but I see coinbase fingerprints for other megabigpower blocks.
567 2015-01-09 17:05:37 <ajweiss> is building on os x with the native xcode compiler still supported?
568 2015-01-09 17:06:03 <paveljanik> ajweiss, sure
569 2015-01-09 17:06:20 <ajweiss> and the unit tests should all pass?
570 2015-01-09 17:09:20 <paveljanik> yes
571 2015-01-09 17:11:16 <ajweiss> interesting...
572 2015-01-09 17:11:48 <ajweiss> and there's no magic beyond build-osx.md?
573 2015-01-09 17:12:36 <ajweiss> i get a test_bitcoin that blows up in script_tests.cpp and transaction_tests.cpp
574 2015-01-09 17:13:13 <ajweiss> although i'm something of a mac n00b so i may have done something silly... i did follow the directions on the build page carefully though..
575 2015-01-09 17:15:03 <paveljanik> how they blow up?
576 2015-01-09 17:17:26 <ajweiss> "P2PK with too much R padding but no DERSIG" is one that appears frequently
577 2015-01-09 17:18:10 <paveljanik> never seen this...
578 2015-01-09 17:18:56 <paveljanik> ajweiss, sorry, have to go now.
579 2015-01-09 17:18:59 <paveljanik> bye
580 2015-01-09 17:23:00 <cfields> wumpus: i took a crack at a trivial tree here: https://github.com/coryfields/bitcoin/
581 2015-01-09 17:23:22 <cfields> wumpus: not sure what's the best approach though, as i assume we'll want to avoid 2-level merges into mainline
582 2015-01-09 17:24:19 <ajweiss> oh haha, it's using the wrong compiler
583 2015-01-09 17:26:35 <gmaxwell> cfields: interesting. Thats probably a good way to handle things... though I worry a bit about a trivial tree that isn't e.g. provably same code.
584 2015-01-09 17:26:45 <gmaxwell> I guess its easier to audit many trivial things at once still.
585 2015-01-09 17:26:48 <cfields> wumpus: my approach: set a default branch of "trivial-next" for PR's to be issued to. That way they can be accepted into the trivial tree only on top of others queued in the tree. Then there's a "trivial-rebase" branch that will be used to submit PRs to mainline
586 2015-01-09 17:28:30 <cfields> gmaxwell: yea, i'm not sure where to draw the lines. I agree it'd be nice if a merge from -trivial created the same bitcoind binary, but at the same time, that'd rule out things like: https://github.com/coryfields/bitcoin/commit/002b02b28afac18558a9b9d1e2afa9dc85e8b3b0
587 2015-01-09 17:28:51 <cfields> which would be a shame, since changes like that would be the bulk of -trivial, i should think
588 2015-01-09 17:31:10 <gmaxwell> I've worried before that "trivial" means "unreviewed". :( Of course, thats probably no less true when they're not batched.
589 2015-01-09 17:33:05 <cfields> gmaxwell: i've started thinking about a dumb auditor for travis, which would show modified objects in the PR
590 2015-01-09 17:33:09 <cfields> just for eyeballing
591 2015-01-09 17:35:33 <cfields> not sure how much that would actually help, though, since it'd probably be obvious which objects should be modified.. it'd be the typos contained therein that could bite
592 2015-01-09 17:45:46 <wumpus> well at least when they're batched it can be reviewed in one go
593 2015-01-09 17:46:01 <wumpus> and no possible critical changes should go into the trivial tree
594 2015-01-09 17:46:58 <wumpus> it's meant for comment and simple message changes
595 2015-01-09 17:48:51 <wumpus> certainly not for things that could result in bugs, e.g. reordering statements or such, so I don't think gmaxwell's concern is valid in that case
596 2015-01-09 17:49:16 <earlz> when is rc2 coming out? any estimate?
597 2015-01-09 17:53:15 <wumpus> cfields: looks good to me, I don't really mind two-level merges
598 2015-01-09 17:53:46 <cfields> wumpus: doesn't the github merge script forbit them?
599 2015-01-09 17:53:52 <wumpus> cfields: the structure is clear
600 2015-01-09 17:53:55 <cfields> or break down if it encounters them?
601 2015-01-09 17:53:55 <wumpus> cfields: no
602 2015-01-09 17:54:03 <cfields> i recall some kind of discussion about that
603 2015-01-09 17:54:14 <wumpus> the github merge script just creates merges
604 2015-01-09 17:54:23 <wumpus> creates the commit message, and signs them
605 2015-01-09 17:54:45 <cfields> ah wait, maybe it was the find-unsigned-merges script
606 2015-01-09 17:55:44 <wumpus> possibly
607 2015-01-09 17:56:20 <wumpus> cfields: the only thing that is complicated by having merges inside the trivial tree is that you can't combine commits; eg if there are lots of small changes to one documentation file
608 2015-01-09 17:56:22 <Luke-Jr> so the goal of trivial is for the typo/whitespace/etc stuff?
609 2015-01-09 17:56:42 <cfields> Luke-Jr: and docs
610 2015-01-09 17:56:49 <apeiron> docs!
611 2015-01-09 17:56:53 <Luke-Jr> makes sense
612 2015-01-09 17:56:56 <wumpus> Luke-Jr: yes, messages, comments and small documentation changes
613 2015-01-09 17:57:50 <Luke-Jr> btw, maybe it should be bitcoin/bitcoin-trivial rather that cfields/bitcoin?
614 2015-01-09 17:57:52 <cfields> wumpus: well it could always be squashed before PR into mainline, but that would nuke the audit trail
615 2015-01-09 17:57:59 <Luke-Jr> meh, not important I guess
616 2015-01-09 17:58:07 <cfields> Luke-Jr: it's just a playground for now
617 2015-01-09 17:58:44 <Luke-Jr> squashing separate changes seems unnecessary
618 2015-01-09 17:58:52 <Luke-Jr> I mean, git log --first-parent exists after all
619 2015-01-09 17:58:54 <cfields> but ideally, yea, under bitcoin org
620 2015-01-09 17:59:02 <wumpus> well, I don't like tons of commits for simple things, but ok
621 2015-01-09 17:59:30 <Luke-Jr> maybe just squash it in the changelog
622 2015-01-09 17:59:33 <cfields> wumpus: for trivial changes, it also makes rebasing over them easier if they're not squashed
623 2015-01-09 17:59:42 <wumpus> and with merge commit for everything it resuults in *two* comment
624 2015-01-09 17:59:44 <wumpus> commits
625 2015-01-09 18:00:01 <wumpus> for something like 'add a missing newline' that's awful imo
626 2015-01-09 18:00:36 <Luke-Jr> well, maybe the trivial maintainer can selectively squash/fixup things before PRing to master
627 2015-01-09 18:00:49 <cfields> wumpus: yea, that's why i originally assumed we'd want the merge-commits rebased away before PR to master
628 2015-01-09 18:01:07 <wumpus> cfields: yes, that makes sense
629 2015-01-09 18:01:21 <wumpus> Luke-Jr: IMHO that was the point, yes
630 2015-01-09 18:01:25 <cfields> wumpus: https://github.com/coryfields/bitcoin/commits/trivial-rebase
631 2015-01-09 18:02:09 <cfields> PR to trivial-next -> queue up for a while -> move to trivial-rebase -> pr to master. after merge, trivial-next is reset to master and repeat.
632 2015-01-09 18:02:31 <wumpus> cfields: as for audit trail: just don't combine commits from different authors?
633 2015-01-09 18:02:49 <wumpus> and keep a reference to the PRs in the commit message
634 2015-01-09 18:03:22 <cfields> wumpus: makes sense. Also, i suppose the diff between -next and -rebase should be empty, proving the rebase made no changes
635 2015-01-09 18:03:22 <wumpus> cfields: sounds good to me
636 2015-01-09 18:04:10 <wumpus> yes
637 2015-01-09 18:04:17 <cfields> wumpus: worth trying for a test-period to see how it goes?
638 2015-01-09 18:04:29 <cfields> maybe after 0.10 though, to reduce backport complications initially
639 2015-01-09 18:05:14 <wumpus> cfields: nah, that doesn't matter, let's just start now, these changes should be easy to backport over
640 2015-01-09 18:05:50 <cfields> ok
641 2015-01-09 18:11:01 <wumpus> cfields: btw: re: dumb auditor, one of the things I'm working on (sometimes) is a script that compares two build results binary, on the function level, could add something that verifies string-only changes
642 2015-01-09 18:12:19 <cfields> wumpus: good idea
643 2015-01-09 18:15:06 <wumpus> currently it just shows which functions were added, modified or removed, which is sometimes useful, especially if we start labeling what belongs to the consensus code
644 2015-01-09 18:15:49 <wumpus> could allow some automatic pre-sorting of PRs
645 2015-01-09 18:18:39 <hearn> is there an irc channel which gets block announcements?
646 2015-01-09 18:19:12 <apeiron> that would be a very busy channel
647 2015-01-09 18:19:19 <apeiron> probably too busy to be meaningfully useful
648 2015-01-09 18:19:37 <apeiron> blockchain and some other services offer a webservices stream for getting block info, though
649 2015-01-09 18:19:52 <kgk> could you just run bitcoind and tail the debug log?
650 2015-01-09 18:20:43 <hearn> i know how to learn about new block announcements. just an irc channel would have been convenient at the moment
651 2015-01-09 19:14:10 <shesek> if you had two passwords, one for logging-in to a service, and a second one to authorize more sensitive actions (controlling funds) - how would you refer to the second password?
652 2015-01-09 19:14:58 <apeiron> design flaw
653 2015-01-09 19:14:58 <shesek> its kinda like a 2FA authentication, only that its the same factor (something you know) as the first authentication
654 2015-01-09 19:15:07 <shesek> apeiron, why so?
655 2015-01-09 19:15:12 <apeiron> how does one recover it?
656 2015-01-09 19:15:54 <shesek> apeiron, he doesn't. these passwords are used as seeds for generating private keys
657 2015-01-09 19:16:08 <apeiron> then call it 'private key seed' :)
658 2015-01-09 19:17:04 <shesek> hmm... something like that sounds good, but both passwords are used to generate private keys
659 2015-01-09 19:17:09 <gmaxwell> Mystery of that prior block resolved;  Now I'm looking for the miner that mines to 17JJ3oZyF4ShQMGukDjpMWhmooCjEvoVVB  and has apparently about 1-2% of the hashpower.
660 2015-01-09 19:18:57 <shesek> the first password is used to derive a private key that represents the user identity (allowing him to login, sign messages, decrypt incoming messages, etc), while the second (in combination with the first) is used to derive a master HD key for signing transactions
661 2015-01-09 19:19:56 <shesek> the reason for separating them being that the browser permanently remembers the first, but asks for the second one only when needed, and throws it away as soon as its done with it
662 2015-01-09 19:20:10 <shesek> coming up with a proper terminology is proving to be quite challenging
663 2015-01-09 19:20:37 <shesek> from my user testing so far, this is by far the thing people are most confused about
664 2015-01-09 19:23:34 <jtimon> gmaxwell is it related to "Unknown with 1AcAj9p Address" and "Unknown with 1BwZeHJ Address"?
665 2015-01-09 19:25:49 <gmaxwell> I don't believe so.
666 2015-01-09 19:25:55 <jtimon> I just saw that for the first time in https://blockchain.info/pools the other day and became very curious about it
667 2015-01-09 19:27:27 <jtimon> it's surprising that they have that much hashrate but not enough knowledge to avoid reusing a single address...
668 2015-01-09 19:28:14 <jtimon> is there any reason to reuse in mining that I'm missing?
669 2015-01-09 19:29:39 <gmaxwell> compensation for inadequate monitoring / auditing infrastructure.
670 2015-01-09 19:30:13 <jtimon> ??
671 2015-01-09 19:30:42 <jtimon> oh, I see, that is easier to monitor
672 2015-01-09 19:31:13 <jtimon> than say using a bip32 seed or something
673 2015-01-09 20:26:19 <jonasschnelli> needs GUI tag: https://github.com/bitcoin/bitcoin/pull/5467
674 2015-01-09 20:26:58 <gmaxwell> done
675 2015-01-09 20:43:47 <jonasschnelli> same here, needs GUI tag: https://github.com/bitcoin/bitcoin/pull/5632
676 2015-01-09 20:44:07 <gmaxwell> doning
677 2015-01-09 20:48:21 <jonasschnelli> needs close: https://github.com/bitcoin/bitcoin/issues/5254
678 2015-01-09 20:49:17 <jonasschnelli> same here: https://github.com/bitcoin/bitcoin/issues/5037
679 2015-01-09 20:53:31 <gmaxwell> maybe a little premature, but not harm, if he objects can can respond.
680 2015-01-09 20:54:09 <jonasschnelli> i know. bit aggressive. But both issues are minor an author suddenly disappeared.
681 2015-01-09 20:54:28 <jonasschnelli> (and still 312 open issues)
682 2015-01-09 21:03:22 <earlz> So I get some failing tests using a fresh compile on Arch Linux of the 0.10 branch
683 2015-01-09 21:03:26 <earlz> http://pastebin.com/CAyF7636
684 2015-01-09 21:05:40 <gmaxwell> 11:31 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 264 seconds]
685 2015-01-09 21:05:43 <gmaxwell> 11:34 -!- jb55 [~jb55@208.98.200.98] has joined #bitcoin-dev
686 2015-01-09 21:05:46 <gmaxwell> 11:34 -!- kadoban [~mud@ip68-3-81-129.ph.ph.cox.net] has quit [Quit: bye]
687 2015-01-09 21:05:48 <gmaxwell> 11:38 -!- ericmuyser [~ericmuyse@S010628c68e00af53.vc.shawcable.net] has joined #bitcoin-dev
688 2015-01-09 21:05:51 <gmaxwell> 11:40 -!- RoboTeddy [~roboteddy@2601:9:3483:2400:c81c:a250:4391:d1b0] has joined #bitcoin-dev