1 2014-10-10 00:03:51 <cfields> BlueMatt: We need to be able to control how we build internally, externally, and how we present that to client libs
  2 2014-10-10 00:04:10 <cfields> for example, we'll soon have the choice of using openssl/libsecp256k1 for the lib..
  3 2014-10-10 00:04:25 <sipa> ... which should not affect the external interface at all
  4 2014-10-10 00:05:41 <cfields> external, right. but since we share the header, it differs for internal usage
  5 2014-10-10 00:05:53 <cfields> grrgh, just give me a bit to do up a POC :)
  6 2014-10-10 00:05:58 <sipa> i don't understand
  7 2014-10-10 00:06:00 <cfields> better yet, sec, let me find another
  8 2014-10-10 00:06:00 <sipa> ok
  9 2014-10-10 00:07:12 <cfields>  /usr/include/pngconf.h
 10 2014-10-10 00:07:22 <cfields> i'm sure you have that around
 11 2014-10-10 00:08:12 <lechuga_> libconsensus!
 12 2014-10-10 00:08:17 <lechuga_> BlueMatt: awesome
 13 2014-10-10 00:08:24 <sipa> cfields: what does it need that for?
 14 2014-10-10 00:12:28 <cfields> sipa: there are all kinds of build configs that need to be supported. they require different attributes in different cases. for ex, if we ship a .a, it needs to be able to work in a .dll or a .obj. declspec oddities make that difficult.
 15 2014-10-10 00:12:49 <cfields> it's possible that we can skip all that since our interface is so small, but that's the standard approach
 16 2014-10-10 00:12:49 <sipa> but a .h.in handles that fine, no?
 17 2014-10-10 00:13:56 <cfields> possibly, depends if we end up needing any of our config info
 18 2014-10-10 00:13:58 <sipa> anyway, no strong opinion here -it all sounds ugly :p
 19 2014-10-10 00:14:25 <cfields> for example, if we still have the boost dep, we'll have to check a few things about how it was built
 20 2014-10-10 00:15:25 <cfields> heh yes, it's ugly. i'm really not suggesting anything crazy though, it's quite standard for libs
 21 2014-10-10 00:16:47 <BlueMatt> cfields: for now, I think all we need is ship a .so, so that means we should need a .h.in to ship proper declspec, and that should be it, no?
 22 2014-10-10 00:17:02 <sipa> BlueMatt: whoa, rpcprotocol.cpp? :o
 23 2014-10-10 00:17:23 <sipa> (not a complaint; just surprised that you need it - and certainly something to fix)
 24 2014-10-10 00:17:27 <cfields> heh, fwiw, my list is about 1/10 that size
 25 2014-10-10 00:17:29 <BlueMatt> if we're doing that, that should mean just build one .h to be instaleld (with an #if WINDOWS -> declspec) and one for build time (that can include bitcoin-config.h for the visibility availability)?
 26 2014-10-10 00:17:37 <BlueMatt> sipa: yes, I think it still builds with that removed
 27 2014-10-10 00:17:49 <BlueMatt> sipa: but I deliberately didnt remove anything and just copied EVERYTHING
 28 2014-10-10 00:17:54 <sipa> ah, ok
 29 2014-10-10 00:18:25 <BlueMatt> if we turned on -flto it wouldnt matter since we only expose the right symbols
 30 2014-10-10 00:18:33 <BlueMatt> but since we dont, we can trim it down by listing files
 31 2014-10-10 00:19:25 <sipa> anyway, the code looks good
 32 2014-10-10 00:19:46 <sipa> i'll let you can cory flesh out the building issues
 33 2014-10-10 00:19:51 <cfields> BlueMatt: i'll work something up. it's really hard to discuss the edge-cases without a working example
 34 2014-10-10 00:19:55 <sipa> s/can/and/
 35 2014-10-10 00:20:19 <BlueMatt> cfields: sure, go for it
 36 2014-10-10 00:20:20 <cfields> let me push up my boost stuff so you guys can start berating me for that instead :)
 37 2014-10-10 00:20:30 <BlueMatt> cfields: heh, sounds like a plan
 38 2014-10-10 00:20:34 <lechuga_> super excited
 39 2014-10-10 00:21:19 <cfields> BlueMatt: i'm not trying to be NIH about it, just that i think there are more edge cases than you'd realize
 40 2014-10-10 00:21:29 <sipa> 
ACTION fires a laser a lecu

 41 2014-10-10 00:21:35 <sipa> 
ACTION fires a laser a lechuga_ 

 42 2014-10-10 00:21:37 <lechuga_> :)
 43 2014-10-10 00:21:49 <BlueMatt> cfields: I'm absolutely sure there are
 44 2014-10-10 00:21:49 <lechuga_> unsure if that's bad
 45 2014-10-10 00:21:52 <BlueMatt> cfields: go for it :)
 46 2014-10-10 00:22:16 <gmaxwell> 
