1 2017-03-10 00:02:31	0|cbits_|Yeah, and it automatically sets rbf checked when you have it set to visible
  2 2017-03-10 02:58:41	0|gmaxwell|wumpus: would we perhaps want to consider removing zap? we added it because we had no way to abandon transactions, but we do now. I've seen it used in a way that created a lot of damage. (user ran into the unconfirmed depth limit and couldn't make transactions. Then zapped their wallet, then stared paying again, doublspending the @#$@# out of themselves.  .. then were stuck trying to reassemble
  3 2017-03-10 02:58:47	0|gmaxwell|the pieces... figure out who they still owed, etc.
  4 2017-03-10 05:11:52	0|tonebox|It seems like segwit is a temporary fix...  4M is going to be overwhelmed, just like 1mb now...  Wouldn't a better solution be to change the time-base, so now it's 10 minutes per block... Soon, 5 min, then 2.5...  It could revert to 10, and be automatically adjusted just like the difficulty.
  5 2017-03-10 05:13:25	0|Lightsword|tonebox, no, that results in higher orphan rates due to latency
  6 2017-03-10 05:14:57	0|tonebox|Ok...  Thanks...   Would there be any way to make segwit not fixed at 4mb so this won't be a problem that needs to be solved again in a few years?
  7 2017-03-10 05:17:11	0|tonebox|Also, it would seem like a dynamic timebase and fixing the issue with orphans would be a better solution long term.
  8 2017-03-10 05:20:12	0|CubicEarth|Lightsword: I always thought moving to a 5 minute block time would be perfectly fine
  9 2017-03-10 05:20:27	0|gwillen|This isn't really a good channel for this kind of discussion -- better in #bitcoin probably.
 10 2017-03-10 05:20:37	0|CubicEarth|a slightly higher orphan rate wouldn't hurt anything
 11 2017-03-10 05:59:18	0|wumpus|gmaxwell: I'm fine with that...
 12 2017-03-10 06:01:03	0|wumpus|gmaxwell: what I mostly don't like about it is that it requires a rescan, and is very non-selective (zap all unconfirmed)
 13 2017-03-10 06:02:33	0|wumpus|gmaxwell: mostly it's useful to troubleshoot issues with wallet bugs and corruption, when a certain transaction behavres strangely.  But a tool to remove a single transaction from the database would work much better for that and be less impactful. Back in the day,though,that was hard to do for some reason
 14 2017-03-10 06:03:30	0|wumpus|I agree abandontransaction replaces all end-use servicable reasons to use zap
 15 2017-03-10 06:11:44	0|gmaxwell|It might just make sense to rename it and hide it for that reason. If there is a reason to not do that, we should probably enhance abandon further.
 16 2017-03-10 06:12:53	0|wumpus|me preference would be to hide it in some dangerous-sounding wallet salvage or editing tool, not have it in the main executable at least or maybe not even in the main distribution
 17 2017-03-10 06:13:16	0|wumpus|I mean there's a use for low-level-ish wallet editing, but it certainly shouldn't be easily available
 18 2017-03-10 06:14:52	0|gmaxwell|Salvage is also pretty raw... I've said before it should be called "savage (verb) wallet"
 19 2017-03-10 06:15:08	0|wumpus|hehe
 20 2017-03-10 06:15:54	0|wumpus|salvage has been actually useful to a lot of people though, it tends to be the only thing available if the rest if something is corrupted
 21 2017-03-10 06:16:37	0|luke-jr|doesn't zap recover from corrupt bdbs we can't open?
 22 2017-03-10 06:16:48	0|wumpus|no, zap doesn't do that
 23 2017-03-10 06:17:02	0|wumpus|it assumes that records are simply readable, what it does is remove all transactions
 24 2017-03-10 06:17:16	0|wumpus|with a mode to keep metadata (by default) and another to trash it
 25 2017-03-10 06:17:25	0|gmaxwell|salvage does. though at least historically it would also miss data in perfectly fine wallet.dats (though I think some of that was due to bugs which have been fixed)
 26 2017-03-10 06:17:39	0|luke-jr|ah, mixed them up I guess
 27 2017-03-10 06:18:00	0|wumpus|I think those issues have been fixed
 28 2017-03-10 06:18:34	0|wumpus|thoug there are still some weird issues with salvagewallet, for example berkeleydb can return an error when salvaging an otherwise ok wallet (but it doesn't lose records anymore IIRC)
 29 2017-03-10 06:18:58	0|wumpus|then again this is the kind of thing we're asking for with not updating the backend library for years. BDB should die.
 30 2017-03-10 06:20:45	0|gmaxwell|so I did some testing and later BDB now appear to be bidirectionally compatible?!
 31 2017-03-10 06:20:56	0|gmaxwell|but I couldn't find any announcement of it.
 32 2017-03-10 06:21:00	0|gmaxwell|it just worked.
 33 2017-03-10 06:21:06	0|wumpus|it works in some cases
 34 2017-03-10 06:21:33	0|wumpus|that's been the case when I tried too. But I don't trust it.
 35 2017-03-10 06:21:56	0|gmaxwell|ah, I wasn't aware that it ever worked before.
 36 2017-03-10 06:22:42	0|wumpus|I think the backward incompatiblity thing is just a matter of no one ever seriously researching this, and what are the edge cases of it, than a sure thing
 37 2017-03-10 06:22:57	0|wumpus|it doesn't work in *all* cases that is clear
 38 2017-03-10 06:26:33	0|wumpus|one thing that is not backwards compatible is the log files; so if there are still log files behind, the old version will error out
 39 2017-03-10 06:36:16	0|wumpus|it may well be that a "clean" .dat file, like produced by backupwallet, is always backwards compatible. Though that doesn't help a user that crashes on first run with the new version then tries to go back, the wallet being in intermediate state.
 40 2017-03-10 06:37:28	0|wumpus|of course it's fairly simple to work around this with a conversion tools and/or making and automatic backup at first run. But it was just never deemed worth the trouble
 41 2017-03-10 06:37:39	0|wumpus|especially as newer BDBs have license issues
 42 2017-03-10 06:38:00	0|wumpus|the plan was ,and should still be, to move away from it
 43 2017-03-10 08:58:11	0|wumpus|baahh.. this is the second time I have trouble with the tests due to a stale qa/cache directory
 44 2017-03-10 08:58:51	0|wumpus|we should probably nix it when a change in bitcoind is detected
 45 2017-03-10 09:00:21	0|wumpus|e.g. write that path and sha256sum of the bitcoind used into the cache directory, and if that changes, delete it
 46 2017-03-10 09:02:12	0|sipa|unsure that's worth it... breaks of the cache direction are very infrequent, i think
 47 2017-03-10 09:02:27	0|sipa|at least in my experience
 48 2017-03-10 09:02:41	0|wumpus|any change to the wallet, at least
 49 2017-03-10 09:03:40	0|wumpus|node0 keeps a wallet from mining the initial blocks, which is usually what causes the problems, if the test expects a certain newly introduced property of transactions
 50 2017-03-10 09:04:16	0|wumpus|maybe it's infrequent but it is really frustrating and can lead to hours of misdirected search for bugs if it happens
 51 2017-03-10 09:05:00	0|wumpus|conceptually it's also not *valid* to use an older cache, there is no guarantee that your tests passing is worth anything
 52 2017-03-10 09:05:20	0|wumpus|the new bitcoind may completely mess up the initial steps and it'd still pass because it is cached
 53 2017-03-10 09:06:26	0|wumpus|but ok I'll just add a message "Using cached node state in %s" to the test output, maybe that's enough to remind people to delete it if they run into weird issues
 54 2017-03-10 09:06:58	0|sipa|no, i think you're right
 55 2017-03-10 09:07:11	0|sipa|we shouldn't be using outdated caches
 56 2017-03-10 09:20:01	0|jonasschnelli|wumpus: https://github.com/bitcoin/bitcoin/pull/9294#issuecomment-285612826
 57 2017-03-10 09:20:10	0|jonasschnelli|This is strange... can it be a caching issue?
 58 2017-03-10 09:20:34	0|jonasschnelli|I can't see a reason why the dump is different on your machine than on mine / travis.
 59 2017-03-10 09:21:26	0|jonasschnelli|Maybe you have a chance and check the file "wallet.unencrypted.dump" (maybe pastebin it) when running with --nocleanup
 60 2017-03-10 09:28:02	0|jonasschnelli|sipa: maybe you have a chance to review #9965. It seems that you ate most familiar with that code part. It also touches the segwit.py test (where I'm not sure if I did the right thing).
 61 2017-03-10 09:29:35	0|wumpus|jonasschnelli: yes it was a caching issue
 62 2017-03-10 09:30:07	0|jonasschnelli|Great! *relief*
 63 2017-03-10 09:30:12	0|wumpus|jonasschnelli: that why I wrote the posts above ^^
 64 2017-03-10 09:33:08	0|wumpus|I think we should store a hash of the bitcoind executable in the cache directory and delete it when it mismatches
 65 2017-03-10 09:39:26	0|jonasschnelli|wumpus: Ah. Thanks. I haven't read the scrollback. Yes. Good idea with the binary-hash mismatch detection.
 66 2017-03-10 10:31:03	0|MarcoFalke|1
 67 2017-03-10 12:20:09	0|MarcoFalke|no, the salvagewallet issue is not yet fixed
 68 2017-03-10 12:21:22	0|MarcoFalke|At least I am not aware that anyone fixed it and the tests are still disabled
 69 2017-03-10 12:28:53	0|wumpus|MarcoFalke: from what I remember what causes the test to fail is that salvagewallet can return false when the answer should be true. I don't think any keys are still being lost
 70 2017-03-10 12:39:30	0|wumpus|at least that was my experience from last time I tried to reproduce the issue
 71 2017-03-10 12:43:00	0|MarcoFalke|ok, going to enable the test on the nightly builds and see what happens
 72 2017-03-10 12:58:04	0|wumpus|good idea.
 73 2017-03-10 12:58:59	0|wumpus|what I also found back then is that if you have a wallet that it fails on, it's fully reproducible with that. So it's something in the specific database that triggers it
 74 2017-03-10 12:59:49	0|Victorsueca|be careful, maybe the code becomes self-aware and starts gathering private keys all around the world and then spends all UTXOs to 1Yoink.... :P
 75 2017-03-10 13:18:29	0|wumpus|:p
 76 2017-03-10 13:56:33	0|morcos|Re: fee estimation and RBF.  My plan for Core wallet is as follows:
 77 2017-03-10 13:56:55	0|morcos|Fee estimation allowed for targets of: 2, 4, 6, 12, 24, 48, 144, 1008
 78 2017-03-10 13:57:42	0|morcos|There will be 2 types of estimate for each target, a conservative estimate (probably not too different from todays estimates, but still a bit less conservative) and an actual estimate
 79 2017-03-10 13:58:20	0|morcos|I was imagining some kind of interaction between those and RBF, such that if you don't have RBF enabled then it prompts you to use the conservative estimate or something
 80 2017-03-10 13:59:00	0|morcos|Via RPC, you'll be able to get all kinds of more specific information if you choose
 81 2017-03-10 14:00:25	0|morcos|Turns out its a bit tricky to do the longer time horizon estimates, b/c if your node hasn't been up for that long, you can't really know..  And if you shut your node down, it doesn't currently record all the txs stuck in your mempool as failing.
 82 2017-03-10 14:00:52	0|morcos|Fixing these issues is what's holding me up now...   And then I think I may have a performance problem to fix.
 83 2017-03-10 14:01:45	0|petertodd|morcos: whatever you do, I'd suggest you plan for far more opt-in usage in the future; with ppl spamming the network to apparently raise fees the next round may make whatever estimating thing we come up with unreliable; tx replacement otoh is much harder to game
 84 2017-03-10 14:02:53	0|morcos|Yeah I think a separate but related project is to have an auto-replace mode...
 85 2017-03-10 14:02:58	0|petertodd|(e.g. something that ignored opt-in txs entirely my fail if the % of them becomes much higher)
 86 2017-03-10 14:03:17	0|petertodd|yeah. auto-replace mode is nice - gmaxwell has a neat way to do it where nlocktime is used to ensure replacements can be done prematurely
 87 2017-03-10 14:03:32	0|morcos|As far as fee estimates dealing with opt-in txs.. I don't think thats much of a problem.. The only issue with that was to be cautious when they were knew that some miners might nto accept them
 88 2017-03-10 14:03:51	0|morcos|prematurely?  oh you mean sign in advance?
 89 2017-03-10 14:04:13	0|petertodd|morcos: exactly! he suggested signing n contradictory txs, each with a higher nlocktime and higher fee
 90 2017-03-10 14:04:32	0|petertodd|morcos: particulkarly relevant for hw wallets like trezor
 91 2017-03-10 14:04:40	0|morcos|interesting...  and maybe you could have a differential relay too... :)
 92 2017-03-10 14:05:07	0|petertodd|morcos: yeah, differential relay would be nice, although at least replacement BW just increases the average; peak BW is our actual bottleneck
 93 2017-03-10 15:59:34	0|bsm1175322|I have a need to deliver witness data to SPV clients, which necessitates a one-line change: https://github.com/VidaID/bitcoin/commit/2a3052622596db9b1fe29cd357cfc58a831b050c
 94 2017-03-10 16:00:09	0|bsm1175322|Would we make this an option or something?
 95 2017-03-10 16:00:12	0|bsm1175322|*could
 96 2017-03-10 16:09:08	0|BlueMatt|bsm1175322: you need to do this over p2p?
 97 2017-03-10 16:09:16	0|bsm1175322|yes
 98 2017-03-10 16:09:59	0|BlueMatt|bsm1175322: if you can do it over rpc via the gettxoutproof/verifytxoutproof stuff we could probably tweak the format to include proofs of witnesses as well, but p2p....ugh, i think everyone wants to completely remove that code sooner or later, its not good
 99 2017-03-10 16:10:12	0|BlueMatt|bsm1175322: (need to replace it with bloom filter commitments in blocks or so)
