1 2014-11-18 02:08:43 <cfields> sipa: ping. any chance you're around?
  2 2014-11-18 02:09:22 <cfields> sipa: a while back you mentioned that you wanted to get rid of CPrivKey. I'm curious now about what you'd like to see replace it
  3 2014-11-18 05:52:57 <gues>  /leave
  4 2014-11-18 07:36:04 <Krellan> gmaxwell: There, I refactored my -whiteconnections patch after our nice chat the other day
  5 2014-11-18 07:36:05 <Krellan> https://github.com/bitcoin/bitcoin/pull/5288
  6 2014-11-18 07:36:42 <Krellan> I put in what we had talked about, seems to work nicely now
  7 2014-11-18 08:01:56 <sipa> cfields: i was talking about what was called CPrivKey before
  8 2014-11-18 08:02:09 <sipa> ah, no, i wasn't
  9 2014-11-18 08:02:18 <sipa> are you talking about CPrivKey or Ckey?
 10 2014-11-18 08:02:38 <cfields> sipa: CPrivKey
 11 2014-11-18 08:02:58 <sipa> CPrivKey is just a dumb container that's only used in wallets because of backward compatibility
 12 2014-11-18 08:03:52 <cfields> sipa: right. I was hoping we could move it out of Ckey and into the wallet
 13 2014-11-18 08:04:01 <sipa> that's probably possible
 14 2014-11-18 08:04:25 <cfields> ok, great
 15 2014-11-18 08:04:44 <cfields> i already hacked something up, it was pretty trivial. just wanted to make sure it lined up with what you had in mind
 16 2014-11-18 08:04:51 <cfields> or.. wasn't counter to it, at least :)
 17 2014-11-18 09:43:30 <rubensayshi> hmm, why are testnet p2sh addresses 35 chars :/ ?
 18 2014-11-18 09:47:47 <sipa> rubensayshi: because 256^25 is more than 58^34
 19 2014-11-18 09:48:21 <sipa> so encoding 25 characters (version byte, 20 data bytes, 4 checksum bytes) in base58 can result in more than 34 characters, if the number is large enough
 20 2014-11-18 09:48:49 <sipa> it doesn't happen for other address types because the version byte is small enough not to go over the threshold
 21 2014-11-18 09:49:22 <rubensayshi> ah okay, thanks!
 22 2014-11-18 12:25:42 <hearn> good afternoon
 23 2014-11-18 12:28:18 <sipa> ... infidels
 24 2014-11-18 12:37:48 <jtimon> I'm still waiting for an answer on "should I squash #4793 already?"
 25 2014-11-18 13:02:41 <jtimon> I squashed it and conserved the old version in https://github.com/jtimon/bitcoin/tree/proof2_old just in case
 26 2014-11-18 13:23:33 <jtimon> mhmm, no I need to squash again
 27 2014-11-18 13:55:14 <sipa> wumpus: what's your opinion about #5220/#5227 in 0.10?
 28 2014-11-18 13:56:07 <wumpus> that's for deterministic signing? sounds good to me
 29 2014-11-18 13:56:30 <sipa> and libsecp256k1 signing
 30 2014-11-18 13:57:16 <wumpus> and we should also merge the sanity check after key generation
 31 2014-11-18 13:57:25 <wumpus> #5224
 32 2014-11-18 13:58:14 <sipa> if you just want deterministic signing, but not libsecp256k1, the openssl implementation probably needs some minimal effort to reduce timing leaks, as OpenSSL is better at it than #5227 (but libsecp256k1 should now be 100% branch-free for signing)
 33 2014-11-18 13:58:16 <wumpus> I'll take a look at those today, I was planning to do bitcoinconsensus tests on windows, but wasn't expecting last-minute changes to the API
 34 2014-11-18 13:59:12 <wumpus> using libsecp256k1 is fine
 35 2014-11-18 14:00:44 <sipa> so script/sign.cpp calls VerifySignature on every created signature, so even if the signing code in libsecp256k1 is broken, at worst you'd occasionally get a "transaction signing failed"
 36 2014-11-18 14:01:56 <wumpus> yes I think that check rules out any risk there (besides side-channel leaks, but OpenSSL isn't very good there in the first place)
 37 2014-11-18 14:06:10 <jtimon> oh, I missed the latest libconsensus PR
 38 2014-11-18 14:15:31 <jtimon> wumpus I know this is not prioritary at all, but can we deprecate gethashpersec RPC call (included in #4793) by 0.10 ?
 39 2014-11-18 14:29:54 <wumpus> jtimon: I have no problem with that, though in the larger scheme I'm not so sure about subjecting the internal miner to death by a thousand paper cuts, if we're going to strip it feature by feature, I'd rather just remove the whole thing
 40 2014-11-18 14:30:13 <wumpus> earlier you already had a commit to make it slower, for example
 41 2014-11-18 14:31:26 <wumpus> I mean, I get it that it's only a reference implementation, but if the goal is to have a nice clean reference miner, it'd be better to have it as separate project based on getblocktemplate
 42 2014-11-18 14:33:48 <wumpus> but *if* you have a miner, isn't it useful to know the hash rate?
 43 2014-11-18 14:54:37 <wumpus> on the other hand, a while ago we've also talked about removing parellism from the internal miner, so if we're going to strip it down we may as well bundle a few things...
 44 2014-11-18 14:56:09 <sipa> do we have some reference GBT python miner?
 45 2014-11-18 14:56:18 <sipa> for regtest that would be more than sufficient
 46 2014-11-18 14:56:24 <wumpus> nope
 47 2014-11-18 14:56:44 <wumpus> we used to have a getwork reference miner, but it was removed along with getwork
 48 2014-11-18 14:57:05 <sipa> right
 49 2014-11-18 15:00:45 <wumpus> what is the relationship between #5227 and #5220? which one should go in first?
 50 2014-11-18 15:01:32 <wumpus> or does #5220 make #5227 unnecessary?
 51 2014-11-18 15:01:45 <sipa> no, one changes the nonce calculation to be deterministic
 52 2014-11-18 15:02:09 <sipa> but (temporarily) needs a workaround to make openssl be deterministic
 53 2014-11-18 15:02:22 <wumpus> doesn't secp2561k1 (#5220) always use deterministic signing?
 54 2014-11-18 15:02:35 <sipa> no, it leaves the nonce calculation up to the caller
 55 2014-11-18 15:02:45 <wumpus> ok
 56 2014-11-18 15:02:55 <sipa> the other switches the signing to libsecp256k1, so that workaround isn't needed anymore
 57 2014-11-18 15:03:04 <sipa> i can make a combined PR that's simpler
 58 2014-11-18 15:03:18 <sipa> otherwise, either can go in first, and i'll rebase the other
 59 2014-11-18 15:03:30 <wumpus> not necessary, I understand now
 60 2014-11-18 15:12:25 <jgarzik_> wumpus, HTTP REST, yea or nay?
 61 2014-11-18 15:12:59 <jgarzik_> I think it's usefully small and compact, and will be used extensively by upper layer services
 62 2014-11-18 15:13:12 <wumpus> ACK
 63 2014-11-18 15:33:44 <JackH> hello devs
 64 2014-11-18 15:35:59 <cfields> wumpus: seems we had some rather different thoughts on the lib api
 65 2014-11-18 15:36:42 <wumpus> hello JackH
 66 2014-11-18 15:36:43 <cfields> probably better to go ahead and hash them out rather than ping/pong on PRs
 67 2014-11-18 15:36:48 <wumpus> cfields: ok
 68 2014-11-18 15:36:53 <JackH> wumpus hi
 69 2014-11-18 15:36:58 <JackH> I have a suggestion
 70 2014-11-18 15:36:58 <sipa> ohai
 71 2014-11-18 15:37:09 <JackH> can you guys add facebook chat to bitcoind?
 72 2014-11-18 15:37:12 <JackH> or maybe snapchat?
 73 2014-11-18 15:37:15 <wumpus> cfields: BTW I'm fine with not having detailed error reporting in API 0 at all
 74 2014-11-18 15:37:18 <sipa> JackH: lol
 75 2014-11-18 15:37:24 <JackH> haha
 76 2014-11-18 15:37:32 <wumpus> JackH: I was just working on merging doom3 into it
 77 2014-11-18 15:37:46 <cfields> wumpus: i had intended for the errors and ScriptErrorString to both be external
 78 2014-11-18 15:37:49 <paveljanik> wumpus: I hope you used aalib for UI...
 79 2014-11-18 15:37:50 <JackH> it should be mined into bitcoin, lol
 80 2014-11-18 15:37:51 <sipa> I do believe we need an integrated 2048 game to generate entropy for key generation
 81 2014-11-18 15:38:06 <cfields> wumpus: though, used opaquely
 82 2014-11-18 15:38:44 <wumpus> cfields: if it's intended to be external it should be in bitcoinconsensus.h imo
 83 2014-11-18 15:38:55 <sipa> wumpus: which isn't possible without duplication
 84 2014-11-18 15:39:03 <wumpus> sipa: then have duplication
 85 2014-11-18 15:39:07 <cfields> wumpus: well because it's used internally too, i gave it its own header...
 86 2014-11-18 15:39:17 <sipa> yeah, i prefer duplicaton too
 87 2014-11-18 15:39:19 <cfields> with the intention of moving flags and other enums in there as well
 88 2014-11-18 15:39:29 <cfields> hmm, why?
 89 2014-11-18 15:39:33 <cfields> just to keep it to a single header?
 90 2014-11-18 15:39:40 <wumpus> yes, keep the interface in a single header
 91 2014-11-18 15:39:51 <sipa> and to be able to modify the implementation without changing the API
 92 2014-11-18 15:39:55 <wumpus> and because external and internal interface will diverge over time
 93 2014-11-18 15:40:36 <cfields> wumpus: well for the errors, like i said, i meant for them to be opaque. so user code would never check for a particular error, only lookup the one they received...
 94 2014-11-18 15:40:56 <wumpus> the purpose is to have a self-contained library with a trivially simple interface
 95 2014-11-18 15:40:57 <cfields> that might've been more clear if i stuffed it in a struct and passed out a struct pointer instead, more like a c handle
 96 2014-11-18 15:41:09 <wumpus> cfields: then add a bitcoinconsensus_errorstring() to bitcoinconsensus.h ?
 97 2014-11-18 15:41:20 <wumpus> cfields: and add a opaque typedef for the error coe
 98 2014-11-18 15:41:31 <sipa> cfields: at some point we may want to add more data than just an enum too
 99 2014-11-18 15:41:39 <sipa> like which byte position an error occurred or something
100 2014-11-18 15:41:47 <sipa> so an opaque struct seems meaningful
101 2014-11-18 15:41:55 <wumpus> then again, if it's opaque anyway, then we could just as well return a string ...
102 2014-11-18 15:42:10 <sipa> the enum definition shouldn't be exposed
103 2014-11-18 15:42:14 <wumpus> if the only use it to pass it into a string function anyway
104 2014-11-18 15:42:34 <sipa> that's fine to me too
105 2014-11-18 15:42:59 <cfields> wumpus: well, imo it should be valid to say something like: if (status == status_ok) print(status)
106 2014-11-18 15:43:12 <cfields> er, there's should be a ! in there somewhere :)
107 2014-11-18 15:43:13 <sipa> you get the success or not value anyway
108 2014-11-18 15:43:13 <wumpus> anyhow, an opaque error code is fine with me too, that breaks the dependency on script_error.h
109 2014-11-18 15:43:31 <sipa> and further: the return value should matter to you, the string shouldn't
110 2014-11-18 15:43:38 <wumpus> eh, indeed
111 2014-11-18 15:43:49 <wumpus> maybe we should just keep it to that
112 2014-11-18 15:44:27 <wumpus> detailed error status is useful for debugging/troubleshootin, but not much more
113 2014-11-18 15:44:51 <wumpus> leave that for a later API anyhow
114 2014-11-18 15:44:54 <sipa> and from a script semantics perspective, all errors are identical
115 2014-11-18 15:45:07 <sipa> a script verification succeeds or fails
116 2014-11-18 15:45:11 <wumpus> indeed
117 2014-11-18 15:46:14 <sipa> for now you could do with a: char * const * script_error (pointer to const pointer to char) to return the message in
118 2014-11-18 15:46:26 <sipa> but maybe at some point we want on-the-fly generated strings with more information
119 2014-11-18 15:46:41 <wumpus> but that's pretty horrible in C
120 2014-11-18 15:47:20 <sipa> so i guess to be generic you need a size_t* str_error_len, const char* str_error
121 2014-11-18 15:47:26 <wumpus> you'd have to either pass a fixed buffer (eek), or you need to caller to not forget to deallocate it
122 2014-11-18 15:47:35 <cfields> would you be completely against an opaque handle, even if it's overkill for now? and feeding that into a tostring() func ?
123 2014-11-18 15:47:54 <cfields> that would at least give us breathing room for the future without mangling the api
124 2014-11-18 15:47:54 <sipa> how do you define the opaque handle?
125 2014-11-18 15:48:29 <wumpus> well if it is a pointer to a structure of any kind then it needs to be deallocated
126 2014-11-18 15:48:33 <sipa> indeed
127 2014-11-18 15:48:40 <wumpus> that kinds of sucks
128 2014-11-18 15:48:43 <wumpus> why not just 1/0?
129 2014-11-18 15:48:51 <wumpus> why return more at all?
130 2014-11-18 15:48:59 <sipa> the return value should absolutely be 1/0
131 2014-11-18 15:49:09 <sipa> but for debugging, a message may be very usefu
132 2014-11-18 15:49:26 <wumpus> ok, so if it's for humans, a string would make sense
133 2014-11-18 15:49:29 <sipa> let's not mix the evaluation result with the error code
134 2014-11-18 15:49:40 <sipa> the error code shouldn't ever be used to drive application decisions
135 2014-11-18 15:49:45 <wumpus> right
136 2014-11-18 15:49:52 <sipa> which is why a string is fine to me
137 2014-11-18 15:50:36 <sipa> and i'm not against an opaque handle, but i'm not sure it solves match
138 2014-11-18 15:50:38 <sipa> *much
139 2014-11-18 15:50:54 <sipa> as you still get the uglyness of conversion to string somewhere else
140 2014-11-18 15:51:02 <sipa> and you may need to force allocation stuff onto the a client
141 2014-11-18 15:51:17 <wumpus> yes
142 2014-11-18 15:51:28 <cfields> ok, settled then
143 2014-11-18 15:51:45 <sipa> we could just have an API now that doesn't do any status at all
144 2014-11-18 15:51:54 <wumpus> I wouldn't worry about mangling the API, it's versioned for a reason
145 2014-11-18 15:52:05 <sipa> and later have a function added that additionally takes a pointer to a string buffer
146 2014-11-18 15:52:08 <wumpus> version 0 is very experimental
147 2014-11-18 15:53:16 <wumpus> indeed
148 2014-11-18 15:54:36 <jgarzik_> if errors are fixed, you have a string table + error code a la errno
149 2014-11-18 15:55:02 <jgarzik_> if errors are variable, you need a buffer with dynamic info.  typically a struct where caller supplies buffer (or NULL/dont care)
150 2014-11-18 15:55:16 <wumpus> yes, that is one idea, return an opaque but fixed error code and provide a function to look up a stirng
151 2014-11-18 15:55:20 <jgarzik_> forcing the app to free an error message it doesn't care about is cumbersome
152 2014-11-18 15:55:33 <sipa> jgarzik_: agree
153 2014-11-18 15:55:56 <sipa> for now, errors are fixed, but maybe they won't be in the future
154 2014-11-18 15:55:58 <cfields> wumpus: that's essentially what we have now, we just enum -> int
155 2014-11-18 15:56:16 <HM> "Writing an assembly language module to handle field
156 2014-11-18 15:56:17 <HM> arithmetic is very easy (1 day to write, 1 day to
157 2014-11-18 15:56:17 <sipa> if they are intended to permanently remain fixed, you can just returns a const char* too
158 2014-11-18 15:56:19 <HM> optimize/debug)."
159 2014-11-18 15:56:27 <HM> do you agree with that sipa?
160 2014-11-18 15:56:37 <sipa> HM: i didn't write the assembly in libsecp256k1 :p
161 2014-11-18 15:56:42 <wumpus> let's not worry about 'maybe they won't inte future'
162 2014-11-18 15:56:43 <sipa> no idea how much time it took the author
163 2014-11-18 15:56:50 <wumpus> we now design for what we need now
164 2014-11-18 15:57:01 <wumpus> if that changes it's time for a new API version
165 2014-11-18 15:57:40 <sipa> HM: but i do know that more mental time was spent on coming up with the optimized data flow than on the implementation of it in asm
166 2014-11-18 15:58:18 <sipa> (not just by me...)
167 2014-11-18 15:58:24 <HM> optimized data flow?
168 2014-11-18 15:58:26 <wumpus> cfields: yes
169 2014-11-18 15:58:45 <sipa> HM: like the algorithm for multiplication/squaring/normalization and the data types and representation used
170 2014-11-18 15:59:00 <sipa> HM: everything excluding the actual implementation
171 2014-11-18 15:59:35 <wumpus> cfields: for ex 1) make scripterror opaque 2) break bitcoinconsensus.h depend on script_error.h 3) add const char *bitcoinconsensus_error_string(...) to bitcoinconsensus.h
172 2014-11-18 16:00:45 <cfields> wumpus: 1 how do you mean?
173 2014-11-18 16:00:56 <wumpus> cfields: it'd be a typedef int
174 2014-11-18 16:01:05 <wumpus> cfields: so that external users don't have to see the typedef
175 2014-11-18 16:01:11 <cfields> wumpus: ok, i'm onboard with that
176 2014-11-18 16:01:20 <wumpus> cfields: internally you can use the enum of course
177 2014-11-18 16:01:26 <sipa> i'd rather just have a pointer to const char * passed to the verify
178 2014-11-18 16:01:39 <sipa> if all you can do is lookup anyway, that's both more efficient and less cumbersome
179 2014-11-18 16:01:52 <wumpus> I wouldn't worry about efficiency here
180 2014-11-18 16:02:00 <sipa> ok
181 2014-11-18 16:02:09 <sipa> if all you can do is lookup anyway, that's less cumbersome
182 2014-11-18 16:02:11 <wumpus> apart from that I agree sipa
183 2014-11-18 16:02:37 <sipa> you can pass NULL if you don't care
184 2014-11-18 16:02:39 <wumpus> but somehow it feels a bit cleaner to have the string on a separate interface
185 2014-11-18 16:03:01 <wumpus> s/interface/method
186 2014-11-18 16:03:14 <sipa> i think that would only be true if the returned code had meaning beyond its string representation
187 2014-11-18 16:03:25 <sipa> but that implies that you can do more with it than show it
188 2014-11-18 16:03:36 <wumpus> true...
189 2014-11-18 16:04:03 <sipa> if we plan to expose the error code, i agree
190 2014-11-18 16:04:17 <HM> the traditional C approach is to return an error code and then call strerror()
191 2014-11-18 16:04:18 <cfields> well ideally it'd allow you to differentiate very high-level errors, but i suppose that's beyond the current scope
192 2014-11-18 16:04:31 <cfields> for ex between a tx deserialization error and script eval false
193 2014-11-18 16:04:39 <sipa> ok agree
194 2014-11-18 16:04:42 <cfields> it's a shame to have those both lumped into a single return 1/0
195 2014-11-18 16:04:52 <wumpus> cfields: ok
196 2014-11-18 16:04:58 <sipa> but a tx serialization shouldn't be part of the script code at all!
197 2014-11-18 16:05:03 <wumpus> cfields: so libbitcoinconsensus_error_category() that returns an enum ?
198 2014-11-18 16:05:13 <wumpus> cfields: so you can do something else than convert it to a string?
199 2014-11-18 16:05:22 <sipa> you can have an error code that is specific to libbitcoinconsensus_script_verify or whatever
200 2014-11-18 16:05:39 <sipa> please *please* keep those separate
201 2014-11-18 16:05:55 <wumpus> cfields: if you want the application to differntiate high-level errors, you need a way to extract that
202 2014-11-18 16:05:58 <cfields> sipa: yes, i was looking for ideas to separate them.
203 2014-11-18 16:06:16 <sipa> now that i think about it, i don't think i like the fact of calling it script *errors* actually
204 2014-11-18 16:06:26 <sipa> they're not exceptional conditions
205 2014-11-18 16:06:33 <wumpus> anyhow, if we can't decide on this, I'm for not returning any specific info at all in API v0
206 2014-11-18 16:06:37 <sipa> they're normal cases of failed validation
207 2014-11-18 16:06:57 <cfields> wumpus: it may be better to wait and see what client code actually needs
208 2014-11-18 16:07:12 <wumpus> the client code needs just 1/0
209 2014-11-18 16:07:21 <wumpus> the detailed message would be for troubleshooting and logging only
210 2014-11-18 16:07:35 <sipa> i'm perfectly fine at this stage with an error enum that just has OK, FAILED_DESERIALIZATION (and perhaps an strerror for that)
211 2014-11-18 16:07:38 <wumpus> there is no need for the applciation to act on specific 'errors'
212 2014-11-18 16:07:48 <sipa> the reason why a script evaluaton failed should be 100% independent imho
213 2014-11-18 16:07:57 <wumpus> why would you need to distinguish failed deserialization?
214 2014-11-18 16:08:06 <wumpus> failed is failed right?
215 2014-11-18 16:08:10 <sipa> because it signifies incorrect usage of the API
216 2014-11-18 16:08:21 <wumpus> ok, agreed
217 2014-11-18 16:08:25 <sipa> rather than a genuinely failed verification
218 2014-11-18 16:09:31 <wumpus> but indeed, that's completely separate from the reasons script evaluation can 'fail'
219 2014-11-18 16:09:47 <wumpus> makes no sense to combine it even in one enum
220 2014-11-18 16:10:17 <jgarzik_> 
ACTION updates the ZMQ patch to build