ACTION looks forward to being able to upgrade to gcc 4.7+ and being able to use lto.

 47 2014-10-10 00:22:35 <cfields> gmaxwell: iirc i didn't have anyt luck with it until 4.9
 48 2014-10-10 00:22:59 <cfields> but i think there was also an adjustment period for binutils, so that might not've been all gcc's fault
 49 2014-10-10 00:23:30 <gmaxwell> cfields: it's pretty solid in 4.7+ in my expirence (also from reading gcc buzilla)
 50 2014-10-10 00:23:46 <gmaxwell> but indeed there are binutils interactions, were you testing on mac?
 51 2014-10-10 00:23:57 <cfields> no
 52 2014-10-10 00:24:34 <cfields> gmaxwell: iirc it was that binutils' ar couln't pull out gimple, so it just kinda skipped over it
 53 2014-10-10 00:24:53 <cfields> worked well with a bunch of .o's though :)
 54 2014-10-10 00:25:31 <cfields> for me that wasn't fixed until 4.9ish, but maybe that just coincided with the first set of working binutils i ended up with
 55 2014-10-10 00:26:19 <gmaxwell> I'm pretty sure that was your binutils.
 56 2014-10-10 00:27:02 <cfields> well i think upstream binutils still has that problem, no? isn't that why the gcc-ar and friends were born?
 57 2014-10-10 00:30:17 <cfields> ah, right, those just setup the plugins correctly
 58 2014-10-10 00:31:26 <cfields> sipa / BlueMatt: https://github.com/theuni/bitcoin/commits/nuke-boost-in-script
 59 2014-10-10 00:32:00 <cfields> not quite finished yet, but there's a ton of reshuffling, so i'm hesitant to keep going
 60 2014-10-10 00:38:40 <sipa> cfields: wow, looks like it was a lot more work than i expected
 61 2014-10-10 00:38:48 <sipa> i'm halfway threough the commits
 62 2014-10-10 00:39:37 <cfields> it's not as bad as it looks. it just took some time to figure out how to split it out of the deep core stuff without being too invasive
 63 2014-10-10 00:40:29 <cfields> it's basically just removing boost from serialize, removing allocators from serialize, and splitting out pubkey
 64 2014-10-10 00:41:17 <sipa> yup, you use a ton of commits, but it's fine
 65 2014-10-10 00:41:31 <sipa> lgtm, apart from verifying move-onlyness
 66 2014-10-10 00:42:51 <cfields> sipa: suggestions for where to stick CKey::CheckSignatureElement ?
 67 2014-10-10 00:43:20 <cfields> it needs to move out of CKey. Feels like cheating to just shove it in CPubKey :)
 68 2014-10-10 00:43:41 <sipa> well...
 69 2014-10-10 00:43:53 <sipa> if you 'd call it keyverify and keysign instead of key and pubkey...
 70 2014-10-10 00:46:31 <cfields> heh, ok
 71 2014-10-10 00:47:17 <cfields> sipa: last one is logging. we currently use our own error() stuff which pulls in our logging and boost...
 72 2014-10-10 00:48:20 <cfields> i figure we can either let the user pass in an error object, but i suspect you'll think that's over-engineered
 73 2014-10-10 00:48:29 <cfields> -either
 74 2014-10-10 00:49:05 <gmaxwell> in the long long term I hope we can move to making the interface boundary C callable, as doing so is basically a requirement to use from other languages.
 75 2014-10-10 00:49:19 <gmaxwell> (long long term, not this release or probably next :) )
 76 2014-10-10 00:49:46 <cfields> gmaxwell: i had planned on doing up a quick c shim, i don't think it should be terribly nasty?
 77 2014-10-10 00:50:05 <sipa> gmaxwell: the consensus library?
 78 2014-10-10 00:50:09 <gmaxwell> yes.
 79 2014-10-10 00:50:15 <sipa> it's already C callable
 80 2014-10-10 00:50:23 <sipa> (matt's current proposal)
 81 2014-10-10 00:50:33 <gmaxwell> I said this because cfields was talking about an error object.
 82 2014-10-10 00:50:36 <phantomcircuit> blargh
 83 2014-10-10 00:50:45 <phantomcircuit> er
 84 2014-10-10 00:50:48 <phantomcircuit> wrong channel
 85 2014-10-10 00:50:49 <sipa> gmaxwell: that's internally in the implementation, not in the interface
 86 2014-10-10 00:51:20 <gmaxwell> sipa: the caller is presumably providing the error handling, no? surely logging shouldn't be internal! :)
 87 2014-10-10 00:51:28 <gmaxwell> Sorry if I'm desynced.
 88 2014-10-10 00:51:29 <sipa> it just retuens a bool
 89 2014-10-10 00:51:44 <cfields> sipa: it's not callable as-is, it needs a shim for creating objects
 90 2014-10-10 00:51:58 <cfields> sipa: ah whoops, sorry. nm
 91 2014-10-10 00:52:07 <sipa> cfields: imho the library shouldn't be doing any logging at all
 92 2014-10-10 00:52:13 <gmaxwell> (actually I want the whole thing to become C too. But thats n-phases away.)
 93 2014-10-10 00:52:22 <sipa> nor should any of script or core even call to logging
 94 2014-10-10 00:52:28 <gmaxwell> I thought it gave side information for failure reasons.
 95 2014-10-10 00:52:28 <sipa> it's just data structures and direct checks
 96 2014-10-10 00:52:30 <jtimon> so script/script is free from boost there, and so is script/interpreter, but the latter depends on core.o which uses boost
 97 2014-10-10 00:52:35 <phantomcircuit> gmaxwell, large n i presume
 98 2014-10-10 00:52:57 <sipa> gmaxwell: script currently doesn't even do that in bitcoin
 99 2014-10-10 00:53:08 <sipa> (and yes, it would be useful, but logging is not the right way...)
100 2014-10-10 00:53:15 <gmaxwell> phantomcircuit: not really. It's already not really doing anything super snazzy. It does have consensus risk since it requires making more of the memory management explicit... so not now.
101 2014-10-10 00:53:23 <cfields> jtimon: well, we only need the core header, to be precise..
102 2014-10-10 00:53:31 <sipa> cfields: gah
103 2014-10-10 00:53:39 <sipa> please don't go that way
104 2014-10-10 00:53:40 <cfields> but anyway, it's just a few FOREACH, those can be easily removed
105 2014-10-10 00:54:21 <gmaxwell> I mean, it can be done with less coding than we've done so far in the pure refactoring.... but some work compariable to the bignum change is required to prove it correct.
106 2014-10-10 00:54:26 <cfields> sipa: that's why i was hoping get the core structures layered, so that serialization and higher-level functionality would be split up
107 2014-10-10 00:54:50 <sipa> cfields: core should pretty much just become header only and only be data structures ad serializaqtion
108 2014-10-10 00:54:53 <gmaxwell> (e.g. piecewise exhaustive testing)
109 2014-10-10 00:55:03 <sipa> everything else that is in there is stuff that needs to be moved to validation code
110 2014-10-10 00:55:09 <sipa> or utility code
111 2014-10-10 00:56:17 <sipa> gmaxwell: at this point, all we need is a way to make the code inside script to just not do logging
112 2014-10-10 00:56:22 <cfields> ok, then we're not too far apart :)
113 2014-10-10 00:56:37 <cfields> either way, i didn't mess with the BOOST_FOREACH. those should be easy to kill off
114 2014-10-10 00:56:45 <jtimon> sipa duplicating a few lines from core is the fatest way to avoid both including core.h without linking core.o and removing the boost foreach in core
115 2014-10-10 00:56:48 <cfields> there are a few in script/ too still, iirc
116 2014-10-10 00:57:09 <sipa> jtimon: i know; i really won't repeat myself again anymore about this
117 2014-10-10 00:57:14 <jtimon> when core becomes header only we can stop duplicating
118 2014-10-10 00:57:16 <gmaxwell> jtimon: really not a fan of duplicating even if its the fastest way to achieve nice seperation here. Any duplication is a long term risk which should be carefully justified.
119 2014-10-10 00:57:58 <cfields> so, backing up a bit... was there a conclusion for logging?
120 2014-10-10 00:58:33 <sipa> so one way is splitting off the logging code out of util, and then provide an alternative headers-only dummy .h with the same interface
121 2014-10-10 00:58:41 <sipa> wait, that's not enough
122 2014-10-10 00:58:59 <sipa> can't we just kill off logging from core and script :(
123 2014-10-10 00:59:14 <cfields> sec
124 2014-10-10 00:59:14 <cfields> sipa: iirc there's only 1 major offender
125 2014-10-10 00:59:18 <sipa> like, delete it
126 2014-10-10 00:59:33 <sipa> if we need more specise information about validation failure, it should return a status object
127 2014-10-10 00:59:43 <sipa> not print text directly to disk...
128 2014-10-10 00:59:53 <jtimon> gmaxwell it's not a lot of duplication https://github.com/jtimon/bitcoin/commit/7d492e9d4406c5aecd5fd064c6cf3c5f6d46d3dd
129 2014-10-10 01:00:32 <jtimon> just the structs plus serialization
130 2014-10-10 01:00:36 <cfields> sipa: i agree. but you don't think it's necessary to expose that status externally?
131 2014-10-10 01:00:42 <sipa> which is _exactly_ what coins just should be
132 2014-10-10 01:00:46 <sipa> *core
133 2014-10-10 01:00:58 <sipa> cfields: yes, but we're not doing that right now either
134 2014-10-10 01:01:18 <sipa> i absolutely think we should return information about failure
135 2014-10-10 01:01:25 <sipa> but that's an independent question of this work
136 2014-10-10 01:02:05 <jtimon> sipa, what about creating a basecore.o with those classes as Bases and make the current ones extend from them?
137 2014-10-10 01:02:53 <sipa> that's one solution - though i think just moving the extra validation isn't much more work than that
138 2014-10-10 01:03:02 <jtimon> after moving everything from core, basecore can be renamed to core again
139 2014-10-10 01:03:03 <sipa> ehh, extra logic
140 2014-10-10 01:03:18 <cfields> sipa: so your proposal is to just nuke it, for the sake of the boost removal?
141 2014-10-10 01:03:31 <sipa> cfields: well what are the offenders?
142 2014-10-10 01:03:56 <cfields> it wouldn't be too much work to whip up a quick enum with corresponding error messages, user passes in a pointer to that
143 2014-10-10 01:04:08 <sipa> the non-canonical encodings stuff can just go imho
144 2014-10-10 01:04:19 <cfields> sipa: just interpreter.cpp
145 2014-10-10 01:05:10 <sipa> i vote delete them
146 2014-10-10 01:05:17 <sipa> (but that may be controversial)
147 2014-10-10 01:05:37 <sipa> longer term, have script validation return a status object
148 2014-10-10 01:05:57 <cfields> well, that's easy, and gives us something to build from
149 2014-10-10 01:06:03 <cfields> so, will do
150 2014-10-10 01:12:01 <gmaxwell> it's very useful knowing where something has failed, in particular in some kind of urgent consensus failure situation the time lost just to get an initial bisection on where failure is happening can be critical.  OTOH, this should probably be handled in a different way than the normal logging. E.g. something like a status structure which is set at every possible failure point with a codified rule number and __FILE__ __LINE__ information.
151 2014-10-10 01:12:44 <sipa> right, that.
152 2014-10-10 01:26:30 <sipa> Luke-Jr: seen http://bitcoin.stackexchange.com/questions/20411/bfgminer-rejected-problem ?
153 2014-10-10 01:27:41 <Luke-Jr> nope
154 2014-10-10 01:41:00 <phantomcircuit> sipa, looks like session resume issues
155 2014-10-10 01:41:06 <phantomcircuit> which could either be bfgminer or the pool
156 2014-10-10 01:41:20 <sipa> answer there; i don't care about the answer :)
157 2014-10-10 02:39:58 <earlz> So, is there a library for javascript for interfacing with the RPC interface... that runs in the browser?
158 2014-10-10 02:40:10 <earlz> as dangerous as that sounds lol
159 2014-10-10 02:40:50 <lechuga_> it doesn't exist in bitcore?
160 2014-10-10 02:43:06 <gmaxwell> earlz: no. somewhat hard to prevent CSRF. ... esp some stupid browsers like IE do credential caching.
161 2014-10-10 02:44:52 <earlz> he wayyyy too many stupid altcoin devs provide coins with a configuration including a default username/password/rpcport and of course server=1... so terrible
162 2014-10-10 03:11:24 <earlz> weird. I can't get bitcore to work inbrowser
163 2014-10-10 03:11:42 <earlz> the daemon just seems to return empty responses to an OPTION request or something
164 2014-10-10 03:17:06 <earlz> I don't see how this bitcore browser ever works
165 2014-10-10 04:55:52 <eadz> anyone know what is up with testnet. According to https://test-insight.bitpay.com/blocks the last 7800 blocks are orphaned?
166 2014-10-10 05:05:27 <phantomcircuit> it's test net...
167 2014-10-10 05:07:03 <null_radix> hey sipa are you around?
168 2014-10-10 05:22:46 <linuxguru> hi guys, i just did an install of bitcoind on GENTOO linux, but for some reason its not working with satoshi dice... is this expected behaviour from the master bitcoin code?  did devs start blocking certain addresses and making bitcoin not fungible?  if not why is this bug present in the gentoo package?
169 2014-10-10 05:23:28 <linuxguru> The gentoo package is not behaving as the master branch on github does.... why is there a bug in the gentoo distribution>?
170 2014-10-10 05:26:02 <gmaxwell> linuxguru: Take it up with gentoo. Please don't discuss it further here. (sorry to be harsh, but esp with comments like "did devs start ... making bitcoin not fungible" it's really hard to tell if you're trolling or not. We're not going to discuss this, it's a gentoo thing.
171 2014-10-10 05:26:06 <gmaxwell> )
172 2014-10-10 05:31:17 <gmaxwell> (nice altcoin email address / sig there :( )
173 2014-10-10 05:31:55 <justanotheruser> lol
174 2014-10-10 05:32:06 <justanotheruser> there has been a wave of FUD coming about the gentoo thing
175 2014-10-10 05:32:17 <justanotheruser> I doubt that many people use gentoo. I have a feeling its the same people
176 2014-10-10 05:32:23 <justanotheruser> or a set of different people working for blackcoin
177 2014-10-10 05:34:53 <Luke-Jr> justanotheruser: I doubt half the trolls even use Gentoo themselves. There are more users happy with it than unhappy, though, so I guess that says enough. Anyhow, off-topic here ;)
178 2014-10-10 05:37:36 <gmaxwell> Right.  My frown was mostly just the possibility that it is FUD being pushed by alt pumpers is really unappealing... the world is a hard enough place without people trying to crap on your system purely because it helps them promote something else, some of whom have no reputation to protect and so don't mind how much mud they fling... oh well. no use speculating or lamenting.
179 2014-10-10 05:45:22 <lechuga_> weird
180 2014-10-10 05:45:42 <lechuga_> and they all seem to troll re: luke's patches
181 2014-10-10 05:45:54 <lechuga_> prob same guy
182 2014-10-10 05:46:44 <phantomcircuit> gmaxwell, that was 1000% a troll
183 2014-10-10 05:47:04 <lechuga_> hard to believe they're all actually frustrated using bitcoin-qt for satoshidice
184 2014-10-10 05:47:08 <lechuga_> and find this channel
185 2014-10-10 05:47:33 <gmaxwell> The world is a wide and weird place.
186 2014-10-10 05:47:40 <gmaxwell> All things are possible.
187 2014-10-10 05:47:53 <Belxjander> well the gentoo gain of bitcoind as a package must have happened sometime within the last 2 years
188 2014-10-10 05:47:55 <lechuga_> how's that razor thing go
189 2014-10-10 05:48:05 <Belxjander> lechuga_: occams razor?
190 2014-10-10 05:48:12 <gmaxwell> (in any case, the probablities are why I gave the result I did.)
191 2014-10-10 05:48:21 <lechuga_> i want 2 say yes but suspicious of troll
192 2014-10-10 05:48:30 <lechuga_> heh
193 2014-10-10 05:48:57 <gmaxwell> lechuga_: occams razor cuts both ways. If you think about it trolling actually doesn't make a lot of sense, so ... perhaps we should assume there are no trolls. (also, assume there are no offtopic conversations?)
194 2014-10-10 05:49:28 <Belxjander> gmaxwell: but isn't making the assumptions in the first place also cutting yourself off from possibilities?
195 2014-10-10 05:50:20 <gmaxwell> ::shrugs:: I gave a response which was hopefully acceptable under a wide set of possibilities.
196 2014-10-10 05:50:34 <lechuga_> agreed
197 2014-10-10 05:53:07 <phantomcircuit> gmaxwell, i have yet to see anybody mention that the patch is a use flag
198 2014-10-10 05:53:30 <phantomcircuit> which strongly indicates nobody complaining about it is actually even using gentoo
199 2014-10-10 05:55:23 <gwillen> phantomcircuit: hmm? It's a default-enabled package-specific USE flag
200 2014-10-10 05:55:36 <gwillen> so most people will get it without knowing it exists
201 2014-10-10 05:56:26 <phantomcircuit> gwillen, people install packages without checking the use flags
202 2014-10-10 05:56:28 <phantomcircuit> wat
203 2014-10-10 05:56:36 <gwillen> :rolleyes:
204 2014-10-10 05:56:49 <gwillen> how many gentoo packages have you installed, to claim you have manually checked the USE flags for each one :-P
205 2014-10-10 05:57:00 <gwillen> any functioning gentoo system has thousands of packages with at least thousands of USE flags
206 2014-10-10 05:57:12 <phantomcircuit> lots?
207 2014-10-10 05:57:16 <Luke-Jr> gwillen: 1784, and when I first install something new I usually check it
208 2014-10-10 05:57:20 <phantomcircuit> most packages dont have package specific use flags
209 2014-10-10 05:57:38 <Luke-Jr> and Portage conveniently tells me when packages being updated have new USE flags
210 2014-10-10 05:57:41 <gwillen> I'm sure you've not checked the package specific USE flags for all the dependencies you've ever pulled in
211 2014-10-10 05:57:49 <Belxjander> gwillen: I have run a gentoo system...and I automated the update process to occur fortnightly...left the box for a year and required rewriting the use flags at that point as they actively changed a lot of them
212 2014-10-10 05:57:52 <gwillen> although I suppose that's not at issue here unless bitcoin will get pulled in as a dependency of something
213 2014-10-10 05:57:54 <Luke-Jr> gwillen: most of the time I don't care much
214 2014-10-10 05:58:14 <Belxjander> gwillen: I had made section specific use flags listing ALL of the packages installed on the target system with package specific on/off settings
215 2014-10-10 05:58:29 <phantomcircuit> gwillen, er yeah i have
216 2014-10-10 05:58:34 <gwillen> o_O
217 2014-10-10 05:58:45 <Luke-Jr> gwillen: in any case, a user who doesn't care, doesn't care.
218 2014-10-10 05:58:50 <gwillen> phantomcircuit: that sounds like a lot more effort than I'm willing to put in to sysadminning I guess
219 2014-10-10 05:58:58 <gwillen> since I'm not getting paid for it
220 2014-10-10 05:59:33 <Belxjander> gwillen: I did that on a home server setup...and it was a pita for about a day...then a full rebuild afterwards with some cleanup after that
221 2014-10-10 06:00:15 <gwillen> what I found when I ran gentoo is that most package-specific USE flags were not even adquately documented for me to know what they _did_
222 2014-10-10 06:00:19 <gwillen> this was some years ago, though
223 2014-10-10 06:01:06 <gwillen> anyway, this is not the right place for gentoo discussion, I just found the assumption dubious that most Gentoo users would check for available USE flags before installing every package
224 2014-10-10 06:01:18 <Belxjander> gwillen: definitely...easier to make a global "USE" flags setup and then package specific use flags listings for anything "extra" that may include dependency loops or other "broken" behaviours when installing the system
225 2014-10-10 06:01:43 <gmaxwell> And the troll(?) wins. :-/
226 2014-10-10 06:01:51 <Belxjander> gwillen: the whole gentoo package situation is a bit over-automateable at the moment
227 2014-10-10 06:01:53 <phantomcircuit> gmaxwell, shrug
228 2014-10-10 06:02:07 <Belxjander> at least imho
229 2014-10-10 06:02:13 <gmaxwell> All it takes for trolls to be victorious on the internet is for geeks to be geeks on the internet. :)
230 2014-10-10 06:04:02 <Luke-Jr> XD
231 2014-10-10 06:14:50 <Luke-Jr> (if anyone wants to help stifle this brand of troll on reddit before it gets in the hands of more trolls: http://www.reddit.com/r/Bitcoin/comments/2ityg2/warning_bitcoin_address_blacklists_have_been/ )
232 2014-10-10 06:16:49 <justanotheruser> Luke-Jr: looks like you're about to get boycotted
233 2014-10-10 06:17:01 <justanotheruser> 
ACTION removes every change made by Luke-Jr from bitcoin core

234 2014-10-10 06:17:05 <Luke-Jr> justanotheruser: lol, as if trolls hire me anyway
235 2014-10-10 06:17:40 <Luke-Jr> I mean, part of my job in Bitcoin is to get the trolls on my back so they leave the others alone, right? :p
236 2014-10-10 06:18:12 <Belxjander> well...THAT would be a subtle form of assualt...hire the main programmers of a project for "make work" and dump the results but keeping them too busy to retain management interest in the project...
237 2014-10-10 06:18:34 <Luke-Jr> lol
238 2014-10-10 06:18:38 <Belxjander> Luke-Jr: well it looks like you may be doing that...extra well?
239 2014-10-10 06:18:47 <justanotheruser> Luke-Jr: maybe.
240 2014-10-10 06:19:06 <justanotheruser> Perhaps you can be bitcoin cores PR lead
241 2014-10-10 06:19:14 <Luke-Jr> lol
242 2014-10-10 06:19:39 <justanotheruser> the responses would be hilarious
243 2014-10-10 06:19:48 <wumpus> justanotheruser: ah yes the master_no_lukejr branch :-)
244 2014-10-10 06:20:09 <Luke-Jr> someone should make that
245 2014-10-10 06:20:13 <Luke-Jr> it'd be interesting
246 2014-10-10 06:20:27 <justanotheruser> wumpus: would get a lot of support I bet
247 2014-10-10 06:20:34 <Luke-Jr> "yes, we know it rounds to 2 decimal places; no, that's not a bug, it's what you asked for."
248 2014-10-10 06:22:45 <wumpus> heh, a small practical problem would be that once a patch becomes too deeply buried in history it becomes impossible to revert it
249 2014-10-10 06:22:57 <wumpus> too many changes to the same code since :)
250 2014-10-10 06:23:57 <Luke-Jr> wumpus: not impossible, just very difficult :P
251 2014-10-10 06:25:05 <wumpus> so difficult that at some point it would be easier to build a time machine to go back in time and avoid Luke-Jr's commits from being merged in the first place :p
252 2014-10-10 06:26:00 <Luke-Jr> wumpus: meh, you can always revert by implementing the opposite of the commit message ;)
253 2014-10-10 06:27:32 <gmaxwell> meh, just remove mining and the wallet, that should get the vast majority of luke's code. :P
254 2014-10-10 06:28:44 <wumpus> a sledgehammer approach, but effective
255 2014-10-10 06:31:19 <Luke-Jr> btw, I submitted a PR tonight with step 1 of moving policy to its own (potentially-subclassable) source file :p
256 2014-10-10 06:33:59 <wumpus> Luke-Jr: interesting!
257 2014-10-10 06:34:34 <natoshisakamoto> http://www.reddit.com/r/Bitcoin/comments/2ityg2/warning_bitcoin_address_blacklists_have_been/
258 2014-10-10 06:34:52 <natoshisakamoto> have you guys seen this?
259 2014-10-10 06:36:13 <gmaxwell> natoshisakamoto: you realize that we can tell that you're the same person who joined earlier and was asked to take this elsewhere, right?
260 2014-10-10 06:36:15 <Luke-Jr> natoshisakamoto: yes thanks, but trolling like that is off-topic here
261 2014-10-10 06:36:42 <Luke-Jr> ugh, this guy is spamming every #bitcoin channel
262 2014-10-10 06:36:55 <Luke-Jr> (or at least 2 so far)
263 2014-10-10 06:37:18 <natoshisakamoto> luke, you deserve it. stop fucking with default behaviour of master branch code
264 2014-10-10 06:37:40 <natoshisakamoto> take your facist dictator nazi code elsewhere
265 2014-10-10 06:37:59 <petertodd> thanks
266 2014-10-10 06:38:35 <gwillen> np
267 2014-10-10 06:38:44 <petertodd> trolling for ACKs for 'Discourage fee sniping with nLockTime' - https://github.com/bitcoin/bitcoin/pull/2340
268 2014-10-10 06:38:52 <gmaxwell> Luke-Jr: this is probably too surprising a default, as I said earlier. It would be super better to just have no default and useflag the policy entirely. (well not the most usable, but its more in the gentoo spirit)
269 2014-10-10 06:39:07 <petertodd> fixed the last issue, and I just noticed it's been open for 1 year, 7 months...
270 2014-10-10 07:00:32 <Luke-Jr> gmaxwell: I'll have to split up my branch between policy and features. It's doable, just needs time.
271 2014-10-10 07:11:58 <BlueMatt> wumpus: "well, someone else thinks this is a good idea" may be the worst reason to be the first person to ack a pull....
272 2014-10-10 07:12:15 <wumpus> BlueMatt: well, it's mildly useful isn't it
273 2014-10-10 07:12:24 <wumpus> BlueMatt: I just don't want huge discussions about something trivial like that
274 2014-10-10 07:12:53 <wumpus> the code is obviously correct, so the only discussion would be about desirability of the feature
275 2014-10-10 07:13:03 <BlueMatt> keyword there is "first person to"
276 2014-10-10 07:13:06 <BlueMatt> :)
277 2014-10-10 07:13:16 <sipa> which pull?
278 2014-10-10 07:13:17 <petertodd> the RPC interface is weird, because it gets used so often by humans
279 2014-10-10 07:13:26 <BlueMatt> we need a "meh, I wont merge it, but code lgtm"
280 2014-10-10 07:13:33 <wumpus> https://github.com/bitcoin/bitcoin/pull/4964
281 2014-10-10 07:13:59 <sipa> ah
282 2014-10-10 07:14:04 <sipa> little opibion
283 2014-10-10 07:14:30 <BlueMatt> opibion?
284 2014-10-10 07:14:53 <sipa> "i have little opinion"
285 2014-10-10 07:15:12 <wumpus> but I'm ok with adding it to bitcoin-tx instead as well (if someone bothers to do that)
286 2014-10-10 07:15:44 <BlueMatt> 
ACTION votes for merge to avoid further discussion

