1 2014-10-03 01:30:00 <CodeShark> any asio experts in here?
  2 2014-10-03 01:33:41 <BlueMatt> pge@mattcorallo.comtADFuF_h46a5MGp
  3 2014-10-03 01:34:42 <sipa> ?
  4 2014-10-03 01:34:53 <BlueMatt> really should stop auto-typing passwords next to the irc window
  5 2014-10-03 01:35:42 <sipa> hunter2
  6 2014-10-03 01:47:04 <phantomcircuit> BlueMatt, lolol
  7 2014-10-03 01:47:11 <phantomcircuit> BlueMatt, im always worried about doing that
  8 2014-10-03 01:47:14 <phantomcircuit> have yet to actually do it
  9 2014-10-03 01:47:28 <BlueMatt> phantomcircuit: thats only like the third or fourth time...one of these days its gonna be my bank
 10 2014-10-03 01:52:23 <phantomcircuit> BlueMatt, at least you'd have pretty good proof that you were "hacked"
 11 2014-10-03 01:52:32 <BlueMatt> true
 12 2014-10-03 01:55:19 <jgarzik> One of the top-level Linux kernel hackers did an experiment, where he tweeted each shell command he typed
 13 2014-10-03 01:55:31 <jgarzik> worked great, until he typed too fast for a password prompt
 14 2014-10-03 01:55:59 <BlueMatt> oops
 15 2014-10-03 01:59:11 <CodeShark> I want a separate crypto coprocessor with its own keyboard :)
 16 2014-10-03 01:59:45 <CodeShark> and display
 17 2014-10-03 02:01:15 <BlueMatt> dont we all...
 18 2014-10-03 02:03:13 <CodeShark> I hope to get rid of passwords eventually
 19 2014-10-03 02:03:23 <SomeoneWeird> dont we all...
 20 2014-10-03 02:03:27 <CodeShark> lol
 21 2014-10-03 04:01:17 <prettymuchbryce> I recently created some bare minimum bitcoin functionality in Go, which I'm calling "Hello Bitcoin" for anyone interested in learning more about the protocol. https://github.com/prettymuchbryce/hellobitcoin
 22 2014-10-03 04:10:11 <Luke-Jr> prettymuchbryce: different from btcd how?
 23 2014-10-03 04:13:14 <sipa> Luke-Jr: NIH
 24 2014-10-03 04:14:54 <prettymuchbryce> I'm not trying to build a fully featured client. It was an experiment to help me learn more about the protocol, but I think it would be interesting for anyone who wanted to learn how the protocol works at a lower level in the most simple use cases.
 25 2014-10-03 04:15:18 <prettymuchbryce> Appreciate the cynacism sipa, cheers.
 26 2014-10-03 04:16:27 <sipa> prettymuchbryce: it's not criticism; for experimentation i fully support reimplementing things
 27 2014-10-03 04:16:45 <sipa> doesn't mean t's a good way to do something impactful :)
 28 2014-10-03 04:17:30 <prettymuchbryce> Learning is the first step in doing something impactful.
 29 2014-10-03 05:34:56 <Alina-malina> guys how much space i would require to run abe in postgresql and analize the data?
 30 2014-10-03 05:36:41 <phantomcircuit> try it and find out
 31 2014-10-03 05:38:21 <Alina-malina> >.<
 32 2014-10-03 05:38:24 <Alina-malina> no
 33 2014-10-03 05:38:24 <Alina-malina> u
 34 2014-10-03 05:42:38 <phantomcircuit> Alina-malina, no u
 35 2014-10-03 05:47:13 <Alina-malina> never
 36 2014-10-03 05:47:15 <Alina-malina> u
 37 2014-10-03 05:57:54 <phantomcircuit> make -j
 38 2014-10-03 05:57:55 <phantomcircuit> nom
 39 2014-10-03 06:03:54 <Alina-malina> guys how much hdd space i would require to run abe in postgresql and analize the data?
 40 2014-10-03 06:04:57 <phantomcircuit> Alina-malina, you're off topic
 41 2014-10-03 06:05:03 <phantomcircuit> this is bitcoin core development
 42 2014-10-03 06:05:07 <phantomcircuit> also i doubt anybody has any idea
 43 2014-10-03 06:05:20 <Alina-malina> who cares what bout doubt, just relax
 44 2014-10-03 06:08:38 <chaosagent> Alina-malina: probably the same or a bit mroe than the blkfile size
 45 2014-10-03 06:08:55 <Alina-malina> you mean the .dat file?
 46 2014-10-03 06:09:02 <chaosagent> yeah
 47 2014-10-03 06:09:20 <chaosagent> leave a few gbs just in case
 48 2014-10-03 06:09:42 <Alina-malina> will it run on single core machine? i have a weak machine, so i want to run an analizer algorithm on it?
 49 2014-10-03 06:34:06 <goykasi> is it just me, or has a miner been spamming testnet for the past day?
 50 2014-10-03 06:34:30 <wumpus> Alina-malina: if you want to analyze the whole block chain (ie, at a transaction or even lower level) in a sql database you're going to need tons of harddisk space, much more than the compact format bitcoin core uses
 51 2014-10-03 06:34:53 <wumpus> goykasi: hearn mentioned it as well yesterday, someone spamming empty blocks?
 52 2014-10-03 06:35:25 <goykasi> yah
 53 2014-10-03 06:35:31 <Alina-malina> hmmm right
 54 2014-10-03 06:35:43 <goykasi> it was ok for a second because i was able to test some 0 fee transactions
 55 2014-10-03 06:35:51 <goykasi> but now its splitting
 56 2014-10-03 06:37:08 <goykasi> 2014-10-03 06:37:10 CheckForkWarningConditions: Warning: Large valid fork found
 57 2014-10-03 06:37:13 <goykasi> and
 58 2014-10-03 06:37:13 <goykasi> Chain state database corruption likely.
 59 2014-10-03 06:37:16 <goykasi> argh
 60 2014-10-03 06:37:28 <Alina-malina> is 80GB enough got abe?
 61 2014-10-03 06:37:31 <Alina-malina> *for
 62 2014-10-03 06:37:46 <wumpus> Alina-malina: not sure what tools you're using, but for insight they say: As of June 2014, storing the livenet blockchain takes ~35GB of disk space (2GB for the testnet). Wouldn't be surprised if at least 10GB more is needed since then.
 63 2014-10-03 06:38:09 <Alina-malina> oh
 64 2014-10-03 06:38:36 <wumpus> so that's in addition to the block files themselves
 65 2014-10-03 11:41:39 <michagogo> phantomcircuit: doesn't that switch take an argument?
 66 2014-10-03 12:56:44 <jgarzik> Very nice
 67 2014-10-03 12:56:49 <jgarzik> bitcoinj gains HD wallet + Tor
 68 2014-10-03 12:56:59 <jgarzik> Been waiting ages for that... huzzah :)
 69 2014-10-03 12:57:57 <willermo> hello, i'm trying to send 5430 satashis, bitcoind response is "transaction amount is to small", in the past i was able to transfer this type of amount running bitcoind with -mintxfeerelay=0.0005430 but now it's now working anymore
 70 2014-10-03 13:01:37 <willermo> hello, i'm trying to send 5430 satoshis, bitcoind response is "transaction amount is to small", in the past i was able to transfer this type of amount running bitcoind with -mintxfeerelay=0.0005430 but now it's not working anymore
 71 2014-10-03 13:04:15 <hearn> jgarzik: yeah, finally :) this release took too long
 72 2014-10-03 14:33:36 <willermo> hello, i'm trying to send 5430 satoshis, bitcoind response is "transaction amount is to small", in the past i was able to transfer this type of amount running bitcoind with -mintxfeerelay=0.0005430 but now it's not working anymore
 73 2014-10-03 14:53:10 <michagogo> willermo: you have the switch wrong.
 74 2014-10-03 14:53:21 <michagogo> Run bitcoind --help
 75 2014-10-03 16:40:55 <BlueMatt> cfields: just a random note: I'd /really/ like to see a libscript or so make it in 0.10
 76 2014-10-03 16:41:13 <BlueMatt> and considering headers-first is getting very close, rc should not be far away
 77 2014-10-03 16:47:59 <BlueMatt> cfields: what is required on the build-system front to make that happen?
 78 2014-10-03 16:53:01 <sipa> BlueMatt: can i haz ACK on 4890?
 79 2014-10-03 16:53:26 <BlueMatt> sipa: thats #2 on review list atm
 80 2014-10-03 16:53:31 <BlueMatt> (headers-first now)
 81 2014-10-03 17:13:35 <netg> is there an monero-testnet now?
 82 2014-10-03 17:13:41 <netg> fuck sorry, sorry, sorry
 83 2014-10-03 17:13:45 <netg> wrong channel
 84 2014-10-03 17:13:49 <sipa> :)
 85 2014-10-03 18:09:41 <cfields> BlueMatt: i'm working on that with the deps reductions PRs
 86 2014-10-03 18:11:38 <BlueMatt> cfields: ahh, missed that that one was yours (I try to ignore who originated a pull for review)
 87 2014-10-03 18:11:57 <cfields> BlueMatt: if we can manage to rip out the core deps, the lib process becomes lots easier
 88 2014-10-03 18:12:06 <cfields> so i'm working on it from that angle first
 89 2014-10-03 18:12:21 <BlueMatt> cfields: in any case, what is required on the build system front itself (ie getting windows to build a dll, etc, etc)
 90 2014-10-03 18:15:09 <cfields> BlueMatt: if it can be built without core deps, it doesn't necessarily need build-system integration
 91 2014-10-03 18:15:26 <cfields> not that that's the best way forward ofc, but it creates that option
 92 2014-10-03 18:16:52 <BlueMatt> true, but it doesnt make a good case for other clients to integrate it if its not "official"
 93 2014-10-03 18:17:09 <BlueMatt> and with 0.10 Id like to be able to go to other implementations and beat them over the head to use it :)
 94 2014-10-03 18:17:09 <sipa> cfields: how do you mean without core deps?
 95 2014-10-03 18:17:17 <sipa> it will at least depend on script/interpreter...
 96 2014-10-03 18:17:38 <sipa> oh, you mean without external dependencies?
 97 2014-10-03 18:17:48 <sipa> for now it will inevitably depend on openssl for signature checking
 98 2014-10-03 18:18:24 <cfields> sipa: no, i mean without depending on core structures at all
 99 2014-10-03 18:18:39 <sipa> that makes no sense
