1 2014-10-16 00:01:16 <BlueMatt> sipa: for some reason whatever build of bitcoind I had lying around was getting lots of orphans...then I switched to headers-first :)
  2 2014-10-16 00:10:06 <BlueMatt> sipa: is there a reason we had limited script checking threads to 16?
  3 2014-10-16 00:10:44 <CodeShark> most typical machines don't have more than 16 processors? :)
  4 2014-10-16 00:11:01 <BlueMatt> well thats no reason to put a cap on it
  5 2014-10-16 00:11:25 <CodeShark> agreed - would make more sense to detect the concurrency level
  6 2014-10-16 00:11:33 <BlueMatt> which we do
  7 2014-10-16 00:11:36 <BlueMatt> but we also limit to 16
  8 2014-10-16 00:12:00 <gmaxwell> because more wastes memory due to thread stacks and malloc per thread pools, while not further improving performance.
  9 2014-10-16 00:12:13 <gmaxwell> we do detect the number of processors too.
 10 2014-10-16 00:12:17 <gmaxwell> 16 is just the limit.
 11 2014-10-16 00:12:40 <BlueMatt> gmaxwell: does it not scale further?
 12 2014-10-16 00:12:48 <BlueMatt> ^ was really my original question
 13 2014-10-16 00:12:55 <gmaxwell> BlueMatt: I benchmarked on 32 way hosts, it didn't though this was over a year ago now and average blocksizes are larger.
 14 2014-10-16 00:13:13 <BlueMatt> well, let see
 15 2014-10-16 00:13:14 <BlueMatt> s
 16 2014-10-16 00:13:14 <gmaxwell> feel free to increase it and test.
 17 2014-10-16 00:13:25 <coryfields_> gmaxwell: looks like mlock failures should be very easy to test for. was your experience that those tests don't work? or we just don't do em?
 18 2014-10-16 00:14:44 <gmaxwell> we just don't do them. They were easy to test for.
 19 2014-10-16 00:15:16 <phantomcircuit> BlueMatt, if you run on a system with > 16 cores you'll notice that you almost never get to a load average > 12
 20 2014-10-16 00:15:20 <coryfields_> ok. seems it would be reasonable to return an error, and let the caller retry as necessary?
 21 2014-10-16 00:15:27 <gmaxwell> so maybe a first step is putting in some logging on that, and then making it fail? and seeing if it's still failing with current code on 32kb?
 22 2014-10-16 00:15:45 <gmaxwell> coryfields_: if it fails it'll probably never be successful on retry.
 23 2014-10-16 00:15:47 <BlueMatt> phantomcircuit: yes, I was just looking at cpu was ~1250
 24 2014-10-16 00:15:50 <sipa> phantomcircuit: that's try but not relevant
 25 2014-10-16 00:16:02 <sipa> phantomcircuit: because significant parts are still singlethreaded'
 26 2014-10-16 00:16:18 <gmaxwell> (and of course making an allocator fail is usually a recipy in doom (IOW: a great way to introduce vulnerabilities))
 27 2014-10-16 00:16:42 <sipa> so even though more concurrency may help for the parallel parts, you would not see 100% usage
 28 2014-10-16 00:17:04 <BlueMatt> which, btw, I'm seeing 1250 cpu on headers-first (with some ample additional window size) and -loadblock
 29 2014-10-16 00:17:14 <BlueMatt> which is great news
 30 2014-10-16 00:17:20 <BlueMatt> (over the internet)
 31 2014-10-16 00:17:26 <sipa> -loadblock has nothing tg to do with headersfist..
 32 2014-10-16 00:17:29 <sipa> *first
 33 2014-10-16 00:17:40 <sipa> or you mean you're seeing the same number on both?
 34 2014-10-16 00:17:42 <BlueMatt> yes
 35 2014-10-16 00:17:47 <phantomcircuit> sipa, yeah i know, just saying that increasing the thread count there isn't likely to do much above 16 until the other parts are made concurrent
 36 2014-10-16 00:17:47 <sipa> that's good indeed!
 37 2014-10-16 00:17:54 <BlueMatt> as in headers first seems to be getting blocks nearly as fast as reading from disk!
 38 2014-10-16 00:18:08 <coryfields_> heh, sipa's such a pro he doesn't facepalm, he headersfists.
 39 2014-10-16 00:18:15 <sipa> coryfields_: lol
 40 2014-10-16 00:18:19 <BlueMatt> heh
 41 2014-10-16 00:19:47 <sipa> phantomcircuit: right, which is the diminishing returns argument, which is relevant
 42 2014-10-16 00:20:02 <sipa> but it's not a reason why increasing parallellism does not help at all
 43 2014-10-16 00:20:22 <sipa> and that's because there's just overhead from scheduling jobs on threads and waiting for them
 44 2014-10-16 00:20:37 <sipa> which increases with higher parallellism
 45 2014-10-16 00:22:50 <sipa> BlueMatt: anyway, the overhead may have decreased now, because we're using hashmaps in the utxo set instead of treemaps now
 46 2014-10-16 00:23:04 <sipa> so maybe more validation threads helps
 47 2014-10-16 00:23:12 <sipa> (but not more than a bit)
 48 2014-10-16 00:23:15 <BlueMatt> I'll look later
 49 2014-10-16 00:24:16 <coryfields_> sipa: btw, i don't understand your suggestion in #4981. I'm not aware of that convention
 50 2014-10-16 00:24:34 <coryfields_> sipa: did you mean to templatize <<, and use T::begin() and T::end() ?
 51 2014-10-16 00:25:45 <sipa> coryfields_: yes
 52 2014-10-16 00:25:50 <sipa> heh
 53 2014-10-16 00:25:51 <sipa> no
 54 2014-10-16 00:26:15 <coryfields_> so.. maybe?
 55 2014-10-16 00:26:59 <sipa> class CScript { ... template<typename T> operator(const T& var) { std::vector<unsigned char> vch(T.begin(), T.end()); *this << vch} ... };
 56 2014-10-16 00:27:48 <coryfields_> right
 57 2014-10-16 00:29:59 <coryfields_> sipa: i really wanted to make the distinction between data that was already completely serialized, and data that needs a size appended. i should've objected to moving that into the operator, but i lost sight of my reasoning there
 58 2014-10-16 00:30:38 <sipa> there is no "size appending"
 59 2014-10-16 00:30:49 <sipa> there is a script opcode being prepended to push it
 60 2014-10-16 00:30:54 <coryfields_> er, prepended
 61 2014-10-16 00:30:58 <sipa> and that logic should be in CScript
 62 2014-10-16 00:31:20 <sipa> the serialization can happen else, sure
 63 2014-10-16 00:31:25 <sipa> *elsewhere
 64 2014-10-16 00:32:06 <sipa> wait, let me otherwise quickly suggest another change that should simplify this
 65 2014-10-16 00:32:30 <coryfields_> so, i suppose there's no need to make any kind of distinction from the bytebuffer case, then?
 66 2014-10-16 00:35:31 <coryfields_> my presupposition was that a distinction was warranted, hence the added complexity. If that was overkill from the start, we can just equate them and be done with it
 67 2014-10-16 00:38:24 <sipa> well, scripts just have one data type: byte arrays
 68 2014-10-16 00:38:40 <sipa> anything pushed results in one of the different push opcodes to accomplish that
 69 2014-10-16 00:39:08 <sipa> so i'm just turning it now into a single byte vector push operator that deals with every case
 70 2014-10-16 00:39:18 <sipa> without special casing for numbers
 71 2014-10-16 00:41:03 <coryfields_> ok
 72 2014-10-16 00:57:06 <bigmac> is there an autonomous fund allocation mechanism for satoshi?
 73 2014-10-16 00:57:19 <earlz> wat
 74 2014-10-16 00:57:48 <bigmac> well, how many bitcoins does satoshi own?
 75 2014-10-16 00:57:49 <coryfields_> heh, you mean "has satoshi been skimming all along?"
 76 2014-10-16 00:58:06 <bigmac> no
 77 2014-10-16 00:58:10 <bigmac> actually I mean the inverse
 78 2014-10-16 00:58:24 <bigmac> assume that satoshi has a significant chunk of bitcoin
 79 2014-10-16 00:58:34 <sipa> let's assume
 80 2014-10-16 00:58:35 <bigmac> what's the plan?
 81 2014-10-16 00:58:43 <sipa> should there be a plan?
 82 2014-10-16 00:58:47 <bigmac> absolutely
 83 2014-10-16 00:59:12 <sipa> elaborate?
 84 2014-10-16 00:59:52 <bigmac> let's assume that "satoshi" has had the ability to spend his bitcoin stash whenever he wants
 85 2014-10-16 00:59:57 <bigmac> without notifying
 86 2014-10-16 01:00:02 <bigmac> that he has been spending them
 87 2014-10-16 01:00:14 <bigmac> now
 88 2014-10-16 01:00:18 <bigmac> if you are satoshi
 89 2014-10-16 01:00:23 <bigmac> how would you be spending them?
 90 2014-10-16 01:00:24 <sipa> how is this different for any other human?
 91 2014-10-16 01:00:31 <sipa> they spend their coins how they want
 92 2014-10-16 01:00:49 <bigmac> I'm not arguing against that
 93 2014-10-16 01:00:50 <bigmac> I'm asking
 94 2014-10-16 01:00:52 <bigmac> logically
 95 2014-10-16 01:01:03 <bigmac> where would they be spending?
 96 2014-10-16 01:01:04 <bigmac> for one
 97 2014-10-16 01:01:10 <sipa> i don't see why satoshi is special in your reasoning
 98 2014-10-16 01:01:25 <bigmac> why would he not be?
 99 2014-10-16 01:01:30 <sipa> why would he be?