287 2014-10-10 07:15:48 <sipa> it should be in bitcoin-key :)
288 2014-10-10 07:15:50 <petertodd> BlueMatt: ha
289 2014-10-10 07:15:51 <BlueMatt> since it has now had more discussion than its worth
290 2014-10-10 07:16:09 <BlueMatt> the "fuck it, merge it" approach
291 2014-10-10 07:16:15 <BlueMatt> at least its better than "fuck it, ship it"
292 2014-10-10 07:17:40 <wumpus> well I'm going to test it then...
293 2014-10-10 07:18:05 <BlueMatt> ;;later tell cfields do you know if travis runs its arm tests on an actual arm box, or in an emulator?
294 2014-10-10 07:18:07 <gribble> The operation succeeded.
295 2014-10-10 07:18:20 <Luke-Jr> 
ACTION thinks it is logical for validateaddress to give scriptPubKey, but no strong opinion

296 2014-10-10 07:18:20 <sipa> BlueMatt: it does not run tests, just compiles
297 2014-10-10 07:18:25 <wumpus> IIRC travis doesn't run arm tests, it just does a compile for that platform
298 2014-10-10 07:18:40 <BlueMatt> ;;later tell cfields if its an actual arm box, we really should be running tests (maybe without comparison tool) as arm has flushed out bugs in the past
299 2014-10-10 07:18:40 <gribble> The operation succeeded.
300 2014-10-10 07:18:43 <wumpus> tests are executed for x86 linux 32/64 and win 32/64
301 2014-10-10 07:18:44 <BlueMatt> sipa: I know :p
302 2014-10-10 07:18:52 <wumpus> (latter using wine)
303 2014-10-10 07:19:12 <wumpus> BlueMatt: then why do you ask?
304 2014-10-10 07:19:17 <Luke-Jr> I wonder if we should pass -frandom-seed differently to each x86-64 build
305 2014-10-10 07:19:27 <BlueMatt> wumpus: I asked if its running in physical arm hardware or an emulator
306 2014-10-10 07:19:34 <sipa> neither
307 2014-10-10 07:19:38 <wumpus> BlueMatt: it's doing a cross compile
308 2014-10-10 07:19:42 <BlueMatt> oh, it just compiles it?
309 2014-10-10 07:19:43 <BlueMatt> damn
310 2014-10-10 07:19:44 <BlueMatt> oh well
311 2014-10-10 07:19:44 <Luke-Jr> an earlier version of my policy PR actually failed only when built with some random seeds
312 2014-10-10 07:19:46 <Luke-Jr> :|
313 2014-10-10 07:19:46 <wumpus> yes, as I said
314 2014-10-10 07:19:53 <sipa> and i said :)
315 2014-10-10 07:20:00 <Luke-Jr> BlueMatt: Travis only supports x86-64 Ubuntu :/
316 2014-10-10 07:20:03 <BlueMatt> well I didnt read either right :p
317 2014-10-10 07:20:07 <wumpus> Luke-Jr: wut?! frandom-seed shouldn't make any difference
318 2014-10-10 07:20:12 <Luke-Jr> wumpus: initialisation order
319 2014-10-10 07:20:25 <Luke-Jr> I was using Params() in a global var initialiser
320 2014-10-10 07:20:29 <BlueMatt> ;;later tell cfields as $(EVERYONE) points out, nvm
321 2014-10-10 07:20:29 <gribble> The operation succeeded.
322 2014-10-10 07:20:41 <wumpus> Luke-Jr: whoa, don't do that
323 2014-10-10 07:20:54 <Luke-Jr> yeah, it's fixed now.. but might be good to have Travis exercise looking for those
324 2014-10-10 07:20:55 <wumpus> if possible please don't use global var initializers/destructors at all
325 2014-10-10 07:21:16 <sipa> let's use the git commit as random seed
326 2014-10-10 07:21:34 <Luke-Jr> sipa: … someone will grind the commit until Travis passes it :P
327 2014-10-10 07:21:43 <sipa> so we'll see consistent failure in unrelated commits when someone messes with initialization order :p
328 2014-10-10 07:22:59 <gmaxwell> oops. hm. seems to found a weird bug
329 2014-10-10 07:23:04 <gmaxwell> 2014-10-10 07:21:35 Error: Incorrect or no genesis block found. Wrong datadir for network?
330 2014-10-10 07:23:45 <sipa> gmaxwell: gah, i fixed bugs causing that a couple of times
331 2014-10-10 07:23:47 <wumpus> how did you get that?
332 2014-10-10 07:24:10 <gmaxwell> I was trying to torture 4988 but it seems the node I was testing on didn't have it applied.
333 2014-10-10 07:24:50 <gmaxwell> I started a IBD on a node with no state. Shut the node down (with a polite ctrl-c to bitcoind). deleted the chainstate, and restarted.
334 2014-10-10 07:25:05 <gmaxwell> it was as far as 2014-10-10 07:19:45 LoadBlockIndexDB(): last block file info: CBlockFileInfo(blocks=14943, size=3457320, heights=0...14942, time=2009-01-03...2009-05-18)
335 2014-10-10 07:25:29 <gmaxwell> I see the genesis block at the start of the first block file.
336 2014-10-10 07:30:32 <gmaxwell> sipa: in any case, what I wnated to test about 4988, is that on the first start it ends up deferencing [0] in the vector with nothing else there and printing:
337 2014-10-10 07:30:36 <gmaxwell> 2014-10-10 07:28:59 LoadBlockIndexDB(): last block file info: CBlockFileInfo(blocks=0, size=0, heights=0...0, time=1970-01-01...1970-01-01)
338 2014-10-10 07:30:51 <gmaxwell> which is a bit weird.
339 2014-10-10 07:33:06 <gmaxwell> anycase, the procedure I gave there is a 2/2 reproduction for me on top of the tree here which I think is a couple days ago plus the do not keep fully spent but unwritten ccoins entries code.
340 2014-10-10 07:35:29 <wumpus> does simply deleting the chainstate imply -reindex?
341 2014-10-10 07:36:36 <wumpus> what is *supposed* to happen if you delete the chainstate and restart?
342 2014-10-10 07:38:09 <wumpus> anyhow: I can reproduce it too "Error: Incorrect or no genesis block found. Wrong datadir for network?". Goes away when providing -reindex.
343 2014-10-10 07:39:04 <gmaxwell> wumpus: we used to just rebuild it.
344 2014-10-10 07:39:24 <gmaxwell> (and maybe still do under some conditions)
345 2014-10-10 07:39:29 <wumpus> I think it's pretty much an error if files are simply missing
346 2014-10-10 07:39:45 <wumpus> it does log an unsensible error message, agreed
347 2014-10-10 07:40:50 <gmaxwell> wumpus: not sure why we would have stopped just auto rebuidling it though, which was the intentional behavior before.
348 2014-10-10 07:41:30 <wumpus> probably because no one is testing that behavior, because people don't even know it existed? :p
349 2014-10-10 07:42:59 <wumpus> I'm fine with bringing it back ofcourse
350 2014-10-10 07:43:03 <gmaxwell> hah. dunno I think we broke it recently. I test it... (it's how I hit it here, whenever I delete the blocks directory I usually delete chainstate first and then restart)
351 2014-10-10 07:43:48 <gmaxwell> there was some test case when ultraprune was first developed where testing that way was super helpful. probably not that important but a little dumb setup robustness helps.
352 2014-10-10 07:43:56 <gmaxwell> I assume pieter is off fixing it.
353 2014-10-10 07:44:09 <wumpus> I always give -reindex after deleting the chainstate so didn't notice
354 2014-10-10 07:45:51 <zeroc00l> is luke-jr considered a core dev? im concerned with his attempts to blacklist bitcoin addresses
355 2014-10-10 07:46:03 <Luke-Jr> zeroc00l: trolling is that way ------> ##trollfest
356 2014-10-10 07:46:29 <zeroc00l> ?? its a serious question
357 2014-10-10 07:46:53 <Luke-Jr> zeroc00l: then ask in #bitcoin in a less troll-sounding way
358 2014-10-10 07:47:01 <gwillen> zeroc00l: look, if you're a different person from the last person who was trolling us about this, then please accept my apologies, but this is not the place and it's getting old fast
359 2014-10-10 07:47:10 <wumpus> sigh, bitcoin core is open source and anyone can make changes to it and distribute it
360 2014-10-10 07:47:46 <zeroc00l> Luke-Jr: i'd assume this would be the place for the most accurate question to whether or not you're considered a 'core dev'
361 2014-10-10 07:47:56 <Luke-Jr> zeroc00l: that isn't even a relevant question
362 2014-10-10 07:48:12 <zeroc00l> well, it is.
363 2014-10-10 07:48:14 <gwillen> zeroc00l: please, take this to #bitcoin, this is not appropriate here, final warning
364 2014-10-10 07:48:24 <zeroc00l> alright.
365 2014-10-10 07:48:30 <Luke-Jr> 'core dev' is ambiguous, and you're free to not consider me one if you prefer. Although doing so on the basis on troll rumours is ill-advised.
366 2014-10-10 07:49:54 <wumpus> it's completely ambigious, there is no official 'core dev' status, that's just not how things work... (just like everyone can call themselves linux kernel dev, but some would sound silly)
367 2014-10-10 07:52:45 <phantomcircuit> wumpus, im gonna start calling myself a protocol dev
368 2014-10-10 07:52:52 <phantomcircuit> just to see if anybody calls me on it
369 2014-10-10 07:53:53 <petertodd> phantomcircuit: last conference I was at I decided to pick a title that surely wouldn't exagerate anything: https://twitter.com/victoriavaneyk/status/519304533394993152
370 2014-10-10 07:55:35 <zeroc00l> Is luke-jr a sociopath?  The top post on reddit is about his blacklists, and he says 'only the minority is complaining'.  I'm seriously wondering if he has some sort of mental disorder (like mark karpeles)?  90% have upvoted that reddit post, and said they don't want his patch as default, and he's saying their opinions don't matter.  Is this guy serious?  Why don't any of you core devs make your opinions heard?   Excuse me while
371 2014-10-10 07:55:56 <gwillen> Thaaat's quite enough.
372 2014-10-10 07:56:29 <petertodd> gwillen: New rule: you must pay 1mBTC per #bitcoin-dev /join
373 2014-10-10 07:56:49 <Luke-Jr> lol
374 2014-10-10 07:58:09 <phantomcircuit> petertodd, ahahs
375 2014-10-10 07:58:13 <phantomcircuit> nice
376 2014-10-10 07:58:27 <btcdrak> :-P
377 2014-10-10 07:58:53 <gwillen> this is the SomethingAwful school of discourse? ;-)
378 2014-10-10 07:59:03 <gwillen> (they charge what, $5 per account / removal of ban?)
379 2014-10-10 08:00:26 <petertodd> gwillen: haha, yeah they do - mircea popescu had me buy him SomethingAwful passes with my credit card a few times so he could troll there
380 2014-10-10 08:00:34 <wumpus> its an interesting business model, but IMO it wouldn't filter in the right way, you'd get only people that want to pay to make their opinion/ranting heard :-)
381 2014-10-10 08:00:50 <gwillen> petertodd: ... the number of things wrong in that sentence
382 2014-10-10 08:00:51 <btcdrak> pay per word :-P
383 2014-10-10 08:01:44 <gmaxwell> I wish witcoin had survived.
384 2014-10-10 08:02:10 <gmaxwell> It did neat stuff along that space. maybe all stupid but it was an interesting expirement.
385 2014-10-10 08:02:18 <gmaxwell> (failed for reasons unrelated to the featureset)
386 2014-10-10 08:03:13 <gmaxwell> For those who weren't bitcoin users in 2010 / early 2011  witcoin was a reddit clone/fork where you paid micropayments (internally banked) to post.. but then got them back via upvotes and other such mechenisms, with varrious flow through paths and such.
387 2014-10-10 08:04:55 <wumpus> that does sound somewhat interesting; why did it fail?
388 2014-10-10 08:07:15 <t7> $5 says somebody took the money and ran
389 2014-10-10 08:07:25 <gmaxwell> I believe the operator lost interest... its bitcoind would crash and wouldn't get fixed for days.. eventually the server had some issue and they couldn't be bothered to bring it back up. Vanished off with some small amount of coin from people too.
390 2014-10-10 08:07:27 <t7> seems to be a running theme with any bitcoin business venture
391 2014-10-10 08:07:32 <gmaxwell> t7: you get $2.50
392 2014-10-10 08:07:48 <gmaxwell> No one complained about losing more than a bitcent or so though.
393 2014-10-10 08:08:15 <gmaxwell> It just seemed to not be hugely taking off, and using more maintance time then the people running it had patience for afaict.
394 2014-10-10 08:09:03 <phantomcircuit> gmaxwell, only one person was running it
395 2014-10-10 08:09:16 <t7> has anyone in here written a service using the wallet API from blockchain.info or similar ? seems like a really nice and easy way to do it
396 2014-10-10 08:09:18 <petertodd> gmaxwell: sounds like they would have had more success making it a fully decentralized app, if only because of the amount of vigorous self-referential discussion there could have been had by dozens of nerds writing the app itself
397 2014-10-10 08:09:18 <phantomcircuit> and he had to stop operating it for other reasons than available time
398 2014-10-10 08:09:26 <wumpus> right, that's what I'd be afraid of too with an internet community that would cost money to join... I'm sure you can get people to join, but it will never take off like the free-(first) sites
399 2014-10-10 08:10:21 <gmaxwell> wumpus: it was sort of neat in that writing popular posts could be profitable (though it was all very small amounts)... perhaps awful and weirdly distorting too, but it didn't get big enough to know for sure.
400 2014-10-10 08:11:29 <gmaxwell> (a lot of it was setup so the funds went to charity after circulating around between users too, which may have made the fees more tolerable to some)
401 2014-10-10 08:11:30 <wumpus> gmaxwell: having it actually cost something to upvote is interesting, it makes people more careful with dealing out their upvotes
402 2014-10-10 08:15:41 <midnightmagic> I withdrew the 10 or so bitcoins that the owner of the witcoin gifted me with to spread into the stories that I never ended up doing, well before it disappeared.
403 2014-10-10 08:16:14 <midnightmagic> i was one of its first users.
404 2014-10-10 08:24:45 <bitnumus> Lukejr go fuck yourself
405 2014-10-10 08:25:14 <bitnumus> Xiando found your gentoo patch about 5days ago but I didn't believe you would do that
406 2014-10-10 08:25:19 <bitnumus> You are scum.
407 2014-10-10 08:25:57 <xiando> https://bugs.gentoo.org/show_bug.cgi?id=524512
408 2014-10-10 08:26:03 <wumpus> not here bitnumus
409 2014-10-10 08:26:09 <bitnumus> Lol
410 2014-10-10 08:26:09 <bitnumus> O hi xiando
411 2014-10-10 08:26:33 <bitnumus> Sorry wumpus on tablet and confirmation just riled me.
412 2014-10-10 08:29:11 <justanotheruser> !ops bitnumus harassing Luke-Jr for making scalability improvements to bitcoin
413 2014-10-10 08:30:13 <bitnumus> Hoho
414 2014-10-10 08:31:10 <bitnumus> !ops justanotheruser false reporting for having an opinion on open source software
415 2014-10-10 08:32:27 <justanotheruser> bitnumus: telling someone to go fuck themselves for making a change which is optional use isn't an opinion on open source software. "I disagree with the use of your fork" is an opinion on software.
416 2014-10-10 08:33:12 <t7> wtf gentoo bitcoin ignores satoshi dice?
417 2014-10-10 08:33:59 <bitnumus> t7 apparently its fine, we just have to disagree with the fork
418 2014-10-10 08:34:18 <t7> what is the reasoning ?
419 2014-10-10 08:34:23 <bitnumus> Justanotheruser you are hilarious, this making it into a large distro is a joke
420 2014-10-10 08:34:38 <bitnumus> T7 luke-jr
421 2014-10-10 08:34:42 <wumpus> then complain at your distribution, not here
422 2014-10-10 08:34:44 <justanotheruser> bitnumus: take it up in #gentoo-dev.
423 2014-10-10 08:35:09 <justanotheruser> luke-jr hasn't made any changes to bitcoin itself in that change
424 2014-10-10 08:35:17 <bitnumus> O yea because every user of Bitcoin will know about this and how things work
425 2014-10-10 08:35:27 <bitnumus> That's really catering for the end user
426 2014-10-10 08:35:31 <bitnumus> Cmon guys
427 2014-10-10 08:36:00 <justanotheruser> bitnumus: bitcoin already has spam prevention. This is just a filter that catches slightly more spam
428 2014-10-10 08:36:05 <t7> i think Luke-Jr is wrong
429 2014-10-10 08:36:41 <wumpus> it's open source software, so people are free to make changes to it and redistribute it, there's nothing that can (or should) be done against that... if you don't agree with a change that your specific distribution makes by default, you need to complain at them