100 2014-10-03 18:18:55 <sipa> it needs CScript, CTransaction, CTxIn, CTxOut, ...
101 2014-10-03 18:19:17 <cfields> sipa: CScript no longer depends on core structures..
102 2014-10-03 18:19:22 <cfields> (after that PR)
103 2014-10-03 18:19:30 <sipa> the script interpreter itself can be made independent from core datastructures
104 2014-10-03 18:19:38 <sipa> but actual bitcoin transaction checking still does
105 2014-10-03 18:19:47 <sipa> which is what we want the library to expose, afaik?
106 2014-10-03 18:20:05 <sipa> i don't want users of the library to need to go implement transaction serialization themselves
107 2014-10-03 18:20:11 <cfields> sipa: yes, that's what I was trying to say, i suppose
108 2014-10-03 18:20:38 <sipa> i'm wholly in favor of making script verification _code_ independent from core data structures
109 2014-10-03 18:20:54 <sipa> but the library will still use it
110 2014-10-03 18:21:10 <sipa> so i don't see how dependency reduction is relevant to the library
111 2014-10-03 18:21:50 <sipa> as in: sighash implementation is consensus critical (and tricky), so i want it to be part of it
112 2014-10-03 18:22:39 <sipa> making core data structures themselves more lean and modular so that depending on them pulls less code and less external libraries is also a perfect idea
113 2014-10-03 18:28:26 <cfields> sipa: well, i had still been hoping to continue moving dependencies the other way, so that core and lib could both depend on the same implementation, rather than both depending on deep core structures
114 2014-10-03 18:28:58 <sipa> cfields: i don't understand
115 2014-10-03 18:29:39 <sipa> ideally, we have 1) core data structures  2) validation logic  3) script implementation  4) wallet stuff
116 2014-10-03 18:29:49 <sipa> the lib would be 1+3
117 2014-10-03 18:30:01 <sipa> bitcoind would be 1+2+3
118 2014-10-03 18:30:10 <sipa> wallet would be 1+3+4
119 2014-10-03 18:30:41 <sipa> in practice, things are more complicated of course, because core data structures currently depends on stuff that is unnecessary in script
120 2014-10-03 18:30:49 <sipa> which just means we need to modularize further
121 2014-10-03 18:30:58 <sipa> which i guess is what you're saying
122 2014-10-03 18:31:17 <sipa> but "if it can be built without core deps" makes no sense to me
123 2014-10-03 18:38:52 <cfields> sorry, stupid dog
124 2014-10-03 18:39:50 <cfields> sipa: there's a good chance it makes no sense, then
125 2014-10-03 18:40:49 <sipa> cfields: what i mean is that imho the library should be a "bitcoin transaction script validation library", not a "script evaluation library"
126 2014-10-03 18:42:41 <cfields> sipa: i had imagined breaking out a few base structures as abstractions, which library users would be required to reimplement
127 2014-10-03 18:42:59 <cfields> much like you did with the sigcache
128 2014-10-03 18:43:06 <sipa> yes, for optional parts
129 2014-10-03 18:43:10 <sipa> not for consensus critical stuff
130 2014-10-03 18:44:11 <cfields> well, even those could be implemented as part of the lib which core also uses, but i suppose serialization is too tightly integrated to let that work
131 2014-10-03 18:44:36 <sipa> cfields: i'm making a distinctions between implementation dependencies and library dependencies
132 2014-10-03 18:44:59 <sipa> script/interpreter.{h,cpp} should absolutely have as little dependencies as possible (see 4890 and your work)
133 2014-10-03 18:45:14 <sipa> but that doesn't mean that the finished library should just be script/interpreter.{h,cpp}
134 2014-10-03 18:47:40 <cfields> ok, then yes, that's the point of contention.
135 2014-10-03 18:49:38 <cfields> (was). i understand your point now.
136 2014-10-03 18:55:03 <davec>  While I do think the script libary is overall a decent idea, it really doesn't address the fundamental issues in the long run.  For that, there needs to be distributed, multi-implementation consensus.  Claiming otherwise is being very short sighted in my opinion.
137 2014-10-03 18:55:36 <davec> I'm glad to see work happening to modularize the logic out regardless though
138 2014-10-03 18:55:44 <sipa> davec: claiming multi-implementation can be consistent is naive, imho :)
139 2014-10-03 18:56:24 <sipa> that's not a criticism on the capabilities on people reimplementing things, just the state of the art at this point
140 2014-10-03 18:56:40 <sipa> we've seen too many examples in incredibly subtle places
141 2014-10-03 18:57:03 <cfields> after redoing the scriptnum stuff, agreed. and i'm sure that's minute in the grand scheme
142 2014-10-03 18:57:05 <davec> It will be difficult and require additional infrastructure that isn't well established and/or built yet
143 2014-10-03 18:57:27 <sipa> which is why i'm very much in favor of multiple implelemntations of pretty much everything in the bitcoin ecosystem
144 2014-10-03 18:57:33 <sipa> except consensus critical parts
145 2014-10-03 18:57:54 <davec> aye, I don't disagree the currently it's close to impossible
146 2014-10-03 18:58:25 <davec> s/the/that
147 2014-10-03 18:59:05 <sipa> but the current claim we're making "noooo don't do a full reimplementation, it will be inconsistent!" is obviously non-satisfactory to people who want to do interesting things
148 2014-10-03 18:59:18 <davec> However, a library alone doesn't really solve the issue either.  I mean we could easily have a case where a refactor hits one of those hidden cases
149 2014-10-03 18:59:50 <sipa> so i want at least to have the trickiest part (script evaluation) with no non-consensus policy associated with it available
150 2014-10-03 18:59:57 <davec> nobody notices for a while, then at some point a new transaction type is added, or a non-standard transaction is mined which is handled differently between the code before and after the refactor
151 2014-10-03 19:00:18 <sipa> in a reusable library
152 2014-10-03 19:00:34 <sipa> davec: well, yes, obviously a script evaluation library won't cover all of the consensus critical code
153 2014-10-03 19:00:51 <sipa> but i think it will at least reduce the risk pretty massively
154 2014-10-03 19:00:55 <lechuga_> agreed
155 2014-10-03 19:01:00 <davec> aye, please don't take my comments as disparaging the work.  I do think it's a good step and am excited to see the logic more modularized.
156 2014-10-03 19:01:55 <sipa> i don't disagree either
157 2014-10-03 19:02:09 <sipa> but i would really encourage you to use such a library if we'd make it available
158 2014-10-03 19:06:08 <dhill> how much of a pain to make script not depend on boost?
159 2014-10-03 19:06:16 <sipa> very doable, imho
160 2014-10-03 19:06:22 <davec> I think I mentioned it in here before that I'm not opposed to having a build tag which pulls it in
161 2014-10-03 19:06:49 <dhill> i think btcd will attempt to use it at least for testing to start with
162 2014-10-03 19:07:00 <sipa> dhill: cool, good to know
163 2014-10-03 19:07:04 <dhill> it would be nice if boost depend went away
164 2014-10-03 19:07:26 <sipa> the plan for the script library is to have as little dependencies as possible, and be thread-agnostic
165 2014-10-03 19:07:33 <cfields> sipa: i'd be happy to drop the core deps goal and do boost instead, then
166 2014-10-03 19:07:44 <davec> there are some cases where it wouldn't work though like GAE since it would require cgo and unsafe, both or which are disallowed there
167 2014-10-03 19:07:52 <cfields> i really want that gone, and it seems everyone agrees for once :)
168 2014-10-03 19:07:54 <Luke-Jr> boost::bcscript
169 2014-10-03 19:07:56 <Luke-Jr> <.<
170 2014-10-03 19:08:01 <lechuga_> lol
171 2014-10-03 19:08:06 <sipa> davec: however we can't get rid of openssl for now
172 2014-10-03 19:08:07 <dhill> BOOST_FOREACH is all i see in script?
173 2014-10-03 19:08:19 <sipa> yeah, i think it's trivial after getting the caching out
174 2014-10-03 19:08:26 <sipa> which depends on threading, which uses boost
175 2014-10-03 19:08:45 <cfields> oh, maybe we're done then? :)
176 2014-10-03 19:08:56 <lechuga_> boost:bcscript kind of an awesome idea
177 2014-10-03 19:09:03 <lechuga_> ::
178 2014-10-03 19:09:03 <sipa> davec: sounds like GAE is just a bad choice for consensus critical things in general then :(
179 2014-10-03 19:09:08 <sipa> that's pretty unfortunate
180 2014-10-03 19:10:00 <rfreeman_w> boost::coin<bitcoin>::node n;
181 2014-10-03 19:12:49 <lechuga_> now i have to lie about my user-agent to get through BlueMatt's tests in a reasonable amount of time :/
182 2014-10-03 19:14:44 <lechuga_> nm just an additional 30s
183 2014-10-03 19:14:45 <BlueMatt> lechuga_: yes, that is on purpose
184 2014-10-03 19:14:58 <lechuga_> yeah it doesn't look like an accident :)
185 2014-10-03 19:17:34 <lechuga_> maybe a more comprehensive regression suite for use by any impl should be a priority
186 2014-10-03 19:17:52 <lechuga_> (not implying that should be the responsibility of bitcoin core)
187 2014-10-03 19:17:58 <BlueMatt> clearly it didnt work...did you read the message?
188 2014-10-03 19:18:04 <lechuga_> skimmed it
189 2014-10-03 19:18:05 <davec> lechuga_: just do what I did and recompile it without that childish behavior
190 2014-10-03 19:18:08 <BlueMatt> the priority should be making a shared library
191 2014-10-03 19:18:19 <BlueMatt> then its no big deal :)
192 2014-10-03 19:18:37 <lechuga_> im for a shared library
193 2014-10-03 19:18:56 <lechuga_> but also think a real standard cross-impl regression suite may have value
194 2014-10-03 19:19:16 <BlueMatt> its probably not reasonable to get a non-script shared library used by everyone
195 2014-10-03 19:19:31 <BlueMatt> and luckily a lot of that stuff can be rather well-tested by a regression suite
196 2014-10-03 19:19:37 <BlueMatt> (in fact the current one isnt too bad at that)
197 2014-10-03 19:19:47 <BlueMatt> but the script stuff needs 100% to be a shared library that everyone uses
198 2014-10-03 19:19:53 <BlueMatt> there is simply no other way to do it right
199 2014-10-03 19:20:07 <BlueMatt> (short of strong static analysis)
200 2014-10-03 19:36:41 <cfields> BlueMatt: so to answer your question from way back, i'll shift focus back to the shared lib once boost is removed
201 2014-10-03 19:36:52 <BlueMatt> cfields: ahh, ok, thanks
202 2014-10-03 19:36:53 <cfields> i'll work on that part first
203 2014-10-03 19:37:24 <cfields> boost can be especially tricky since in many cases you need to build your code with the same options boost was built with
204 2014-10-03 19:37:45 <cfields> otherwise it can lead to some very non-obvious problems. So i'd rather just skip those problems entirely
205 2014-10-03 19:39:04 <Luke-Jr> cfields: can we get Travis doing a build on a non-BASH system to avoid bashisms getting reintroduced?
206 2014-10-03 19:39:55 <Luke-Jr> not sure how easy that is to do on Ubuntu - maybe just a ln -sf dash /bin/sh
207 2014-10-03 19:40:00 <cfields> Luke-Jr: we don't have much of a choice there, but we could switch shells before building i suppose?
208 2014-10-03 19:40:33 <Luke-Jr> cfields: I think configure explicitly uses /bin/sh, so we need to change that link somehow at least
209 2014-10-03 19:40:35 <cfields> Luke-Jr: yea, there's an update-alternatives thing, but i'm not sure if that affects the current shell or not
210 2014-10-03 19:40:53 <Luke-Jr> current shell maybe not as important - it's just doing stuff we tell it to anyway
211 2014-10-03 19:41:35 <cfields> Luke-Jr: pretty sure dash is default in ubuntu anyway, these days?
212 2014-10-03 19:41:50 <Luke-Jr> cfields: apparently not, since our configure fails horrifically in dash :/
213 2014-10-03 19:41:54 <Luke-Jr> even for 0.9.3
214 2014-10-03 19:42:26 <cfields> cory@cory-i7:~/dev/bitcoin(0.9.3)$ ls -al /bin/sh
215 2014-10-03 19:42:26 <cfields> lrwxrwxrwx 1 root root 4 Jul  3  2013 /bin/sh -> dash
216 2014-10-03 19:42:38 <Luke-Jr> hmm
217 2014-10-03 19:42:45 <cfields> i just happened to be building there at the moment :)
218 2014-10-03 19:43:11 <Luke-Jr> https://bugs.gentoo.org/show_bug.cgi?id=524332
219 2014-10-03 19:44:00 <cfields> Luke-Jr: i hacked autotools together from this machine...
220 2014-10-03 19:44:27 <cfields> not saying it's not true, just not seeing the discrepancy
221 2014-10-03 19:44:44 <Luke-Jr> I wonder if Ubuntu is patching dash to support bashisms :|
222 2014-10-03 19:45:16 <cfields> that sounds likely
223 2014-10-03 19:45:57 <cfields> sec, seeing if i can find somewhere to turn that on/off
224 2014-10-03 19:51:01 <cfields> Luke-Jr: mm, looks like my interactive shell is bash
225 2014-10-03 19:56:47 <cfields> Luke-Jr: now i'm thoroughly confused. i can get my shell to complain, but configure works fine even with dash hard-coded
226 2014-10-03 19:57:47 <cfields> http://pastebin.com/raw.php?i=M6BfUscR
227 2014-10-03 19:58:06 <cfields> ^^as expected
228 2014-10-03 19:59:59 <Luke-Jr> what if you do it on a system without bash? maybe dash is calling bash if it fails in some cases
229 2014-10-03 20:01:28 <cfields> yea, looks like that's what's happening
230 2014-10-03 20:01:53 <cfields> so i suppose there's some crazy system where bash is a link to dash?
231 2014-10-03 20:02:10 <Luke-Jr> doubt it, more likely just a dash-only
232 2014-10-03 20:03:07 <cfields> tons of scripts use #! /bin/bash (as-is the correct thing to do if you rely on bash)
233 2014-10-03 20:03:24 <cfields> so it's hard to imagine that a system could run without /bin/bash
234 2014-10-03 20:03:44 <cfields> Luke-Jr: either way, i agree that it's worth fixing and trying to test
235 2014-10-03 20:05:43 <cfields> there we go: CONFIG_SHELL=dash ./configure
236 2014-10-03 20:06:12 <Luke-Jr> O.o
237 2014-10-03 20:06:42 <Luke-Jr> aha
238 2014-10-03 20:06:46 <Luke-Jr> configure relaunches itself XD
239 2014-10-03 20:06:56 <cfields> yea
240 2014-10-03 21:03:28 <Gnosis> is it bad practice for new code to use exceptions? I noticed a lot of errors are signaled in the C way (returning false, or a special value like NULL)
241 2014-10-03 21:34:32 <sipa> Gnosis: C does not have exceptions
242 2014-10-03 21:43:57 <Luke-Jr> sipa: I think he means Bitcoin Core
243 2014-10-03 21:44:06 <Luke-Jr> ie, is he okay using exceptions in PRs
244 2014-10-03 21:44:15 <Luke-Jr> I don't see a problem with it, but I dunno how anyone else feels
245 2014-10-03 22:43:00 <Gnosis> Luke-Jr: yeah, that is what I meant; I'll use exceptions in PRs I create until somebody objects. Thanks!