1 2014-08-30 00:00:00 <phantomcircuit> <lechuga_> has a design been considered where there is maybe a stream of utxo updates from node to wallet
2 2014-08-30 00:00:08 <phantomcircuit> yes i considered that and actually implemented it
3 2014-08-30 00:00:34 <phantomcircuit> however it's substantially more complicated than it sounds because you have to guarantee updates are applied in order
4 2014-08-30 00:01:55 <lechuga_> yeah theyd have to be sequence #'ed
5 2014-08-30 00:02:06 <lechuga_> and the node would have to track all of that state as well
6 2014-08-30 00:02:30 <lechuga_> which gets ugly
7 2014-08-30 00:02:42 <phantomcircuit> lechuga_, basically the node has to save each update in a db forever
8 2014-08-30 00:02:46 <phantomcircuit> which is nasty
9 2014-08-30 00:03:50 <phantomcircuit> an easier way to do it is to calculate the utxo delta for each block and store them for the last 100 blocks plus the utxo for block n-100
10 2014-08-30 00:03:56 <phantomcircuit> that should be enough to handle reorgs
11 2014-08-30 00:05:10 <phantomcircuit> but again
12 2014-08-30 00:05:14 <phantomcircuit> it's pointless
13 2014-08-30 00:07:20 <gmaxwell> none of that stuff is needed for a wallet. _at all_.
14 2014-08-30 00:08:06 <gmaxwell> Not unless you're andytoshi with the crazy wizards wallet, and he seemed to manage just fine with the p2p protocol.
15 2014-08-30 00:28:07 <jrick> importaddress has some nice multibyte characters for comments, as well as json-rpc error strings, that don't display too nicely with editors without multibyte encoding support (obviously)
16 2014-08-30 00:28:34 <jrick> like: throw JSONRPCError(RPC_WALLET_ERROR, "Error\302\240adding\302\240address\302\240to\302\240wallet");
17 2014-08-30 00:29:03 <sipa> eh
18 2014-08-30 00:29:06 <sipa> i don't see that
19 2014-08-30 00:30:06 <jrick> they show as underscores if I use an editor with multibyte support
20 2014-08-30 00:30:06 <sipa> hmm, those are not spaces though
21 2014-08-30 00:30:21 <sipa> mcedit shows them as 0xA0 characters
22 2014-08-30 00:31:23 <sipa> should be fixed
23 2014-08-30 00:32:26 <sipa> jrick: only that line?
24 2014-08-30 00:32:40 <jrick> throw JSONRPCError(RPC_INVALID_ADDRESS_OR_KEY, "Invalid\302\240Bitcoin\302\240address or script");
25 2014-08-30 00:32:46 <jrick> //\302\240Whether\302\240to\302\240perform\302\240rescan\302\240after\302\240import
26 2014-08-30 00:32:51 <phantomcircuit> sipa, is there someway to easily avoid bdb flushing for each keypool key added?
27 2014-08-30 00:32:56 <jrick> 3 total, at least for this function
28 2014-08-30 00:32:59 <sipa> phantomcircuit: -noflushwallet
29 2014-08-30 00:33:01 <sipa> :)
30 2014-08-30 00:33:02 <phantomcircuit> it would be nice if it happened just once when it finished
31 2014-08-30 00:33:24 <phantomcircuit> no i mean when you're refilliing the keypool to temporarilly disable flush
32 2014-08-30 00:33:34 <phantomcircuit> or i can see what that flag does and copy/pasta
33 2014-08-30 00:34:19 <dgenr8> pondering wallet separation, i notice the presence of 1 watch-only address causes the entire chain to require checking on a rescan
34 2014-08-30 00:34:49 <phantomcircuit> sipa, oh man i totally forgot there was a separate thread
35 2014-08-30 00:34:53 <phantomcircuit> hmm
36 2014-08-30 00:35:51 <sipa> dgenr8: there's no way to know the birth time of an imported address
37 2014-08-30 00:36:08 <sipa> we once considered adding a birth timestamp to importprivkey
38 2014-08-30 00:36:19 <sipa> but really, people should be using importwallet instead...
39 2014-08-30 00:36:34 <sipa> though that should get support for watch-only too
40 2014-08-30 00:36:43 <sipa> jrick: https://github.com/bitcoin/bitcoin/pull/4789/files
41 2014-08-30 00:37:41 <jrick> sipa: looks right
42 2014-08-30 00:38:31 <jrick> hahaha
43 2014-08-30 00:38:32 <jrick> c8988460 (Pieter Wuille 2013-07-26 01:06:01 +0200 175) //<C2><A0>Whether<C2><A0>to<C2><A0>perform<C2><A0>rescan<C2><A0>after<C2><A0>import
44 2014-08-30 00:39:02 <sipa> :o
45 2014-08-30 00:39:51 <phantomcircuit> sipa, lolololol
46 2014-08-30 00:41:32 <gmaxwell> who the ?! did that?
47 2014-08-30 00:41:47 <sipa> ACTION or whoever rebased my commit before merge
48 2014-08-30 00:41:58 <sipa> ACTION probably
49 2014-08-30 00:42:18 <gmaxwell> I assume they're non-breaking spaces. here are some for comparison: "Â Â Â Â Â "
50 2014-08-30 00:42:22 <Luke-Jr> a little unicode never hurt anyone <.<
51 2014-08-30 00:42:34 <sipa> įÅÄêÄÄ, ÃÅá»ÄÆ¡Äé ÄħẫÅẫçţá»ÅŠäÅẻ ëpÄ¯Ä ÆųÅ
52 2014-08-30 00:42:43 <Luke-Jr> ACTION changes his mind.
53 2014-08-30 00:43:01 <sipa> ooÊ uoıÊÉÊoɹ s,puıɯ ɹnoÊ Êou puÉ
54 2014-08-30 00:43:20 <dgenr8> how does a rescan work when
55 2014-08-30 00:43:27 <Luke-Jr> sipa: that'd be more impressive if you put your nick & timestamp at the right side of the line with it
56 2014-08-30 00:43:38 <sipa> Luke-Jr: my irrsi plugin doesn't do that yet
57 2014-08-30 00:43:49 <Luke-Jr> Konversation displays it correctly if you use RTL chars :P)
58 2014-08-30 00:48:34 <phantomcircuit> hmm
59 2014-08-30 00:48:37 <phantomcircuit> local network
60 2014-08-30 00:48:54 <phantomcircuit> MilliSleep(10) -> MilliSleep(1) 10x performance for ibd
61 2014-08-30 00:49:09 <phantomcircuit> (at least for first ~150k blocks
62 2014-08-30 00:50:38 <DiabloD3> phantomcircuit: it shouldnt be sleeping at all during the initial download
63 2014-08-30 00:50:43 <sipa> which MilliSleep ?
64 2014-08-30 00:51:00 <phantomcircuit> the one in the main socket handling thread
65 2014-08-30 00:51:11 <phantomcircuit> DiabloD3, i switched it for both nodes
66 2014-08-30 00:51:49 <DiabloD3> it shouldnt be sleeping at all anyhow
67 2014-08-30 00:51:56 <DiabloD3> it should be waiting
68 2014-08-30 00:52:11 <DiabloD3> this is why god invented threads. he was wrong, but he still invented them.
69 2014-08-30 00:52:31 <phantomcircuit> DiabloD3, ThreadSocketHandler() sleeps for 10ms
70 2014-08-30 00:52:45 <DiabloD3> yeah and it shouldnt.
71 2014-08-30 00:52:50 <DiabloD3> thats a clear antipattern
72 2014-08-30 00:52:52 <sipa> welcome to 100% cpu usage
73 2014-08-30 00:53:03 <sipa> (yes, it can be solved)
74 2014-08-30 00:53:05 <DiabloD3> sipa: not if its coded correctly
75 2014-08-30 00:53:13 <DiabloD3> you're supposed to wait on sockets appropriately.
76 2014-08-30 00:53:16 <sipa> phantomcircuit: #4230 removes the millisleep in the message handler
77 2014-08-30 00:54:07 <sipa> we do wait, actually
78 2014-08-30 00:54:18 <sipa> i'm not sure that exact millisleep is very useful
79 2014-08-30 01:05:14 <jgarzik> hum
80 2014-08-30 01:06:06 <jgarzik> sipa, what's a good P2P message handler split? you want main to register (strCommand, funcHandler) ?
81 2014-08-30 01:06:24 <sipa> jgarzik: yes
82 2014-08-30 01:06:27 <phantomcircuit> sipa, actually that doesn't look like it's needed
83 2014-08-30 01:06:42 <phantomcircuit> the select has a timeout already
84 2014-08-30 01:06:45 <sipa> jgarzik: but also support each handler to have its own state
85 2014-08-30 01:06:55 <sipa> which can either be per-node or per-peer
86 2014-08-30 01:08:10 <jgarzik> ACTION shall ponder during kid bedtime
87 2014-08-30 01:08:17 <sipa> jgarzik: i have some well-worked-out ideas, but haven't gotten around to implement them
88 2014-08-30 01:08:29 <sipa> jgarzik: plan to do so in the next weeks
89 2014-08-30 01:08:49 <sipa> in any case, wait for #4230 to land
90 2014-08-30 01:12:02 <sipa> (or help getting it land!)
91 2014-08-30 01:13:26 <phantomcircuit> sipa, yeah that millisleep is useless and should be removed
92 2014-08-30 01:13:32 <phantomcircuit> oh wait actually
93 2014-08-30 01:13:41 <phantomcircuit> if you have zero connections that would infinite loop i think
94 2014-08-30 01:13:54 <phantomcircuit> either way it can probably be 99% eliminated
95 2014-08-30 01:14:09 <sipa> ok, so have a boolean that checks whether some work was performed inside the loop
96 2014-08-30 01:14:14 <sipa> and if not, wait briefly
97 2014-08-30 01:14:32 <sipa> where waiting a non-zero amount of time also counts as work
98 2014-08-30 01:16:37 <phantomcircuit> sipa, no im wrong it already does that
99 2014-08-30 01:16:44 <phantomcircuit> that sleep is useless
100 2014-08-30 01:17:12 <phantomcircuit> if the select call fails it sleep for MilliSleep(timeout.tv_usec/1000);
101 2014-08-30 01:17:18 <phantomcircuit> hmm actually that is probably too short
102 2014-08-30 01:18:22 <phantomcircuit> gavinandresen, MilliSleep(timeout.tv_usec/1000);
103 2014-08-30 01:18:28 <phantomcircuit> what's the point of that?
104 2014-08-30 01:19:18 <sipa> phantomcircuit: exactly preventing a busy loop, i guess?
105 2014-08-30 01:19:37 <phantomcircuit> sipa, it's sleeping for like 1000th of the normal sleep time though
106 2014-08-30 01:19:47 <sipa> usec = microseconds
107 2014-08-30 01:19:54 <sipa> /1000 = milliseconds
108 2014-08-30 01:19:55 <phantomcircuit> actually gavin didn't decide on that timeing he just changed from Sleep to MilliSleep
109 2014-08-30 01:20:02 <phantomcircuit> oh right
110 2014-08-30 01:20:03 <phantomcircuit> derp
111 2014-08-30 01:20:25 <sipa> so yes, i think that millisleep(10) can just go
112 2014-08-30 01:20:27 <phantomcircuit> ok so then the sleep at the end of the function is entirely useless
113 2014-08-30 01:22:12 <phantomcircuit> sipa, #4790
114 2014-08-30 01:22:45 <sipa> some argumentation why it's unnecessary may be useful
115 2014-08-30 01:22:49 <sipa> in the PR
116 2014-08-30 01:23:44 <phantomcircuit> sipa, done
117 2014-08-30 01:47:36 <phantomcircuit> sipa, is there a limit on the number of verification threads that will run?
118 2014-08-30 02:50:51 <wumpus> cfields: pong
119 2014-08-30 03:24:52 <phantomcircuit> cfields, i might be missing something on windows, but at least on posix systems the sleep is entirely pointless
120 2014-08-30 03:29:15 <wumpus> sleep is entirely pointless
121 2014-08-30 03:29:21 <wumpus> :-)
122 2014-08-30 03:29:26 <phantomcircuit> wumpus, lawl
123 2014-08-30 03:29:49 <phantomcircuit> no but srsly low latency link i removed that sleep from both ends
124 2014-08-30 03:29:55 <phantomcircuit> 80MB/s transfer for ibd
125 2014-08-30 03:29:57 <Luke-Jr> my wife gets mad if I skip it tho
126 2014-08-30 03:30:39 <wumpus> phantomcircuit: sure, I agree
127 2014-08-30 03:30:56 <wumpus> phantomcircuit: fixed sleeps generally make no sense in code
128 2014-08-30 03:32:27 <wumpus> pegging the CPU in a tight loop *when we're actually doing something* is not a problem
129 2014-08-30 03:33:20 <wumpus> it it would needlessly loop there would be a bug in the code
130 2014-08-30 03:34:52 <wumpus> Luke-Jr: proably because it makes you grumpy
131 2014-08-30 03:37:12 <wumpus> lol@#4789, let's see if the source has any other weird characters in it
132 2014-08-30 03:37:46 <jrick> wumpus: there weren't any more introduced from that commit
133 2014-08-30 03:37:53 <jrick> no idea about the rest of the tree
134 2014-08-30 03:50:15 <phantomcircuit> wumpus, ha
135 2014-08-30 03:50:22 <phantomcircuit> there's a bunch of random stalls
136 2014-08-30 03:50:39 <phantomcircuit> the bitcoind that's pushing blocks is being used by a pool
137 2014-08-30 03:50:54 <phantomcircuit> looks like the block creation code could use some performance improvements
138 2014-08-30 03:52:19 <wumpus> ./src/json/json_spirit_writer_template.h: Found weird characters "â,â"
139 2014-08-30 03:52:19 <wumpus> ./src/qt/bitcoinunits.cpp: Found weird characters "μ"
140 2014-08-30 03:52:19 <wumpus> ./src/rpcdump.cpp: Found weird characters "Â "
141 2014-08-30 03:52:31 <wumpus> no PILE OF POOs at least
142 2014-08-30 03:59:37 <dcousens> hey all :), anyone able to elaborate http://webbtc.com/tx/d65bb24f6289dad27f0f7e75e80e187d9b189a82dcf5a86fb1c6f8ff2b2c190f.json for me? Specifically the scriptSig on the coinbase.
143 2014-08-30 04:01:47 <dcousens> is it just an odd coinbase in that it is a custom input script that anyone could have spent? (aka, no signature check)
144 2014-08-30 04:02:21 <wumpus> coinbases do not have input scripts
145 2014-08-30 04:03:38 <dcousens> wumpus: good point (just waking up), so what is in the scriptSig
146 2014-08-30 04:05:11 <wumpus> arbitrary data
147 2014-08-30 04:05:16 <wumpus> and the block height
148 2014-08-30 04:06:14 <phantomcircuit> which reminds me
149 2014-08-30 04:06:23 <phantomcircuit> wumpus, the block version check should be changed
150 2014-08-30 04:06:29 <phantomcircuit> it cant be downgraded anyways
151 2014-08-30 04:15:07 <dcousens> wumpus: cheers wumpus
152 2014-08-30 05:29:26 <phantomcircuit> 2014-08-30 05:19:22 UpdateTip: new best=0000000000000000059bc21a6f94dbdac904fa8bbba80546c7df3515c0841dc9 height=318194 log2_work=80.428647 tx=45621520 date=2014-08-30 05:19:50 progress=1.000001
153 2014-08-30 05:29:27 <phantomcircuit> 2014-08-30 03:40:29 UpdateTip: new best=00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 height=1 log2_work=33.000022 tx=2 date=2009-01-09 02:54:25 progress=0.000000
154 2014-08-30 05:29:56 <phantomcircuit> 40 minutes ridiculous server p2p protocol after removing 10ms delay
155 2014-08-30 05:39:21 <dgenr8> phantomcircuit: that is great. look forward to trying it on the WAN and with headers first
156 2014-08-30 05:42:17 <phantomcircuit> dgenr8, wont be better, probably will be worse
157 2014-08-30 05:42:22 <phantomcircuit> but not necessarilly
158 2014-08-30 05:42:36 <wumpus> why?
159 2014-08-30 05:45:40 <phantomcircuit> wumpus, because at peak i was pushing 110MB/s
160 2014-08-30 05:45:47 <phantomcircuit> hard to do that over the internetz
161 2014-08-30 05:45:58 <phantomcircuit> also this is on a like
162 2014-08-30 05:46:00 <phantomcircuit> 15k server
163 2014-08-30 05:46:21 <wumpus> oh, I thought you meant that it would be worse with headers first, sure, with a slower network connection it'sworse :)
164 2014-08-30 05:46:52 <phantomcircuit> fun fact
165 2014-08-30 05:47:00 <phantomcircuit> at no time was the load > 11
166 2014-08-30 05:48:03 <phantomcircuit> wumpus, why is getheaders so limited btw?
167 2014-08-30 05:48:14 <phantomcircuit> seems a bit willy compared to the getdata limits
168 2014-08-30 05:48:27 <wumpus> no idea
169 2014-08-30 05:50:27 <phantomcircuit> BlueMatt, ^
170 2014-08-30 05:50:32 <phantomcircuit> ecf07f27 src/main.cpp (Matt Corallo 2012-03-19 00:13:15 -0400 3828) int nLimit = 2000;
171 2014-08-30 05:53:40 <BlueMatt> phantomcircuit: that commit made the code do what it read like it was intended to do (and what everyone assumed it did)
172 2014-08-30 05:53:49 <BlueMatt> phantomcircuit: the 2k limit is a satoshi-era thing
173 2014-08-30 05:56:18 <phantomcircuit> the limit probably should be increased
174 2014-08-30 05:56:23 <phantomcircuit> it just doesn't make much sense
175 2014-08-30 05:56:36 <phantomcircuit> 40kB limit when getdata is like 5MB
176 2014-08-30 05:58:15 <wumpus> I'd say propose it on the mailing list
177 2014-08-30 06:00:03 <wumpus> not sure if it would break all kinds of SPV clients if we suddenly started sending more
178 2014-08-30 06:03:57 <phantomcircuit> wumpus, protocol version bump at the very least
179 2014-08-30 15:24:39 <sipa> phantomcircuit: maximum 16 verificatiin threads afaik
180 2014-08-30 21:13:10 <joedoe-> hello, how long VERSION message is? 108 bytes?
181 2014-08-30 21:18:42 <sipa> depends
182 2014-08-30 21:18:52 <sipa> some of the fields in it are optional
183 2014-08-30 21:58:02 <BlueMatt> so rumor has it gfw is blocking bitcoin p2p
184 2014-08-30 22:05:54 <Eliel> sounds like a futile attempt to prevent people from using bitcoin...
185 2014-08-30 22:12:59 <BlueMatt> and a legitimate fork risk
186 2014-08-30 22:13:54 <coryfields> BlueMatt: mm, i'm headed there in about 1.5 months. could help experiment if still necessary
187 2014-08-30 22:15:14 <BlueMatt> well I think the point is we need to have infrastructure in place to ensure blocks can hop the gfw
188 2014-08-30 22:17:00 <coryfields> ACTION adds QQ support to bitcoind
189 2014-08-30 22:18:57 <sipa> QQ?
190 2014-08-30 22:20:23 <coryfields> https://en.wikipedia.org/wiki/Tencent_QQ
191 2014-08-30 22:23:17 <coryfields> BlueMatt: any idea what could be causing this on the new pull-tester: https://travis-ci.org/coryfields/bitcoin/jobs/33344279#L1782 ?
192 2014-08-30 22:23:49 <coryfields> it happens only randomly (maybe 1/20 runs) and always after b67
193 2014-08-30 22:24:31 <coryfields> gmaxwell suggested it may be a VM/memory issue. Figured I'd get your opinion before I start throwing random values into the test environment to test
194 2014-08-30 22:25:21 <gmaxwell> wumpus: I'm really not happy about proliferating more and more regtest setups.
195 2014-08-30 22:26:28 <gmaxwell> wumpus: it means keeping track of more special case conditionals in production code, and keeping around varrious checks for this mode vs that mode.
196 2014-08-30 22:30:00 <BlueMatt> coryfields: what jar are you even running???
197 2014-08-30 22:30:09 <BlueMatt> those line numbers dont match to anything I can find
198 2014-08-30 22:30:12 <coryfields> BlueMatt: apparently an ancient one
199 2014-08-30 22:30:14 <coryfields> same
200 2014-08-30 22:30:40 <BlueMatt> go build a new one
201 2014-08-30 22:31:00 <coryfields> BlueMatt: I grabbed the ones from your git repo. I believe sipa verified they're the same as what's on the current pull-tester
202 2014-08-30 22:31:20 <BlueMatt> I have a git repo?
203 2014-08-30 22:31:34 <BlueMatt> you should go build a new one
204 2014-08-30 22:32:18 <coryfields> ok
205 2014-08-30 22:34:55 <sipa> BlueMatt: if he's using the same jar as pulltester, it shouldn't be randomly failing
206 2014-08-30 22:35:08 <sipa> BlueMatt: and if it does, it's unlikely to be solved by upgrading to something else?
207 2014-08-30 22:35:32 <BlueMatt> sipa: well, I cant debug it unless the line numbers match up to...something
208 2014-08-30 22:35:40 <sipa> fair enough
209 2014-08-30 22:36:08 <coryfields> BlueMatt: would it be possible for a linked list to get busted like that if it hit a mem limit?
210 2014-08-30 22:36:12 <coryfields> or would it always throw an out of mem?
211 2014-08-30 22:36:34 <BlueMatt> no, thats reading from disk
212 2014-08-30 22:36:36 <BlueMatt> or...should be
213 2014-08-30 22:36:47 <BlueMatt> assuming you're running with the "do a full test" parameter
214 2014-08-30 22:36:52 <BlueMatt> oh, wait, isnt that still broken?
215 2014-08-30 22:37:17 <coryfields> it's not the full reorg
216 2014-08-30 22:37:22 <BlueMatt> oh
217 2014-08-30 22:37:41 <BlueMatt> well, then yea, its in memory...but no, it should get an OutOfMemoryException then
218 2014-08-30 22:37:47 <sipa> -rw-r--r-- 1 root root 1245869 2013-10-27 20:00 BitcoindComparisonTool.jar
219 2014-08-30 22:37:52 <coryfields> hmm, disk full then, maybe?
220 2014-08-30 22:37:53 <sipa> ^- used by pulltester
221 2014-08-30 22:38:01 <BlueMatt> no
222 2014-08-30 22:38:03 <BlueMatt> shouldnt be
223 2014-08-30 22:40:42 <sipa> BlueMatt: https://github.com/TheBlueMatt/test-scripts
224 2014-08-30 22:40:44 <sipa> last commit
225 2014-08-30 22:46:26 <gmaxwell> Am I just in a foul moot today or is it insane to add unit test that will randomly fail if things are changed? (the 'unittest' chain with the target set such that the current tests all just happen to pass with no mining loop)
226 2014-08-30 22:49:29 <sipa> ?
227 2014-08-30 22:52:39 <gmaxwell> #4732 introduces yet another regtest network, but with the difficulty turned way down so that the unit tests it introduces don't need a mining loop.
228 2014-08-30 22:53:21 <gmaxwell> except if you change any of them, perhaps they will, depending on the will of the hashing gods.
229 2014-08-30 22:54:48 <kanzure> what's the point of changing the difficulty if the tests aren't about mining?
230 2014-08-30 22:55:02 <kanzure> why not just instant return
231 2014-08-30 22:55:38 <sipa> more conditionals
232 2014-08-30 22:55:53 <sipa> though we're already doing unnecessarily many of those
233 2014-08-30 22:55:57 <gmaxwell> I'm a little irritated that I recommended to sergio that he change regtest to suit his needs because I didn't want him peppering the code with changes as he did in the first patch; and Mike (you know, the same guy who was going around on the internet saying bitcoind didn't have any tests at all two days ago) shows up and tells him not to change regtest for compatiblity with bitcoinj. (!?!?)
234 2014-08-30 22:56:27 <kanzure> that's what you get for paying attention, i guess
235 2014-08-30 22:57:21 <sipa> i don't really care about more network, as long as they're just changing some parameters that already exist
236 2014-08-30 22:57:24 <kanzure> what do they do for tests in bitcoinj or btcd? do they set a low mining difficulty, or do they just replace mining entirely?
237 2014-08-30 23:00:57 <kanzure> https://github.com/bitcoinj/bitcoinj/tree/master/core/src/test/java/com/google/bitcoin
238 2014-08-30 23:02:49 <gmaxwell> sipa: it just seems stupid to me to have another set of parameters for really no obvious reason, not the end of the worldâ but the goal is to basically have yet another low but not zero difficulty so that mining loops can be left out of the test until they start failing because of some change, and then we'll need yet another stupid parameter set to lower the threshold further or something idiotic like that.
239 2014-08-30 23:04:11 <sipa> isn't regtest easy enough?
240 2014-08-30 23:05:25 <gmaxwell> It's very easy but you still need a loop.
241 2014-08-30 23:06:36 <sipa> i'll have a look at the PR
242 2014-08-30 23:10:04 <sipa> humm
243 2014-08-30 23:45:19 <coryfields> BlueMatt: fyi, current bitcoinj pull-tester borks against current bitcoind. it seems to assume getutxos is present and bails when it's not
244 2014-08-30 23:46:02 <BlueMatt> wat?
245 2014-08-30 23:46:03 <coryfields> er.. current bitcoinj comparisontool