221 2014-11-18 16:10:24 <jgarzik_> and be more generic with signals
222 2014-11-18 16:10:32 <sipa> jgarzik_: i hope for 0.11 :)
223 2014-11-18 16:10:52 <jgarzik_> no timeline
224 2014-11-18 16:11:00 <jgarzik_> I have time right now, and it needs doing
225 2014-11-18 16:11:04 <jgarzik_> ;p
226 2014-11-18 16:11:20 <cfields> wumpus: very much agreed. not sure how to separate it without making the interface even clunkier, though
227 2014-11-18 16:11:50 <wumpus> cfields: well it's actually easier, instead of returning an opaque code you return an enum with only two options (for now :-)
228 2014-11-18 16:11:52 <sipa> let's just forget about script evaluation 'reasons' for now
229 2014-11-18 16:12:12 <sipa> there can also be INCOMPLETE_DESERIALIZATION (signifying garbage)
230 2014-11-18 16:12:22 <wumpus> yea, three options
231 2014-11-18 16:12:52 <sipa> i'm glad to have the script validation reasons abstracted out (as opposed to just a bunch of strprintf's), independent of whether we use it in the library or not
232 2014-11-18 16:13:01 <cfields> and bad index
233 2014-11-18 16:13:12 <wumpus> cfields: yep
234 2014-11-18 16:13:17 <cfields> https://github.com/theuni/bitcoin/commit/1b306c96d6b7359c9332bbf93aa24640e45cfed2#diff-5d284177f966cbad5a370e548271cb1dR74
235 2014-11-18 16:13:37 <cfields> failures are there
236 2014-11-18 16:14:10 <cfields> so, enum those and return that instead, and leave the scripterror out of it?
237 2014-11-18 16:14:15 <wumpus> yes
238 2014-11-18 16:14:42 <cfields> those should be rock-stable too, can't imagine how they'd ever change
239 2014-11-18 16:14:50 <wumpus> indeed
240 2014-11-18 16:14:56 <sipa> indeed, they're specific to thre API
241 2014-11-18 16:15:39 <cfields> ok, and scripterror remains internal. makes sense.
242 2014-11-18 16:15:43 <sipa> ack
243 2014-11-18 16:15:52 <cfields> and sipa can paint the name a new color :)
244 2014-11-18 16:16:03 <sipa> this?
245 2014-11-18 16:16:10 <sipa> 
ACTION hides

