1 2016-08-26 00:47:40	0|phantomcircuit|luke-jr, im looking at the wallet accounting tests (which afaict you wrote)
  2 2016-08-26 00:47:52	0|phantomcircuit|im confused by things like vpwtx[0]->nTimeReceived = (unsigned int)1333333335;
  3 2016-08-26 00:48:12	0|phantomcircuit|it seems like the unit test is mucking around with the internals of the wallet?
  4 2016-08-26 01:25:00	0|GitHub143|[13bitcoin] 15rebroad opened pull request #8595: [Wallet] Ensure <0.13 clients can't open HD wallets (06master...062016/07/hd_minversion) 02https://github.com/bitcoin/bitcoin/pull/8595
  5 2016-08-26 01:28:47	0|luke-jr|phantomcircuit: could be
  6 2016-08-26 01:54:19	0|kanzure|16:54 < saurik> so, I just spent a bunch of time making certain I didn't miss anything via IRC, and I've also checked e-mail. were they intending to tell me anything? I am kind of in shock that of all projects, bitcoin, another open source project, is now continuing the pattern of "we found something mysterious that we fixed that we don't bother mentioning directly to upstream"
  7 2016-08-26 01:54:25	0|kanzure|18:53 < kanzure> saurik: bitcoin core just a bunch of people hanging out on irc doing stuff. so i pinged you about it.
  8 2016-08-26 01:54:50	0|kanzure|i mean.. i don't expect how else to inform upstream other than sending messages :P.
  9 2016-08-26 01:55:40	0|gmaxwell|mindrays.
 10 2016-08-26 01:56:10	0|kanzure|shh don't tell them about my mind rays
 11 2016-08-26 01:57:47	0|midnightmagic|i thought they were my mindrays
 12 2016-08-26 01:57:54	0|midnightmagic|D-:
 13 2016-08-26 01:58:05	0|Squidicuz|woah.. full frontal lobotomy button, and now mindrays?!
 14 2016-08-26 02:02:38	0|midnightmagic|we are.. groot?
 15 2016-08-26 02:05:05	0|phantomcircuit|kanzure, what's he even talking about?
 16 2016-08-26 02:05:27	0|kanzure|don't speak so ill of the lobotomy</nobel prize committee>
 17 2016-08-26 02:05:38	0|kanzure|(actually i'm joking. no idea why that got the nobel prize.)
 18 2016-08-26 02:05:43	0|kanzure|phantomcircuit: osx code signing O_o
 19 2016-08-26 02:06:04	0|phantomcircuit|kanzure, you see you should have connected to his personal irc server
 20 2016-08-26 02:06:27	0|kanzure|actually you're right, there really is an irc.saurik.com
 21 2016-08-26 02:07:08	0|midnightmagic|:-o
 22 2016-08-26 02:12:07	0|luke-jr|kanzure: a pull request? :P
 23 2016-08-26 02:13:30	0|cfields_|kanzure: i fully intended to upstream it
 24 2016-08-26 02:13:51	0|cfields_|kanzure: what channel? I'll ping him to discuss
 25 2016-08-26 02:16:29	0|midnightmagic|I dunno if he really knows what it means to invite rando bitcoiners in to his IRC. :(
 26 2016-08-26 02:19:32	0|dcousens|is there any way to turn off pretty-printing in the bitcoind RPC JSON?
 27 2016-08-26 02:19:50	0|kanzure|cfields_: pm
 28 2016-08-26 02:20:08	0|cfields_|thanks
 29 2016-08-26 02:20:29	0|kanzure|cfields_: btw i don't think it's urgent; i just found his response funny :).
 30 2016-08-26 02:21:39	0|cfields_|kanzure: sure, i'd just like him to understand that I planned to PR it, but it's just a bunch of hard-coded hacks still
 31 2016-08-26 02:23:54	0|phantomcircuit|dcousens, ?
 32 2016-08-26 02:25:15	0|GitHub198|[13bitcoin] 15rebroad opened pull request #8596: Feeler code and debugging. (06master...06FeelerFixes) 02https://github.com/bitcoin/bitcoin/pull/8596
 33 2016-08-26 02:31:55	0|dcousens|phantomcircuit: nevermind, its just bitcoin-cli being smart :)
 34 2016-08-26 03:10:11	0|phantomcircuit|dcousens, yeah i think univalue always produces a single line
 35 2016-08-26 03:10:44	0|dcousens|phantomcircuit: yup, my bad, went into tcpdump and yeah its not pretty printed over the wire which is all I cared about
 36 2016-08-26 03:17:48	0|phantomcircuit|dcousens, as someone who is very guilty of this
 37 2016-08-26 03:17:55	0|phantomcircuit|i usually fine that if something looks dumb it is not
 38 2016-08-26 03:18:04	0|phantomcircuit|except when it is
 39 2016-08-26 03:19:00	0|dcousens|phantomcircuit: haha, yup.  I need to put the rubber duck back on my desk,  it usually gets most of my stupid questions before I branch out haha
 40 2016-08-26 03:36:02	0|phantomcircuit|luke-jr, indeed i think the unit tests are broken
 41 2016-08-26 03:36:13	0|phantomcircuit|or rather are testing the behaviour too specifically
 42 2016-08-26 03:37:08	0|luke-jr|"too specifically" is often subjective. ☺
 43 2016-08-26 03:39:45	0|gmaxwell|not really, ideally a test fails when the software is broken and only fails in those cases, passes when the software is not broken and only passes in those cases.
 44 2016-08-26 03:40:06	0|gmaxwell|this is an objective standard you can judge a test against, even if its not usually achievable for most functions.
 45 2016-08-26 03:43:03	0|gmaxwell|it can be useful, at times, to have test functions which define 'broken' as 'changes in any way at all'; but thats special and not usually a good requirement for tests; especially for functions which you intend to actually change.
 46 2016-08-26 03:55:51	0|phantomcircuit|luke-jr, can you explain why it's testing wtx nTimeReceived ?
 47 2016-08-26 03:57:56	0|luke-jr|gmaxwell: IMO there's a grey area smart times fall into. you don't care about the exact behaviour or even exact results per se, but you probably do need to test for exact results to know the results are sane.
 48 2016-08-26 03:58:50	0|luke-jr|phantomcircuit: what file/module is this?
 49 2016-08-26 03:59:12	0|gmaxwell|luke-jr: if you can't define "sane" better than "same as before" -- can anyone really know if the code is right or not? :P
 50 2016-08-26 03:59:17	0|phantomcircuit|luke-jr, src/wallet/test/accounting_tests.cpp
 51 2016-08-26 03:59:20	0|gmaxwell|(and could it ever be updated?)
 52 2016-08-26 04:00:15	0|gmaxwell|I don't think it's necessarily bad to have tests that do nothing but tell you if something changed, but if thats all we have, then we don't really have tests that are useful for anything except maybe refactoring.
 53 2016-08-26 04:00:24	0|luke-jr|gmaxwell: for example, some payment protocol could possibly provide better time estimate to a user that was offline at the time
 54 2016-08-26 04:00:51	0|gmaxwell|Consider, you intentionally change a function.  Exact behavior tests fail, well "no shit"-- but was your change correct or not? the 'test' gives you no insight-- it just told you something you already knew.
 55 2016-08-26 04:02:37	0|luke-jr|phantomcircuit: it's testing that nTimeReceived either does or doesn't influence the sorting order as it should[n't]
 56 2016-08-26 04:03:25	0|luke-jr|gmaxwell: in this case, it's creating CWalletTxs, adding them to the wallet, and checking the sort comes out correct
 57 2016-08-26 04:04:44	0|luke-jr|(I was wrong thinking it was doing smart fee stuff; it's sort order)
 58 2016-08-26 04:17:59	0|phantomcircuit|luke-jr, is there something that describes how the smart time stuff works?
 59 2016-08-26 04:20:08	0|luke-jr|phantomcircuit: not besides the code, AFAIK. essentially when a new transaction is seen, it uses the earlier of the block time or received/current time, unless that's before the time of the most recent known transaction (within reason)
 60 2016-08-26 04:20:23	0|luke-jr|if the most recent known transaction is newer, it won't go backward
 61 2016-08-26 04:20:31	0|luke-jr|unless it's significantly earlier, IIRC 15 minutes or so
 62 2016-08-26 04:56:54	0|phantomcircuit|luke-jr, so you're simulating the blocktime?
 63 2016-08-26 06:31:26	0|jonasschnelli|gmaxwell: Though about the idea of the BLOB (encrypted key) stored in the wallet and passed to the signer. Do you propose that signing operations will be done in a separate process (or application) by handing over the required tx data and the encrypted private key?
 64 2016-08-26 06:32:32	0|gmaxwell|Yes. And the signer program has you confirm the transaction, enter the passphrase, returns the result.
 65 2016-08-26 06:32:48	0|gmaxwell|and it can have 100% mlocked memory, be highly sandboxed, etc.
 66 2016-08-26 06:33:12	0|jonasschnelli|How do the encrypted private keys get there in the first place?
 67 2016-08-26 06:33:54	0|gmaxwell|It generates them and gives the blob to the wallet, like you were thinking with 'getnewaddress'... but there would be an 'init' or 'initwallet' call.
 68 2016-08-26 06:35:14	0|jonasschnelli|So the signing device creates the encrypted keys,... what the reason of passing them to the wallet instead of keeping track (storing) them in the signers space?
 69 2016-08-26 06:35:32	0|jonasschnelli|*whats
 70 2016-08-26 06:35:51	0|jonasschnelli|Ah. mlocked mem
 71 2016-08-26 06:35:54	0|gmaxwell|because then you have two files to backup for you wallet, and now the signer needs filesystem access.
 72 2016-08-26 06:37:21	0|jonasschnelli|gmaxwell: Yes. I think this would be a nice add-on. Would be nice if the transport layer would be flexible enough to also support hardware wallets.
 73 2016-08-26 06:37:35	0|jonasschnelli|Hardware wallet will probably not export encrypted private keys.
 74 2016-08-26 06:37:41	0|jonasschnelli|So the "blob" could be optional.
 75 2016-08-26 06:37:43	0|gmaxwell|Yes. Also third party co-signers... or at least extended to that eventually.
 76 2016-08-26 06:38:10	0|gmaxwell|yes, it would be optional, but-- I dunno, perhaps a reasonable way to construct a low cost hardware wallet-- why give it any flash? all rom. :)
 77 2016-08-26 06:38:27	0|jonasschnelli|IMO the main problem with co-signing is the missing infrastructure for the communication layer, how to pass partial-signed transaction to the co-signer, etc.
 78 2016-08-26 06:38:56	0|jonasschnelli|The problem with the blob storing encrypted keys is the backward and forward-security IMO
 79 2016-08-26 06:39:24	0|jonasschnelli|A leaked encryption password will result in compromising everything
 80 2016-08-26 06:40:08	0|GitHub61|[13bitcoin] 15rebroad opened pull request #8597: [WIP] Move code from VERACK to VERSION (since VERACK is not requied) (06master...06NotDependentOnVerack) 02https://github.com/bitcoin/bitcoin/pull/8597
 81 2016-08-26 06:40:14	0|jonasschnelli|I'd personally prefer only keeping pub-keys in my wallet and sign on a different system where the priv-keys are not exposed to many I/Os
 82 2016-08-26 06:56:39	0|luke-jr|phantomcircuit: I'm not sure - do smart fees even have tests?
 83 2016-08-26 06:56:46	0|luke-jr|smart times*
 84 2016-08-26 07:05:03	0|phantomcircuit|luke-jr, the accounting stuff appears to be th eonly thing testing them
 85 2016-08-26 07:05:07	0|phantomcircuit|and really it shouldn't be
 86 2016-08-26 07:05:24	0|phantomcircuit|it should at most be testing that they have the expected order
 87 2016-08-26 07:06:32	0|luke-jr|oh, the commit itself describes it: c3f95ef13f48d21db53992984976eac93e7a08fc
 88 2016-08-26 07:27:39	0|GitHub134|[13bitcoin] 15jonasschnelli closed pull request #8135: [OSX] fix make deploy when compiling on OSX (06master...062016/06/makedeploy) 02https://github.com/bitcoin/bitcoin/pull/8135
 89 2016-08-26 07:34:22	0|GitHub48|[13bitcoin] 15fivepiece opened pull request #8598: Fix displaying of invalid and non-minimal small pushes as numbers (06master...06fixasm) 02https://github.com/bitcoin/bitcoin/pull/8598
 90 2016-08-26 07:35:17	0|arubi|<- ^, if anyone has questions
 91 2016-08-26 07:37:53	0|jonasschnelli|arubi: just commented that some tests would be nice
 92 2016-08-26 07:38:04	0|arubi|yep.  I'll have a look!
 93 2016-08-26 07:38:09	0|jonasschnelli|thanks
 94 2016-08-26 07:44:34	0|GitHub164|[13bitcoin] 15laanwj closed pull request #8595: [Wallet] Ensure <0.13 clients can't open HD wallets (06master...062016/07/hd_minversion) 02https://github.com/bitcoin/bitcoin/pull/8595
 95 2016-08-26 07:50:18	0|jonasschnelli|I'd like to merge https://github.com/bitcoin/bitcoin/pull/8371 soon... thanks for reviews
 96 2016-08-26 08:00:12	0|jonasschnelli|sipa: Changing nCoinCacheUsage outside of the init process should be possible (assume covered under a LOCK)? What do you think in having two values, one for in-sync, one for catching up... maybe an additional -dbcacheinsync?
 97 2016-08-26 08:01:12	0|jonasschnelli|I guess sudden reduction of nCoinCacheUsage will just result in writing the state during the next FlushStateToDisk() while "overshooting" the new set target during the time until we do the next FlushStateToDisk()?
 98 2016-08-26 08:02:10	0|sipa|use an atomic instead of a lock
 99 2016-08-26 08:02:58	0|jonasschnelli|sipa: Indeed. What do you think about -dbcacheinsync?
100 2016-08-26 08:03:38	0|gmaxwell|I don't think I've ever seen a user report that would really be helped by that.
101 2016-08-26 08:03:41	0|jonasschnelli|Not sure if we should change nCoinDBCache and nBlockTreeDBCache during "runtime"
102 2016-08-26 08:03:59	0|gmaxwell|I think we'd be using a much larger dbcache except we want to work correctly on the common 2gb hosts and vpses.
103 2016-08-26 08:04:16	0|gmaxwell|and those hosts would crash during sync if it was bigger during sync.
104 2016-08-26 08:04:37	0|sipa|i actually would want a separate dbcache value in IBD on my phone :)
105 2016-08-26 08:04:40	0|gmaxwell|now-- allowing the dbcache to use memory the mempool isn't using-- that would be a useful stunt.
106 2016-08-26 08:04:51	0|GitHub129|13bitcoin/06master 14259ee09 15R E Broadley: Show "end" instead of many zeros when getheaders request received with a hashStop of Null.
107 2016-08-26 08:04:51	0|GitHub129|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/53f8f226bd1d...6c9f1b8c2405
108 2016-08-26 08:04:52	0|GitHub129|13bitcoin/06master 146c9f1b8 15Wladimir J. van der Laan: Merge #8561: Show "end" instead of many zeros when getheaders request received with a hashStop of Null...
109 2016-08-26 08:04:54	0|gmaxwell|but wouldn't need an option (hurray)
110 2016-08-26 08:05:05	0|GitHub110|[13bitcoin] 15laanwj closed pull request #8561: Show "end" instead of many zeros when getheaders request received with a hashStop of Null (06master...06LessGetheadersZeros) 02https://github.com/bitcoin/bitcoin/pull/8561
111 2016-08-26 08:05:25	0|jonasschnelli|I started adding a DBCache option during the intro screen on the GUI... And I think users don't want to "waste" 2GB (example) during in-sync state... but they may want 2GB during IBD.
112 2016-08-26 08:05:57	0|sipa|i think 2GB is not much anymore for most desktop systems
113 2016-08-26 08:06:10	0|sipa|but there are others
114 2016-08-26 08:06:21	0|gmaxwell|on systems where you're okay using that at ~any~ point, it's probably not a bad idea at all times. :(
115 2016-08-26 08:06:39	0|gmaxwell|keep in mind too small a dbcache is responsible for some of the io thrashing users frequently complain about.
116 2016-08-26 08:06:51	0|phantomcircuit|sipa, it would actually be nice to have a "stall" function for things which regularly overheat
117 2016-08-26 08:07:11	0|sipa|phantomcircuit: you shouldn't run a full node on hardware that overheats
118 2016-08-26 08:07:29	0|phantomcircuit|sipa, that covers virtually all phones and most laptops
119 2016-08-26 08:07:32	0|gmaxwell|sipa: that excludes about 75% of laptops available commercially now.
120 2016-08-26 08:07:41	0|jonasschnelli|;-)
121 2016-08-26 08:07:43	0|phantomcircuit|the thermal protection stuff isn't designed for continuous load
122 2016-08-26 08:07:51	0|sipa|heh
123 2016-08-26 08:08:09	0|gmaxwell|only a few makers actually build hardware that can stat sustained load. (your lenovo being such an example)
124 2016-08-26 08:08:17	0|gmaxwell|s/stat/stand/
125 2016-08-26 08:08:33	0|gmaxwell|though it doesn't crash when overheating.
126 2016-08-26 08:08:37	0|gmaxwell|mostly.
127 2016-08-26 08:08:45	0|phantomcircuit|gmaxwell, 10:1 his lenovo is not designed for continuous max load either
128 2016-08-26 08:08:59	0|gmaxwell|phantomcircuit: the t-series are.
129 2016-08-26 08:09:12	0|gmaxwell|the x1 isn't, as I'm sure you've noticed.
130 2016-08-26 08:09:13	0|sipa|i have a w540
131 2016-08-26 08:09:18	0|gmaxwell|sipa: those too.
132 2016-08-26 08:09:18	0|phantomcircuit|i have indeed
133 2016-08-26 08:09:33	0|phantomcircuit|the t series is not generally designed for max tdp actually
134 2016-08-26 08:09:36	0|phantomcircuit|they're more like 80%
135 2016-08-26 08:09:42	0|phantomcircuit|the x1 is maybe 50%
136 2016-08-26 08:09:49	0|phantomcircuit|a w450 probably is
137 2016-08-26 08:09:52	0|phantomcircuit|540
138 2016-08-26 08:09:53	0|phantomcircuit|whatever
139 2016-08-26 08:10:09	0|gmaxwell|in any case, what about the suggestion I made about dbcache using unused mempool space?
140 2016-08-26 08:10:22	0|gmaxwell|that basically matches the sync and cachup use case... and doesn't add parameters.
141 2016-08-26 08:10:23	0|sipa|ugh.
142 2016-08-26 08:10:37	0|phantomcircuit|gmaxwell, eh we should just fix this and have a unified "memory usage" thing
143 2016-08-26 08:10:41	0|gmaxwell|It's only stupidly hard, have courage.
144 2016-08-26 08:10:43	0|phantomcircuit|implement out own oom killer
145 2016-08-26 08:10:44	0|phantomcircuit|:P
146 2016-08-26 08:10:50	0|phantomcircuit|our
147 2016-08-26 08:10:56	0|sipa|now normal transaction relay can trigger utxo flushing
148 2016-08-26 08:11:05	0|sipa|actually, it already does
149 2016-08-26 08:11:22	0|gmaxwell|yea, well if the flushing were ... less dumb, that wouldn't be a big deal.
150 2016-08-26 08:12:36	0|gmaxwell|what I'm suggesting could be something kinda dumb, like, when the mempool goes over 10MB. take the 290 MB away from the dbcache, flushing once. and then go on with life.
151 2016-08-26 08:14:27	0|phantomcircuit|gmaxwell, i tried making it less dumb and broke one of the unit tests
152 2016-08-26 08:14:33	0|phantomcircuit|i dont think what i did was broken actually
153 2016-08-26 08:15:37	0|gmaxwell|one can analyize the blockchain history to evaluate candidate eviction policies.
154 2016-08-26 08:16:07	0|phantomcircuit|gmaxwell, yeah my eviction policy was random eviction
155 2016-08-26 08:16:12	0|phantomcircuit|but even that broke the tests
156 2016-08-26 08:16:14	0|phantomcircuit|so idk
157 2016-08-26 08:16:26	0|gmaxwell|you need to carefully handle dirty entries.
158 2016-08-26 08:20:27	0|gmaxwell|phantomcircuit: random eviction is probably pretty bad. I was thinking of taking age, total value, remaining txouts, then fitting a piecewise linear model to create an eviction score that gives the best hitrate when tested against the historical chain with some simulated cache size.
159 2016-08-26 08:29:18	0|jonasschnelli|sipa: regarding your profiles idea: https://github.com/bitcoin/bitcoin/issues/8437, how could setting profile values make sense? I guess in bitcoin.conf would be ideal (not another file), this would mean, it must be something like -profile0-par or -profile1-maxconnections, etc.
160 2016-08-26 08:29:20	0|phantomcircuit|gmaxwell, i just ignored dirty entries
161 2016-08-26 08:29:25	0|phantomcircuit|still broke the unit tests
162 2016-08-26 08:34:21	0|sipa|jonasschnelli: the profiles would just be hardcoded
163 2016-08-26 08:34:28	0|gmaxwell|considering the tests work fine if you twiddle the dbcache size, you screwed something up. Perhaps you were dropping things while views existed.
164 2016-08-26 08:34:48	0|sipa|the only option you have is selecting which profile to ude
165 2016-08-26 08:34:49	0|jonasschnelli|sipa: this seems not to scale,..
166 2016-08-26 08:34:56	0|sipa|how so?
167 2016-08-26 08:35:18	0|jonasschnelli|If it covers DBCache, we would need to adjust the static value over time
168 2016-08-26 08:35:31	0|sipa|why?
169 2016-08-26 08:36:01	0|sipa|it corresponds to the amount of resources it can use
170 2016-08-26 08:36:31	0|jonasschnelli|Lets say, we have a hardcoded profile "large", it could cover 2GB dbcache,.. in 3 years, the UTXO set is larger, computers have more RAM...
171 2016-08-26 08:36:47	0|sipa|ok, then we occasionally update the profole
172 2016-08-26 08:36:53	0|sipa|or add a "verylarge"
173 2016-08-26 08:36:58	0|jonasschnelli|heh
174 2016-08-26 08:37:15	0|sipa|allowing people to modify the profile seems to defeat the prupose
175 2016-08-26 08:37:16	0|jonasschnelli|Not sure if I like hardcoded values...
176 2016-08-26 08:37:29	0|sipa|why don't they just modify the settings directly?
177 2016-08-26 08:37:37	0|jonasschnelli|Whats the advantage over -profile0-dbcache (could still have hardcoded defaults)
178 2016-08-26 08:37:57	0|sipa|why would you have -profile0-dbcache, and not just... -dbcache ?
179 2016-08-26 08:38:08	0|sipa|if you're going to override it, override it
180 2016-08-26 08:38:13	0|jonasschnelli|Okay.. I see .. let me explain.
181 2016-08-26 08:38:23	0|jonasschnelli|I'd like to have switchable profile...
182 2016-08-26 08:38:51	0|jonasschnelli|Some users might want to run in blocksonly (or par=1) during a time when they want to use the system for different purposes
183 2016-08-26 08:39:04	0|jonasschnelli|Then, switch back to a different profile when their system is idling
184 2016-08-26 08:39:04	0|sipa|mobile phones used to have configurable profiles... for different times of the day, for special contants, ...
185 2016-08-26 08:39:16	0|sipa|nobody used those as they take way too much time to maintain
186 2016-08-26 08:39:28	0|gmaxwell|I feel like it's a mistake to optimize for users going in and twiddling detailed settings at runtime. Thats adding a feature less than 1% of users would use at all, and half of those who would use it would probably use it in confused ways.
187 2016-08-26 08:39:31	0|jonasschnelli|Yes. You could set your "low bandwith" profile to take affect during 23:00 - 06:00 or so
188 2016-08-26 08:39:46	0|sipa|and phones switched back to very simple things, like 3 preconfigured ones
189 2016-08-26 08:39:51	0|jonasschnelli|Remember when we had the PR for "pause network activity"
190 2016-08-26 08:40:16	0|jonasschnelli|I guess there are some users out there who like to change the resource consumption during runtime.
191 2016-08-26 08:40:23	0|sipa|the point of profiles is to allow people to have more control with fewer tweakable
192 2016-08-26 08:40:27	0|sipa|not mkre knobs
193 2016-08-26 08:40:44	0|sipa|ok, so make the profile switchable at runtime
194 2016-08-26 08:41:33	0|gmaxwell|jonasschnelli: yes, though often even that is someone trying to rationalize their suffering from something else we've screwed up.
195 2016-08-26 08:41:34	0|jonasschnelli|Yes. Switchable during runtime makes sense... but I don't understand why there should be no optional -profile0-par, default overwrite option
196 2016-08-26 08:42:09	0|gmaxwell|So for example, bandwidth bursts are distrubing their VoIP, so they ask for a pause. We can provide, but 1% of the users having the problem will find it and use it, the rest will suffer or just remove bitcoin.
197 2016-08-26 08:42:09	0|sipa|jonasschnelli: pfft we could add that, but i think it's a waste of time
198 2016-08-26 08:42:55	0|jonasschnelli|My goal is that people will not shut down bitcoin-qt in order to do a VoIP call (because restarting in pain in the ass).
199 2016-08-26 08:43:06	0|gmaxwell|time spent setting up and maintaining knobs for a tiny pool of highly advanced users would usually be better spent figuring out the root issues that drive them to have any reason to customize at all.
200 2016-08-26 08:43:28	0|jonasschnelli|Not sure if this feature would be for highly advanced users...
201 2016-08-26 08:43:43	0|jonasschnelli|It could be a "turtle icon" somewhere with a tooltip "use less resources"...
202 2016-08-26 08:43:44	0|gmaxwell|then we should fix it so that it doesn't screw up voip, _generally_, even when they don't know bitcoin is the cause, not by finding some obscure option.
203 2016-08-26 08:43:48	0|sipa|jonasschnelli: that's why we have compact blocks and not pause network :)
204 2016-08-26 08:44:23	0|gmaxwell|if you've figured out that bitcoin is the cause you are already more advanced than we should hope for, usually once they've figured that out bitcoin is doomed. :P
205 2016-08-26 08:44:40	0|jonasschnelli|Yes. But IMO is a fact that people have stopped running bitcoin-qt because of its extensive resource consumption. But maybe I'm wrong here.
206 2016-08-26 08:44:55	0|gmaxwell|I feel like you're not listening to me. :(
207 2016-08-26 08:45:40	0|jonasschnelli|I agree with fixing it in the first place... but some stuff is on a layer not controllable by our stack.. like QoS.
208 2016-08-26 08:45:50	0|gmaxwell|I agree that they have, but they will continue to stop running it unless the resource consumption is improved--  adding some advanced profile things will save a few users, but not that many.
209 2016-08-26 08:46:07	0|jonasschnelli|Partially agree on that.
210 2016-08-26 08:46:30	0|gmaxwell|and exposing many settings to users actually complicates improving resource management, since we have to figure out how to handle changing the sensible parameters.
211 2016-08-26 08:46:37	0|jonasschnelli|A non-dump dbcache option would be significant more worth then a dbcache profile option
212 2016-08-26 08:56:34	0|sipa|i don't think there is any problem with providing options to modify what the profiles correspond wth, and perhaps there is a good use for it... but having profiles in the first place is so much more valuable
213 2016-08-26 08:57:04	0|sipa|right now, almost no user modify dbcache, and even less know that there are half a dozen other settings that affect memory usage
214 2016-08-26 08:57:17	0|sipa|don't get carried away with configurability
215 2016-08-26 08:57:39	0|sipa|the problem we're facing is that most users don't even touch the few settings we do have, adding more won't improve that
216 2016-08-26 08:57:53	0|MarcoFalke|What about -maxtotalmem, and bitcoind will figure out how to use that  memory on it's own?
217 2016-08-26 08:57:53	0|phantomcircuit|gmaxwell, hmm maybe i was dropping things while a view existed?
218 2016-08-26 08:57:56	0|phantomcircuit|im not sure actually
219 2016-08-26 08:58:22	0|sipa|MarcoFalke: except we don't have good accounting for all of the memory yet
220 2016-08-26 08:58:30	0|jonasschnelli|Yes. Maybe in the GUI intro we can offer a switch between "low" (default), "moderate" (1GB cache,...) and "height" (3GB cache).
221 2016-08-26 08:58:48	0|sipa|MarcoFalke: and it is pretty hard to do due to memory fragmentation etc
222 2016-08-26 08:59:00	0|gmaxwell|consider, if _we_ knew how to set all these things, we'd set them and not bother writing and translating UI for them..  but if we don't know how to set them, the user almost certantly doesn't.
223 2016-08-26 08:59:22	0|sipa|jonasschnelli: yes, that's what i propose
224 2016-08-26 08:59:32	0|sipa|jonasschnelli: but it could affect a few more options than dbcache
225 2016-08-26 08:59:49	0|gmaxwell|MarcoFalke: ultimately thats what we should have, but it's hard. (and probably can't be done without changing to jemalloc, ... memory accounting was a big reason firefox changed to jemalloc, in fact)
226 2016-08-26 08:59:49	0|jonasschnelli|Okay. What happens if a user sets profile "hight" (3GiB) and has only 2GB wired ram?
227 2016-08-26 09:00:00	0|jonasschnelli|sipa: yes. more options..
228 2016-08-26 09:00:09	0|sipa|jonasschnelli: no, less options
229 2016-08-26 09:00:17	0|sipa|jonasschnelli: there is low, medium, and high
230 2016-08-26 09:00:28	0|jonasschnelli|yes. I meant more values that are affected by the profiles.
231 2016-08-26 09:00:36	0|jonasschnelli|-par, -maxuploadtarget, etc.
232 2016-08-26 09:00:37	0|sipa|and each corresponds to a preset oglf settings for mempool, dbcache, maxconnections, ...
233 2016-08-26 09:00:40	0|sipa|exactly
234 2016-08-26 09:00:54	0|sipa|we could do a quick test
235 2016-08-26 09:01:22	0|sipa|but i don't know if physical memory is portably detectable
236 2016-08-26 09:02:05	0|sipa|allocate a gilb and see how fast a random walk through it is? :)
237 2016-08-26 09:03:09	0|sipa|*gb
238 2016-08-26 09:03:22	0|gmaxwell|too bad container objects basically force runtime allocation. :(
239 2016-08-26 09:04:21	0|phantomcircuit|sipa, what are the assumptions CCoinsViewCache makes about it's contents?
240 2016-08-26 09:04:38	0|phantomcircuit|if something isn't marked dirty i assumed it could just be removed
241 2016-08-26 09:04:41	0|phantomcircuit|is this wrong?
242 2016-08-26 09:06:38	0|sipa|yes, unless there is another view on top
243 2016-08-26 09:06:50	0|sipa|in that case you are not allowed to modify it in any way
244 2016-08-26 09:15:54	0|jonasschnelli|Aborted
245 2016-08-26 09:15:54	0|jonasschnelli|grml... bitcoind: sync.cpp:125: void potential_deadlock_detected(const std::pair<void*, void*>&, const LockStack&, const LockStack&): Assertion `onlyMaybeDeadlock' failed.
246 2016-08-26 09:15:59	0|jonasschnelli|current master
247 2016-08-26 09:16:22	0|jonasschnelli|http://pastebin.com/YCVFK5KY
248 2016-08-26 09:17:05	0|jonasschnelli|Before I updated to current master, it was running for a couple of weeks,.. just updated an ran into the deadlock assertion
249 2016-08-26 09:17:23	0|sipa|jonasschnelli: open an issue so we don't forgrt
250 2016-08-26 09:17:36	0|jonasschnelli|ok
251 2016-08-26 09:21:04	0|GitHub123|13bitcoin/06master 144c3e2cb 15R E Broadley: Show XTHIN in GUI
252 2016-08-26 09:21:04	0|GitHub123|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/6c9f1b8c2405...c19f8a4a7795
253 2016-08-26 09:21:05	0|GitHub123|13bitcoin/06master 14c19f8a4 15Wladimir J. van der Laan: Merge #8583: Show XTHIN in GUI...
254 2016-08-26 09:21:14	0|GitHub63|[13bitcoin] 15laanwj closed pull request #8583: Show XTHIN in GUI (06master...06ShowXTHINinGUI) 02https://github.com/bitcoin/bitcoin/pull/8583
255 2016-08-26 09:21:15	0|jonasschnelli|sipa: maybe my fault.. I'm running https://github.com/bitcoin/bitcoin/pull/7685/files on top
256 2016-08-26 09:22:14	0|GitHub197|13bitcoin/06master 14fab5ecb 15MarcoFalke: [wallet] rpc: Drop misleading option
257 2016-08-26 09:22:14	0|GitHub197|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c19f8a4a7795...65837375d98b
258 2016-08-26 09:22:15	0|GitHub197|13bitcoin/06master 146583737 15Wladimir J. van der Laan: Merge #8581: [wallet] rpc: Drop misleading option...
259 2016-08-26 09:22:30	0|GitHub156|[13bitcoin] 15laanwj closed pull request #8581: [wallet] rpc: Drop misleading option (06master...06Mf1608-walletDropRpc) 02https://github.com/bitcoin/bitcoin/pull/8581
260 2016-08-26 09:33:41	0|GitHub65|[13bitcoin] 15MarcoFalke opened pull request #8600: [0.13.1]: Backport [wallet] rpc: Drop misleading option (060.13...06Mf1608-walletRpcDropBackport) 02https://github.com/bitcoin/bitcoin/pull/8600
261 2016-08-26 10:17:32	0|GitHub161|[13bitcoin] 15laanwj opened pull request #8601: Add option to opt into full-RBF when sending funds (rebase) (06master...062016_08_full_rbf_option) 02https://github.com/bitcoin/bitcoin/pull/8601
262 2016-08-26 10:17:51	0|GitHub138|[13bitcoin] 15laanwj closed pull request #7132: Add option to opt into full-RBF when sending funds (06master...062015-11-opt-into-full-rbf-option) 02https://github.com/bitcoin/bitcoin/pull/7132
263 2016-08-26 10:51:18	0|phantomcircuit|sipa, how can you tell if there's another view on top?
264 2016-08-26 10:51:21	0|phantomcircuit|also, why?
265 2016-08-26 10:57:53	0|sipa|phantomcircuit: uh.. i can't say for sure. i've swapped out the understanding that resulting in that code :)
266 2016-08-26 10:58:18	0|sipa|phantomcircuit: but there is an extensive random simulation test; if you can integrate your pruning into that, you're likely to find any errors
267 2016-08-26 10:58:36	0|sipa|as to knowing when there is another view on top... don't call it from connectblock or anything below
268 2016-08-26 11:01:22	0|phantomcircuit|sipa, hasModifier?
269 2016-08-26 11:02:31	0|sipa|no
270 2016-08-26 11:02:43	0|sipa|hasModifier is when there is a modifier :)
271 2016-08-26 11:03:05	0|sipa|which is a RAII object to have an automatic cleanup after modifying an entry
272 2016-08-26 11:03:55	0|sipa|still, these caches don't do any locking, so they're not safe to modify from multiple threads
273 2016-08-26 11:04:33	0|sipa|and if you're doing cleanup from the same thread as the modifications are happening, you'll know when there is another cache on top just by the place of the code
274 2016-08-26 11:24:38	0|GitHub41|13bitcoin/06master 14fa6dc9f 15MarcoFalke: Remove unused variables
275 2016-08-26 11:24:38	0|GitHub41|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/65837375d98b...12892dbb9fb6
276 2016-08-26 11:24:39	0|GitHub41|13bitcoin/06master 1412892db 15Wladimir J. van der Laan: Merge #8590: Remove unused variables...
277 2016-08-26 11:24:53	0|GitHub7|[13bitcoin] 15laanwj closed pull request #8590: Remove unused variables (06master...06Mf1608-unusedCode) 02https://github.com/bitcoin/bitcoin/pull/8590
278 2016-08-26 11:27:24	0|GitHub7|[13bitcoin] 15laanwj closed pull request #8600: [0.13.1]: Backport [wallet] rpc: Drop misleading option (060.13...06Mf1608-walletRpcDropBackport) 02https://github.com/bitcoin/bitcoin/pull/8600
279 2016-08-26 11:27:24	0|GitHub87|13bitcoin/060.13 14526d2b0 15MarcoFalke: [wallet] rpc: Drop misleading option...
280 2016-08-26 11:27:24	0|GitHub87|[13bitcoin] 15laanwj pushed 2 new commits to 060.13: 02https://github.com/bitcoin/bitcoin/compare/f2306fbe0142...122fdfdae915
281 2016-08-26 11:27:25	0|GitHub87|13bitcoin/060.13 14122fdfd 15Wladimir J. van der Laan: Merge #8600: [0.13.1]: Backport [wallet] rpc: Drop misleading option...
282 2016-08-26 11:36:12	0|phantomcircuit|sipa, i was trying to make the change in ccoinsviewcache so it's triggered whenever usage goes above the limit
283 2016-08-26 11:37:34	0|phantomcircuit|so it wouldn't know where it is
284 2016-08-26 11:38:13	0|phantomcircuit|i guess i could add something to the constructor to call down to the base view and increment a counter in each
285 2016-08-26 11:38:37	0|wumpus|btcdrak: do you have a plan for https://github.com/bitcoin/bitcoin/pull/7562?
286 2016-08-26 11:38:52	0|wumpus|I think it's still relevant?
287 2016-08-26 11:40:01	0|GitHub44|[13bitcoin] 15laanwj closed pull request #8227: tests: Re-enable RPC tests for Windows (06master...062016_05_win_reenable_rpc_tests) 02https://github.com/bitcoin/bitcoin/pull/8227
288 2016-08-26 11:42:03	0|GitHub56|[13bitcoin] 15fanquake opened pull request #8602: [trivial][doc] Mention ++i as preferred over i++ in dev notes (06master...06trvial-dev-notes) 02https://github.com/bitcoin/bitcoin/pull/8602
289 2016-08-26 11:47:55	0|sipa|can i haz ack on #8524 ?
290 2016-08-26 12:12:40	0|GitHub9|[13bitcoin] 15fanquake opened pull request #8603: [trivial][doc] Mention gpg --refresh-keys in release-process.md (06master...06release-process-refresh-keys) 02https://github.com/bitcoin/bitcoin/pull/8603
291 2016-08-26 13:00:04	0|phantomcircuit|sipa, ACK the number 8524 is excellent
292 2016-08-26 13:00:51	0|phantomcircuit|sipa, is that a picture of you in a ball pit?
293 2016-08-26 13:03:25	0|sipa|phantomcircuit: yes
294 2016-08-26 13:46:04	0|wumpus|heh, bitcoin can no longer be compiled with gcc 4.9.3 with OpenBSD's default max data segment limit of 1536MB
295 2016-08-26 13:46:15	0|wumpus|(main.cpp)
296 2016-08-26 13:46:55	0|sipa|FINALLY
297 2016-08-26 13:47:06	0|wumpus|yes, a milestone
298 2016-08-26 13:47:41	0|btcdrak|inb4 someone complains :)
299 2016-08-26 13:47:46	0|wumpus|pushing the lmits of modern compiler technology
300 2016-08-26 13:54:31	0|GitHub56|13bitcoin/06master 14c25083b 15fanquake: [trivial][doc] Mention gpg --refresh-keys in release-process.md
301 2016-08-26 13:54:31	0|GitHub56|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/12892dbb9fb6...fd37acaedab1
302 2016-08-26 13:54:32	0|GitHub56|13bitcoin/06master 14fd37aca 15Wladimir J. van der Laan: Merge #8603: [trivial][doc] Mention gpg --refresh-keys in release-process.md...
303 2016-08-26 13:54:46	0|GitHub169|[13bitcoin] 15laanwj closed pull request #8603: [trivial][doc] Mention gpg --refresh-keys in release-process.md (06master...06release-process-refresh-keys) 02https://github.com/bitcoin/bitcoin/pull/8603
304 2016-08-26 13:54:55	0|GitHub182|13bitcoin/06master 14ab53207 15fanquake: [trivial][doc] Mention ++i as preferred to i++ in dev notes
305 2016-08-26 13:54:55	0|GitHub182|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/fd37acaedab1...bb566761fbe1
306 2016-08-26 13:54:56	0|GitHub182|13bitcoin/06master 14bb56676 15Wladimir J. van der Laan: Merge #8602: [trivial][doc] Mention ++i as preferred over i++ in dev notes...
307 2016-08-26 13:55:06	0|GitHub114|[13bitcoin] 15laanwj closed pull request #8602: [trivial][doc] Mention ++i as preferred over i++ in dev notes (06master...06trvial-dev-notes) 02https://github.com/bitcoin/bitcoin/pull/8602
308 2016-08-26 13:55:36	0|GitHub183|[13bitcoin] 15laanwj closed pull request #8547: Update btcdrak key with new expiry dates (06master...06btcdrak-key) 02https://github.com/bitcoin/bitcoin/pull/8547
309 2016-08-26 13:59:11	0|sipa|wth?
310 2016-08-26 13:59:12	0|sipa|SyntaxError: Non-ASCII character '\xf0' in file /home/pw/git/bitcoin/qa/rpc-tests/test_framework/util.py on line 180, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details
311 2016-08-26 14:04:20	0|sipa|ah, i'm running with a python2 interpreter
312 2016-08-26 14:04:38	0|sipa|those are still pretty weird characters to appear in source code...
313 2016-08-26 14:04:53	0|cfields_|sipa: surely those chars are the least of your concerns, then? :)
314 2016-08-26 14:05:09	0|wumpus|only python3 is supported for the RPC tests
315 2016-08-26 14:05:40	0|sipa|yes, it works with python3
316 2016-08-26 14:05:40	0|wumpus|for python2 it was necessary to define the character set at the top, python3 defaults to UTF-8
317 2016-08-26 14:05:59	0|wumpus|(but yes, that's far from the only thing that prevents it from working in  2.x)
318 2016-08-26 14:06:15	0|sipa|still, i'm baffled why we have unicode character u+1f4bb in our source code...
319 2016-08-26 14:06:35	0|wumpus|probably to test RPC unicode support
320 2016-08-26 14:06:46	0|cfields_|\xf0 does look suspiciously like typo'd hex
321 2016-08-26 14:07:20	0|sipa|i doubt it: https://github.com/bitcoin/bitcoin/blob/master/qa/rpc-tests/test_framework/util.py#L170
322 2016-08-26 14:07:42	0|cfields_|oh, huh
323 2016-08-26 14:07:53	0|wumpus|that's to test that unicode characters work in username/password
324 2016-08-26 14:08:10	0|cfields_|https://github.com/bitcoin/bitcoin/commit/fad184550e1c507a897be59169f9c5dabce8d652
325 2016-08-26 14:08:11	0|sipa|ah
326 2016-08-26 14:10:24	0|wumpus|if those funny characters work, then Chinese Russian etc certainly will (as they are in lower unicode planes)
327 2016-08-26 14:12:34	0|cfields_|great. Soon every 13yr old's passwords will be filled with poop emojis, and we'll all have to account for that possibility.
328 2016-08-26 14:12:57	0|wumpus|yes :-)
329 2016-08-26 14:13:32	0|Chris_Stewart_5|lol
330 2016-08-26 14:14:11	0|sipa|true ☺
331 2016-08-26 14:20:02	0|kanzure|sipa: use "#encoding: utf8" at top of .py files for python2
332 2016-08-26 14:21:42	0|wumpus|better to just not use python2 anymore :)
333 2016-08-26 14:22:31	0|wumpus|but yes that works
334 2016-08-26 14:27:04	0|kanzure|if you want to enforce definitely not using python2, then using a more explicit method might be good
335 2016-08-26 14:27:54	0|kanzure|(import sys; sys.version_info.major)
336 2016-08-26 14:28:14	0|GitHub154|[13bitcoin] 15laanwj opened pull request #8604: build,doc: Update for 0.13.0+ and OpenBSD 5.9 (06master...062016_08_openbsd_update) 02https://github.com/bitcoin/bitcoin/pull/8604
337 2016-08-26 14:29:21	0|wumpus|I think there is a python version check in some scripts; though OTOH, most of them will probably error out on missing imports and other problems before they reach that
338 2016-08-26 15:06:33	0|phantomcircuit|sipa, i dont see why you cant remove things from a CCoinsCacheView (or whichever arrangement of words it is) which aren't dirty
339 2016-08-26 15:06:35	0|phantomcircuit|like
340 2016-08-26 15:06:39	0|phantomcircuit|logically that makes no sense
341 2016-08-26 15:08:30	0|sipa|ok, maybe i'm wrong
342 2016-08-26 15:09:43	0|phantomcircuit|you see now i am questioning my own sanity
343 2016-08-26 15:09:49	0|phantomcircuit|god damned caching problems!
344 2016-08-26 15:15:23	0|sipa|There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
345 2016-08-26 15:37:32	0|instagibbs|are there any good summaries/discussions for tx relay DoS prevention in Core?
346 2016-08-26 15:38:09	0|instagibbs|esp wrt when certain things are checked in sequence
347 2016-08-26 16:07:53	0|rinzes_|I am trying to find out how to remove bitcoin core completely
348 2016-08-26 16:08:03	0|rinzes_|windows 10
349 2016-08-26 16:09:03	0|helo|rinzes_: #bitcoin
350 2016-08-26 16:09:04	0|btcdrak|Control panel -> programs -> uninstall
351 2016-08-26 16:09:30	0|rinzes_|will that remove the database and everything
352 2016-08-26 16:13:47	0|GitHub107|13bitcoin/06master 14ff8d279 15Pavel Janík: Do not shadow member variables
353 2016-08-26 16:13:47	0|GitHub107|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/bb566761fbe1...9a0ed08b40b1
354 2016-08-26 16:13:48	0|GitHub107|13bitcoin/06master 149a0ed08 15Pieter Wuille: Merge #8109: Do not shadow member variables...
355 2016-08-26 16:13:52	0|GitHub43|[13bitcoin] 15sipa closed pull request #8109: Do not shadow member variables (06master...0620160527_shadow_httpserver) 02https://github.com/bitcoin/bitcoin/pull/8109
356 2016-08-26 17:18:34	0|GitHub8|13bitcoin/06master 14fa3d974 15MarcoFalke: [doc] Update git-subtree-check.sh README
357 2016-08-26 17:18:34	0|GitHub8|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/9a0ed08b40b1...c072b8fd95cd
358 2016-08-26 17:18:35	0|GitHub8|13bitcoin/06master 14c072b8f 15Pieter Wuille: Merge #8545: [doc] Update git-subtree-check.sh README...
359 2016-08-26 17:18:44	0|GitHub93|[13bitcoin] 15sipa closed pull request #8545: [doc] Update git-subtree-check.sh README (06master...06Mf1608-doc) 02https://github.com/bitcoin/bitcoin/pull/8545
360 2016-08-26 18:10:12	0|Lauda|Does the gitian build script from achow101 include everything now?
361 2016-08-26 18:13:25	0|sipa|i believe it does
362 2016-08-26 18:14:09	0|Lauda|I'll test now and post results then.
363 2016-08-26 18:14:11	0|Lauda|Thanks
364 2016-08-26 18:45:29	0|arubi|I pushed a few unit tests ( https://github.com/bitcoin/bitcoin/pull/8598/commits ) that triggered an error in a specific travis build ( https://travis-ci.org/bitcoin/bitcoin/builds/155297369 ), I'm trying to build that environment to try and debug it, and I'd appreciate input as to what should I be looking for.  I was pretty surprised that adding tests caused something like that
365 2016-08-26 18:47:31	0|arubi|specifically, it failed at: "Assertion failed: 449.99100000 != 999.980" when running 'qa/rpc-tests/segwit.py'
366 2016-08-26 18:48:32	0|sipa|we've been seeing that test fail for a while
367 2016-08-26 18:48:57	0|arubi|oh, so it might be that re-running it will pass then?
368 2016-08-26 18:51:04	0|arubi|sipa, er, maybe I misunderstood.  it fails consistently?  I see other builds pass, and my previous pr passed
369 2016-08-26 18:53:14	0|sipa|no, just occasionally
370 2016-08-26 18:54:11	0|arubi|mhm.  well, the PR is ready then, if anyone finds it useful :)
371 2016-08-26 18:57:23	0|sipa|great; will review in mmore detail
372 2016-08-26 18:57:39	0|arubi|thanks!
373 2016-08-26 19:09:21	0|GitHub103|[13bitcoin] 15sipa opened pull request #8606: Fix some locks (06master...06lockfix) 02https://github.com/bitcoin/bitcoin/pull/8606
374 2016-08-26 19:10:01	0|GitHub127|[13bitcoin] 15MarcoFalke opened pull request #8607: [doc] Fix doxygen off-by-one comments, fix typos (06master...06Mf1608-trivial17) 02https://github.com/bitcoin/bitcoin/pull/8607
375 2016-08-26 19:15:49	0|sipa|arubi: https://github.com/bitcoin/bitcoin/issues/8532
376 2016-08-26 19:21:44	0|arubi|sipa, I see, so this is some timing issue then?
377 2016-08-26 19:23:27	0|arubi|I see tests passed now, phew :)
378 2016-08-26 19:55:38	0|btcdrak|sipa: do you have any idea why changing the default transaction version to 2 would break these tests? https://gist.github.com/btcdrak/7aeeccf8b487d6058ab87e1d3fcf6c62
379 2016-08-26 20:23:26	0|MarcoFalke|ugh
380 2016-08-26 20:23:46	0|MarcoFalke|seeing segfaults while testing the stalling issue
381 2016-08-26 20:24:26	0|sipa|can you run from gdb and inspect?
382 2016-08-26 20:24:54	0|MarcoFalke|Would that work with trickle?
383 2016-08-26 20:25:02	0|sipa|what is trickle?
384 2016-08-26 20:25:22	0|sipa|ah, bandwidth manager
385 2016-08-26 20:25:36	0|MarcoFalke|Jup, I need to simulate my "rural bandwith"
386 2016-08-26 20:25:43	0|sipa|yes, you can run bitcoind normally, and then gdb bitcoind -p <pid>
387 2016-08-26 20:25:54	0|MarcoFalke|ok
388 2016-08-26 20:25:56	0|sipa|to attach to the existing process
389 2016-08-26 20:26:19	0|sipa|when it segfaults, type 'bt' to see a backtrace
390 2016-08-26 20:38:30	0|gmaxwell|::sigh:: "BU" ripped out the outbound connection limiting logic, so we can probably expect more ignorant users connecting to the whole darn network.
391 2016-08-26 20:44:36	0|luke-jr|:|
392 2016-08-26 20:45:30	0|gmaxwell|I'd try to encourage them to not do this, but they're so antagonistic towards me that I'm sure trying would just make them double down.
393 2016-08-26 21:25:36	0|MarcoFalke|sipa: Well, the trace does not look helpful? http://pastebin.ubuntu.com/23095029/
394 2016-08-26 21:26:13	0|sipa|MarcoFalke: try 'thread apply all bt'
395 2016-08-26 21:28:27	0|MarcoFalke|http://pastebin.ubuntu.com/23095049/
396 2016-08-26 21:28:32	0|MarcoFalke|sipa: ^
397 2016-08-26 21:29:44	0|sipa|MarcoFalke: that looks like a segfault inside trickle...
398 2016-08-26 21:30:49	0|MarcoFalke|Ok, will try without trickle during the weekend
399 2016-08-26 21:36:25	0|murch|sipa: I assume the P2WPKH is then 4 bytes/4 larger as well?
400 2016-08-26 21:37:57	0|sipa|murch: presumably
401 2016-08-26 21:38:22	0|murch|The sequence number is part of the discounted section, right?
402 2016-08-26 21:39:33	0|sipa|no
403 2016-08-26 21:40:08	0|sipa|since it is in non-witness inputs as well, it can't be discounted
404 2016-08-26 21:45:35	0|luke-jr|hm, looks like AMD may beat Intel to SHA instructions
405 2016-08-26 21:46:02	0|sipa|intel already has sha instructions?
406 2016-08-26 21:46:09	0|luke-jr|sipa: not in any desktop CPU, AFAIK
407 2016-08-26 21:47:30	0|Lauda|http://i.imgur.com/jEid47S.png Does anyone have any ideas how to mitigate this?
408 2016-08-26 21:47:44	0|Lauda|Seems an Upstart error is present in Ubuntu 14.0.4 and 15.10 in a VM.
409 2016-08-26 23:07:29	0|murch|sipa: thanks
410 2016-08-26 23:36:07	0|gmaxwell|on PR #8606 did jonasschnelli find this before 0.13 was released and then we forgot it, or is this a new instance of a lock order inversion around cs_filter?