100 2014-10-16 01:01:46 <sipa> he has no privileges
101 2014-10-16 01:01:47 <bigmac> he is the generator function for the bitcoin network :P you don't think he has interests in other networks?
102 2014-10-16 01:01:52 <bigmac> he has
103 2014-10-16 01:01:56 <bigmac> inherent privileges
104 2014-10-16 01:01:58 <bigmac> from ownership
105 2014-10-16 01:02:02 <sipa> he announced bitcoin before starting the system
106 2014-10-16 01:02:03 <bigmac> of that many bitcoins
107 2014-10-16 01:02:12 <bigmac> yes
108 2014-10-16 01:02:12 <sipa> anyone had the ability to join in right from the start
109 2014-10-16 01:02:13 <bigmac> and?
110 2014-10-16 01:05:30 <gmaxwell> please take this out of #bitcoin-dev
111 2014-10-16 01:05:36 <gmaxwell> #bitcoin would be nice.
112 2014-10-16 01:06:55 <bigmac> apologies @gmaxwell
113 2014-10-16 02:15:34 <sipa> coryfields: gah, two out of the transaction tests fail now, for unexplainable reason
114 2014-10-16 02:17:58 <coryfields_> ?
115 2014-10-16 02:18:46 <sipa> yeah i have some change that simplifies a lot of the script pushing code
116 2014-10-16 02:18:54 <sipa> but now two seemingly unrelated tests fail
117 2014-10-16 02:20:35 <coryfields_> which?
118 2014-10-16 02:21:32 <sipa> nvm, fixed it
119 2014-10-16 02:21:42 <sipa> still don't understand why just those failed
120 2014-10-16 02:22:04 <coryfields_> now i'm curious :) which?
121 2014-10-16 02:23:13 <sipa> the bug was in script/interpreter, the FindAndReplace(CScript(vchSig))
122 2014-10-16 02:23:21 <coryfields_> hah!
123 2014-10-16 02:23:24 <sipa> which i thought was creating a script equal to vchSig
124 2014-10-16 02:23:30 <sipa> but it was creating a script that pushes vchSig
125 2014-10-16 02:23:35 <coryfields_> there's a bug in it
126 2014-10-16 02:23:49 <sipa> no, i missed its meaning when changing it
127 2014-10-16 03:42:39 <Luke-Jr> possible to get debug.log-output from test_bitcoin? :/
128 2014-10-16 03:47:06 <Luke-Jr> aha, checkpoints..
129 2014-10-16 04:51:41 <Luke-Jr> FWIW, http://conference.hitb.org/hitbsecconf2014kul/materials/D1T1%20-%20Filippo%20Valsorda%20-%20Exploiting%20ECDSA%20Failures%20in%20the%20Bitcoin%20Blockchain.pdf (nothing new, same old known security issues with address reuse)
130 2014-10-16 05:05:27 <phantomcircuit> Luke-Jr, he's smart enough to construct a bloom filter
131 2014-10-16 05:05:36 <phantomcircuit> but not smart enough to just write an index to disk
132 2014-10-16 05:05:40 <Luke-Jr> XD
133 2014-10-16 05:05:41 <phantomcircuit> wat
134 2014-10-16 05:06:01 <phantomcircuit> actually
135 2014-10-16 05:06:18 <phantomcircuit> it just needs to be a set of all r values
136 2014-10-16 05:06:22 <phantomcircuit> which will easily fit in memory
137 2014-10-16 05:06:25 <phantomcircuit> on my phone
138 2014-10-16 05:06:55 <Luke-Jr> 
ACTION wonders if any of those reused k are actually still spendable