246 2014-11-18 16:16:12 <wumpus> yes, at least for now, at some point we may support debugging of scripts, but for now it's internal
247 2014-11-18 16:16:34 <cfields> works for me. thanks for talking it through.
248 2014-11-18 16:16:39 <wumpus> a name for what?
249 2014-11-18 16:16:51 <wumpus> this would just be an error enumeration for the bitcoinconsensus library
250 2014-11-18 16:17:00 <cfields> sipa doesn't seem to like the name ScriptError
251 2014-11-18 16:17:17 <cfields> nah, that was an off-topic joke :)
252 2014-11-18 16:17:17 <wumpus> bitconconsensus_error :p
253 2014-11-18 16:17:20 <wumpus> ohh
254 2014-11-18 16:17:49 <wumpus> ScriptResultOfLastOperation ? :p
255 2014-11-18 16:18:15 <sipa> ScriptWhyUNoSucceed
256 2014-11-18 16:18:17 <wumpus> ReasonOfNegativeEvalOfLastOperation
257 2014-11-18 16:18:22 <wumpus> lol sipa
258 2014-11-18 16:18:44 <cfields> heh
259 2014-11-18 16:20:11 <cfields> btw, it's agreed that extra garbage in txTo is an error, even if the script would verify without the garbage?
260 2014-11-18 16:20:21 <wumpus> IMO that's an error
261 2014-11-18 16:20:29 <sipa> yes, that's incorrect usage of the API
262 2014-11-18 16:20:55 <wumpus> caller must pass the right size
263 2014-11-18 16:21:05 <cfields> ok, great. same.
264 2014-11-18 16:21:16 <sipa> if you're unable to do transaction deserialization in whatever layer you're using, your code is probably broken no matter what
265 2014-11-18 16:21:42 <wumpus> indeed, better to fail early then
266 2014-11-18 16:40:32 <cfields> wumpus: btw, if you're testing the consensus lib on win, the dll builds fine, but libstdc++/libgcc aren't built-in static (yet)
267 2014-11-18 16:41:59 <cfields> libtool needs a little coercion there, just haven't gotten around to finding the least hackish way yet
268 2014-11-18 16:42:17 <wumpus> cfields: ok, no problem, I'll wait with that until the pull is 'final'
269 2014-11-18 16:43:29 <cfields> wumpus: well i'd be ok with merging it without that fixed yet, since it should still work fine. either way works for me
270 2014-11-18 16:44:04 <wumpus> but i suppose it can't end up in a release that way
271 2014-11-18 16:44:44 <wumpus> unless we package libstdc++ and libgcc as dlls, of course
272 2014-11-18 16:45:11 <sipa> we could just not distribute libconsensus for windows
273 2014-11-18 16:45:39 <wumpus> right
274 2014-11-18 16:46:13 <wumpus> I suppose we don't distribute it for macosx either, so it's linux-only for now
275 2014-11-18 16:46:31 <wumpus> fine with me, then I also don't have to test it on windows
276 2014-11-18 16:47:06 <cfields> hmm, really? i figured the dll would have the biggest advantage, since it's otherwise such a pain to get the consensus code built/running on win
277 2014-11-18 16:47:22 <wumpus> cfields: it only makes sense if it can be self-contained
278 2014-11-18 16:47:45 <sipa> cfields: oh i agree, but it's a proof of concept - we can always add a windows release if people ask for it
279 2014-11-18 16:48:01 <cfields> wumpus: sure, it can be, it'll just need a trick or two. nothing too difficult
280 2014-11-18 16:48:17 <wumpus> I was thinking let's say you want to load the DLL from a MSVC-built program, it would kind of suck to need the libstdc++ libgcc dlls from mingw
281 2014-11-18 16:48:19 <cfields> i have a few one-liners that work, just hoping to stumble upon something cleaner
282 2014-11-18 16:49:10 <wumpus> well it depends on what we focus on now, it could be done later, for 0.10 only Linux would be fine
283 2014-11-18 16:49:44 <cfields> ok
284 2014-11-18 16:49:53 <sipa> a few one-liners sounds good to me as well :)
285 2014-11-18 16:50:06 <wumpus> let's focus on getting libbitcoin_consensus to a mergable state first
286 2014-11-18 16:50:26 <cfields> ok, fixing that up right now
287 2014-11-18 17:16:23 <sipa> cfields: many 'usage: git rev-list [OPTION] <commit-id>....' lines in the travis output
288 2014-11-18 17:16:34 <Luke-Jr> sipa: I'm awake
289 2014-11-18 17:16:53 <Luke-Jr> noticed you forked my PR, so I'm trying to catch up before commenting
290 2014-11-18 17:16:55 <cfields> sipa: yea, there are a few tickets around for that. not sure why the fixes were never merged
291 2014-11-18 17:16:58 <cfields> will have a look
292 2014-11-18 17:17:52 <sipa> Luke-Jr: i'm done with #5302
293 2014-11-18 17:18:35 <jgarzik_> hum
294 2014-11-18 17:18:50 <sipa> 
ACTION humms along

