1 2018-01-16 01:10:24	0|shaowei|hello guys
  2 2018-01-16 04:27:11	0|gmaxwell|sdaftuar: Do you have any idea if your collected transaction flux dataset has any sigops attacks in it?
  3 2018-01-16 04:28:13	0|gmaxwell|sdaftuar: I was thinking it would would be interesting to try some efficient approximations of multidimensional optimization. I have a fairly concrete idea of what I'd like to try.
  4 2018-01-16 04:47:00	0|jtimon|shouldn't https://github.com/bitcoin/bitcoin/pull/11426 have the refactoring label too ?
  5 2018-01-16 05:15:33	0|gmaxwell|sdaftuar: e.g. lowering the initial sigops lagrangian and having it increase only when the sigops limit is hit. ... though any change in it would require rescoring the whole mempool, I think that could be done infrequently.
  6 2018-01-16 06:26:33	0|echelon|is anyone working on adding support for boost-1.66.0
  7 2018-01-16 06:27:19	0|gmaxwell|echelon: what isn't compatible?
  8 2018-01-16 06:27:52	0|gmaxwell|We generally prefer to reduce boost dependency, so if there is any incompatiblity that can be resolved by removing boost stuff (and e.g. replacing with C++11 functionality), that would be good.
  9 2018-01-16 06:28:26	0|echelon|gmaxwell: i had the same errors as this guy.. https://gist.github.com/carlocapocasa/5f31ac2bd7c1ce3f09f4fc1474ad2cb3#file-gistfile1-txt-L287-L321
 10 2018-01-16 06:28:48	0|echelon|ah, good to know
 11 2018-01-16 06:32:42	0|sipa|echelon: wasn't that just fixed in master?
 12 2018-01-16 06:33:38	0|echelon|has it? i see that the ticket is still open
 13 2018-01-16 06:33:41	0|echelon|let me check
 14 2018-01-16 06:34:06	0|sipa|#11847
 15 2018-01-16 06:34:08	0|gribble|https://github.com/bitcoin/bitcoin/issues/11847 | Make boost::multi_index comparators const by sdaftuar · Pull Request #11847 · bitcoin/bitcoin · GitHub
 16 2018-01-16 06:34:50	0|echelon|ah ok, i guess this can be closed as well then https://github.com/bitcoin/bitcoin/issues/12116
 17 2018-01-16 06:34:55	0|sipa|and issue #11837 is closed. what other issue is there?
 18 2018-01-16 06:34:56	0|gribble|https://github.com/bitcoin/bitcoin/issues/11837 | CompareModifiedEntry::operator() not const · Issue #11837 · bitcoin/bitcoin · GitHub
 19 2018-01-16 06:35:00	0|gmaxwell|k, well muti-index we probably wouldn't fix by removing for now.
 20 2018-01-16 06:35:24	0|gmaxwell|echelon: have you tried building master?
 21 2018-01-16 06:35:45	0|echelon|doing a pull right now
 22 2018-01-16 06:36:13	0|gmaxwell|thanks
 23 2018-01-16 06:40:12	0|echelon|seems to have passed the miner.o compilation :)
 24 2018-01-16 06:44:01	0|sipa|echelon: thanks for pointing out 12116 was still open
 25 2018-01-16 06:44:11	0|echelon|anytime
 26 2018-01-16 07:09:19	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #12196: Add scantxoutset RPC method (06master...062017/12/utxo_sweep) 02https://github.com/bitcoin/bitcoin/pull/12196
 27 2018-01-16 07:11:00	0|echelon|all tests passed, and everything is running fine :)
 28 2018-01-16 07:13:31	0|sipa|good to hear
 29 2018-01-16 07:15:58	0|jonasschnelli|gmaxwell: https://github.com/bitcoin/bitcoin/pull/12196#issuecomment-357872742
 30 2018-01-16 07:16:07	0|jonasschnelli|What do you mean with " addresses for the pubkey part"?
 31 2018-01-16 07:17:00	0|gmaxwell|I would expect the argument you would supply would be addresses, exactly like importing for a watching wallet.  Not pubkeys.
 32 2018-01-16 07:17:25	0|gmaxwell|(I suppose a pubkey would be okay to accept in addition to addresses, but I'm not sure if anyone would use it)
 33 2018-01-16 07:18:09	0|jonasschnelli|Using addresses would mean, you would have to known what script types where used for the unspents you are looking for...
 34 2018-01-16 07:18:36	0|sipa|how would you not know?
 35 2018-01-16 07:18:47	0|gmaxwell|the address tells you the script type. Any address can be converted into a scriptpubkey, otherwise how could someone pay it?
 36 2018-01-16 07:19:12	0|gmaxwell|(also, with a bare pubkey you're left guessing at the script type)
 37 2018-01-16 07:20:13	0|sipa|maybe this is easier to discuss with explicit use cases in mind?
 38 2018-01-16 07:20:30	0|jonasschnelli|Yes... hard to give arguments against addresses,...
 39 2018-01-16 07:20:32	0|gmaxwell|The use case is in the linked PR.
 40 2018-01-16 07:20:45	0|jonasschnelli|my use case is that there are backups where only pubkey/privkeys are visible
 41 2018-01-16 07:21:01	0|jonasschnelli|But could also be addresses...
 42 2018-01-16 07:21:19	0|jonasschnelli|I though pubkeys and derive all common scipts makes it easier ...
 43 2018-01-16 07:21:45	0|gmaxwell|The only shortcomming of also supporting pubkeys is that pubkeys don't encode the script type; and we are trying to move away from the "use all the types" handling in the wallet in general.
 44 2018-01-16 07:21:47	0|sipa|well i think it's a bad situation we're in now that public keys explicitly don't have an associated script type
 45 2018-01-16 07:22:03	0|sipa|which simplifies things "they can be anything" in one way
 46 2018-01-16 07:22:11	0|jonasschnelli|Maybe both should work
 47 2018-01-16 07:22:44	0|sipa|unfortunately at this point we really need to treat xpubs as deriving all address types that currentpy exist
 48 2018-01-16 07:22:49	0|jonasschnelli|sipa: that's why you want to scan for all possible related funds...
 49 2018-01-16 07:22:56	0|gmaxwell|I would say that it's fine to also support pubkeys and do wildcard handling, but I'm a little concerned that it'll make it harder to rip out wildcard handling in general in the future.
 50 2018-01-16 07:23:16	0|gmaxwell|jonasschnelli: that has pretty poor scalablity long term as the number of possible types increases.
 51 2018-01-16 07:23:23	0|sipa|jonasschnelli: yeah, compatibiloty with how things are done now is a reason in favor
 52 2018-01-16 07:23:29	0|gmaxwell|at least for the general usage in the wallet, perhaps it's excusable in an import.
 53 2018-01-16 07:23:44	0|sipa|compatibiloty with how i hope thongs work in the future is an argument against
 54 2018-01-16 07:24:02	0|sipa|*some s/o/i/ where appropriate
 55 2018-01-16 07:24:07	0|jonasschnelli|I agree... but I guess the only point where we want that fallback-scan-for-everything is exactly the utxo-base-sweep (scan)
 56 2018-01-16 07:24:28	0|jonasschnelli|(or at least an option)
 57 2018-01-16 07:24:34	0|sipa|fair
 58 2018-01-16 07:24:36	0|sipa|i agree
 59 2018-01-16 07:24:46	0|jonasschnelli|I think supporting addresses and pubkeys makes most sense... will add
 60 2018-01-16 07:25:14	0|sipa|it's analogous to importpubkey and importprivkey
 61 2018-01-16 07:25:20	0|sipa|which also derive everything
 62 2018-01-16 07:25:29	0|jonasschnelli|Right
 63 2018-01-16 07:25:37	0|sipa|or at least all existing addresses
 64 2018-01-16 07:25:51	0|gmaxwell|I think for sweeps its probably fine.  Addresses should be the recommended input, if you have a choice, and they don't have that problem.  Later we can introduce a script type augmented xpub to cover that case too.
 65 2018-01-16 07:26:02	0|jonasschnelli|There is also a missing rpc call for a rawsweep... something that can calculate fees based on an array of unspents and a send-to-address
 66 2018-01-16 07:26:04	0|sipa|longer term i hope we have address-type-specific privkeys/xpubs (like electrum has)
 67 2018-01-16 07:26:29	0|gmaxwell|I think the behavior should be analogous to importaddress-- e.g. equal or a superset of what that can import.
 68 2018-01-16 07:26:54	0|gmaxwell|jonasschnelli: can fundrawtransaction do that already?
 69 2018-01-16 07:27:15	0|gmaxwell|without thinking too hard I think fundraw could be made to do that, without breaking compatibility with anything.
 70 2018-01-16 07:28:05	0|sipa|yes createraw + fun draw can donthat, but it's abit cumbersome
 71 2018-01-16 07:28:12	0|jonasschnelli|gmaxwell: I don't think so it can today... what you want is no change outputs, just the total - the required fee after the given confirmation target
 72 2018-01-16 07:28:12	0|sipa|*do that
 73 2018-01-16 07:28:28	0|gmaxwell|sipa: if the app is still unclear, consider e.g. sweeping spinoff coins without having to do a importaddress and wallet rescan on a spinoff node.
 74 2018-01-16 07:28:30	0|jonasschnelli|fund* is also the wrong term if you have all unspents
 75 2018-01-16 07:28:43	0|sipa|right
 76 2018-01-16 07:28:48	0|sipa|yes, makes sense
 77 2018-01-16 07:28:59	0|gmaxwell|jonasschnelli: well thats the change from payment amount behavior.
 78 2018-01-16 07:29:37	0|jonasschnelli|What would easy work is allowing an send-to-address in the utxo scan and spit out the recommended fee
 79 2018-01-16 07:29:49	0|jonasschnelli|(for the tx in the background and use the estimator)
 80 2018-01-16 07:29:55	0|jonasschnelli|but meh
 81 2018-01-16 07:30:03	0|gmaxwell|I suppose someone could then edit the tx if they want other behavior.
 82 2018-01-16 07:30:41	0|gmaxwell|ah, I see ... maybe this should wait for achow's PSBT support.
 83 2018-01-16 07:31:04	0|jonasschnelli|maybe the scantxout command should spit out (additionally) the raw tx for a sweep to a given address
 84 2018-01-16 07:31:05	0|gmaxwell|The best interface for this, I think, would be to output a raw transaction. But the problem with that is that it isn't an acceptable input for signrawtransaction.
 85 2018-01-16 07:31:26	0|gmaxwell|I suppose it could output BOTH a raw transaction and the argument for signrawtransaction.
 86 2018-01-16 07:31:41	0|jonasschnelli|Yes.
 87 2018-01-16 07:31:49	0|gmaxwell|But that problem is the primary motivation for PSBTs.
 88 2018-01-16 07:31:52	0|jonasschnelli|Though we would need xpriv support in signraw
 89 2018-01-16 07:31:57	0|gmaxwell|well one of the primary motivations.
 90 2018-01-16 07:31:58	0|jonasschnelli|(can be added at later stage=
 91 2018-01-16 07:33:13	0|gmaxwell|I like it outputting the raw transaction and signraw argument, though a PSBT would be even better.
 92 2018-01-16 07:33:57	0|gmaxwell|it could take a destition array, and if it's empty, then just leave off the destinations for further editing.
 93 2018-01-16 07:34:16	0|jonasschnelli|gmaxwell: I think it does already output the signraw arguments,.. the "unspents" array can be used for singraw (it contains the scriptPubKey)
 94 2018-01-16 07:34:27	0|gmaxwell|and support a feerate argument override for the estimator as some of the other rpcs do.
 95 2018-01-16 07:34:28	0|jonasschnelli|(but not the rawtx)
 96 2018-01-16 07:34:34	0|gmaxwell|I know.
 97 2018-01-16 07:34:51	0|jonasschnelli|gmaxwell: good point, feerate override would be great to have
 98 2018-01-16 07:36:00	0|gmaxwell|esp because estimator is dumb on recently started nodes... and I think for this a common use will be to start something, catch up to tip, and sweep...
 99 2018-01-16 07:36:44	0|jonasschnelli|Oh.... yes.
100 2018-01-16 07:37:00	0|jonasschnelli|I hope we have disabled the default fallbackfee for such cases...
101 2018-01-16 07:37:09	0|gmaxwell|listunspent has a modifier dictionary that it takes, which you might consider having. The obvious modification would be to ignore dust outputs.
102 2018-01-16 07:38:26	0|gmaxwell|(other modifier might be height<=x, which could _sometimes_ be used to create spinoff txn without the spinoff chain-- though that could be added later)
103 2018-01-16 07:38:53	0|jonasschnelli|Great ideas...
104 2018-01-16 07:39:34	0|gmaxwell|e.g. you have a signer that knows how to sign for SBTC, and you haven't spent any coins since the fork.. you could use a bitcoin node to create the sweep transactions...
105 2018-01-16 07:39:53	0|jonasschnelli|One downside of those utxo scans is: "real    8m38.318s"... they take relatively long,... 8m is on a very fast SSD machine
106 2018-01-16 07:40:36	0|gmaxwell|that is still a HELL of a lot better than a full wallet rescan.
107 2018-01-16 07:40:46	0|jonasschnelli|indeed...
108 2018-01-16 07:41:09	0|jonasschnelli|Also,... pruned peers
109 2018-01-16 07:41:49	0|gmaxwell|8m still seems like a long time, our poor poor utxo set.
110 2018-01-16 07:42:04	0|gmaxwell|oh I assume you flush first, perhaps some of that was flush time?
111 2018-01-16 07:42:20	0|gmaxwell|which can take a long time if your dbcache is gigantic.
112 2018-01-16 07:43:04	0|gmaxwell|hm. I seem to recall the gettxoutsetinfo taking ~2 minutes. :(
113 2018-01-16 07:43:05	0|jonasschnelli|gmaxwell: I removed the flush...
114 2018-01-16 07:43:29	0|gmaxwell|uh, but if you don't flush you won't return correct results?
115 2018-01-16 07:43:49	0|gmaxwell|flushing is needed to make the utxo set on disk consistent with the chaintip.
116 2018-01-16 07:44:07	0|sipa|unless you scan both the disk and memory explicitly
117 2018-01-16 07:44:42	0|gmaxwell|I suppose you can do that... scan disk, then memory to remove anything found but spent, and add anything added... seems complicated.
118 2018-01-16 07:44:43	0|jonasschnelli|I guess I should re-add that. :)
119 2018-01-16 07:45:11	0|sipa|i believe ryanofski has a PR to pet you scan through a view of the merged disk+cache
120 2018-01-16 07:45:23	0|sipa|*let
121 2018-01-16 07:45:40	0|jonasschnelli|8min is on a AMD Ryzen 7 1700X, 6Gb/s SSD (software raid though)
122 2018-01-16 07:46:43	0|echelon|gmaxwell: off-topic, but did you used to do ports for zipit?
123 2018-01-16 07:47:58	0|gmaxwell|echelon: I don't know what 'ports for zipit' would be, so presumably not. :)
124 2018-01-16 07:48:33	0|echelon|zipit z2, the handheld linux console thingy
125 2018-01-16 07:48:37	0|echelon|nevermind :)
126 2018-01-16 07:49:06	0|gmaxwell|nope! only handheld linux things I've done anything with are sharp zarus and openmoko.
127 2018-01-16 07:49:18	0|echelon|kk, gotcha
128 2018-01-16 07:49:46	0|gmaxwell|jonasschnelli: just as a sanity check, can you time a gettxoutsetinfo on the same host?
129 2018-01-16 07:50:15	0|jonasschnelli|gmaxwell: one sec
130 2018-01-16 07:50:19	0|gmaxwell|it might be that my cached memory of how long that takes is outdated or just wrong... but if not, there might be something to optimize in your code.
131 2018-01-16 07:50:27	0|jonasschnelli|Oh... it's --enable-debug
132 2018-01-16 07:50:48	0|sipa|jonasschnelli: don't do that when benchmarking :)
133 2018-01-16 07:51:05	0|jonasschnelli|I fall into this over and over again
134 2018-01-16 07:51:41	0|sipa|i'm happy sokeone is regularly running with debug enabled :)
135 2018-01-16 07:51:46	0|sipa|*someone
136 2018-01-16 07:52:06	0|gmaxwell|lol
137 2018-01-16 07:52:29	0|gmaxwell|whew, well I hope its faster without it.
138 2018-01-16 07:56:14	0|gmaxwell|not that 2m would be all that awesome either.
139 2018-01-16 08:03:23	0|jonasschnelli|real    9m38.249s (gettxoutsetinfo)
140 2018-01-16 08:03:32	0|jonasschnelli|now trying with no-debug
141 2018-01-16 08:04:22	0|jonasschnelli|oh... much faster
142 2018-01-16 08:04:52	0|gmaxwell|okay so under a minute
143 2018-01-16 08:04:57	0|jonasschnelli|UTXO scan: real    0m47.572s
144 2018-01-16 08:05:04	0|gmaxwell|whew
145 2018-01-16 08:06:02	0|gmaxwell|now to just figure out how to get future spinoffs to base themselves off 0.17 or whatever will have this feature. :P
146 2018-01-16 08:06:28	0|jonasschnelli|heh
147 2018-01-16 08:06:41	0|jonasschnelli|Funny... gettxoutsetinfo takes longer: 1m3.496s
148 2018-01-16 08:06:50	0|gmaxwell|thats because you removed the flush?
149 2018-01-16 08:07:06	0|jonasschnelli|I have readded but not pulled on that machine... true!
150 2018-01-16 08:07:13	0|gmaxwell|thats probably it.
151 2018-01-16 08:07:19	0|jonasschnelli|doublechecking...
152 2018-01-16 08:07:27	0|gmaxwell|well ettxoutsetinfo does hashing, so maybe not just that.
153 2018-01-16 08:07:37	0|jonasschnelli|Flush is there!
154 2018-01-16 08:07:46	0|gmaxwell|okay, probably the hashing then
155 2018-01-16 08:13:35	0|sipa|gettxoutsetinfo uses a lot mkre CPU as it's hashing everything too
156 2018-01-16 08:14:31	0|sipa|Europa
157 2018-01-16 08:15:02	0|sipa|hmm, rough estimate tells me the overhead of hashing the whole UTXO set shouldn't be more than a second
158 2018-01-16 08:19:57	0|gmaxwell|using bytes or compression function calls to estimate?
159 2018-01-16 08:28:37	0|gmaxwell|/query gmaxwell
160 2018-01-16 08:28:39	0|gmaxwell|oops
161 2018-01-16 08:29:01	0|gmaxwell|(yes, I talk to myself on IRC)
162 2018-01-16 08:29:43	0|sipa|gmaxwell: on a stream of several GB i'm sure that rounding up to the next multiple of 64 doesn't matter :)
163 2018-01-16 08:32:13	0|gmaxwell|well I guess the worst case overhead is only 2x for inputs longer than 32 bytes.
164 2018-01-16 08:42:19	0|gmaxwell|How'd you get into RWC btw?
165 2018-01-16 08:46:06	0|gmaxwell|nevermind.
166 2018-01-16 10:12:37	0|bitcoin-git|13bitcoin/06master 14e60cb99 15MeshCollider: Add a lock to the wallet directory
167 2018-01-16 10:12:37	0|bitcoin-git|[13bitcoin] 15laanwj pushed 6 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/bbc91b769973...66e3af709dd4
168 2018-01-16 10:12:38	0|bitcoin-git|13bitcoin/06master 1464226de 15MeshCollider: Generalise walletdir lock error message for correctness
169 2018-01-16 10:12:38	0|bitcoin-git|13bitcoin/06master 14c9ed4bd 15MeshCollider: Add a test for wallet directory locking
170 2018-01-16 10:13:14	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11904: Add a lock to the wallet directory (06master...06201712_walletdir_lock) 02https://github.com/bitcoin/bitcoin/pull/11904
171 2018-01-16 10:17:19	0|wumpus|jonasschnelli: I've also fallen into that trap a few times; maybe it'd make sense to make --enable-debug builds emit a warning in the log, as well as when running the benchmarks
172 2018-01-16 10:17:56	0|gmaxwell|maybe add an extra colum "DEBUG" after the timestamp in all log output?
173 2018-01-16 10:18:02	0|gmaxwell|or something like that.
174 2018-01-16 10:18:29	0|gmaxwell|though I bet jonas was doing time ./bitcoin-cli gettxoutsetinfo  :P
175 2018-01-16 10:18:36	0|wumpus|hehe that's very intrusive :)
176 2018-01-16 10:18:40	0|wumpus|on every log line
177 2018-01-16 10:19:12	0|gmaxwell|I dunno about you, though, if it only logged it at start I'd never notice. I've run the wrong binaries many times and missed the logged version numbers.
178 2018-01-16 10:19:14	0|wumpus|that veers into the domain of actively discouraging people to run debug builds
179 2018-01-16 10:19:21	0|gmaxwell|but fair enough.
180 2018-01-16 10:19:36	0|gmaxwell|it would be less intrusive if we already had a column there.
181 2018-01-16 10:19:42	0|wumpus|adding just a 'D' or so would be a compromise
182 2018-01-16 10:19:43	0|gmaxwell|like "bitcoin-mainnet"
183 2018-01-16 10:20:03	0|gmaxwell|or B for bitcoin mainnet... so at least your log parsing commands don't break.
184 2018-01-16 10:20:19	0|gmaxwell|ah interesting, we each thought it was intrusive for different reasons.
185 2018-01-16 10:20:35	0|wumpus|but in any case, logging it in some way is better than not logging it, even if it's just an adition to the version message, you can always check/correlate logs later
186 2018-01-16 10:20:54	0|gmaxwell|true. +1 for at least sticking it in the version string that gets logged.
187 2018-01-16 10:21:34	0|wumpus|I learned to always check the version message in the log painfully by bisecting kernels on embedded devices; it happens that the programming did go well, so I ended up testing the wrong kernel version, making me bisect 15 steps over again :p
188 2018-01-16 10:21:42	0|wumpus|did not*
189 2018-01-16 10:23:10	0|wumpus|yes it might also be intrusive for another reason (e.g. breaking log parsers)
190 2018-01-16 10:51:40	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #12197: Log debug build status and warn when running benchmarks (06master...062018_01_debug_in_log) 02https://github.com/bitcoin/bitcoin/pull/12197
191 2018-01-16 11:40:51	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #12198: rpc: Add deprecation error for `getinfo` (06master...062018_01_getinfo_deprecation_message) 02https://github.com/bitcoin/bitcoin/pull/12198
192 2018-01-16 12:12:19	0|provoostenator|Functional test suite passes on my machine a lot more often these days, so kudos to whoever improved things.
193 2018-01-16 12:12:54	0|provoostenator|Now I just need to find out how to prevent those dozen firewall permission popups on OSX after each recompile.
194 2018-01-16 12:22:42	0|wumpus|you get firewall permission popups for localhost?
195 2018-01-16 12:30:52	0|aj|wumpus: for #11774, i figure it makes sense to wait until #12101 and #12119 (and any other 0.16 PRs modifying tests?) get merged... should i rebase it so github is happy, or does merging it via git directly work okay?
196 2018-01-16 12:30:54	0|gribble|https://github.com/bitcoin/bitcoin/issues/11774 | [WIP] [tests] Rename functional tests by ajtowns · Pull Request #11774 · bitcoin/bitcoin · GitHub
197 2018-01-16 12:30:56	0|gribble|https://github.com/bitcoin/bitcoin/issues/12101 | Clamp walletpassphrase timeout to 2^30 seconds and check its bounds by achow101 · Pull Request #12101 · bitcoin/bitcoin · GitHub
198 2018-01-16 12:30:58	0|gribble|https://github.com/bitcoin/bitcoin/issues/12119 | [wallet] use P2WPKH change output if any destination is P2WPKH or P2SH-P2WSH by Sjors · Pull Request #12119 · bitcoin/bitcoin · GitHub
199 2018-01-16 12:32:07	0|wumpus|aj: you'd need to rebase it just before merging, I guess
200 2018-01-16 12:32:22	0|wumpus|after the PRs you're waiting for go in, at least
201 2018-01-16 12:32:40	0|wumpus|rebasing *now* isn't worth it if you just have to do it again
202 2018-01-16 12:33:33	0|aj|wumpus: rebasing just means running "./fix_tests" :) (well, and eyeballing the patches, and checking the tests actually run)
203 2018-01-16 12:33:35	0|provoostenator|wumpus: it seems so, haven't investigated what exactly these functional test bitcoind nodes are asking permission for
204 2018-01-16 12:33:38	0|provoostenator|wumpus: shouldn't #11536 be in he high priority review list, given that #7729 can be based on it?
205 2018-01-16 12:33:41	0|gribble|https://github.com/bitcoin/bitcoin/issues/11536 | Rename account to label where appropriate by ryanofsky · Pull Request #11536 · bitcoin/bitcoin · GitHub
206 2018-01-16 12:33:44	0|gribble|https://github.com/bitcoin/bitcoin/issues/7729 | rpc: introduce label API for wallet by laanwj · Pull Request #7729 · bitcoin/bitcoin · GitHub
207 2018-01-16 12:34:24	0|provoostenator|aj: I don't mind doing a rebase, so don't wait for me
208 2018-01-16 12:34:26	0|wumpus|provoostenator: currently https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.16.0 is the high priority review list; the project didn't get updated last meeting
209 2018-01-16 12:34:38	0|wumpus|all focus is on getting 0.16.0 out
210 2018-01-16 12:36:31	0|wumpus|provoostenator: well all the tests can be run without any external network access, so rejecting them to do that shouldn't make a difference, just localhost counts
211 2018-01-16 12:37:15	0|gmaxwell|it might be due to spurrious dns lookups it doing something that looks like network access, I suppose.
212 2018-01-16 12:37:19	0|provoostenator|Right, but I'd rather not have to see that popup at all.
213 2018-01-16 12:37:27	0|gmaxwell|though we'd probably want to fix that if reasonably possible
214 2018-01-16 12:37:40	0|wumpus|gmaxwell: yep, it's fully possible that there is some 'leakage', there, but blocking it shouldn't affect the test results
215 2018-01-16 12:37:57	0|provoostenator|Let me try rejecting...
216 2018-01-16 12:38:20	0|provoostenator|I grew up with Windows as a kid, so I'm used to clicking Yes
217 2018-01-16 12:38:22	0|aj|oh, is https://github.com/bitcoin/bitcoin/issues/11782 (assertion failure in validation.cpp when you use a 0.15 regtest datadir with 0.16) worth fixing for 0.16?
218 2018-01-16 12:38:32	0|wumpus|I've never tried runnign the tests on host with only localhost network interface, that'd be kind of interesting (but I don't see why it wouldn't pass)
219 2018-01-16 12:38:43	0|gmaxwell|aj: uh, that sounds bad
220 2018-01-16 12:39:13	0|gmaxwell|oh right due to changing where segwit activated.
221 2018-01-16 12:39:15	0|aj|gmaxwell: 0.15's segwit activations is later than 0.16's, so erroring out is reasonable, assertion failure is just an unpleasant way of doing it
222 2018-01-16 12:39:34	0|gmaxwell|okay not bad... just ugly.
223 2018-01-16 12:39:57	0|aj|yeah
224 2018-01-16 12:42:42	0|wumpus|if it (for sure) only affects regtest it shouldn't block 0.16.0
225 2018-01-16 12:43:42	0|gmaxwell|A trivial deuglyfication could be to adjust the assert with a note about why it's triggering.
226 2018-01-16 12:44:06	0|wumpus|<wumpus> I've never tried runnign the tests on host with only localhost network interface, that'd be kind of interesting (but I don't see why it wouldn't pass) <- it's trivial to simulate that using linux netns, will try it
227 2018-01-16 12:44:10	0|gmaxwell|(via the string equality assert hack)
228 2018-01-16 12:45:04	0|wumpus|yes, that'd make sense
229 2018-01-16 13:01:51	0|wumpus|phew, both functional and unit tests pass with only loopback networking
230 2018-01-16 13:02:49	0|wumpus|theoretically, with the UNIX sockets patches it could work even without a loopback interface, but I'm not going to try that :)
231 2018-01-16 13:06:24	0|provoostenator|Tests seem to be fine if I deny permission. Still trying to see what triggers the permission popup. I assume it's related to what it tries to listen on.
232 2018-01-16 13:06:28	0|bitcoin-git|13bitcoin/06master 145f911c5 15mruddy: trivial: fix address_type help text of getnewaddress and getrawchangeaddress
233 2018-01-16 13:06:28	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/66e3af709dd4...cad504bf4c30
234 2018-01-16 13:06:29	0|bitcoin-git|13bitcoin/06master 14cad504b 15MarcoFalke: Merge #12177: trivial: fix address_type help text of getnewaddress and getrawchangeaddress...
235 2018-01-16 13:07:14	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #12177: trivial: fix address_type help text of getnewaddress and getrawchangeaddress (06master...06trivial1) 02https://github.com/bitcoin/bitcoin/pull/12177
236 2018-01-16 13:19:17	0|provoostenator|OSX remembers the answer to the popup question until you recompile bitcoind with some change (whitespace is enough). src/bitcoind -regtest is enough to trigger it. -listen=0 prevents it
237 2018-01-16 13:21:00	0|provoostenator|-bind=127.0.0.1 also prevents the popup
238 2018-01-16 13:25:30	0|wumpus|right, it probably remembers the hash of the executable. Which is cleverer than some windows 'firewall' software I've encountered which just looks at the name of a program...
239 2018-01-16 13:25:54	0|wumpus|provoostenator: binding to 127.0.0.1 would make sense for the functional test suite
240 2018-01-16 13:25:56	0|provoostenator|Adding -bind=127.0.0.1 to each test node in address_types.py make the popup go away while tests still pass, so that's probably the solution.
241 2018-01-16 13:26:25	0|wumpus|there is no need for the tests to blnd globally, it could even be somewhat of a security risk
242 2018-01-16 13:26:37	0|gmaxwell|I was about to say the same thing (security risk)
243 2018-01-16 13:26:54	0|provoostenator|wumpus: not sure if it's just the hash. Adding whitespace, recompiling and then removing whitespace and recompiling also triggers the popup. But deleting the executable and then running make again doesn't.
244 2018-01-16 13:27:40	0|gmaxwell|like if some future change/mistake resulted in setting static rpc credentials in some test, and enabling remote connections... then someone could, if not worse, at least clobber files you can write to with wallet backups and dumps.
245 2018-01-16 13:28:48	0|gmaxwell|provoostenator: timestamp is pretty cheap to include in a hash... or maybe OSX has some kind of privledged capabilities for executables.
246 2018-01-16 13:29:41	0|gmaxwell|would be pretty useful for AV/backups to be able to set a flag on a file that only the setting program can access, that gets nuked if the file is modified.
247 2018-01-16 14:07:21	0|bitcoin-git|[13bitcoin] 15Sjors opened pull request #12200: Bind functional test nodes to 127.0.0.1 (06master...06test-framework-bind) 02https://github.com/bitcoin/bitcoin/pull/12200
248 2018-01-16 15:57:01	0|hehe|hello
249 2018-01-16 15:58:20	0|hehe|can i ask bout wallet service that i develop from bitcore?
250 2018-01-16 15:58:41	0|hehe|#bitcoin
251 2018-01-16 18:57:53	0|bitcoin-git|[13bitcoin] 15morcos opened pull request #12204: Fix overly eager BIP30 bypass (06master...06bip30bypassfix) 02https://github.com/bitcoin/bitcoin/pull/12204
252 2018-01-16 18:57:55	0|morcos|oops
253 2018-01-16 19:00:30	0|echeveria|was slightly worried until I realised how far we are from block height 1.9M.
254 2018-01-16 19:04:20	0|rabidus|you can continue breathing
255 2018-01-16 19:33:34	0|games_|echeveria: what's the difference between block size and block height?
256 2018-01-16 19:33:48	0|games_|(if this is the wrong place to ask, sorry)
257 2018-01-16 19:34:02	0|echeveria|what's the difference between a tomato and a cucumber?
258 2018-01-16 19:35:12	0|Randolf|games_:  This might be helpful to you:  https://bitcoin.org/en/glossary/block-height
259 2018-01-16 19:36:14	0|Randolf|games_:  And this:  https://en.bitcoin.it/wiki/Scalability_FAQ
260 2018-01-16 19:39:43	0|instagibbs|games_, #bitcoin please
261 2018-01-16 20:44:24	0|games_|instagibbs, Randolf: thanks
262 2018-01-16 22:21:07	0|dx25_|With my update to boost 1.66.0-1, I'm getting this really hard-to-understand (for me) compile error.  i guess something should be const that isn't?
263 2018-01-16 22:21:09	0|dx25_|https://pastebin.com/DQr2t7ss
264 2018-01-16 22:21:28	0|dx25_|compiling latest commit in master
265 2018-01-16 22:25:42	0|echelon|dx25_: what version of boost do you have installed?
266 2018-01-16 22:26:27	0|dx25_|1.66.0-1.  If i downgrade to previous version it compiles ok.
267 2018-01-16 22:27:36	0|echelon|1.66.0-1 doesn't seem to be a release verrsion
268 2018-01-16 22:27:45	0|echelon|is that something from your distro?
269 2018-01-16 22:28:01	0|dx25_|maybe so
270 2018-01-16 22:28:03	0|dx25_|antergos
271 2018-01-16 22:28:19	0|dx25_|which i thought was just arch but maybe not
272 2018-01-16 22:28:50	0|echelon|yeah, you should find out what they patched up in boost
273 2018-01-16 22:29:38	0|echelon|because i'm running 1.66.0, without any changes made by my distro maintainers, and it compiles cleanly
274 2018-01-16 22:31:24	0|dx25_|looks like they did some weird patchups to their bitcoin package too, the version number there is 0.15.1-4
275 2018-01-16 22:32:18	0|echelon|maybe you should let them know about the fix and have them just use the patch from master
276 2018-01-16 22:34:20	0|dx25_|this seems to be the official archlinux packages from "extra".  i'm going to get their package sources and see what they changed.
277 2018-01-16 22:35:32	0|dx25_|https://git.archlinux.org/svntogit/community.git/tree/trunk/0001-Make-boost-multi_index-comparators-const.patch?h=packages/bitcoin
278 2018-01-16 22:36:51	0|dx25_|seems like this change ought to get merged into core?
279 2018-01-16 22:48:11	0|sipa|dx25_: it already is
280 2018-01-16 22:48:22	0|sipa|(in master, not in a release)
281 2018-01-16 22:55:18	0|dx25_|oh, thought i git fetched, maybe not.
282 2018-01-16 23:00:00	0|ossifrage|I wonder why this fails: bitcoin-cli getblock $(bitcoin-cli getblockchaininfo | jq .bestblockhash)
283 2018-01-16 23:01:06	0|ossifrage|Stupid extra quotes, doh