139 2014-10-16 05:07:14 <Luke-Jr> phantomcircuit: ironically, he's trolling that Bitcoin Core and Armory are "unsafe" because we use random k values..
140 2014-10-16 05:07:28 <phantomcircuit> lol
141 2014-10-16 05:08:33 <phantomcircuit> Luke-Jr, of course he side steps that generating k from the private key while almost certainly safe
142 2014-10-16 05:08:35 <phantomcircuit> is a risk
143 2014-10-16 05:09:02 <phantomcircuit> unless we're perfect coders
144 2014-10-16 05:09:07 <phantomcircuit> so i guess it's a compliment?
145 2014-10-16 05:17:35 <BlueMatt> Luke-Jr: IIRC there was a bot auto-stealing reused k txn
146 2014-10-16 05:17:56 <BlueMatt> Luke-Jr: and, yes, bitcoin core is relatively unsafe for using non-random k values (when people reuse addresses)
147 2014-10-16 05:18:23 <Luke-Jr> BlueMatt: but we *don't* use non-random k values
148 2014-10-16 05:18:27 <BlueMatt> this bug is potentially exploitable if you even have partially repeated k's (ie not the same one, but similar), so.....
149 2014-10-16 05:18:37 <BlueMatt> ehh, sorry, random
150 2014-10-16 05:19:00 <Luke-Jr> BlueMatt: it's just as likely to be partially repeated if you use deterministic, than if you use random..
151 2014-10-16 05:19:20 <BlueMatt> if you use a strong rng, yes, but the history of rng failures is....rich
152 2014-10-16 07:36:34 <wumpus> coryfields: wouldn't that waste a lot of memory?
153 2014-10-16 07:36:55 <sipa> wumpus: what would?
154 2014-10-16 07:37:04 <wumpus> coryfields: <coryfields_> if no, then with posix_memalign aligned to page boundary, we can use our allocator to lock the current structure and know that it won't overlap with the next
155 2014-10-16 07:37:14 <sipa> it won't waste _memory_
156 2014-10-16 07:37:17 <wumpus> locked memory is restricted per process
157 2014-10-16 07:37:21 <sipa> it will waste locked memory
158 2014-10-16 07:37:23 <wumpus> yes
159 2014-10-16 07:37:46 <sipa> which is why i said we should first have an idea of how much locked memory we're actually suing
160 2014-10-16 07:37:49 <coryfields_> wumpus: other things could still be allocated there, but it'd limit the amount of locked resources to 1/page
161 2014-10-16 07:37:59 <coryfields_> *purposeful locked resources
162 2014-10-16 07:38:08 <sipa> as iirc it's just encryption keys and occasionally a private key
163 2014-10-16 07:38:12 <wumpus> do you have any specific reason of going after LockedPageManager though? it's mostly used in wallet code
164 2014-10-16 07:38:29 <phantomcircuit> btw that is almost universally 64kB
165 2014-10-16 07:38:40 <phantomcircuit> (which you will hit if you use a wallet with lots and lots of keys btw)
166 2014-10-16 07:38:52 <wumpus> right
167 2014-10-16 07:38:58 <sipa> oh
168 2014-10-16 07:39:08 <sipa> in an unencrypted wallet, all keys are held in memory
169 2014-10-16 07:39:13 <sipa> i forgot about that
170 2014-10-16 07:39:26 <sipa> sooo... ehm
171 2014-10-16 07:39:32 <sipa> what if we just drop the mlocking?
172 2014-10-16 07:39:34 <wumpus> phantomcircuit: I do think the default amount of locked memory per process is more than 64kB though
173 2014-10-16 07:39:42 <sipa> wumpus: nope, 64 KiB
174 2014-10-16 07:39:43 <phantomcircuit> wumpus, nope
175 2014-10-16 07:39:46 <wumpus> ok...
176 2014-10-16 07:40:08 <gmaxwell> pretty sure it's 32kb in fedora... but I'm not on a fedora host right now.
177 2014-10-16 07:40:16 <coryfields_> wumpus: i'm just going after the state and nasty dependencies in the really low-level stuff that we may need as part of a lib
178 2014-10-16 07:40:18 <wumpus> well then it is easy - just mlock 64kB at start and use it as a pool? the difficulty always was that the pool may not fit, but in this case...
179 2014-10-16 07:40:24 <coryfields_> sipa: haha, i was afraid to ask that one :)
180 2014-10-16 07:40:25 <wumpus> it never has to expand
181 2014-10-16 07:40:43 <phantomcircuit> i've actually taken to doing mlockall() and expensing the limit to ~6GB
182 2014-10-16 07:40:45 <sipa> wumpus: you still need an own memory allocator that uses that 64 KiB for backing
183 2014-10-16 07:40:54 <phantomcircuit> but that's on systems with 32+GB of ram
184 2014-10-16 07:41:00 <sipa> gpg uses mlockall, iirc
185 2014-10-16 07:41:15 <phantomcircuit> maybe
186 2014-10-16 07:41:49 <wumpus> sipa: sure
187 2014-10-16 07:41:53 <gmaxwell> we should probably add a flag to allow people to mlockall... it's really the most safe thing but.. not a good solution in general.  Though if the wallet was another process it would be more reasonable!
188 2014-10-16 07:42:02 <gmaxwell> (or even better, key management/signing another process!)
189 2014-10-16 07:42:16 <sipa> coryfields_: well nothing but wallet code should use secure_allocator
190 2014-10-16 07:42:29 <sipa> coryfields_: so it could be split off easily
191 2014-10-16 07:42:40 <wumpus> sipa: agreed
192 2014-10-16 07:42:52 <sipa> i wouldn't waste too much time on it
193 2014-10-16 07:42:53 <gmaxwell> back to earth, I suggested earlier just make a fixed size satic object to keep data that should be locked.  (encryption derrived key, private key currently being used)
194 2014-10-16 07:43:04 <sipa> yeah, wumpus suggested that too just now
195 2014-10-16 07:43:12 <sipa> but i think that is more work than you think it is
196 2014-10-16 07:43:22 <sipa> and it still wouldn't work well...
197 2014-10-16 07:43:24 <gmaxwell> its probably a lot of work.
198 2014-10-16 07:43:36 <wumpus> if it's just for the wallet: don't bother
199 2014-10-16 07:43:52 <gmaxwell> thats the only place we have confidential information.
200 2014-10-16 07:44:09 <sipa> (if you have more than 2048 keys, it can't fit in 64 KiB, even with optimal allocation strategies)
201 2014-10-16 07:44:36 <gmaxwell> sipa: thats derpy though. We should decrypt the private key on the fly, if the kdf is already done the AES is fast ... much faster than signing.
202 2014-10-16 07:44:42 <sipa> gmaxwell: we do
203 2014-10-16 07:44:49 <sipa> for encryptred wallets
204 2014-10-16 07:45:03 <sipa> of course, we could just encrypt private keys in memory too... even for unencrypted ones
205 2014-10-16 07:45:09 <gmaxwell> so no need to have more than one key and one kdf master key mlocked.
206 2014-10-16 07:47:49 <wumpus> anyhow I never knew that the limit was only 64kB... in that case we could just as well drop secure_allocator completely as it's already not doing anything useful
207 2014-10-16 07:48:48 <gmaxwell> well it's configuarable and OS specific. We shouldn't do something clearly bad even if it's not fully effective on all systems now.
208 2014-10-16 07:48:59 <wumpus> 64kB is... 16 pages, no need for all that admin overhead
209 2014-10-16 07:49:35 <gmaxwell> e.g. on gentoo it appears the default is unlimited.
210 2014-10-16 07:50:19 <phantomcircuit> wumpus, if you go over the limit bitcoind will crash
211 2014-10-16 07:50:21 <coryfields_> well it's always $allmem/2, right? :p
212 2014-10-16 07:50:22 <phantomcircuit> so
213 2014-10-16 07:50:24 <phantomcircuit> no leave it
214 2014-10-16 07:50:30 <gmaxwell> oh darn, no 64 there too. well it's easily increased (you often have to for realtime audio apps)
215 2014-10-16 07:50:30 <wumpus> phantomcircuit: no, it won't crash
216 2014-10-16 07:50:35 <gmaxwell> phantomcircuit: no it won't.
217 2014-10-16 07:50:38 <gmaxwell> it'll fail silently.
218 2014-10-16 07:50:41 <phantomcircuit> oh it does
219 2014-10-16 07:50:44 <phantomcircuit> i remember this now
220 2014-10-16 07:50:59 <wumpus> no, it does not crash, it ignores errors from mlock
221 2014-10-16 07:51:02 <phantomcircuit> i seem to recall having a "solution" (hint: not useful)
222 2014-10-16 07:51:08 <wumpus> people are using wallets wiht 100000's of keys
223 2014-10-16 07:51:14 <phantomcircuit> lol right
224 2014-10-16 07:51:18 <gmaxwell> phantomcircuit: it fails silently. I promise.
225 2014-10-16 07:51:24 <phantomcircuit> that's why i patched bitcoind to call mlockall
226 2014-10-16 07:51:28 <phantomcircuit> derp
227 2014-10-16 07:51:43 <gmaxwell> yes, if you are MCL future then sure, you'll crash when you run out.
228 2014-10-16 07:53:42 <wumpus> some strings are mlocked as well (SecureString) - that's mostly symbolic, as neither the RPC nor the GUI has the whole path mlocked
229 2014-10-16 07:54:31 <gmaxwell> (I'm not sure why it not being very effective is news to people; I know I've pointed it out before. :-/ It's an initial attempt, and in particular if you unlock the wallet right at start I think it still has a good chance of keeping the master key out of swap.
230 2014-10-16 07:54:59 <gmaxwell> yea, making the full rpc path locked wouldn't be hard with jgarzik's stuff, but would probably require more locked memory.
231 2014-10-16 07:55:05 <wumpus> I just didn't know about the 64kB limit
232 2014-10-16 07:55:17 <wumpus> so it's *even less effective* then I thought
233 2014-10-16 07:55:42 <wumpus> I assumed it was at least a few MiB
234 2014-10-16 07:55:44 <gmaxwell> "just run bitcoin as root" :P
235 2014-10-16 07:56:26 <gmaxwell> wumpus: no sadly, I think the goal is that a runaway task can't exaust memory so easily; and with any non-trivial limit something that forked a lot could do so easily.
236 2014-10-16 07:56:32 <phantomcircuit> gmaxwell, just run bitcoin on gentoo hardened
237 2014-10-16 07:56:35 <wumpus> if I know about the low limit I'd have written LockedPagemanager in a completely different way, ie with a fixed memory size in mind
238 2014-10-16 07:56:46 <phantomcircuit> proceed to cry when you get weird selinux issues though
239 2014-10-16 07:56:59 <phantomcircuit> actually i bet that some of those could fork you
240 2014-10-16 07:57:04 <phantomcircuit> so maybe dont do that
241 2014-10-16 07:58:05 <gmaxwell> wumpus: could detect the failure and log once "you should increase your locked page ulimit"
242 2014-10-16 07:58:06 <wumpus> gmaxwell: but then, why can mlockall lock more?
243 2014-10-16 07:58:22 <phantomcircuit> wumpus, it cant
244 2014-10-16 07:58:27 <phantomcircuit> that will crash
245 2014-10-16 07:58:58 <wumpus> phantomcircuit: I'm not listening to you anymore :)
246 2014-10-16 07:59:23 <phantomcircuit> lol
247 2014-10-16 08:00:00 <gmaxwell> wumpus: he was saying he replaced it with mlockall(MCL_CURRENT|MCL_FUTURE) and it was crashing until he upped the limit, I think.  which is what I'd expect.
248 2014-10-16 08:00:31 <phantomcircuit> gmaxwell, that
249 2014-10-16 08:00:44 <phantomcircuit> and actually i just added mlockall(MCL_CURRENT|MCL_FUTURE) to init.cpp somewhere
250 2014-10-16 08:00:51 <gmaxwell> (which might even be a reasonable runtime configuration "lockmemory=1" though obviously that has some pretty big implications given our memory usage (well, our memory usage has gotten a lot better. :) ))
251 2014-10-16 08:00:51 <wumpus> gmaxwell: ohh.. right, I thought he was saying that the current bitcoind crashes when it goes over the limit, just a miscommunication then
252 2014-10-16 08:01:17 <gmaxwell> well he was, but then he rememered he replaced it with mlockall.
253 2014-10-16 08:01:20 <wumpus> locking all the block headers and data to memory just makes no sense
254 2014-10-16 08:01:51 <phantomcircuit> wumpus, it has the distinct advantage of being trivially obviously correct for all the secret stuff though
255 2014-10-16 08:02:00 <phantomcircuit> which is why i did it
256 2014-10-16 08:02:02 <gmaxwell> sure but if you have 16 gbytes of ram its harmless... and it does close all the json paths.
257 2014-10-16 08:02:47 <wumpus> this would be interesting discussion if, at some point, the wallet completely split off... talking about that, I'm fairly sure the other SPV wallets don't do any memory locking at all
258 2014-10-16 08:02:59 <wumpus> so anything would be an improvement :p
259 2014-10-16 08:03:25 <gmaxwell> nothing does, we're AFAIK the only implemention that tries at all. Many implementations are written in languages where its fundimentally hard or impossible.
260 2014-10-16 08:04:38 <gmaxwell> So I've considered our effort here to be in the right direction if not complete. Fortunately nothing in the software promises the user this works, so it shouldn't be giving anyone false security (well perhaps it was to a small number of fairly technical people if the limit wasn't widely known)
261 2014-10-16 08:07:28 <gmaxwell> wrt splitting off the wallet, actually splitting off private key management and signing is independantly interesting. E.g. you can end up with an interface that talks equally to a hardware signer (like btchip) or a software one that runs in its own little process.
262 2014-10-16 08:07:58 <coryfields_> wumpus: i was hoping (long-term push, nothing immediate obviously) to move towards signing as part of a lib, so that the wallet functionality could start to split off somewhat
263 2014-10-16 08:08:31 <coryfields_> er, and what gmaxwell said :)
264 2014-10-16 08:08:52 <sinetek> you can use OpenMP primitives
265 2014-10-16 08:08:57 <gmaxwell> ...
266 2014-10-16 08:09:00 <sinetek> hmm
267 2014-10-16 08:09:04 <sinetek> that will get swapped
268 2014-10-16 08:09:06 <sinetek> nvm
269 2014-10-16 08:09:11 <wumpus> gmaxwell: right, and in that case the private key mangement process could mlockall and/or use other OS support for security
270 2014-10-16 08:09:52 <gmaxwell> right, the private key mamangement process could have ptrace denied, no network communiations, very highly sealed.
271 2014-10-16 08:10:14 <coryfields_> wumpus: that's what started this discussion... i didn't want boost and the singleton involved in the lib that would start to emerge
272 2014-10-16 08:10:37 <gmaxwell> hm. seperately I need that kind of process written for other stuff.
273 2014-10-16 08:10:41 <wumpus> coryfields: but in that case it's up to the caller to keep memory secure, not a responsibility of the lib!
274 2014-10-16 08:10:52 <sinetek> i remember somethign about disk encryption and private keys never going into RAM unencrypted
275 2014-10-16 08:11:01 <wumpus> gmaxwell: yes - that would make sense as a general standard, ie not just for bitcoin core, but at least for other wallets as well
276 2014-10-16 08:11:05 <sinetek> maybe something like this could be used. would need assembly
277 2014-10-16 08:11:12 <phantomcircuit> gmaxwell, so you need a process that strongly fights being debugged basically?
278 2014-10-16 08:11:14 <sinetek> store the keys in XMM registers.
279 2014-10-16 08:11:24 <phantomcircuit> i can think of a certain community with experience in that
280 2014-10-16 08:11:29 <wumpus> let's not get too obscure here - any step would work
281 2014-10-16 08:11:33 <wumpus> would help*
282 2014-10-16 08:11:55 <coryfields_> wumpus: exactly, it has no business being so low-level. it's an implementation detail.
283 2014-10-16 08:12:32 <wumpus> coryfields: so you can just split it off from the library, instead of reimplementing it
284 2014-10-16 08:14:55 <wumpus> coryfields: it's like the signature caching in a way, it's just up to the host process to handle it or not
285 2014-10-16 08:15:03 <coryfields_> wumpus: well atm they're tied. i figured the path of least resistance was a compromise in the implementation (fixup to avoid the memlock manager) that the lib would share, then separating it further once it actually exists and is useful
286 2014-10-16 08:15:17 <gmaxwell> phantomcircuit: well 'a basic level' of debugging resistance, e.g. block ptrace and locking memory is table stakes.
287 2014-10-16 08:15:54 <coryfields_> wumpus: ok, i can imagine a split that way, then. something like CKey and friends requiring an allocator (in a general sense, not necessarily in the stl sense) at creation time
288 2014-10-16 08:16:23 <wumpus> coryfields: possibly - or require that the caller allocates
289 2014-10-16 08:16:36 <wumpus> coryfields: does the library need to do any allocation of keys?
290 2014-10-16 08:17:04 <wumpus> if it's 'signing' I'd imagine that a key is passed in, and your signer will just use it
291 2014-10-16 08:17:34 <wumpus> then it's secure if you can avoid copying it around unnecessarily
292 2014-10-16 08:17:46 <wumpus> but maybe you can't, I don't know
293 2014-10-16 08:18:31 <coryfields_> yea, that makes sense
294 2014-10-16 08:18:33 <sipa> getting key signing (and maybe something very abstract like CKeyStore) and script signing into a library sounds nice, but i really wouldn't go as far as putting actual wallet behavior in a lib
295 2014-10-16 08:18:50 <coryfields_> so then... do we mlock the passed-in key? :p
296 2014-10-16 08:18:59 <coryfields_> (joking)
297 2014-10-16 08:19:04 <sipa> the caller is responsible for having it mlocked if they want that
298 2014-10-16 08:19:17 <sinetek> http://frozencache.blogspot.ca/2009/01/concept.html
299 2014-10-16 08:19:32 <wumpus> no, we don't mlock the passed-in key, the caller already has to have done that or it makes no sense (you're too late!)
300 2014-10-16 08:19:44 <gmaxwell> sinetek: this isn't helpful.
301 2014-10-16 08:19:50 <coryfields_> sipa: yea, agreed. after thinking on it for a min, that'd pretty much defeat the purpose
302 2014-10-16 08:20:00 <sinetek> ok. i'll stop
303 2014-10-16 08:20:01 <coryfields_> (any wallet behavior in the lib)
304 2014-10-16 08:20:35 <gmaxwell> sinetek: also in that space there are much more efficient approaches, when bluematt is away if that stuff interest you, you should chat him up in #bitcoin. But its much too low level for our general concerns.
305 2014-10-16 08:21:53 <sinetek> will do
306 2014-10-16 08:22:05 <coryfields_> i'll explor that a bit tomorrow and see how tangled up it is
307 2014-10-16 08:22:27 <coryfields_> would that make sense to you guys as the next logical step for libification, or is there something more obvious?
308 2014-10-16 08:22:55 <wumpus> first step = script library, second step = UTXO library ?
309 2014-10-16 08:23:11 <sipa> well, there's two directions
310 2014-10-16 08:23:32 <sipa> a script library (which may be more than now, as it could also do signing, maybe support non-transaction use cases, ...)
311 2014-10-16 08:23:33 <coryfields_> wumpus: script library meaning what, exactly?
312 2014-10-16 08:23:41 <wumpus> I like compiling bitcoind with -rdynamic and linking that? *ducks*
313 2014-10-16 08:24:01 <sipa> and a consensus library (which combines everything for consensus, including utxo behavior, block validity, script validation)
314 2014-10-16 08:24:04 <sipa> which overlap
315 2014-10-16 08:25:25 <sipa> a general script library is certainly easier than a consensus library
316 2014-10-16 08:25:38 <sipa> as consensus code is still heavily intertwined with p2p code in main
317 2014-10-16 08:25:42 <wumpus> script library is what we're working on as first step; consensus/utxo would include leveldb and basic block management
318 2014-10-16 08:25:58 <sipa> oh, i wouldn't even go that far
319 2014-10-16 08:26:06 <wumpus> (which indeed would have to be peeled from the P2P code)
320 2014-10-16 08:26:11 <sipa> it could let you do your own UTXO database, and have hooks to fetch things
321 2014-10-16 08:26:27 <sipa> there is a ton of consensus code that is not UTXO handling
322 2014-10-16 08:26:36 <sipa> like which script validity flags to use when
323 2014-10-16 08:26:48 <wumpus> it could, but it may well be that leveldb has some specific properties that the consensus relies on
324 2014-10-16 08:26:53 <sipa> no
325 2014-10-16 08:27:05 <sipa> it doesn't even use iteration
326 2014-10-16 08:27:10 <wumpus> after all that was the case before with berkeleydb
327 2014-10-16 08:27:11 <sipa> it's just a key-value store
328 2014-10-16 08:27:11 <wumpus> ok...
329 2014-10-16 08:27:41 <sipa> look at CCoinsViewDB
330 2014-10-16 08:27:43 <wumpus> so you're 100% sure that leveldb has no bugs that we indirectly rely on?
331 2014-10-16 08:27:54 <sipa> i didn't say that
332 2014-10-16 08:28:14 <sipa> but assuming leveldb has no bugs, we should be able to swap leveldb for any other bugfree key-value store
333 2014-10-16 08:28:21 <wumpus> ok in that case I'd also be more inclined to allow luke-jr's --with-external-leveldb
334 2014-10-16 08:28:41 <sinetek> i had success swapping berkeley btw
335 2014-10-16 08:28:53 <wumpus> I always rejected such changes because I assumed we were considering leveldb to be part of the consensus-critical code
336 2014-10-16 08:28:58 <sinetek> wrote a db backing for sqlite
337 2014-10-16 08:29:31 <sipa> wumpus: wait wait
338 2014-10-16 08:29:37 <sipa> we use leveldb for more than the utxo set
339 2014-10-16 08:29:44 <wumpus> 'assuming leveldb has no bugs'... famous last words? :-)
340 2014-10-16 08:30:06 <coryfields_> sipa: you could "do your own" meaning that it's abstract enough to be stuffed into mysql or json or anything in between, as defined by the application? or a particular store-format that the application implements?
341 2014-10-16 08:30:12 <sipa> coryfields_: sure
342 2014-10-16 08:30:24 <sipa> coryfields_: there is one: CCoinsViewCache
343 2014-10-16 08:30:49 <wumpus> sipa: I know, we use it for the block index as well
344 2014-10-16 08:30:50 <sipa> but for low level stuff: you can swap out CCoinsViewDB for anything else
345 2014-10-16 08:31:04 <sipa> yeah, i'm strictly only speaking about the UTXO set here
346 2014-10-16 08:31:23 <sipa> but the block database is much less complex
347 2014-10-16 08:31:25 <coryfields_> ok, good.
348 2014-10-16 08:31:31 <phantomcircuit> if anybody is interested this is what im running for mlockall currently http://pastebin.com/bp0suXjX
349 2014-10-16 08:31:34 <gmaxwell> there can be multiple levels e.g. libconsensusL0 libconsensusL1 ... if you force use of leveldb you'll preclude some users.
350 2014-10-16 08:31:34 <sipa> though it relies on for example iterating over the entires
351 2014-10-16 08:31:47 <sipa> *entries
352 2014-10-16 08:32:12 <Luke-Jr> IMO people should be able to swap out leveldb… as long as they understand the risk in doing so
353 2014-10-16 08:32:33 <sipa> also, we may at some point experiment with a by-txout indexed UTXO set rather than a per-tx indexed one
354 2014-10-16 08:32:33 <wumpus> gmaxwell: well my original idea was also to just provide a database interface, and have the host application decide what backend to use, but I think it was petertodd that convinced me that leveldb was important part of the consensus
355 2014-10-16 08:32:56 <Luke-Jr> wumpus: it's "accidentally" part of consensus, like the CPU itself is
356 2014-10-16 08:33:04 <sipa> for which leveldb would be incredibly useful, because it compacts reused prefixes in keys
357 2014-10-16 08:33:08 <wumpus> Luke-Jr: yes - it is accidental, no doubt there
358 2014-10-16 08:33:32 <sipa> well, everyone would have said the same thing about bdb
359 2014-10-16 08:33:37 <gmaxwell> well thus why I said levels there. It's not part of the consensus if the interface and behavior is perfectly defined and reliable... an unsafe assumption today, but perhaps better in the future.
360 2014-10-16 08:33:49 <sipa> everyone thought that it was just a key-value store, and it was
361 2014-10-16 08:33:56 <sipa> but it failed to do some large updates
362 2014-10-16 08:34:06 <gmaxwell> leveldb has also had similar bugs, but before our usage, fwiw.
363 2014-10-16 08:34:11 <wumpus> exactly, everyone said the same about bdb ... 'assuming bdb has no bugs'...
364 2014-10-16 08:34:15 <sipa> nobody would say that it failed in its property as being a key-value store
365 2014-10-16 08:34:40 <sipa> it just had a limitation we didn't know about (and we had a bug that caused failure to write to consider a block invalid)
366 2014-10-16 08:35:02 <Luke-Jr> heh, to make it worse, IIRC we explicitly *set* the limit lower than it was by default XD
367 2014-10-16 08:35:08 <wumpus> Luke-Jr: well personal risks are fine, but risks to the network are more serious
368 2014-10-16 08:35:13 <gmaxwell> I do think that pretty little blinding idea was cute, annoyingly it wouldn't have saved us from anything we've seen so far.
369 2014-10-16 08:35:54 <wumpus> Luke-Jr: if a major linux distro uses bitcoin in a certain way that causes it to split from consensus, that would be bad
370 2014-10-16 08:36:04 <Luke-Jr> wumpus: we can't eliminate risks to the network. the question is when do we give up trying.
371 2014-10-16 08:36:40 <wumpus> Luke-Jr: yes...
372 2014-10-16 08:37:20 <phantomcircuit> the question is when does the value of eliminated risk become lower than the value of other things
373 2014-10-16 08:37:30 <phantomcircuit> which is a dynamic equilibrium
374 2014-10-16 08:37:32 <Luke-Jr> whether that's before or after leveldb is debatable, and we want people who disagree with our decision to still use the code for the rest..
375 2014-10-16 08:37:38 <phantomcircuit> (ie not an equilibrium)
376 2014-10-16 08:39:12 <sipa> we should perhaps have tests that try to do a sync while some leveldb writes fail
377 2014-10-16 08:39:18 <sipa> and see whether it recovers after reload
378 2014-10-16 08:39:43 <wumpus> that it either recovers or exits with a fatal error
379 2014-10-16 08:39:56 <wumpus> continue with a corrupted state is the worst outcome
380 2014-10-16 08:40:02 <sipa> yup
381 2014-10-16 08:40:42 <phantomcircuit> pretty sure leveldb will happily continue in bizarre corrupted states
382 2014-10-16 08:40:55 <wumpus> that's what made the leveldb-on-ARM issue a bit scary, by the way: nodes would run with the copied database, but the results would be flakey... luckily flakey enough to not work at all
383 2014-10-16 08:41:10 <wumpus> but if it was more subtle it'd have been pretty bad
384 2014-10-16 08:41:17 <sipa> yeah - it's enough that _either_ leveldb or we detect the corruption
385 2014-10-16 08:41:34 <phantomcircuit> i believe that leveldb silently ignore corrupt entries in the journal
386 2014-10-16 08:41:44 <phantomcircuit> it simply skips them
387 2014-10-16 08:41:57 <phantomcircuit> so a deletion from the utxo could be missed
388 2014-10-16 08:42:17 <wumpus> btw still no progress on https://code.google.com/p/leveldb/issues/detail?id=237
389 2014-10-16 08:42:22 <phantomcircuit> sipa, i believe we discussed this ~6months ago
390 2014-10-16 08:42:26 <sipa> phantomcircuit: i know
391 2014-10-16 08:42:36 <coryfields_> wumpus: great find on that, btw
392 2014-10-16 08:43:51 <sipa> yup, very nice detective work :)
393 2014-10-16 08:44:00 <coryfields_> so, backing up to the lib discussion a bit...
394 2014-10-16 08:44:00 <wumpus> thanks :)
395 2014-10-16 08:44:05 <phantomcircuit> sipa, is there a single point at which all of the updates to the utxo are queued?
396 2014-10-16 08:44:11 <sipa> phantomcircuit: yes
397 2014-10-16 08:44:26 <coryfields_> sipa: would you be opposed to adding signing to the current lib work, ignoring what the name of that lib ends up being?
398 2014-10-16 08:44:37 <phantomcircuit> so it should be relatively easy to write a custom delta file and then merge the delta with a full snapshot async
399 2014-10-16 08:44:38 <coryfields_> or would you prefer to focus solely on validation at first?
400 2014-10-16 08:44:49 <sipa> coryfields_: it would be a different library, imho
401 2014-10-16 08:44:56 <sipa> as i said; one for validation, one for signing
402 2014-10-16 08:45:01 <phantomcircuit> ie disk space would expand and then contract as the snapshot was merged with the delta for each block
403 2014-10-16 08:45:02 <coryfields_> i only ask because it seems like a relatively easy target
404 2014-10-16 08:45:09 <sipa> eh, one for validation, one for general script stuff
405 2014-10-16 08:45:15 <phantomcircuit> which iirc is similar to what leveldb does anyways
406 2014-10-16 08:45:26 <sipa> phantomcircuit: yup
407 2014-10-16 08:45:55 <coryfields_> ok
408 2014-10-16 08:46:06 <sipa> coryfields_: no, i think making script stuff into a library is fine, but i think it wuld be different from the current lib
409 2014-10-16 08:46:35 <sipa> (and the script stuff is an easier target that more-than-script consensus stuff imho)
410 2014-10-16 08:47:04 <coryfields_> sipa: i'm mainly thinking in terms of the first release of the lib. seems signing would be easy to add, but not worth doing if they're going to end up split up differently later
411 2014-10-16 08:47:20 <sipa> coryfields_: please don't do that
412 2014-10-16 08:47:30 <coryfields_> ok, understood.
413 2014-10-16 08:47:35 <sipa> i think it's important to have a lib that does consensus _and nothing more_
414 2014-10-16 08:47:49 <sipa> as in: doesn't aim to be "the bitcoin library"
415 2014-10-16 08:48:03 <Luke-Jr> I agree with sipa
416 2014-10-16 08:48:15 <sipa> just aims to be "the one part of bitcoin that you really shouldn't reimplement"
417 2014-10-16 08:49:34 <sipa> 
ACTION zZzZ