295 2014-11-18 17:18:58 <jgarzik_> Ideally, I wonder if boost has a feature to auto-register plugins
296 2014-11-18 17:19:06 <jgarzik_> eliminating an explicit ZMQInit call
297 2014-11-18 17:19:31 <jgarzik_> easy enough to create a PluginShutdown signal, but PluginInit is rather harder ;p
298 2014-11-18 17:19:32 <cfields> jgarzik_: like once?
299 2014-11-18 17:19:49 <sipa> once doesn't deinitialize
300 2014-11-18 17:20:03 <sipa> class ZMQInitializer { ZMQInitializer() { ZMQInit(); } ~ZMQInitializer() { ZMQFree(); } } zmqinitializer_instance;
301 2014-11-18 17:20:06 <sipa> one line!
302 2014-11-18 17:20:20 <wumpus> I prefer explicit initializations
303 2014-11-18 17:20:25 <jgarzik_> that's not what I'm talking about
304 2014-11-18 17:20:30 <jgarzik_> think boost test cases
305 2014-11-18 17:20:48 <jgarzik_> there is no master list of tests, boost just Figures It Out
306 2014-11-18 17:21:03 <jgarzik_> once you have init, the plugin init function registers a shutdown signal
307 2014-11-18 17:21:12 <wumpus> initialization/deinistialization is not a good place for ravioli code, it's good to have control over the order
308 2014-11-18 17:21:25 <jgarzik_> thus all you need is the init hook
309 2014-11-18 17:21:46 <jgarzik_> the PR as implemented uses explicit init/shutdown
310 2014-11-18 17:21:46 <wumpus> jgarzik_: that works in a similar way, just linking in the .o is enough as the initialization code registers the plugin
311 2014-11-18 17:22:12 <wumpus> note that that can give problems if you use .a's and the linker decides that it doesn't need to link in an object file
312 2014-11-18 17:22:16 <jgarzik_> Yes, though I think we want an explicit point at which plugins are activated
313 2014-11-18 17:22:21 <jgarzik_> pure linker is too chaotic
314 2014-11-18 17:22:29 <wumpus> yes, it's crazy
315 2014-11-18 17:26:35 <Luke-Jr> sipa: this changes the function signature of ContextualCheckBlockHeader, but doesn't change its use in TestBlockValidity
316 2014-11-18 17:27:28 <sipa> Luke-Jr: oh, indeed
317 2014-11-18 17:27:57 <Luke-Jr> sipa: keep in mind TestBlockValidity should reject duplicate blocks
318 2014-11-18 17:28:38 <Luke-Jr> (it can perhaps be argued to be ambiguous whether it should - but I think the fact of common use expecting the rejection for shares pushes it far in favour of rejecting dupes
319 2014-11-18 17:29:09 <sipa> Luke-Jr: fair enough, but a header is not invalid because we already have it
320 2014-11-18 17:29:51 <sipa> and a check function optionally inserting its argument in a n index is pretty ugly
321 2014-11-18 17:29:58 <Luke-Jr> indeed
322 2014-11-18 17:30:16 <Luke-Jr> maybe it deserves a new function?
323 2014-11-18 17:31:00 <Luke-Jr> it'd be nice to atomically do the two checks (dupe & prevblk lookup) within one lock
324 2014-11-18 17:31:02 <sipa> ok
325 2014-11-18 17:31:52 <Luke-Jr> sipa: are you making these changes, or should I?
326 2014-11-18 17:33:34 <sipa> Luke-Jr: probably easier if uou do
327 2014-11-18 17:34:00 <sipa> as reacting to other comments is probably easier for you
328 2014-11-18 17:35:01 <Luke-Jr> k
329 2014-11-18 17:38:43 <Luke-Jr> sipa: it also appears you are calling AddToBlockIndex when it previously was not?
330 2014-11-18 17:42:09 <sipa> Luke-Jr: shouldn't be
331 2014-11-18 17:42:18 <sipa> i can reorganize the code a bit to make the diff smaller
332 2014-11-18 17:44:00 <Luke-Jr> sipa: previously, it was only called when !*ppindex
333 2014-11-18 17:44:17 <sipa> Luke-Jr: second
334 2014-11-18 17:45:16 <sipa> Luke-Jr: at that point in the code, it would always be !*ppindex
335 2014-11-18 17:45:25 <sipa> as there is a return in the only branch that updates it
336 2014-11-18 17:45:44 <Luke-Jr> ah
337 2014-11-18 17:45:52 <sipa> i'll push a new version that makes it more obvious in a second
338 2014-11-18 17:47:08 <sipa> done
339 2014-11-18 17:47:50 <sipa> ah, i had hoped that the diff would be smaller
340 2014-11-18 17:47:57 <sipa> maybe i need to reorder the function or something
341 2014-11-18 18:01:52 <Luke-Jr> -    const int nHeight = pindexPrev->nHeight + 1;
342 2014-11-18 18:01:54 <Luke-Jr> +    const int nHeight = pindexPrev == NULL ? 0 : pindexPrev->nHeight + 1;
343 2014-11-18 18:01:55 <Luke-Jr> sipa: ^ purpose?
344 2014-11-18 18:02:17 <Luke-Jr> going to just make the contextual checks assert(pindexPrev), ok?
345 2014-11-18 18:02:26 <sipa> ContextualCheckBlockHeader can reasonably be called on the genesis block, imho
346 2014-11-18 18:02:33 <sipa> -Header
347 2014-11-18 18:06:41 <Luke-Jr> sipa: hm
348 2014-11-18 18:07:17 <sipa> in AcceptBlock that doesn't happen because everything is guarded by a != genesis check, and maybe there is higher level logic that prevents it
349 2014-11-18 18:07:34 <sipa> but i prefer that those functions give valid results when called on genesis too
350 2014-11-18 18:07:42 <Luke-Jr> assert(pindexPrev || hash == Params().HashGenesisBlock()); ?
351 2014-11-18 18:07:52 <sipa> Meh.
352 2014-11-18 18:08:41 <sipa> another call to GetHash...
353 2014-11-18 18:08:48 <Luke-Jr> it's already called in the header check
354 2014-11-18 18:09:05 <sipa> it's already called to many times :)
355 2014-11-18 18:09:07 <Luke-Jr> :P
356 2014-11-18 18:51:47 <Luke-Jr> sipa: #1816 updated with your changes squashed
357 2014-11-18 18:56:34 <Luke-Jr> sipa: is .count cheaper than .find? O.o
358 2014-11-18 18:56:45 <sipa> i doubt it; but it's shorter
359 2014-11-18 18:56:48 <Luke-Jr> XD
360 2014-11-18 18:59:53 <Luke-Jr> sipa: hm, does it make sense to not fail as duplicate if we have only the header?
361 2014-11-18 19:00:36 <sipa> Luke-Jr: up to you
362 2014-11-18 19:01:03 <Luke-Jr> 
ACTION ponders

363 2014-11-18 19:01:11 <sipa> the only way that i can expect that to happen is if the block has announced already, and we have processed the header, and requested the block, but it hasn't been processed in full yet
364 2014-11-18 19:01:16 <sipa> i doubt it can happen at all right now
365 2014-11-18 19:01:19 <sipa> but maybe that changes
366 2014-11-18 19:10:13 <Luke-Jr> sipa: I made it return duplicate, but still process the block in the case of submitblock
367 2014-11-18 19:17:52 <Luke-Jr> ok, it actually compiles now ;)
368 2014-11-18 19:17:59 <Luke-Jr> 
ACTION prods QA RPC tests for being broken :/