100 2017-03-10 16:10:14	0|bsm1175322|BlueMatt: agreed on that.
101 2017-03-10 16:10:28	0|bsm1175322|Well giving every random client direct access to RPC is not a good idea for a number of reasons
102 2017-03-10 16:10:45	0|bsm1175322|Stage 2 of this project will be to redesign BIP37.  I'm well aware of its flaws.
103 2017-03-10 16:11:07	0|bsm1175322|But, for the moment we're just using it, warts and all.
104 2017-03-10 16:11:12	0|BlueMatt|bsm1175322: well the other thing we can do is extend the rpc to support it and then your patch will be simpler :)
105 2017-03-10 16:11:32	0|BlueMatt|(right now your patch isnt providing any proof of the witnesses, only the tx data, and providing the witness itself just as extra)
106 2017-03-10 16:12:35	0|bsm1175322|Oh I hadn't thought of that...there's a Merkle proof that's possible for the witness data too...
107 2017-03-10 16:12:58	0|bsm1175322|But...who would care about that?  The client can verify that the witness signature is correct...
108 2017-03-10 16:13:09	0|BlueMatt|bsm1175322: yea, would have to provide the merkle path to coinbase + merkle path to the witness in question
109 2017-03-10 16:13:26	0|BlueMatt|well assuming they have the transactions being spent, sure
110 2017-03-10 16:14:16	0|bsm1175322|Hmmm since you're here in NYC...we should get together soon and have a brainstorming session about a BIP37 replacement...
111 2017-03-10 16:16:24	0|BlueMatt|sure, iirc there was some ml post not too long ago on it
112 2017-03-10 16:16:42	0|BlueMatt|something about committed bloom filters, I dont recall if they concluded that the filters were too big to be practical or if they were excited though
113 2017-03-10 16:16:46	0|BlueMatt|maybe it was a few months ago.....
114 2017-03-10 16:17:15	0|bsm1175322|Oh that one...and I calculated the size was unreasonable...
115 2017-03-10 16:17:22	0|BlueMatt|awww, damn
116 2017-03-10 16:17:32	0|BlueMatt|well, ok, brainstorming it is
117 2017-03-10 16:17:48	0|bsm1175322|https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012674.html
118 2017-03-10 16:18:00	0|BlueMatt|oh wow that was months ago
119 2017-03-10 16:18:08	0|bsm1175322|original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012636.html
120 2017-03-10 16:20:58	0|bsm1175322|UTXO set commitment in some form are #1 on my wishlist for improving light client security.
121 2017-03-10 16:20:59	0|gribble|https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
122 2017-03-10 16:23:00	0|bitcoin-git|[13bitcoin] 15sdaftuar opened pull request #9970: Improve readability of segwit.py (06master...062017-03-segwit-test-improvements) 02https://github.com/bitcoin/bitcoin/pull/9970
123 2017-03-10 16:23:46	0|BlueMatt|bsm1175322: hmm, yea, 12 GB total isnt trivial, though I dont think its insane...I mean its not like you download that whole dataset unless you dont know when your keys were created
124 2017-03-10 16:23:54	0|BlueMatt|bsm1175322: does have lots of challenges, though :(
125 2017-03-10 16:24:05	0|bsm1175322|There's probably a workable mutation of that idea...
126 2017-03-10 16:24:20	0|BlueMatt|bsm1175322: utxo commitments dont help you sync, though, but, yea, are a huge win
127 2017-03-10 16:24:51	0|BlueMatt|its unclear what the "right" solution is, I mean scanning the chain for your transactions makes less and less sense every day, especially given that folks are moving towards off-chain txn
128 2017-03-10 16:24:54	0|BlueMatt|cant scan for those.....
129 2017-03-10 16:25:42	0|bsm1175322|That's a different problem entirely ;-)  SPV-lightning...
130 2017-03-10 16:26:39	0|bsm1175322|Another idea I'm a fan of on this topic is andytoshi's PoW skiplists...
131 2017-03-10 16:29:11	0|BlueMatt|yea, PoW skiplists are cool, though you have to be careful with them depending on your use-case
132 2017-03-10 16:29:26	0|BlueMatt|what use-case do you have for them? I mean 80 bytes * 400k blocks isnt that much, still, today?
133 2017-03-10 16:29:44	0|bsm1175322|Linear algorithms suck. ;-)
134 2017-03-10 16:30:03	0|bsm1175322|Initial sync in SPV mode still takes a non-trivial amount of time on phones.
135 2017-03-10 16:30:21	0|bsm1175322|It's just hashing those 400k blocks...
136 2017-03-10 16:32:18	0|BlueMatt|i mean we can improve that....we need a "give me all headers without the previous block hash in binary form" thing
137 2017-03-10 16:32:27	0|BlueMatt|mabye not p2p, just connect to blockchainheaders.com and get it
138 2017-03-10 16:32:29	0|BlueMatt|its 18MB
139 2017-03-10 16:32:37	0|BlueMatt|and hashing that cant take that long, no?
140 2017-03-10 16:34:03	0|bsm1175322|It does take that long, for whatever reason.  Bcoin only verifies headers at a rate of ~20/s on the phone.
141 2017-03-10 16:35:11	0|dgenr8|bsm1175322: did you mean committed bloom filters?
142 2017-03-10 16:35:12	0|bsm1175322|@chjj is there any other reason you can think of besides sha256 speed which might be causing spv sync to be slower on the phone?  Obviously it's quite fast in nodejs.
143 2017-03-10 16:35:38	0|bsm1175322|dgenr8: yes that's what we were discussing
144 2017-03-10 16:36:26	0|BlueMatt|bsm1175322: I mean I assume its also p2p latency, which isnt fun
145 2017-03-10 16:36:30	0|dgenr8|BlueMatt: size unreasonable with what fp rate
146 2017-03-10 16:36:33	0|BlueMatt|20/s seems supperrr slow
147 2017-03-10 16:37:24	0|bsm1175322|dgenr8: see the referenced post with my calculation, I used fp rate= 1/height ~ 10^-6
148 2017-03-10 16:37:39	0|bsm1175322|came out to about 12GB of committed filters.
149 2017-03-10 16:37:48	0|bsm1175322|obviously this can be tuned...
150 2017-03-10 16:37:54	0|bsm1175322|At the cost of holding blocks you don't need.
151 2017-03-10 16:37:57	0|BlueMatt|(though we may want a similar command to remove checkpoints entirely for ibd - much easier to connect to a few peers and ask them for 4MB of headers (~100k blocks) at a time and then get a header chain and ban anyone who tried to spam you
152 2017-03-10 16:38:04	0|BlueMatt|instead of the current getheaders stuff
153 2017-03-10 16:38:39	0|BlueMatt|bsm1175322: to be fair, you probably want something much higher than 10^-6
154 2017-03-10 16:38:48	0|bsm1175322|yes
155 2017-03-10 16:38:52	0|BlueMatt|bsm1175322: you definitely want to download some extra blocks
156 2017-03-10 16:40:13	0|bsm1175322|The desirable false positive rate is still (constant)/(height) though, or it's still a linear algorithm...
157 2017-03-10 16:41:15	0|BlueMatt|bsm1175322: welcome to the real world, low-cost linear is perfectly ok :P
158 2017-03-10 16:42:12	0|BlueMatt|as long as batteries and lte improve faster than your linear increases, at least for as long as you're not using 2nd layer stuff, you should be fine :)
159 2017-03-10 16:42:44	0|bsm1175322|Only in the bitcoin world...it makes for a horrible user experience. :-P
160 2017-03-10 16:42:46	0|BlueMatt|(well, and data caps...fuck data caps)
161 2017-03-10 16:43:04	0|bsm1175322|I'll keep looking for logarithmic solutions :-P
162 2017-03-10 16:43:24	0|BlueMatt|10 seconds in a linear scan isnt all that much different from 10 seconds in a magical logarithmic scan, at least for users :P
163 2017-03-10 16:43:37	0|BlueMatt|I see your point, but I'm less worried
164 2017-03-10 16:43:50	0|BlueMatt|superlinear, well...lets not do that
165 2017-03-10 16:44:18	0|bsm1175322|Well...having been doing dev work on testnet for a few months...where it takes 30 minutes for bcoin to do an initial spv sync...
166 2017-03-10 16:45:01	0|BlueMatt|lol, ok, fair point
167 2017-03-10 16:45:16	0|BlueMatt|see previous comment about chunking header requests with new p2p messages
168 2017-03-10 16:45:19	0|BlueMatt|:)
169 2017-03-10 16:45:43	0|BlueMatt|its slow because we've been busy optimizing other things, should be easy to optimize, though
170 2017-03-10 16:47:27	0|bsm1175322|Yeah I'm going to have to look into that on bcoin.  For now we're beta testing on regtest so are avoiding the problem.
171 2017-03-10 17:40:02	0|bsm1175322|BlueMatt: FYI another idea that's floating in my head for improving SPV is whether we could use some form of https://en.wikipedia.org/wiki/Oblivious_transfer
172 2017-03-10 17:44:40	0|BlueMatt|bsm1175322: hmm, possibly useful to receive blocks after a high-fp-rate filter commitment or something? Maybe too high overhead, though, gmaxwell might have more to say
173 2017-03-10 17:45:10	0|bsm1175322|To be clear, I haven't figured out any algorithm that works and I'm not making a proposal...but I want to find a way...
174 2017-03-10 17:45:53	0|BlueMatt|heh, ok
175 2017-03-10 17:46:11	0|BlueMatt|the old "that sounds cool, we should use it somewhere" approach :)
176 2017-03-10 17:46:54	0|bsm1175322|exactly
177 2017-03-10 18:24:40	0|gmaxwell|.... there have been many concrete proposals before. the performance is bad though.
178 2017-03-10 18:32:34	0|bsm1175322|Yes...in order to be oblivous about which of N bytes are sent, you have to read/process all N bytes, for *each* request...
179 2017-03-10 18:32:54	0|bsm1175322|I'm still hoping there's a way around that observation...
180 2017-03-10 18:35:45	0|BlueMatt|uhh, that would be kinda obvious if you didnt....
181 2017-03-10 18:35:59	0|BlueMatt|"hey, i dont know what I'm sending you, but its one of A or B, and I never read B from my hdd......"
182 2017-03-10 18:36:37	0|bsm1175322|Insert some preprocessing/Merkle tree magic...
183 2017-03-10 18:38:24	0|BlueMatt|heh
184 2017-03-10 18:43:26	0|gmaxwell|bsm1175322: https://bitcointalk.org/index.php?topic=1762589.0
185 2017-03-10 19:56:48	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #9971: qa: Initialize log in TestManager (06master...06Mf1703-logFixup) 02https://github.com/bitcoin/bitcoin/pull/9971
186 2017-03-10 20:24:05	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #9972: Fix extended rpc tests broken by #9768 (06master...06test_logging_fixups) 02https://github.com/bitcoin/bitcoin/pull/9972
187 2017-03-10 20:40:14	0|gmaxwell|https://www.reddit.com/r/Bitcoin/comments/5yojyp/on_the_recent_bout_of_malleated_transactions/
188 2017-03-10 20:40:42	0|midnightmagic|\o/
189 2017-03-10 21:53:06	0|bitcoin-git|[13bitcoin] 15theuni opened pull request #9973: depends: fix zlib build on osx (06master...06fix-zlib-osx) 02https://github.com/bitcoin/bitcoin/pull/9973
190 2017-03-10 21:57:02	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #9974: Add basic Qt wallet test (06master...06pr/qt-test) 02https://github.com/bitcoin/bitcoin/pull/9974
191 2017-03-10 22:08:29	0|bitcoin-git|13bitcoin/06master 14d055bd6 15John Newbery: Fix extended rpc tests broken by 8910b4717e5bb946ee6988f7fe9fd461f53a5935
192 2017-03-10 22:08:29	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/8910b4717e5b...21833f9456f6
193 2017-03-10 22:08:30	0|bitcoin-git|13bitcoin/06master 1421833f9 15MarcoFalke: Merge #9972: Fix extended rpc tests broken by #9768...
194 2017-03-10 22:08:57	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9972: Fix extended rpc tests broken by #9768 (06master...06test_logging_fixups) 02https://github.com/bitcoin/bitcoin/pull/9972
195 2017-03-10 23:23:36	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9971: qa: Initialize log in TestManager (06master...06Mf1703-logFixup) 02https://github.com/bitcoin/bitcoin/pull/9971
196 2017-03-10 23:32:24	0|Telmo|Ola