12016-08-26T00:20:34  *** [Author] has quit IRC
  22016-08-26T00:32:21  *** belcher has quit IRC
  32016-08-26T00:32:30  *** Giszmo has quit IRC
  42016-08-26T00:33:40  *** Giszmo has joined #bitcoin-core-dev
  52016-08-26T00:47:40  <phantomcircuit> luke-jr, im looking at the wallet accounting tests (which afaict you wrote)
  62016-08-26T00:47:52  <phantomcircuit> im confused by things like vpwtx[0]->nTimeReceived = (unsigned int)1333333335;
  72016-08-26T00:48:11  <phantomcircuit> it seems like the unit test is mucking around with the internals of the wallet?
  82016-08-26T00:51:47  *** spudowiar has quit IRC
  92016-08-26T00:52:40  *** justanotheruser has quit IRC
 102016-08-26T00:53:19  *** justanotheruser has joined #bitcoin-core-dev
 112016-08-26T00:57:49  *** [Author] has joined #bitcoin-core-dev
 122016-08-26T01:08:43  *** arowser has joined #bitcoin-core-dev
 132016-08-26T01:21:04  *** achow101 has quit IRC
 142016-08-26T01:25:00  <GitHub143> [bitcoin] rebroad opened pull request #8595: [Wallet] Ensure <0.13 clients can't open HD wallets (master...2016/07/hd_minversion) https://github.com/bitcoin/bitcoin/pull/8595
 152016-08-26T01:28:47  <luke-jr> phantomcircuit: could be
 162016-08-26T01:39:41  *** pmienk has quit IRC
 172016-08-26T01:48:50  *** sanada` has joined #bitcoin-core-dev
 182016-08-26T01:50:23  *** btcdrak has quit IRC
 192016-08-26T01:50:40  *** sanada has quit IRC
 202016-08-26T01:51:19  *** pmienk has joined #bitcoin-core-dev
 212016-08-26T01:54:19  <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"
 222016-08-26T01:54:19  *** Samdney has left #bitcoin-core-dev
 232016-08-26T01:54:25  <kanzure> 18:53 < kanzure> saurik: bitcoin core just a bunch of people hanging out on irc doing stuff. so i pinged you about it.
 242016-08-26T01:54:49  <kanzure> i mean.. i don't expect how else to inform upstream other than sending messages :P.
 252016-08-26T01:55:40  <gmaxwell> mindrays.
 262016-08-26T01:56:09  <kanzure> shh don't tell them about my mind rays
 272016-08-26T01:57:38  *** Chris_Stewart_5 has quit IRC
 282016-08-26T01:57:47  <midnightmagic> i thought they were my mindrays
 292016-08-26T01:57:54  <midnightmagic> D-:
 302016-08-26T01:58:04  <Squidicuz> woah.. full frontal lobotomy button, and now mindrays?!
 312016-08-26T01:59:42  *** achow101 has joined #bitcoin-core-dev
 322016-08-26T02:02:37  <midnightmagic> we are.. groot?
 332016-08-26T02:05:05  <phantomcircuit> kanzure, what's he even talking about?
 342016-08-26T02:05:27  <kanzure> don't speak so ill of the lobotomy</nobel prize committee>
 352016-08-26T02:05:38  <kanzure> (actually i'm joking. no idea why that got the nobel prize.)
 362016-08-26T02:05:43  <kanzure> phantomcircuit: osx code signing O_o
 372016-08-26T02:06:04  <phantomcircuit> kanzure, you see you should have connected to his personal irc server
 382016-08-26T02:06:27  <kanzure> actually you're right, there really is an irc.saurik.com
 392016-08-26T02:07:08  <midnightmagic> :-o
 402016-08-26T02:12:07  <luke-jr> kanzure: a pull request? :P
 412016-08-26T02:13:30  <cfields_> kanzure: i fully intended to upstream it
 422016-08-26T02:13:51  <cfields_> kanzure: what channel? I'll ping him to discuss
 432016-08-26T02:16:28  <midnightmagic> I dunno if he really knows what it means to invite rando bitcoiners in to his IRC. :(
 442016-08-26T02:19:08  *** dcousens has joined #bitcoin-core-dev
 452016-08-26T02:19:32  <dcousens> is there any way to turn off pretty-printing in the bitcoind RPC JSON?
 462016-08-26T02:19:32  *** Giszmo has quit IRC
 472016-08-26T02:19:50  <kanzure> cfields_: pm
 482016-08-26T02:20:08  <cfields_> thanks
 492016-08-26T02:20:29  <kanzure> cfields_: btw i don't think it's urgent; i just found his response funny :).
 502016-08-26T02:21:39  <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
 512016-08-26T02:23:53  <phantomcircuit> dcousens, ?
 522016-08-26T02:25:15  <GitHub198> [bitcoin] rebroad opened pull request #8596: Feeler code and debugging. (master...FeelerFixes) https://github.com/bitcoin/bitcoin/pull/8596
 532016-08-26T02:31:55  <dcousens> phantomcircuit: nevermind, its just bitcoin-cli being smart :)
 542016-08-26T02:52:15  *** btcdrak has joined #bitcoin-core-dev
 552016-08-26T02:56:29  *** ryan-c has quit IRC
 562016-08-26T02:57:00  *** dcousens has quit IRC
 572016-08-26T02:59:01  *** dcousens has joined #bitcoin-core-dev
 582016-08-26T03:01:36  *** [Author] has quit IRC
 592016-08-26T03:01:36  *** fengling has quit IRC
 602016-08-26T03:05:55  *** ryan-c has joined #bitcoin-core-dev
 612016-08-26T03:06:05  *** [Author] has joined #bitcoin-core-dev
 622016-08-26T03:06:06  *** fengling has joined #bitcoin-core-dev
 632016-08-26T03:10:10  <phantomcircuit> dcousens, yeah i think univalue always produces a single line
 642016-08-26T03:10:44  <dcousens> phantomcircuit: yup, my bad, went into tcpdump and yeah its not pretty printed over the wire which is all I cared about
 652016-08-26T03:11:40  *** justanotheruser has quit IRC
 662016-08-26T03:11:58  *** justanotheruser has joined #bitcoin-core-dev
 672016-08-26T03:17:48  <phantomcircuit> dcousens, as someone who is very guilty of this
 682016-08-26T03:17:55  <phantomcircuit> i usually fine that if something looks dumb it is not
 692016-08-26T03:18:04  <phantomcircuit> except when it is
 702016-08-26T03:19:00  <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
 712016-08-26T03:35:56  *** tom3 has quit IRC
 722016-08-26T03:36:02  <phantomcircuit> luke-jr, indeed i think the unit tests are broken
 732016-08-26T03:36:12  <phantomcircuit> or rather are testing the behaviour too specifically
 742016-08-26T03:37:07  <luke-jr> "too specifically" is often subjective. ☺
 752016-08-26T03:38:34  *** moli has quit IRC
 762016-08-26T03:39:45  <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.
 772016-08-26T03:40:05  <gmaxwell> this is an objective standard you can judge a test against, even if its not usually achievable for most functions.
 782016-08-26T03:43:03  <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.
 792016-08-26T03:53:31  *** Alopex has quit IRC
 802016-08-26T03:54:36  *** Alopex has joined #bitcoin-core-dev
 812016-08-26T03:55:50  <phantomcircuit> luke-jr, can you explain why it's testing wtx nTimeReceived ?
 822016-08-26T03:57:56  <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.
 832016-08-26T03:58:50  <luke-jr> phantomcircuit: what file/module is this?
 842016-08-26T03:59:12  <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
 852016-08-26T03:59:17  <phantomcircuit> luke-jr, src/wallet/test/accounting_tests.cpp
 862016-08-26T03:59:19  <gmaxwell> (and could it ever be updated?)
 872016-08-26T04:00:14  <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.
 882016-08-26T04:00:24  <luke-jr> gmaxwell: for example, some payment protocol could possibly provide better time estimate to a user that was offline at the time
 892016-08-26T04:00:50  <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.
 902016-08-26T04:02:37  <luke-jr> phantomcircuit: it's testing that nTimeReceived either does or doesn't influence the sorting order as it should[n't]
 912016-08-26T04:03:25  <luke-jr> gmaxwell: in this case, it's creating CWalletTxs, adding them to the wallet, and checking the sort comes out correct
 922016-08-26T04:04:43  <luke-jr> (I was wrong thinking it was doing smart fee stuff; it's sort order)
 932016-08-26T04:10:25  *** moli has joined #bitcoin-core-dev
 942016-08-26T04:14:06  *** fengling has quit IRC
 952016-08-26T04:17:02  *** fengling has joined #bitcoin-core-dev
 962016-08-26T04:17:59  <phantomcircuit> luke-jr, is there something that describes how the smart time stuff works?
 972016-08-26T04:20:08  <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)
 982016-08-26T04:20:23  <luke-jr> if the most recent known transaction is newer, it won't go backward
 992016-08-26T04:20:30  <luke-jr> unless it's significantly earlier, IIRC 15 minutes or so
1002016-08-26T04:20:54  *** achow101 has quit IRC
1012016-08-26T04:39:46  *** fengling has quit IRC
1022016-08-26T04:48:35  *** fengling has joined #bitcoin-core-dev
1032016-08-26T04:54:06  *** Alopex has quit IRC
1042016-08-26T04:55:12  *** Alopex has joined #bitcoin-core-dev
1052016-08-26T04:56:54  <phantomcircuit> luke-jr, so you're simulating the blocktime?
1062016-08-26T05:20:37  *** Alopex has quit IRC
1072016-08-26T05:21:42  *** Alopex has joined #bitcoin-core-dev
1082016-08-26T05:22:26  *** fengling has quit IRC
1092016-08-26T05:29:44  *** dcousens has quit IRC
1102016-08-26T05:54:33  *** paveljanik has quit IRC
1112016-08-26T05:56:26  *** harrymm has quit IRC
1122016-08-26T06:04:15  *** fengling has joined #bitcoin-core-dev
1132016-08-26T06:12:51  *** harrymm has joined #bitcoin-core-dev
1142016-08-26T06:19:40  *** mturquette has quit IRC
1152016-08-26T06:19:59  *** mturquette has joined #bitcoin-core-dev
1162016-08-26T06:21:28  *** crescendo has quit IRC
1172016-08-26T06:21:52  *** crescendo has joined #bitcoin-core-dev
1182016-08-26T06:26:12  *** harrymm has quit IRC
1192016-08-26T06:30:23  *** btcdrak has quit IRC
1202016-08-26T06:31:26  <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?
1212016-08-26T06:32:32  <gmaxwell> Yes. And the signer program has you confirm the transaction, enter the passphrase, returns the result.
1222016-08-26T06:32:48  <gmaxwell> and it can have 100% mlocked memory, be highly sandboxed, etc.
1232016-08-26T06:33:12  <jonasschnelli> How do the encrypted private keys get there in the first place?
1242016-08-26T06:33:53  <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.
1252016-08-26T06:35:14  <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?
1262016-08-26T06:35:32  <jonasschnelli> *whats
1272016-08-26T06:35:33  *** BashCo has quit IRC
1282016-08-26T06:35:50  <jonasschnelli> Ah. mlocked mem
1292016-08-26T06:35:54  <gmaxwell> because then you have two files to backup for you wallet, and now the signer needs filesystem access.
1302016-08-26T06:36:06  *** fengling has quit IRC
1312016-08-26T06:37:20  <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.
1322016-08-26T06:37:34  <jonasschnelli> Hardware wallet will probably not export encrypted private keys.
1332016-08-26T06:37:41  <jonasschnelli> So the "blob" could be optional.
1342016-08-26T06:37:43  <gmaxwell> Yes. Also third party co-signers... or at least extended to that eventually.
1352016-08-26T06:38:10  <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. :)
1362016-08-26T06:38:27  <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.
1372016-08-26T06:38:56  <jonasschnelli> The problem with the blob storing encrypted keys is the backward and forward-security IMO
1382016-08-26T06:39:23  <jonasschnelli> A leaked encryption password will result in compromising everything
1392016-08-26T06:40:08  <GitHub61> [bitcoin] rebroad opened pull request #8597: [WIP] Move code from VERACK to VERSION (since VERACK is not requied) (master...NotDependentOnVerack) https://github.com/bitcoin/bitcoin/pull/8597
1402016-08-26T06:40:14  <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
1412016-08-26T06:40:33  *** harrymm has joined #bitcoin-core-dev
1422016-08-26T06:55:43  *** fengling has joined #bitcoin-core-dev
1432016-08-26T06:56:39  <luke-jr> phantomcircuit: I'm not sure - do smart fees even have tests?
1442016-08-26T06:56:45  <luke-jr> smart times*
1452016-08-26T06:56:55  *** BashCo has joined #bitcoin-core-dev
1462016-08-26T07:05:03  <phantomcircuit> luke-jr, the accounting stuff appears to be th eonly thing testing them
1472016-08-26T07:05:07  <phantomcircuit> and really it shouldn't be
1482016-08-26T07:05:24  <phantomcircuit> it should at most be testing that they have the expected order
1492016-08-26T07:06:31  <luke-jr> oh, the commit itself describes it: c3f95ef13f48d21db53992984976eac93e7a08fc
1502016-08-26T07:12:26  *** fengling has quit IRC
1512016-08-26T07:17:04  *** fengling has joined #bitcoin-core-dev
1522016-08-26T07:27:30  *** laurentmt has joined #bitcoin-core-dev
1532016-08-26T07:27:38  <GitHub134> [bitcoin] jonasschnelli closed pull request #8135: [OSX] fix make deploy when compiling on OSX (master...2016/06/makedeploy) https://github.com/bitcoin/bitcoin/pull/8135
1542016-08-26T07:29:56  *** laurentmt has quit IRC
1552016-08-26T07:31:15  *** JackH has joined #bitcoin-core-dev
1562016-08-26T07:34:22  <GitHub48> [bitcoin] fivepiece opened pull request #8598: Fix displaying of invalid and non-minimal small pushes as numbers (master...fixasm) https://github.com/bitcoin/bitcoin/pull/8598
1572016-08-26T07:35:17  <arubi> <- ^, if anyone has questions
1582016-08-26T07:37:53  <jonasschnelli> arubi: just commented that some tests would be nice
1592016-08-26T07:38:04  <arubi> yep.  I'll have a look!
1602016-08-26T07:38:09  <jonasschnelli> thanks
1612016-08-26T07:42:27  *** btcdrak has joined #bitcoin-core-dev
1622016-08-26T07:44:34  <GitHub164> [bitcoin] laanwj closed pull request #8595: [Wallet] Ensure <0.13 clients can't open HD wallets (master...2016/07/hd_minversion) https://github.com/bitcoin/bitcoin/pull/8595
1632016-08-26T07:45:10  *** isis has joined #bitcoin-core-dev
1642016-08-26T07:50:18  <jonasschnelli> I'd like to merge https://github.com/bitcoin/bitcoin/pull/8371 soon... thanks for reviews
1652016-08-26T07:52:52  *** neha has quit IRC
1662016-08-26T07:55:06  *** neha has joined #bitcoin-core-dev
1672016-08-26T07:55:42  *** Guyver2 has joined #bitcoin-core-dev
1682016-08-26T07:59:59  *** arowser has quit IRC
1692016-08-26T08:00:12  <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?
1702016-08-26T08:00:51  *** kadoban has quit IRC
1712016-08-26T08:01:12  <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()?
1722016-08-26T08:01:27  *** arowser has joined #bitcoin-core-dev
1732016-08-26T08:02:10  <sipa> use an atomic instead of a lock
1742016-08-26T08:02:58  <jonasschnelli> sipa: Indeed. What do you think about -dbcacheinsync?
1752016-08-26T08:03:37  <gmaxwell> I don't think I've ever seen a user report that would really be helped by that.
1762016-08-26T08:03:40  <jonasschnelli> Not sure if we should change nCoinDBCache and nBlockTreeDBCache during "runtime"
1772016-08-26T08:03:59  <gmaxwell> I think we'd be using a much larger dbcache except we want to work correctly on the common 2gb hosts and vpses.
1782016-08-26T08:04:16  <gmaxwell> and those hosts would crash during sync if it was bigger during sync.
1792016-08-26T08:04:37  <sipa> i actually would want a separate dbcache value in IBD on my phone :)
1802016-08-26T08:04:39  <gmaxwell> now-- allowing the dbcache to use memory the mempool isn't using-- that would be a useful stunt.
1812016-08-26T08:04:50  <GitHub129> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/53f8f226bd1d...6c9f1b8c2405
1822016-08-26T08:04:50  <GitHub129> bitcoin/master 259ee09 R E Broadley: Show "end" instead of many zeros when getheaders request received with a hashStop of Null.
1832016-08-26T08:04:51  <GitHub129> bitcoin/master 6c9f1b8 Wladimir J. van der Laan: Merge #8561: Show "end" instead of many zeros when getheaders request received with a hashStop of Null...
1842016-08-26T08:04:54  <gmaxwell> but wouldn't need an option (hurray)
1852016-08-26T08:05:05  <GitHub110> [bitcoin] laanwj closed pull request #8561: Show "end" instead of many zeros when getheaders request received with a hashStop of Null (master...LessGetheadersZeros) https://github.com/bitcoin/bitcoin/pull/8561
1862016-08-26T08:05:25  <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.
1872016-08-26T08:05:57  <sipa> i think 2GB is not much anymore for most desktop systems
1882016-08-26T08:06:09  <sipa> but there are others
1892016-08-26T08:06:21  <gmaxwell> on systems where you're okay using that at ~any~ point, it's probably not a bad idea at all times. :(
1902016-08-26T08:06:38  <gmaxwell> keep in mind too small a dbcache is responsible for some of the io thrashing users frequently complain about.
1912016-08-26T08:06:50  <phantomcircuit> sipa, it would actually be nice to have a "stall" function for things which regularly overheat
1922016-08-26T08:07:10  <sipa> phantomcircuit: you shouldn't run a full node on hardware that overheats
1932016-08-26T08:07:29  <phantomcircuit> sipa, that covers virtually all phones and most laptops
1942016-08-26T08:07:32  <gmaxwell> sipa: that excludes about 75% of laptops available commercially now.
1952016-08-26T08:07:41  <jonasschnelli> ;-)
1962016-08-26T08:07:43  <phantomcircuit> the thermal protection stuff isn't designed for continuous load
1972016-08-26T08:07:50  <sipa> heh
1982016-08-26T08:08:08  <gmaxwell> only a few makers actually build hardware that can stat sustained load. (your lenovo being such an example)
1992016-08-26T08:08:16  <gmaxwell> s/stat/stand/
2002016-08-26T08:08:33  <gmaxwell> though it doesn't crash when overheating.
2012016-08-26T08:08:37  <gmaxwell> mostly.
2022016-08-26T08:08:44  <phantomcircuit> gmaxwell, 10:1 his lenovo is not designed for continuous max load either
2032016-08-26T08:08:59  <gmaxwell> phantomcircuit: the t-series are.
2042016-08-26T08:09:12  <gmaxwell> the x1 isn't, as I'm sure you've noticed.
2052016-08-26T08:09:13  <sipa> i have a w540
2062016-08-26T08:09:18  <gmaxwell> sipa: those too.
2072016-08-26T08:09:18  <phantomcircuit> i have indeed
2082016-08-26T08:09:33  <phantomcircuit> the t series is not generally designed for max tdp actually
2092016-08-26T08:09:36  <phantomcircuit> they're more like 80%
2102016-08-26T08:09:41  <phantomcircuit> the x1 is maybe 50%
2112016-08-26T08:09:49  <phantomcircuit> a w450 probably is
2122016-08-26T08:09:52  <phantomcircuit> 540
2132016-08-26T08:09:53  <phantomcircuit> whatever
2142016-08-26T08:10:09  <gmaxwell> in any case, what about the suggestion I made about dbcache using unused mempool space?
2152016-08-26T08:10:22  <gmaxwell> that basically matches the sync and cachup use case... and doesn't add parameters.
2162016-08-26T08:10:23  <sipa> ugh.
2172016-08-26T08:10:36  <phantomcircuit> gmaxwell, eh we should just fix this and have a unified "memory usage" thing
2182016-08-26T08:10:41  <gmaxwell> It's only stupidly hard, have courage.
2192016-08-26T08:10:43  <phantomcircuit> implement out own oom killer
2202016-08-26T08:10:44  <phantomcircuit> :P
2212016-08-26T08:10:49  <phantomcircuit> our
2222016-08-26T08:10:56  <sipa> now normal transaction relay can trigger utxo flushing
2232016-08-26T08:11:05  <sipa> actually, it already does
2242016-08-26T08:11:22  <gmaxwell> yea, well if the flushing were ... less dumb, that wouldn't be a big deal.
2252016-08-26T08:12:36  <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.
2262016-08-26T08:14:27  <phantomcircuit> gmaxwell, i tried making it less dumb and broke one of the unit tests
2272016-08-26T08:14:32  <phantomcircuit> i dont think what i did was broken actually
2282016-08-26T08:15:36  <gmaxwell> one can analyize the blockchain history to evaluate candidate eviction policies.
2292016-08-26T08:16:07  <phantomcircuit> gmaxwell, yeah my eviction policy was random eviction
2302016-08-26T08:16:12  <phantomcircuit> but even that broke the tests
2312016-08-26T08:16:14  <phantomcircuit> so idk
2322016-08-26T08:16:26  <gmaxwell> you need to carefully handle dirty entries.
2332016-08-26T08:16:44  *** laurentmt has joined #bitcoin-core-dev
2342016-08-26T08:20:27  <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.
2352016-08-26T08:20:40  *** MarcoFalke has joined #bitcoin-core-dev
2362016-08-26T08:20:57  *** laurentmt has quit IRC
2372016-08-26T08:22:07  *** laurentmt has joined #bitcoin-core-dev
2382016-08-26T08:22:34  *** neha has quit IRC
2392016-08-26T08:24:30  *** Megaf has joined #bitcoin-core-dev
2402016-08-26T08:24:44  *** neha has joined #bitcoin-core-dev
2412016-08-26T08:29:18  <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.
2422016-08-26T08:29:20  <phantomcircuit> gmaxwell, i just ignored dirty entries
2432016-08-26T08:29:25  <phantomcircuit> still broke the unit tests
2442016-08-26T08:30:16  *** murch has joined #bitcoin-core-dev
2452016-08-26T08:34:20  <sipa> jonasschnelli: the profiles would just be hardcoded
2462016-08-26T08:34:27  <gmaxwell> considering the tests work fine if you twiddle the dbcache size, you screwed something up. Perhaps you were dropping things while views existed.
2472016-08-26T08:34:47  <sipa> the only option you have is selecting which profile to ude
2482016-08-26T08:34:49  <jonasschnelli> sipa: this seems not to scale,..
2492016-08-26T08:34:55  <sipa> how so?
2502016-08-26T08:35:18  <jonasschnelli> If it covers DBCache, we would need to adjust the static value over time
2512016-08-26T08:35:30  <sipa> why?
2522016-08-26T08:36:00  <sipa> it corresponds to the amount of resources it can use
2532016-08-26T08:36:30  <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...
2542016-08-26T08:36:47  <sipa> ok, then we occasionally update the profole
2552016-08-26T08:36:53  <sipa> or add a "verylarge"
2562016-08-26T08:36:57  <jonasschnelli> heh
2572016-08-26T08:37:14  <sipa> allowing people to modify the profile seems to defeat the prupose
2582016-08-26T08:37:16  <jonasschnelli> Not sure if I like hardcoded values...
2592016-08-26T08:37:28  <sipa> why don't they just modify the settings directly?
2602016-08-26T08:37:36  <jonasschnelli> Whats the advantage over -profile0-dbcache (could still have hardcoded defaults)
2612016-08-26T08:37:56  <sipa> why would you have -profile0-dbcache, and not just... -dbcache ?
2622016-08-26T08:38:08  <sipa> if you're going to override it, override it
2632016-08-26T08:38:13  <jonasschnelli> Okay.. I see .. let me explain.
2642016-08-26T08:38:22  <jonasschnelli> I'd like to have switchable profile...
2652016-08-26T08:38:51  <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
2662016-08-26T08:39:04  <jonasschnelli> Then, switch back to a different profile when their system is idling
2672016-08-26T08:39:04  <sipa> mobile phones used to have configurable profiles... for different times of the day, for special contants, ...
2682016-08-26T08:39:16  <sipa> nobody used those as they take way too much time to maintain
2692016-08-26T08:39:28  <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.
2702016-08-26T08:39:31  <jonasschnelli> Yes. You could set your "low bandwith" profile to take affect during 23:00 - 06:00 or so
2712016-08-26T08:39:45  <sipa> and phones switched back to very simple things, like 3 preconfigured ones
2722016-08-26T08:39:51  <jonasschnelli> Remember when we had the PR for "pause network activity"
2732016-08-26T08:40:16  <jonasschnelli> I guess there are some users out there who like to change the resource consumption during runtime.
2742016-08-26T08:40:23  <sipa> the point of profiles is to allow people to have more control with fewer tweakable
2752016-08-26T08:40:27  <sipa> not mkre knobs
2762016-08-26T08:40:44  <sipa> ok, so make the profile switchable at runtime
2772016-08-26T08:41:32  <gmaxwell> jonasschnelli: yes, though often even that is someone trying to rationalize their suffering from something else we've screwed up.
2782016-08-26T08:41:33  <jonasschnelli> Yes. Switchable during runtime makes sense... but I don't understand why there should be no optional -profile0-par, default overwrite option
2792016-08-26T08:42:08  <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.
2802016-08-26T08:42:09  <sipa> jonasschnelli: pfft we could add that, but i think it's a waste of time
2812016-08-26T08:42:55  <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).
2822016-08-26T08:43:05  <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.
2832016-08-26T08:43:28  <jonasschnelli> Not sure if this feature would be for highly advanced users...
2842016-08-26T08:43:43  <jonasschnelli> It could be a "turtle icon" somewhere with a tooltip "use less resources"...
2852016-08-26T08:43:44  <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.
2862016-08-26T08:43:48  <sipa> jonasschnelli: that's why we have compact blocks and not pause network :)
2872016-08-26T08:44:00  *** spudowiar has joined #bitcoin-core-dev
2882016-08-26T08:44:22  <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
2892016-08-26T08:44:39  <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.
2902016-08-26T08:44:54  <gmaxwell> I feel like you're not listening to me. :(
2912016-08-26T08:45:40  <jonasschnelli> I agree with fixing it in the first place... but some stuff is on a layer not controllable by our stack.. like QoS.
2922016-08-26T08:45:49  <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.
2932016-08-26T08:46:07  <jonasschnelli> Partially agree on that.
2942016-08-26T08:46:30  <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.
2952016-08-26T08:46:37  <jonasschnelli> A non-dump dbcache option would be significant more worth then a dbcache profile option
2962016-08-26T08:56:20  *** laurentmt has quit IRC
2972016-08-26T08:56:33  <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
2982016-08-26T08:57:03  <sipa> right now, almost no user modify dbcache, and even less know that there are half a dozen other settings that affect memory usage
2992016-08-26T08:57:17  <sipa> don't get carried away with configurability
3002016-08-26T08:57:38  <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
3012016-08-26T08:57:52  <phantomcircuit> gmaxwell, hmm maybe i was dropping things while a view existed?
3022016-08-26T08:57:53  <MarcoFalke> What about -maxtotalmem, and bitcoind will figure out how to use that  memory on it's own?
3032016-08-26T08:57:55  <phantomcircuit> im not sure actually
3042016-08-26T08:58:22  <sipa> MarcoFalke: except we don't have good accounting for all of the memory yet
3052016-08-26T08:58:30  <jonasschnelli> Yes. Maybe in the GUI intro we can offer a switch between "low" (default), "moderate" (1GB cache,...) and "height" (3GB cache).
3062016-08-26T08:58:48  <sipa> MarcoFalke: and it is pretty hard to do due to memory fragmentation etc
3072016-08-26T08:58:59  <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.
3082016-08-26T08:59:22  <sipa> jonasschnelli: yes, that's what i propose
3092016-08-26T08:59:32  <sipa> jonasschnelli: but it could affect a few more options than dbcache
3102016-08-26T08:59:48  <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)
3112016-08-26T08:59:49  <jonasschnelli> Okay. What happens if a user sets profile "hight" (3GiB) and has only 2GB wired ram?
3122016-08-26T09:00:00  <jonasschnelli> sipa: yes. more options..
3132016-08-26T09:00:09  <sipa> jonasschnelli: no, less options
3142016-08-26T09:00:17  <sipa> jonasschnelli: there is low, medium, and high
3152016-08-26T09:00:28  <jonasschnelli> yes. I meant more values that are affected by the profiles.
3162016-08-26T09:00:36  <jonasschnelli> -par, -maxuploadtarget, etc.
3172016-08-26T09:00:37  <sipa> and each corresponds to a preset oglf settings for mempool, dbcache, maxconnections, ...
3182016-08-26T09:00:40  <sipa> exactly
3192016-08-26T09:00:54  <sipa> we could do a quick test
3202016-08-26T09:01:22  <sipa> but i don't know if physical memory is portably detectable
3212016-08-26T09:02:04  <sipa> allocate a gilb and see how fast a random walk through it is? :)
3222016-08-26T09:02:30  * jonasschnelli :|
3232016-08-26T09:02:41  *** Megaf is now known as }[-_-]{
3242016-08-26T09:03:09  <sipa> *gb
3252016-08-26T09:03:22  <gmaxwell> too bad container objects basically force runtime allocation. :(
3262016-08-26T09:04:21  <phantomcircuit> sipa, what are the assumptions CCoinsViewCache makes about it's contents?
3272016-08-26T09:04:38  <phantomcircuit> if something isn't marked dirty i assumed it could just be removed
3282016-08-26T09:04:40  <phantomcircuit> is this wrong?
3292016-08-26T09:06:37  <sipa> yes, unless there is another view on top
3302016-08-26T09:06:49  <sipa> in that case you are not allowed to modify it in any way
3312016-08-26T09:15:54  <jonasschnelli> grml... bitcoind: sync.cpp:125: void potential_deadlock_detected(const std::pair<void*, void*>&, const LockStack&, const LockStack&): Assertion `onlyMaybeDeadlock' failed.
3322016-08-26T09:15:54  <jonasschnelli> Aborted
3332016-08-26T09:15:59  <jonasschnelli> current master
3342016-08-26T09:16:22  <jonasschnelli> http://pastebin.com/YCVFK5KY
3352016-08-26T09:17:05  <jonasschnelli> Before I updated to current master, it was running for a couple of weeks,.. just updated an ran into the deadlock assertion
3362016-08-26T09:17:23  <sipa> jonasschnelli: open an issue so we don't forgrt
3372016-08-26T09:17:35  <jonasschnelli> ok
3382016-08-26T09:18:31  *** }[-_-]{ has quit IRC
3392016-08-26T09:21:03  <GitHub123> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6c9f1b8c2405...c19f8a4a7795
3402016-08-26T09:21:04  <GitHub123> bitcoin/master 4c3e2cb R E Broadley: Show XTHIN in GUI
3412016-08-26T09:21:04  <GitHub123> bitcoin/master c19f8a4 Wladimir J. van der Laan: Merge #8583: Show XTHIN in GUI...
3422016-08-26T09:21:14  <GitHub63> [bitcoin] laanwj closed pull request #8583: Show XTHIN in GUI (master...ShowXTHINinGUI) https://github.com/bitcoin/bitcoin/pull/8583
3432016-08-26T09:21:14  <jonasschnelli> sipa: maybe my fault.. I'm running https://github.com/bitcoin/bitcoin/pull/7685/files on top
3442016-08-26T09:22:13  <GitHub197> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c19f8a4a7795...65837375d98b
3452016-08-26T09:22:14  <GitHub197> bitcoin/master fab5ecb MarcoFalke: [wallet] rpc: Drop misleading option
3462016-08-26T09:22:14  <GitHub197> bitcoin/master 6583737 Wladimir J. van der Laan: Merge #8581: [wallet] rpc: Drop misleading option...
3472016-08-26T09:22:30  <GitHub156> [bitcoin] laanwj closed pull request #8581: [wallet] rpc: Drop misleading option (master...Mf1608-walletDropRpc) https://github.com/bitcoin/bitcoin/pull/8581
3482016-08-26T09:33:41  <GitHub65> [bitcoin] MarcoFalke opened pull request #8600: [0.13.1]: Backport [wallet] rpc: Drop misleading option (0.13...Mf1608-walletRpcDropBackport) https://github.com/bitcoin/bitcoin/pull/8600
3492016-08-26T09:47:41  *** Megaf has joined #bitcoin-core-dev
3502016-08-26T10:01:02  *** Guyver2 has quit IRC
3512016-08-26T10:13:46  *** [Author] has quit IRC
3522016-08-26T10:17:05  *** spudowiar is now known as cc
3532016-08-26T10:17:13  *** cc is now known as spudowiar
3542016-08-26T10:17:32  <GitHub161> [bitcoin] laanwj opened pull request #8601: Add option to opt into full-RBF when sending funds (rebase) (master...2016_08_full_rbf_option) https://github.com/bitcoin/bitcoin/pull/8601
3552016-08-26T10:17:51  <GitHub138> [bitcoin] laanwj closed pull request #7132: Add option to opt into full-RBF when sending funds (master...2015-11-opt-into-full-rbf-option) https://github.com/bitcoin/bitcoin/pull/7132
3562016-08-26T10:35:02  *** moli has quit IRC
3572016-08-26T10:43:58  *** cryptapus_afk has quit IRC
3582016-08-26T10:47:51  * MarcoFalke likes sipa's new GitHub icon
3592016-08-26T10:51:18  <phantomcircuit> sipa, how can you tell if there's another view on top?
3602016-08-26T10:51:20  <phantomcircuit> also, why?
3612016-08-26T10:54:42  *** cryptapus_afk has joined #bitcoin-core-dev
3622016-08-26T10:57:53  <sipa> phantomcircuit: uh.. i can't say for sure. i've swapped out the understanding that resulting in that code :)
3632016-08-26T10:58:18  <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
3642016-08-26T10:58:36  <sipa> as to knowing when there is another view on top... don't call it from connectblock or anything below
3652016-08-26T11:01:22  <phantomcircuit> sipa, hasModifier?
3662016-08-26T11:02:31  <sipa> no
3672016-08-26T11:02:42  <sipa> hasModifier is when there is a modifier :)
3682016-08-26T11:03:04  <sipa> which is a RAII object to have an automatic cleanup after modifying an entry
3692016-08-26T11:03:54  <sipa> still, these caches don't do any locking, so they're not safe to modify from multiple threads
3702016-08-26T11:04:32  <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
3712016-08-26T11:08:26  *** fengling has quit IRC
3722016-08-26T11:24:38  <GitHub41> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/65837375d98b...12892dbb9fb6
3732016-08-26T11:24:38  <GitHub41> bitcoin/master fa6dc9f MarcoFalke: Remove unused variables
3742016-08-26T11:24:38  <GitHub41> bitcoin/master 12892db Wladimir J. van der Laan: Merge #8590: Remove unused variables...
3752016-08-26T11:24:52  <GitHub7> [bitcoin] laanwj closed pull request #8590: Remove unused variables (master...Mf1608-unusedCode) https://github.com/bitcoin/bitcoin/pull/8590
3762016-08-26T11:27:24  <GitHub87> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/f2306fbe0142...122fdfdae915
3772016-08-26T11:27:24  <GitHub87> bitcoin/0.13 526d2b0 MarcoFalke: [wallet] rpc: Drop misleading option...
3782016-08-26T11:27:24  <GitHub7> [bitcoin] laanwj closed pull request #8600: [0.13.1]: Backport [wallet] rpc: Drop misleading option (0.13...Mf1608-walletRpcDropBackport) https://github.com/bitcoin/bitcoin/pull/8600
3792016-08-26T11:27:25  <GitHub87> bitcoin/0.13 122fdfd Wladimir J. van der Laan: Merge #8600: [0.13.1]: Backport [wallet] rpc: Drop misleading option...
3802016-08-26T11:36:12  <phantomcircuit> sipa, i was trying to make the change in ccoinsviewcache so it's triggered whenever usage goes above the limit
3812016-08-26T11:37:34  <phantomcircuit> so it wouldn't know where it is
3822016-08-26T11:38:12  <phantomcircuit> i guess i could add something to the constructor to call down to the base view and increment a counter in each
3832016-08-26T11:38:36  <wumpus> btcdrak: do you have a plan for https://github.com/bitcoin/bitcoin/pull/7562?
3842016-08-26T11:38:52  <wumpus> I think it's still relevant?
3852016-08-26T11:40:01  <GitHub44> [bitcoin] laanwj closed pull request #8227: tests: Re-enable RPC tests for Windows (master...2016_05_win_reenable_rpc_tests) https://github.com/bitcoin/bitcoin/pull/8227
3862016-08-26T11:42:03  <GitHub56> [bitcoin] fanquake opened pull request #8602: [trivial][doc] Mention ++i as preferred over i++ in dev notes (master...trvial-dev-notes) https://github.com/bitcoin/bitcoin/pull/8602
3872016-08-26T11:43:20  *** cryptapus_afk is now known as cryptapus
3882016-08-26T11:47:55  <sipa> can i haz ack on #8524 ?
3892016-08-26T11:48:09  *** Megaf has quit IRC
3902016-08-26T11:49:25  *** Megaf has joined #bitcoin-core-dev
3912016-08-26T11:56:53  *** fengling has joined #bitcoin-core-dev
3922016-08-26T12:01:26  *** fengling has quit IRC
3932016-08-26T12:04:54  *** someone1337 has joined #bitcoin-core-dev
3942016-08-26T12:10:02  *** someone1337 has quit IRC
3952016-08-26T12:12:39  <GitHub9> [bitcoin] fanquake opened pull request #8603: [trivial][doc] Mention gpg --refresh-keys in release-process.md (master...release-process-refresh-keys) https://github.com/bitcoin/bitcoin/pull/8603
3962016-08-26T12:17:16  *** moli has joined #bitcoin-core-dev
3972016-08-26T12:24:23  *** [Author] has joined #bitcoin-core-dev
3982016-08-26T12:27:45  *** fengling has joined #bitcoin-core-dev
3992016-08-26T12:32:46  *** fengling has quit IRC
4002016-08-26T12:44:20  *** Giszmo has joined #bitcoin-core-dev
4012016-08-26T12:44:20  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4022016-08-26T12:59:55  *** jouke has quit IRC
4032016-08-26T13:00:03  <phantomcircuit> sipa, ACK the number 8524 is excellent
4042016-08-26T13:00:39  *** Samdney has joined #bitcoin-core-dev
4052016-08-26T13:00:51  <phantomcircuit> sipa, is that a picture of you in a ball pit?
4062016-08-26T13:01:49  *** jouke has joined #bitcoin-core-dev
4072016-08-26T13:03:13  * sipa googles ball pit
4082016-08-26T13:03:25  <sipa> phantomcircuit: yes
4092016-08-26T13:29:39  *** fengling has joined #bitcoin-core-dev
4102016-08-26T13:34:26  *** fengling has quit IRC
4112016-08-26T13:38:14  *** tom3 has joined #bitcoin-core-dev
4122016-08-26T13:46:07  <wumpus> heh, bitcoin can no longer be compiled with gcc 4.9.3 with OpenBSD's default max data segment limit of 1536MB
4132016-08-26T13:46:15  <wumpus> (main.cpp)
4142016-08-26T13:46:54  <sipa> FINALLY
4152016-08-26T13:47:06  <wumpus> yes, a milestone
4162016-08-26T13:47:41  <btcdrak> inb4 someone complains :)
4172016-08-26T13:47:46  <wumpus> pushing the lmits of modern compiler technology
4182016-08-26T13:54:31  <GitHub56> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/12892dbb9fb6...fd37acaedab1
4192016-08-26T13:54:31  <GitHub56> bitcoin/master c25083b fanquake: [trivial][doc] Mention gpg --refresh-keys in release-process.md
4202016-08-26T13:54:32  <GitHub56> bitcoin/master fd37aca Wladimir J. van der Laan: Merge #8603: [trivial][doc] Mention gpg --refresh-keys in release-process.md...
4212016-08-26T13:54:46  <GitHub169> [bitcoin] laanwj closed pull request #8603: [trivial][doc] Mention gpg --refresh-keys in release-process.md (master...release-process-refresh-keys) https://github.com/bitcoin/bitcoin/pull/8603
4222016-08-26T13:54:55  <GitHub182> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fd37acaedab1...bb566761fbe1
4232016-08-26T13:54:55  <GitHub182> bitcoin/master ab53207 fanquake: [trivial][doc] Mention ++i as preferred to i++ in dev notes
4242016-08-26T13:54:56  <GitHub182> bitcoin/master bb56676 Wladimir J. van der Laan: Merge #8602: [trivial][doc] Mention ++i as preferred over i++ in dev notes...
4252016-08-26T13:55:06  <GitHub114> [bitcoin] laanwj closed pull request #8602: [trivial][doc] Mention ++i as preferred over i++ in dev notes (master...trvial-dev-notes) https://github.com/bitcoin/bitcoin/pull/8602
4262016-08-26T13:55:36  <GitHub183> [bitcoin] laanwj closed pull request #8547: Update btcdrak key with new expiry dates (master...btcdrak-key) https://github.com/bitcoin/bitcoin/pull/8547
4272016-08-26T13:59:11  <sipa> wth?
4282016-08-26T13:59:11  <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
4292016-08-26T14:04:20  <sipa> ah, i'm running with a python2 interpreter
4302016-08-26T14:04:38  <sipa> those are still pretty weird characters to appear in source code...
4312016-08-26T14:04:52  <cfields_> sipa: surely those chars are the least of your concerns, then? :)
4322016-08-26T14:05:08  <wumpus> only python3 is supported for the RPC tests
4332016-08-26T14:05:40  <sipa> yes, it works with python3
4342016-08-26T14:05:40  <wumpus> for python2 it was necessary to define the character set at the top, python3 defaults to UTF-8
4352016-08-26T14:05:59  <wumpus> (but yes, that's far from the only thing that prevents it from working in  2.x)
4362016-08-26T14:06:14  <sipa> still, i'm baffled why we have unicode character u+1f4bb in our source code...
4372016-08-26T14:06:35  <wumpus> probably to test RPC unicode support
4382016-08-26T14:06:46  <cfields_> \xf0 does look suspiciously like typo'd hex
4392016-08-26T14:07:20  <sipa> i doubt it: https://github.com/bitcoin/bitcoin/blob/master/qa/rpc-tests/test_framework/util.py#L170
4402016-08-26T14:07:41  <cfields_> oh, huh
4412016-08-26T14:07:52  <wumpus> that's to test that unicode characters work in username/password
4422016-08-26T14:08:10  <cfields_> https://github.com/bitcoin/bitcoin/commit/fad184550e1c507a897be59169f9c5dabce8d652
4432016-08-26T14:08:10  <sipa> ah
4442016-08-26T14:10:24  <wumpus> if those funny characters work, then Chinese Russian etc certainly will (as they are in lower unicode planes)
4452016-08-26T14:12:34  <cfields_> great. Soon every 13yr old's passwords will be filled with poop emojis, and we'll all have to account for that possibility.
4462016-08-26T14:12:57  <wumpus> yes :-)
4472016-08-26T14:13:32  <Chris_Stewart_5> lol
4482016-08-26T14:14:11  <sipa> true ☺
4492016-08-26T14:16:40  *** Samdney has quit IRC
4502016-08-26T14:20:02  <kanzure> sipa: use "#encoding: utf8" at top of .py files for python2
4512016-08-26T14:21:41  <wumpus> better to just not use python2 anymore :)
4522016-08-26T14:22:30  <wumpus> but yes that works
4532016-08-26T14:27:04  <kanzure> if you want to enforce definitely not using python2, then using a more explicit method might be good
4542016-08-26T14:27:53  <kanzure> (import sys; sys.version_info.major)
4552016-08-26T14:28:13  <GitHub154> [bitcoin] laanwj opened pull request #8604: build,doc: Update for 0.13.0+ and OpenBSD 5.9 (master...2016_08_openbsd_update) https://github.com/bitcoin/bitcoin/pull/8604
4562016-08-26T14:28:16  *** mkarrer has joined #bitcoin-core-dev
4572016-08-26T14:29:21  <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
4582016-08-26T14:31:11  *** fengling has joined #bitcoin-core-dev
4592016-08-26T14:36:06  *** fengling has quit IRC
4602016-08-26T14:49:08  *** jannes has quit IRC
4612016-08-26T14:55:10  *** hybridsole has quit IRC
4622016-08-26T15:01:42  *** hybridsole has joined #bitcoin-core-dev
4632016-08-26T15:06:33  <phantomcircuit> sipa, i dont see why you cant remove things from a CCoinsCacheView (or whichever arrangement of words it is) which aren't dirty
4642016-08-26T15:06:34  <phantomcircuit> like
4652016-08-26T15:06:38  <phantomcircuit> logically that makes no sense
4662016-08-26T15:08:30  <sipa> ok, maybe i'm wrong
4672016-08-26T15:09:43  <phantomcircuit> you see now i am questioning my own sanity
4682016-08-26T15:09:48  <phantomcircuit> god damned caching problems!
4692016-08-26T15:15:23  <sipa> There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
4702016-08-26T15:30:03  *** laurentmt has joined #bitcoin-core-dev
4712016-08-26T15:31:35  *** epopt has joined #bitcoin-core-dev
4722016-08-26T15:32:45  *** fengling has joined #bitcoin-core-dev
4732016-08-26T15:35:22  *** Samdney has joined #bitcoin-core-dev
4742016-08-26T15:37:32  <instagibbs> are there any good summaries/discussions for tx relay DoS prevention in Core?
4752016-08-26T15:37:46  *** fengling has quit IRC
4762016-08-26T15:38:08  <instagibbs> esp wrt when certain things are checked in sequence
4772016-08-26T15:38:42  *** jcorgan has quit IRC
4782016-08-26T15:55:45  *** whphhg has quit IRC
4792016-08-26T15:58:15  *** whphhg has joined #bitcoin-core-dev
4802016-08-26T16:06:01  *** slackircbridge has quit IRC
4812016-08-26T16:06:11  *** slackircbridge2 has joined #bitcoin-core-dev
4822016-08-26T16:06:47  *** rinzes_ has joined #bitcoin-core-dev
4832016-08-26T16:07:53  <rinzes_> I am trying to find out how to remove bitcoin core completely
4842016-08-26T16:08:02  <rinzes_> windows 10
4852016-08-26T16:09:02  <helo> rinzes_: #bitcoin
4862016-08-26T16:09:04  <btcdrak> Control panel -> programs -> uninstall
4872016-08-26T16:09:30  <rinzes_> will that remove the database and everything
4882016-08-26T16:10:18  *** laurentmt has quit IRC
4892016-08-26T16:13:46  <GitHub107> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/bb566761fbe1...9a0ed08b40b1
4902016-08-26T16:13:47  <GitHub107> bitcoin/master ff8d279 Pavel Janík: Do not shadow member variables
4912016-08-26T16:13:47  <GitHub107> bitcoin/master 9a0ed08 Pieter Wuille: Merge #8109: Do not shadow member variables...
4922016-08-26T16:13:51  <GitHub43> [bitcoin] sipa closed pull request #8109: Do not shadow member variables (master...20160527_shadow_httpserver) https://github.com/bitcoin/bitcoin/pull/8109
4932016-08-26T16:16:39  *** rinzes_ has quit IRC
4942016-08-26T16:17:20  *** laurentmt has joined #bitcoin-core-dev
4952016-08-26T16:17:31  *** laurentmt has quit IRC
4962016-08-26T16:29:30  *** BashCo has quit IRC
4972016-08-26T16:29:57  *** BashCo has joined #bitcoin-core-dev
4982016-08-26T16:34:08  *** fengling has joined #bitcoin-core-dev
4992016-08-26T16:39:06  *** fengling has quit IRC
5002016-08-26T17:03:12  *** kadoban has joined #bitcoin-core-dev
5012016-08-26T17:11:01  *** davec has quit IRC
5022016-08-26T17:18:34  <GitHub8> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9a0ed08b40b1...c072b8fd95cd
5032016-08-26T17:18:34  <GitHub8> bitcoin/master fa3d974 MarcoFalke: [doc] Update git-subtree-check.sh README
5042016-08-26T17:18:35  <GitHub8> bitcoin/master c072b8f Pieter Wuille: Merge #8545: [doc] Update git-subtree-check.sh README...
5052016-08-26T17:18:44  <GitHub93> [bitcoin] sipa closed pull request #8545: [doc] Update git-subtree-check.sh README (master...Mf1608-doc) https://github.com/bitcoin/bitcoin/pull/8545
5062016-08-26T17:35:46  *** fengling has joined #bitcoin-core-dev
5072016-08-26T17:40:46  *** fengling has quit IRC
5082016-08-26T17:41:17  *** davec has joined #bitcoin-core-dev
5092016-08-26T17:45:29  *** Megaf has quit IRC
5102016-08-26T18:09:07  *** Guyver2_ has joined #bitcoin-core-dev
5112016-08-26T18:10:12  <Lauda> Does the gitian build script from achow101 include everything now?
5122016-08-26T18:13:25  <sipa> i believe it does
5132016-08-26T18:14:09  <Lauda> I'll test now and post results then.
5142016-08-26T18:14:10  <Lauda> Thanks
5152016-08-26T18:20:58  *** BashCo has quit IRC
5162016-08-26T18:34:40  *** pmienk has quit IRC
5172016-08-26T18:37:16  *** fengling has joined #bitcoin-core-dev
5182016-08-26T18:38:43  *** Guyver2_ is now known as Guyver2
5192016-08-26T18:42:26  *** fengling has quit IRC
5202016-08-26T18:44:20  *** JZA has joined #bitcoin-core-dev
5212016-08-26T18:45:28  <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
5222016-08-26T18:46:21  *** pmienk has joined #bitcoin-core-dev
5232016-08-26T18:47:30  <arubi> specifically, it failed at: "Assertion failed: 449.99100000 != 999.980" when running 'qa/rpc-tests/segwit.py'
5242016-08-26T18:48:32  <sipa> we've been seeing that test fail for a while
5252016-08-26T18:48:56  <arubi> oh, so it might be that re-running it will pass then?
5262016-08-26T18:51:04  <arubi> sipa, er, maybe I misunderstood.  it fails consistently?  I see other builds pass, and my previous pr passed
5272016-08-26T18:53:14  <sipa> no, just occasionally
5282016-08-26T18:54:11  <arubi> mhm.  well, the PR is ready then, if anyone finds it useful :)
5292016-08-26T18:57:23  <sipa> great; will review in mmore detail
5302016-08-26T18:57:39  <arubi> thanks!
5312016-08-26T19:05:26  *** Megaf has joined #bitcoin-core-dev
5322016-08-26T19:09:21  <GitHub103> [bitcoin] sipa opened pull request #8606: Fix some locks (master...lockfix) https://github.com/bitcoin/bitcoin/pull/8606
5332016-08-26T19:10:01  <GitHub127> [bitcoin] MarcoFalke opened pull request #8607: [doc] Fix doxygen off-by-one comments, fix typos (master...Mf1608-trivial17) https://github.com/bitcoin/bitcoin/pull/8607
5342016-08-26T19:15:02  *** BashCo has joined #bitcoin-core-dev
5352016-08-26T19:15:49  <sipa> arubi: https://github.com/bitcoin/bitcoin/issues/8532
5362016-08-26T19:16:30  *** achow101 has joined #bitcoin-core-dev
5372016-08-26T19:16:49  *** spudowiar has quit IRC
5382016-08-26T19:21:44  <arubi> sipa, I see, so this is some timing issue then?
5392016-08-26T19:23:26  <arubi> I see tests passed now, phew :)
5402016-08-26T19:30:32  *** Megaf has quit IRC
5412016-08-26T19:46:45  *** Guyver2 has quit IRC
5422016-08-26T19:48:10  *** achow101 has quit IRC
5432016-08-26T19:55:37  <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
5442016-08-26T20:01:40  *** mappum has quit IRC
5452016-08-26T20:02:52  *** btcdrak has quit IRC
5462016-08-26T20:03:30  *** eragmus has quit IRC
5472016-08-26T20:13:48  *** pmienk has quit IRC
5482016-08-26T20:16:43  *** pmienk has joined #bitcoin-core-dev
5492016-08-26T20:23:26  <MarcoFalke> ugh
5502016-08-26T20:23:45  <MarcoFalke> seeing segfaults while testing the stalling issue
5512016-08-26T20:24:26  <sipa> can you run from gdb and inspect?
5522016-08-26T20:24:54  <MarcoFalke> Would that work with trickle?
5532016-08-26T20:25:01  <sipa> what is trickle?
5542016-08-26T20:25:22  <sipa> ah, bandwidth manager
5552016-08-26T20:25:36  <MarcoFalke> Jup, I need to simulate my "rural bandwith"
5562016-08-26T20:25:43  <sipa> yes, you can run bitcoind normally, and then gdb bitcoind -p <pid>
5572016-08-26T20:25:53  <MarcoFalke> ok
5582016-08-26T20:25:56  <sipa> to attach to the existing process
5592016-08-26T20:26:18  <sipa> when it segfaults, type 'bt' to see a backtrace
5602016-08-26T20:26:23  * sipa afk for 5 minutes
5612016-08-26T20:28:53  *** voids has joined #bitcoin-core-dev
5622016-08-26T20:38:30  <gmaxwell> ::sigh:: "BU" ripped out the outbound connection limiting logic, so we can probably expect more ignorant users connecting to the whole darn network.
5632016-08-26T20:40:18  *** fengling has joined #bitcoin-core-dev
5642016-08-26T20:44:36  <luke-jr> :|
5652016-08-26T20:45:06  *** fengling has quit IRC
5662016-08-26T20:45:08  *** davec has quit IRC
5672016-08-26T20:45:29  <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.
5682016-08-26T20:45:48  *** davec has joined #bitcoin-core-dev
5692016-08-26T20:47:11  *** mappum has joined #bitcoin-core-dev
5702016-08-26T20:54:03  *** zooko has joined #bitcoin-core-dev
5712016-08-26T21:03:19  *** eragmus has joined #bitcoin-core-dev
5722016-08-26T21:10:23  *** btcdrak has joined #bitcoin-core-dev
5732016-08-26T21:13:43  *** spudowiar has joined #bitcoin-core-dev
5742016-08-26T21:15:04  *** Chris_Stewart_5 has quit IRC
5752016-08-26T21:16:08  *** spudowiar has quit IRC
5762016-08-26T21:16:20  *** spudowiar has joined #bitcoin-core-dev
5772016-08-26T21:25:35  <MarcoFalke> sipa: Well, the trace does not look helpful? http://pastebin.ubuntu.com/23095029/
5782016-08-26T21:26:13  <sipa> MarcoFalke: try 'thread apply all bt'
5792016-08-26T21:28:26  <MarcoFalke> http://pastebin.ubuntu.com/23095049/
5802016-08-26T21:28:31  <MarcoFalke> sipa: ^
5812016-08-26T21:28:35  *** kyletorpey has joined #bitcoin-core-dev
5822016-08-26T21:29:44  <sipa> MarcoFalke: that looks like a segfault inside trickle...
5832016-08-26T21:30:49  <MarcoFalke> Ok, will try without trickle during the weekend
5842016-08-26T21:36:25  <murch> sipa: I assume the P2WPKH is then 4 bytes/4 larger as well?
5852016-08-26T21:37:57  <sipa> murch: presumably
5862016-08-26T21:38:21  <murch> The sequence number is part of the discounted section, right?
5872016-08-26T21:39:33  <sipa> no
5882016-08-26T21:40:07  <sipa> since it is in non-witness inputs as well, it can't be discounted
5892016-08-26T21:40:47  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5902016-08-26T21:41:54  *** fengling has joined #bitcoin-core-dev
5912016-08-26T21:45:35  <luke-jr> hm, looks like AMD may beat Intel to SHA instructions
5922016-08-26T21:46:02  <sipa> intel already has sha instructions?
5932016-08-26T21:46:09  <luke-jr> sipa: not in any desktop CPU, AFAIK
5942016-08-26T21:46:46  *** fengling has quit IRC
5952016-08-26T21:47:30  <Lauda> http://i.imgur.com/jEid47S.png Does anyone have any ideas how to mitigate this?
5962016-08-26T21:47:43  <Lauda> Seems an Upstart error is present in Ubuntu 14.0.4 and 15.10 in a VM.
5972016-08-26T21:49:43  *** tom3 has quit IRC
5982016-08-26T21:52:14  *** Chris_Stewart_5 has quit IRC
5992016-08-26T21:54:16  *** cryptapus is now known as cryptapus_afk
6002016-08-26T21:56:05  *** MarcoFalke has left #bitcoin-core-dev
6012016-08-26T22:08:17  *** Chris_Stewart_5 has joined #bitcoin-core-dev
6022016-08-26T22:09:29  *** spudowiar has quit IRC
6032016-08-26T22:09:56  *** spudowiar1 has joined #bitcoin-core-dev
6042016-08-26T22:10:18  *** spudowiar1 is now known as spudowiar
6052016-08-26T22:17:46  * luke-jr wonders if there's a way to tell his node to only fetch blocks from CB peers
6062016-08-26T22:22:34  *** achow101 has joined #bitcoin-core-dev
6072016-08-26T22:26:15  *** zooko` has joined #bitcoin-core-dev
6082016-08-26T22:43:11  *** fengling has joined #bitcoin-core-dev
6092016-08-26T22:48:06  *** fengling has quit IRC
6102016-08-26T22:50:49  *** zooko` has quit IRC
6112016-08-26T22:51:24  *** zooko has quit IRC
6122016-08-26T22:54:32  *** Alopex has quit IRC
6132016-08-26T22:55:37  *** Alopex has joined #bitcoin-core-dev
6142016-08-26T23:02:31  *** eragmus has quit IRC
6152016-08-26T23:02:37  *** mappum has quit IRC
6162016-08-26T23:03:40  *** btcdrak has quit IRC
6172016-08-26T23:07:29  <murch> sipa: thanks
6182016-08-26T23:15:09  *** eragmus has joined #bitcoin-core-dev
6192016-08-26T23:19:59  *** mappum has joined #bitcoin-core-dev
6202016-08-26T23:24:57  *** voids has quit IRC
6212016-08-26T23:25:15  *** voids has joined #bitcoin-core-dev
6222016-08-26T23:34:45  *** murch has quit IRC
6232016-08-26T23:36:07  <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?
6242016-08-26T23:36:38  *** CodeShark has quit IRC
6252016-08-26T23:37:46  *** CodeShark has joined #bitcoin-core-dev
6262016-08-26T23:44:47  *** fengling has joined #bitcoin-core-dev
6272016-08-26T23:46:03  *** eragmus has quit IRC
6282016-08-26T23:46:04  *** mappum has quit IRC
6292016-08-26T23:49:46  *** fengling has quit IRC
6302016-08-26T23:59:35  *** JZA has quit IRC