369 2014-11-18 19:18:03 <Luke-Jr> (in general)
370 2014-11-18 19:21:01 <kanzure> oops is that my fault
371 2014-11-18 19:21:07 <kanzure> ah, no
372 2014-11-18 19:21:25 <Luke-Jr> it thinks it's in IBD
373 2014-11-18 19:21:38 <Luke-Jr> for now, I'm just going to rebase on an older master
374 2014-11-18 19:22:48 <sipa> Luke-Jr: merge in 5158
375 2014-11-18 19:23:24 <Luke-Jr> sipa: well, it was working a few days ago
376 2014-11-18 19:23:40 <Luke-Jr> weird
377 2014-11-18 19:24:35 <Luke-Jr> sipa: I'm going to leave 5158 non-merged for my PR, if that's okay - I'll just merge it locally for testing?
378 2014-11-18 19:24:51 <Luke-Jr> meh
379 2014-11-18 19:24:55 <Luke-Jr> it didn't fix it anyway
380 2014-11-18 19:25:06 <sipa> yeah
381 2014-11-18 19:25:10 <sipa> ok
382 2014-11-18 19:26:15 <Luke-Jr> 
ACTION removes IBD check locally

383 2014-11-18 19:26:31 <sipa> see #5304?
384 2014-11-18 19:27:22 <Luke-Jr> sipa: doesn't look related
385 2014-11-18 19:27:26 <sipa> ok
386 2014-11-18 19:28:42 <Luke-Jr> anyhow, proposal tests now pass (with IBD check removed)
387 2014-11-18 19:29:13 <sipa> which IBD check specifically?
388 2014-11-18 19:29:39 <Luke-Jr> rpcmining.cpp:getblocktemplate
389 2014-11-18 19:29:54 <Luke-Jr> hm, I wonder if I should bypass that for proposals
390 2014-11-18 19:30:21 <Luke-Jr> nm, it already is
391 2014-11-18 19:30:32 <Luke-Jr> just that the tests require using it for a template :>
392 2014-11-18 19:37:52 <Luke-Jr> side note: git commit --fixup=COMMIT is handy
393 2014-11-18 19:38:59 <sipa> interesting
394 2014-11-18 20:24:04 <wiz> would someone mind sending me like 0.1 testnet coins?
395 2014-11-18 20:24:53 <wiz> i tried one of the faucets but the coins never came
396 2014-11-18 20:42:19 <Luke-Jr> wiz: address?
397 2014-11-18 20:42:55 <wiz> msJKXLPbu2q2uer4wcAxcAuj4vs4EV4U4P
398 2014-11-18 20:43:13 <wiz> thank you sir
399 2014-11-18 20:47:03 <Luke-Jr> wiz: sent
400 2014-11-18 20:47:47 <wiz> thanks, if you give me your real btc address I'll buy you a beer in return :)
401 2014-11-18 20:55:11 <Luke-Jr> wiz: lol, no need, but thanks 19eA9GoyfGSD9NvsYxxac23KV424XMpFB3 (disclaimer: I'm not getting beer with anything you send :P)
402 2014-11-18 20:56:09 <wiz> coffee? tea? what is your beverage of choice
403 2014-11-18 20:56:46 <Luke-Jr> lately all I drink is pepsi and dr. pepper :/
404 2014-11-18 20:58:32 <sipa> combine them into dr. pepsipper
405 2014-11-18 20:59:41 <Diablo-D3> DO NOT DO IT
406 2014-11-18 20:59:50 <Diablo-D3> never mix dr pepper with anything but alchohol
407 2014-11-18 20:59:55 <Diablo-D3> and even them, thats not recommended
408 2014-11-18 21:00:06 <Diablo-D3> there is just something entirely foreign with how they do their flavor mix
409 2014-11-18 21:00:19 <Diablo-D3> anything else? you can probably mix and get away with it
410 2014-11-18 21:01:31 <Luke-Jr> O.o
411 2014-11-18 21:02:11 <maaku> somebody feels strongly about Dr. P
412 2014-11-18 21:02:25 <Luke-Jr> sipa: reckon #1816 is ACKworthy yet? or anything else for me to do?
413 2014-11-18 21:05:35 <phantomcircuit> Diablo-D3, ha
414 2014-11-18 21:07:00 <Diablo-D3> phantomcircuit: tell me Im wrong here
415 2014-11-18 21:07:18 <phantomcircuit> i will not
416 2014-11-18 21:07:27 <phantomcircuit> there's already a ton of random flavors in dr pepper
417 2014-11-18 21:07:41 <phantomcircuit> adding more will not end well
418 2014-11-18 21:21:21 <BlueMatt> wumpus: did you intend to ack https://github.com/bitcoin/bitcoin/pull/2844 (and could you, if you did)
419 2014-11-18 21:35:00 <wiz> I forked the bitcoin.org website on github, removed all languages except japanese, and put it on bitcoin.jp
420 2014-11-18 21:35:39 <wiz> kinda thinking what else to put on there next
421 2014-11-18 21:37:40 <Luke-Jr> wizkid057: http://bitcoin.jp/en/ seems to work just fine :p
422 2014-11-18 21:37:43 <Luke-Jr> err, wiz*
423 2014-11-18 21:37:55 <Luke-Jr> wiz: I suggest making it link to bitcoin.org for non-jp links
424 2014-11-18 21:38:02 <Luke-Jr> but that might take effort
425 2014-11-18 21:38:06 <wiz> heh okay more accurately, i changed the default language to ja
426 2014-11-18 21:38:11 <wiz> but okay sure good idea
427 2014-11-18 21:38:25 <Luke-Jr> 
ACTION wonders why the video is in English with Spanish subtitles XD

428 2014-11-18 21:38:46 <wiz> actually i was just replacing that with one that roger ver uploaded to youtube with japanese subtitles
429 2014-11-18 21:39:19 <wiz> this is a few years old https://www.youtube.com/watch?v=sXOxImTtCEQ
430 2014-11-18 21:39:51 <wiz> but better than nothing, i mean most japanese people think bitcoin got hacked and went bankrupt in the beginning of the year and that ripple won the cryptocoin war :P
431 2014-11-18 21:42:17 <Luke-Jr> hopefully it's an accurate translation, and doesn't add anarchist stuff? :p
432 2014-11-18 21:42:24 <wiz> nah it's legit
433 2014-11-18 21:42:49 <Luke-Jr> cool
434 2014-11-18 21:43:01 <Luke-Jr> be neat if someone redubbed it
435 2014-11-18 21:43:07 <ahmed_> hey all. im experimenting with the bitcoin source. and im wondering how to add the genesis block to the txdb ?
436 2014-11-18 21:43:33 <Luke-Jr> ahmed_: don't do that, it'd hardfork
437 2014-11-18 21:43:36 <sipa> ahmed_: what do you mean by 'txdb' ?
438 2014-11-18 21:43:53 <ahmed_> Luke-Jr:  ive obvs forked it so it isnt running using the bitcoin network
439 2014-11-18 21:43:53 <wiz> yeah we have lots of people in tokyo who want to help out, thats why i went the github method... but i dont think anyone realizes they can submit PRs
440 2014-11-18 21:44:02 <ahmed_> its just a testcoin
441 2014-11-18 21:44:35 <ahmed_> sipa: well the genesis block is already added to the blkxxx.dat right? so its just the tx's that arent there which makes it unspendable right?
442 2014-11-18 21:44:41 <ahmed_> or have i confused myself?
443 2014-11-18 21:44:42 <Luke-Jr> wiz: please try to avoid forking the repo in a permanent fashon if possible - best to have bitcoin.org get any changes made too
444 2014-11-18 21:44:58 <sipa> ahmed_: there is no such thing as a transaction database really
445 2014-11-18 21:45:06 <sipa> ahmed_: only a set of unspent transaction outputs
446 2014-11-18 21:45:18 <sipa> and indeed, the genesis block isn't processed when adding
447 2014-11-18 21:45:25 <ahmed_> ah yep
448 2014-11-18 21:45:26 <BlueMatt> jgarzik: wtf is with https://github.com/bitcoin/bitcoin/pull/2844 ???
449 2014-11-18 21:45:39 <sipa> ahmed_: finding the place in the code where that decision is made should be a nice exercise then :)
450 2014-11-18 21:45:44 <wiz> Luke-Jr: in that case, do you mind if i submit PRs for japanese language specific stuff to the main bitcoin.org repo?
451 2014-11-18 21:45:51 <ahmed_> sipa: in main.cpp im guessing
452 2014-11-18 21:45:56 <sipa> ahmed_: good guess
453 2014-11-18 21:45:58 <Luke-Jr> ahmed_: IF you are in fact making an altcoin, please be straightforward and use ##altcoin-dev, and don't lie here. (not saying you are, just making a request in case since it's commonish)
454 2014-11-18 21:46:00 <ahmed_> but ive spent a couple of hours trying to find it
455 2014-11-18 21:46:03 <wiz> also, do you host the website on github directly?
456 2014-11-18 21:46:08 <ahmed_> Luke-Jr: not making an altcoin
457 2014-11-18 21:46:21 <ahmed_> altcoin's are 99% ipo/ico/ixx scams nowadays
458 2014-11-18 21:47:14 <ahmed_> although i will join that chan and see what i can find there too. thanks Luke-Jr :)
459 2014-11-18 21:47:48 <ahmed_> sipa any hint as to what function its in?
460 2014-11-18 21:48:11 <Luke-Jr> wiz: please feel free
461 2014-11-18 21:48:42 <sipa> ahmed_: follow the calls from ProcessNewBlock
462 2014-11-18 21:48:55 <ahmed_> sipa: great will do thanks man
463 2014-11-18 21:49:08 <sipa> ahmed_: which is where all block data (from disk, from network, from initialization, ...) go through
464 2014-11-18 21:50:06 <Luke-Jr> wiz: I believe it is hosted off GitHub these days, yes - but not 100% sure
465 2014-11-18 21:51:58 <BlueMatt> Luke-Jr: wiz nope, blacklotus over something else
466 2014-11-18 21:52:03 <Luke-Jr> ah
467 2014-11-18 21:56:45 <aschildbach> Question: how do I know in bitcoin-qt if the address that was just assigned is contained in my last backup? I know it pre-creates a pool of keys for that purpose.
468 2014-11-18 21:57:01 <Luke-Jr> aschildbach: you don't. :/
469 2014-11-18 21:57:06 <aschildbach> omg
470 2014-11-18 21:57:11 <Luke-Jr> backup is one of Bitcoin Core's weak areas
471 2014-11-18 21:57:49 <sipa> you do; there's an RPC to query the timestamp of the oldest pool address
472 2014-11-18 21:57:59 <sipa> if that's older than your backup, you need a new one
473 2014-11-18 21:58:13 <Luke-Jr> hm
474 2014-11-18 21:58:23 <Luke-Jr> not very user-friendly, but ok
475 2014-11-18 21:58:29 <sipa> not at all
476 2014-11-18 21:59:05 <aschildbach> Ah screw it, I just don't backup...
477 2014-11-18 21:59:26 <Luke-Jr> :|
478 2014-11-18 22:01:12 <aschildbach> I think the logic would be easy to fix. Only a backup creates 100 fresh addresses which you may use up. After that, it refuses to create new addresses unless you backup again.
479 2014-11-18 22:01:20 <aschildbach> Or, of course, implement HD.
480 2014-11-18 22:02:04 <Luke-Jr> aschildbach: HD doesn't negate the need of backups; I do think erroring (or at least warning) when you create an address beyond the recent backup is a good idea
481 2014-11-18 22:02:56 <aschildbach> Sure you likely want to backup metadata.
482 2014-11-18 22:03:01 <helo> aschildbach: old rpc stuff probably expects it to always succeed and won't handle an error gracefully
483 2014-11-18 22:03:17 <aschildbach> But at least your monetary value would be backed up with one backup "forever".
484 2014-11-18 22:03:37 <sipa> well, HD wallet support welcome
485 2014-11-18 22:03:45 <Luke-Jr> helo: it will fail already if the wallet is locked
486 2014-11-18 22:03:55 <Luke-Jr> sipa: I thought you were doing that? :P
487 2014-11-18 22:03:56 <aschildbach> sipa: Yes I know (-:
488 2014-11-18 22:04:09 <sipa> Luke-Jr: i'm very willing to share my partially finished branch
489 2014-11-18 22:04:17 <Luke-Jr> sipa: are you abandoning it?
490 2014-11-18 22:04:30 <sipa> i think 'mummifying' is the correct term
491 2014-11-18 22:04:43 <ahmed_> sipa: is it connectblock?
492 2014-11-18 22:04:48 <sipa> ahmed_: bingo
493 2014-11-18 22:05:12 <sipa> Luke-Jr: at this point i'm not sure whether i'd rather work on bitcoin core's wallet, or rewrite a new efficient, SPV-compatible one from scratch
494 2014-11-18 22:05:16 <Luke-Jr> sipa: well, push it somewhere and maybe some day someone will finish it? :P
495 2014-11-18 22:05:17 <ahmed_> sweet thanks sipa  much appreciated :)
496 2014-11-18 22:05:28 <Luke-Jr> sipa: hm, that's a point
497 2014-11-18 22:05:44 <ahmed_> sipa: what lang would u write the SPV one in? c++?
498 2014-11-18 22:05:52 <sipa> ahmed_: same codebase; yes
499 2014-11-18 22:06:09 <Luke-Jr> why not C?
500 2014-11-18 22:06:10 <ahmed_> ahh ok a spv wallet would be nice in C++
501 2014-11-18 22:06:26 <sipa> Luke-Jr: because i want to reuse pretty much all of bitcoin core's code, except the actual wallet
502 2014-11-18 22:06:43 <Luke-Jr> sipa: use non-wallet code for a wallet lib? O.o
503 2014-11-18 22:07:10 <sipa> ?
504 2014-11-18 22:07:14 <ahmed_> i agree with sipa there, reusing the bitcoin core's code would likely simplify a lot of the work to be put into creating a functioning SPV wallet
505 2014-11-18 22:07:33 <sipa> i think that's the difference between a one month project and a one year project
506 2014-11-18 22:07:52 <Luke-Jr> I'm assuming the SPV code would all be independent from the wallet code
507 2014-11-18 22:07:59 <lechuga_> sipa: new spv pls
508 2014-11-18 22:08:16 <Luke-Jr> in which case, there's nothing left in Bitcoin Core you'd want to use in the wallet code
509 2014-11-18 22:08:16 <sipa> lechuga_: SPV == node in headers-only mode + wallet that does its own block fetching
510 2014-11-18 22:08:27 <sipa> um
511 2014-11-18 22:09:18 <sipa> script signing, headers tracking, p2p code, serialization, base58 code, keystore, peer management
512 2014-11-18 22:09:55 <Luke-Jr> that should all be other libs <.<
513 2014-11-18 22:10:04 <sipa> sure
514 2014-11-18 22:10:10 <sipa> one day :)
515 2014-11-18 22:10:19 <cfields> getting there :)
516 2014-11-18 22:19:14 <lechuga_> a reference impl of an spv wallet would be nice in core
517 2014-11-18 22:19:16 <lechuga_> imo
518 2014-11-18 22:19:35 <sipa> it would be even nicer if it wasn't inside core, but just reused parts
519 2014-11-18 22:19:44 <lechuga_> right i dont mean in bitcoin/bitcoin
520 2014-11-18 22:19:51 <sipa> fair enough; yes
521 2014-11-18 22:19:52 <lechuga_> but bitcoin/wallet (or stte)
522 2014-11-18 22:20:09 <Luke-Jr> I wonder if we should just contribute to CodeShark's wallet codebase, if we want a new wallet?
523 2014-11-18 22:20:15 <Luke-Jr> (I haven't looked at it)
524 2014-11-18 22:20:53 <sipa> i have looked at it briefly, but indeed, not enough
525 2014-11-18 22:21:24 <Luke-Jr> recently*
526 2014-11-18 22:22:34 <Luke-Jr> btw, just in case you missed it [21:02:26] <Luke-Jr> sipa: reckon #1816 is ACKworthy yet? or anything else for me to do?
527 2014-11-18 22:23:00 <sipa> will look at it again
528 2014-11-18 22:56:39 <espringe> What’s the complexity of `bitcoind getreceivedbyaddress X` when you have hundreds of thousands of addresses/transactions in your wallet?
529 2014-11-18 22:56:56 <espringe> Is that a full scan over all wallet transactions?
530 2014-11-18 23:06:00 <sipa> espringe: yes