418 2014-10-16 08:50:04 <coryfields_> jeez, 5am. me too. nnite.
419 2014-10-16 08:50:51 <wumpus> agree with sipa
420 2014-10-16 08:51:32 <sipa> a script signing/util library probably also needs higher velocity, especially if we want to it to do interesting multisig/p2sh/... stuff
421 2014-10-16 08:51:35 <wumpus> that would be the first step, that doesn't rule out doing "the bitcoin library" later of course
422 2014-10-16 08:51:41 <wumpus> but it's much lower priority
423 2014-10-16 08:51:47 <sipa> as we could add support for merging signatures of various kinds, etc
424 2014-10-16 08:52:05 <sipa> while changes to the consensus part would need much higher scrutiny
425 2014-10-16 08:52:20 <coryfields_> i'm certainly not interested in doing "a library", just that there are different ways to split how the libs could be defined/used
426 2014-10-16 08:52:20 <wumpus> (and there are already plenty of other initiatives in that direction; for Bitcoin the network it's most important to have the consensus unified)
427 2014-10-16 08:52:49 <sipa> (as in: whatever a signing/utility library does can always be verified using consensus code, so there is very little risk in it doing invalid things)
428 2014-10-16 08:53:36 <coryfields_> sipa: btw, before i forget, not sure if you saw earlier... full sync on osx with headers-first, no problems
429 2014-10-16 08:53:46 <coryfields_> really gone now
430 2014-10-16 08:54:07 <sipa> hmm that statement is too strong... it could still reveal private keys, leak things, result in loss of privacy, malleable signatures, ...
431 2014-10-16 08:54:11 <sipa> coryfields_: cool
432 2014-10-16 08:54:41 <sipa> 
ACTION .sleep(28800);

433 2014-10-16 08:55:25 <Luke-Jr> too long
434 2014-10-16 08:56:38 <coryfields_> Luke-Jr: send him a spurious wake in 10000 or so for me ;)
435 2014-10-16 08:56:58 <Luke-Jr> :P
436 2014-10-16 08:57:11 <Luke-Jr> coryfields_: that'd screw up his day :/
437 2014-10-16 09:05:17 <wumpus> set_current_state(TASK_UNINTERRUPTIBLE) :p
438 2014-10-16 09:08:33 <phantomcircuit> sipa, maybe just, things which almost certainly wont fail because of resource constraints
439 2014-10-16 09:08:39 <phantomcircuit> hmm that isn't right either
440 2014-10-16 09:09:21 <phantomcircuit> stuff that will fail 100% of the time when wrong vs fails some % of the time when wrong
441 2014-10-16 09:09:36 <phantomcircuit> random failures being less dangerous but still dangerous
442 2014-10-16 10:27:14 <anarchystar> https://act.eff.org/action/stop-the-bitlicense  <- sign this stuff guys! spread the word
443 2014-10-16 10:45:03 <t7> do i have to be a yank?
444 2014-10-16 10:46:27 <hearn> hey anarchystar
445 2014-10-16 10:47:36 <anarchystar> hey mike ;)
446 2014-10-16 18:10:14 <lechuga_> hmm
447 2014-10-16 18:10:54 <lechuga_> has any1 tried writing a CCoinsViewDB backed by SQL/something else
448 2014-10-16 18:13:28 <sipa> not afaik
449 2014-10-16 18:13:36 <sipa> it would also be very useless
450 2014-10-16 18:14:02 <sipa> as it stores information in a highly custom compact form - it's not like you can easily find addresses or scripts in it
451 2014-10-16 18:14:19 <gmaxwell> it would also be uselessly slow.
452 2014-10-16 18:14:31 <sipa> sqlite may be acceptbale
453 2014-10-16 18:16:37 <sipa> wumpus, gmaxwell: https://github.com/google/leveldb   <-  leveldb 1.18
454 2014-10-16 18:17:01 <sipa> google moved it to github
455 2014-10-16 18:17:25 <earlz> What was the rationale for moving to leveldb instead of, say, sqlite?
456 2014-10-16 18:18:54 <sipa> earlz: we don't need a relation database; we need a key-value store...
457 2014-10-16 18:18:58 <sipa> *relational
458 2014-10-16 18:19:27 <earlz> but it'd be nice for txindex
459 2014-10-16 18:19:46 <sipa> no
460 2014-10-16 18:20:09 <sipa> txindex stores txid -> diskposition entries
461 2014-10-16 18:20:17 <earlz> it'd be nice for mythical things that aren't currently in teh reference wallet (ie, address lookup)
462 2014-10-16 18:20:43 <sipa> that would still require storing address information in those indexes, which we currently don't
463 2014-10-16 18:20:51 <sipa> sql doesn't let you magically look up things that don't exist
464 2014-10-16 18:21:20 <earlz> yea, but you could have a -addressindex or some such to optionally make it.. but at that point I bet sqlite would choke
465 2014-10-16 18:21:41 <sipa> there is an -addrindex patch that i wrote long ago, and sql would still not help with it
466 2014-10-16 18:21:49 <sipa> all it requires is maintaining an address based index
467 2014-10-16 18:22:19 <sipa> sql is meaningful when you want to store highly structured information and want to do arbitrary queries over it
468 2014-10-16 18:22:23 <earlz> where is the patch for that?
469 2014-10-16 18:22:38 <sipa> some pull request that i closed long ago, because i consider it a terrible idea
470 2014-10-16 18:23:02 <earlz> Well, being able to query some things form the wallet would be useful, but not definitely not required of the reference wallet
471 2014-10-16 18:23:15 <sipa> you can query things from the wallet
472 2014-10-16 18:23:24 <earlz> beyond rawtransaction x 1
473 2014-10-16 18:23:38 <sipa> getrawtransaction is not a wallet RPC but a block database RPC
474 2014-10-16 18:23:46 <sipa> use gettransaction is you want to query the wallet
475 2014-10-16 18:23:56 <sipa> which does the same and more, and works for every wallet transaction
476 2014-10-16 18:24:11 <earlz> But I'm concerned with transactions where I don't own the key, etc
477 2014-10-16 18:24:19 <sipa> then you're not talking about the wallet
478 2014-10-16 18:24:36 <sipa> you can use watchonly keys in the wallet now, though
479 2014-10-16 18:24:43 <sipa> which is much more efficient than an addrindex patch would be
480 2014-10-16 18:24:51 <earlz> either way, my current "block explorer" works around it decently.. just wish it could do things at a reasonable speed
481 2014-10-16 18:24:54 <sipa> and deals correctly with unconfirmed transactions
482 2014-10-16 18:25:06 <earlz> is that in 0.9.3? Or only 0.10 master