1 2017-02-23 00:14:11	0|jtimon|can we please just get rid of accounts for 0.15 ?
  2 2017-02-23 00:14:56	0|luke-jr|ryanofsky: accounts don't have coins
  3 2017-02-23 00:15:12	0|luke-jr|jtimon: IIRC there's still some things we lack substitutes for? dunno
  4 2017-02-23 00:15:47	0|jtimon|not sure what the progress on that was, but I thought we were close
  5 2017-02-23 00:41:35	0|jtimon|sorry for repeating the question, why are all these functions declared as extern? https://github.com/bitcoin/bitcoin/blob/master/src/rpc/server.h#L188
  6 2017-02-23 02:46:38	0|jtimon|luke-jr: ok, sorry, it was -disablewallet, not wallet=0, right now, with that option, and with either -help or invalid args it says: error code: -32601 error message: Method not found, it could instead
  7 2017-02-23 05:37:06	0|luke-jr|https://github.com/iancoleman/bip39/issues/58
  8 2017-02-23 05:37:24	0|luke-jr|not sure if it's a real problem or not yet, but some crypto experts may want to look (sipa, gmaxwell)
  9 2017-02-23 06:01:58	0|bitcoin-git|[13bitcoin] 15NicolasDorier opened pull request #9830: Add trusted flag to listunspent result (06master...06listunspenttrusted) 02https://github.com/bitcoin/bitcoin/pull/9830
 10 2017-02-23 06:33:46	0|bitcoin-git|[13bitcoin] 15theuni opened pull request #9831: build: force a c++ standard to be specified (06master...06no-default-std) 02https://github.com/bitcoin/bitcoin/pull/9831
 11 2017-02-23 06:46:40	0|midnightmagic|That feeler-connections PR is a very nice read.
 12 2017-02-23 06:50:28	0|gmaxwell|luke-jr: crazy js code treating binary data as strings. :(
 13 2017-02-23 06:52:51	0|luke-jr|>_<
 14 2017-02-23 06:57:38	0|gmaxwell|should be recoverable at least... better than prior bitcoinjs / bn.js bugs.
 15 2017-02-23 07:05:54	0|cannon-c|Does bitcoin core have bip39 for backing up wallet? Having trouble seeming to find it.
 16 2017-02-23 07:06:08	0|cannon-c|If not, any objection to including bip39?
 17 2017-02-23 07:10:57	0|gmaxwell|It is a terrible spec which shouldn't be implemented by anyone, in my opinion.
 18 2017-02-23 07:12:13	0|gmaxwell|It forces the use of public derrivation which results in security issues when used with software that allows public key export. It has no versioning, so wallets cannot change the schemes without creating a potential for funds loss.  The 'check values' for it are optional and can't really be enforced for general compatiblity, which then also means that most uses of it end up unintentioally promot
 19 2017-02-23 07:12:19	0|gmaxwell|ing insecure brainwallet usage.
 20 2017-02-23 07:12:46	0|gmaxwell|The authors of the sepcification were uninterested in resolving these and other shortcomings, resulting in one of the authors having their name pulled from it.
 21 2017-02-23 07:13:24	0|luke-jr|I thought BIP 39 didn't dictate anything re derivation?
 22 2017-02-23 07:14:07	0|cannon-c|what is "public derrivation"?
 23 2017-02-23 07:15:03	0|cannon-c|I thought bip39 was just using dictionary wordlist in 2048 length list to convert 256 bit entropy to human readable words (256bit being 24 words)
 24 2017-02-23 07:15:56	0|gmaxwell|indeed you're right it's BIP 44 that does but it doesn't matter because the lack of versioning means that you're stuck with the defacto standard.
 25 2017-02-23 07:16:53	0|cannon-c|I do like idea of words for backup, I can write down backup on paper using words instead of key that is prone to misspelling and funds lost.
 26 2017-02-23 07:17:05	0|cannon-c|gmaxwell what do you prefer above word based mnemonic then?
 27 2017-02-23 07:18:56	0|gmaxwell|words are fine, but should be a scheme that can encode versioning and bidirectionally convert.
 28 2017-02-23 07:20:58	0|cannon-c|If I udnerstand correctly, Electrum's scheme even if dictionary is lost can still recover direct from words themselves?
 29 2017-02-23 07:21:21	0|cannon-c|Just something I heard, not familiar with Electrum's scheme though.
 30 2017-02-23 07:23:26	0|bitcoin-git|[13bitcoin] 15NicolasDorier opened pull request #9832: [qa] assert_start_raises_init_error (06master...06assert_start_raises_init_error) 02https://github.com/bitcoin/bitcoin/pull/9832
 31 2017-02-23 07:37:51	0|wumpus|what's up with travis?  https://github.com/bitcoin/bitcoin/issues/9825   How can there be a threading error *before* the tests of test_bitcoin even start?
 32 2017-02-23 07:38:32	0|wumpus|errors such as "test_bitcoin: tpp.c:62: __pthread_tpp_change_priority: Assertion `new_prio == -1 || (new_prio >= __sched_fifo_min_prio && new_prio <= __sched_fifo_max_prio)' failed."
 33 2017-02-23 07:39:00	0|wumpus|and "../include/boost/thread/pthread/recursive_mutex.hpp:113: void boost::recursive_mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed."
 34 2017-02-23 07:40:13	0|wumpus|sounds like locking is being done before locking is initialized, e.g. before we even get to main()?
 35 2017-02-23 07:40:54	0|bitcoin-git|[13bitcoin] 15benma opened pull request #9833: Trivial: fix comments referencing AppInit2 (06master...06stalecomments) 02https://github.com/bitcoin/bitcoin/pull/9833
 36 2017-02-23 07:50:43	0|jonasschnelli|wumpus: you think this is a travis issue or did we break the context initialisation in some way?
 37 2017-02-23 07:51:07	0|wumpus|I don't think it's a travis issue, but I can't (which is always terribly frustrating with these issues) reproduce it locally
 38 2017-02-23 07:51:27	0|wumpus|but yes it's probably something we do differently in our code now
 39 2017-02-23 07:52:37	0|wumpus|current master simply passes https://travis-ci.org/bitcoin/bitcoin/builds/204167316 - so it's intermittent
 40 2017-02-23 07:53:20	0|jonasschnelli|wumpus: we recently changes something close to that,,,
 41 2017-02-23 07:53:29	0|jonasschnelli|the missing bitcoin-tx ECC_Start()
 42 2017-02-23 07:53:34	0|jonasschnelli|Not sure if this is related
 43 2017-02-23 07:53:48	0|wumpus|unknown location(0): fatal error: in "rpc_tests/rpc_rawsign": signal: illegal operand; address of failing instruction: 0x2b73cbf4cf3b
 44 2017-02-23 07:53:50	0|wumpus|WAT??
 45 2017-02-23 07:54:36	0|jonasschnelli|:/
 46 2017-02-23 07:55:09	0|midnightmagic|I wonder if it would be worthwhile to include a "legal participation" flag of some sort.. so that people who use the services provided by your bitcoin node must agree to the EULA of your node, in order to use it.
 47 2017-02-23 07:55:57	0|wumpus|jonasschnelli: yes, might be related, I don't know. Although I think the test setup happens after the "Running 228 test cases...", not before it
 48 2017-02-23 07:56:04	0|wumpus|not sure tho
 49 2017-02-23 07:56:31	0|wumpus|midnightmagic: you could include a url in your subversion
 50 2017-02-23 07:57:14	0|wumpus|(though it's a bit challenging with all those characters sanitized out :-)
 51 2017-02-23 07:57:19	0|midnightmagic|Then, technically, mass-sybil'ing could be prosecuted if the sybils didn't disconnect immediately and refuse to connect again.
 52 2017-02-23 07:58:01	0|wumpus|depending on your country you can set any terms of use when you run a service
 53 2017-02-23 08:00:58	0|midnightmagic|auto-EULA might not be strong enough.
 54 2017-02-23 08:01:51	0|wumpus|so you imagine something where you have to read an EULA and click for every node you connect to?
 55 2017-02-23 08:02:07	0|wumpus|uhm, no, I'll pass
 56 2017-02-23 08:02:52	0|gmaxwell|midnightmagic: proposed previously was an alternative protocol for transaction relay that has standard requirements like that as just part of the protocol spec.
 57 2017-02-23 08:03:04	0|gmaxwell|midnightmagic: anyone is free to create such a thing.
 58 2017-02-23 08:03:24	0|midnightmagic|well, triangulation of an idea is nice to hear anyway.
 59 2017-02-23 08:03:32	0|gmaxwell|Because so much of the abusive behavior we can detect is commercially motivated-- its an intresting question.
 60 2017-02-23 08:03:58	0|midnightmagic|commercial motivation implies pockets, and corporation behavioural laws.
 61 2017-02-23 08:04:03	0|wumpus|yes, separating transaction submission/relay would make sense
 62 2017-02-23 08:04:10	0|gmaxwell|But it's not something that would make sense as the general Bitcoin protocol I think. Or at least it would be too easily trolled. But people are free to try it out and I hope they do.
 63 2017-02-23 08:04:12	0|wumpus|that's the only thing people care to spy on anyway
 64 2017-02-23 08:04:27	0|wumpus|for relaying blocks, it doesn't matter nearly as much
 65 2017-02-23 08:05:29	0|midnightmagic|I was thinking just connecting at all. I wonder if it would devolve into horros e.g. to authorize your client to agree to EULA semi-automatically on your behalf based on acceptable terms.
 66 2017-02-23 08:06:13	0|gmaxwell|midnightmagic: I think it only makes sense if the terms are basically just part of the protocol.
 67 2017-02-23 08:07:01	0|midnightmagic|hrm.
 68 2017-02-23 08:07:41	0|wumpus|making it harder to spy on transactions by using onion routing / some kind of deaddrop system, would do a lot against spying
 69 2017-02-23 08:07:56	0|wumpus|better than getting involved inthe vagaries of international law
 70 2017-02-23 08:18:25	0|wumpus|what are the exact specifications of the travis VMs?
 71 2017-02-23 08:19:35	0|wumpus|ubuntu trusty at least, will try with that locally
 72 2017-02-23 08:25:19	0|bitcoin-git|[13bitcoin] 15benma opened pull request #9834: qt: clean up initialize/shutdown signals (06master...06exitcode) 02https://github.com/bitcoin/bitcoin/pull/9834
 73 2017-02-23 08:46:18	0|wumpus|of course, it all passes perfectly in my own trusty vm...
 74 2017-02-23 08:47:23	0|gmaxwell|make your vm slower? :P
 75 2017-02-23 08:48:54	0|wumpus|I guess running a few instances of test_bitcoin in parallel could simulate that
 76 2017-02-23 08:54:13	0|wumpus|looks like test_bitcoin doesn't clean up its UUID directories (/tmp/92bc-0a4a-f496-6b40)
 77 2017-02-23 08:54:36	0|wumpus|while the /tmp/test_bitcoin_1487840020_6012 are being cleaned up
 78 2017-02-23 08:55:57	0|wumpus|(yes, the tests finish succesfully)
 79 2017-02-23 09:39:14	0|bitcoin-git|13bitcoin/06master 14874c736 15Russell Yanofsky: Fix pruning test broken by 2 hour manual prune window...
 80 2017-02-23 09:39:14	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/bed5b30a5622...d14555de3de9
 81 2017-02-23 09:39:15	0|bitcoin-git|13bitcoin/06master 14d14555d 15Wladimir J. van der Laan: Merge #9820: Fix pruning test broken by 2 hour manual prune window...
 82 2017-02-23 09:39:34	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9820: Fix pruning test broken by 2 hour manual prune window (06master...06pr/prunewind) 02https://github.com/bitcoin/bitcoin/pull/9820
 83 2017-02-23 09:39:54	0|bitcoin-git|13bitcoin/060.14 14599c69a 15Russell Yanofsky: Fix pruning test broken by 2 hour manual prune window...
 84 2017-02-23 09:39:54	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.14: 02https://github.com/bitcoin/bitcoin/commit/599c69abe3101512eeee13733c0f58eb3e363eae
 85 2017-02-23 09:41:07	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d14555de3de9...1d2a57e9fd2c
 86 2017-02-23 09:41:08	0|bitcoin-git|13bitcoin/06master 141d2a57e 15Wladimir J. van der Laan: Merge #9824: qa: Check return code when stopping nodes...
 87 2017-02-23 09:41:08	0|bitcoin-git|13bitcoin/06master 14fa4cd2e 15MarcoFalke: qa: Check return code when stopping nodes...
 88 2017-02-23 09:41:24	0|bitcoin-git|13bitcoin/060.14 14260c71c 15MarcoFalke: qa: Check return code when stopping nodes...
 89 2017-02-23 09:41:24	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.14: 02https://github.com/bitcoin/bitcoin/commit/260c71cbb857d12540a2f53372282d11f2b401a8
 90 2017-02-23 09:41:32	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9824: qa: Check return code when stopping nodes (06master...06Mf1702-qaRet) 02https://github.com/bitcoin/bitcoin/pull/9824
 91 2017-02-23 09:49:10	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/1d2a57e9fd2c...e68c266f3d56
 92 2017-02-23 09:49:11	0|bitcoin-git|13bitcoin/06master 14b602fe0 15Cory Fields: build: warn about variable length arrays
 93 2017-02-23 09:49:12	0|bitcoin-git|13bitcoin/06master 14205830a 15Cory Fields: build: add --enable-werror option...
 94 2017-02-23 09:49:12	0|bitcoin-git|13bitcoin/06master 14e68c266 15Wladimir J. van der Laan: Merge #9789: build: add --enable-werror and warn on vla's...
 95 2017-02-23 09:49:31	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9789: build: add --enable-werror and warn on vla's (06master...06no-vla) 02https://github.com/bitcoin/bitcoin/pull/9789
 96 2017-02-23 09:49:45	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 060.14: 02https://github.com/bitcoin/bitcoin/compare/260c71cbb857...05e906dbc68e
 97 2017-02-23 09:49:46	0|bitcoin-git|13bitcoin/060.14 1405e906d 15Cory Fields: build: add --enable-werror option...
 98 2017-02-23 09:49:46	0|bitcoin-git|13bitcoin/060.14 14749fe95 15Cory Fields: build: warn about variable length arrays...
 99 2017-02-23 11:22:39	0|wumpus|I've been running test_bitcoin with five threads, for three hours on a trusty VM - no single failure
100 2017-02-23 12:40:38	0|warren|Hmm, the blk*.dat files exported by linearize-data.py is slightly modified by bitcoind if you drop them in your blocks/ directory.  http://pastebin.com/PH99QYdm   diff of two hexdumps shows a tiny bit at the end of each file is truncated.
101 2017-02-23 13:38:56	0|wumpus|warren: hm that;s a bug
102 2017-02-23 13:39:22	0|wumpus|only the last blk.dat file should be modified
103 2017-02-23 13:39:46	0|wumpus|oh, of course, it scans them again from the beginning, so every file is 'last file' for a while
104 2017-02-23 13:40:21	0|wumpus|so the truncating behavior makes some sense - don't think it necessarily needs to do that during reindexing, but it's not unexpected
105 2017-02-23 13:41:26	0|wumpus|this is different from the bootstrap.dat file which was really an external file which was imported
106 2017-02-23 15:35:07	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e68c266f3d56...7146d96de3e1
107 2017-02-23 15:35:08	0|bitcoin-git|13bitcoin/06master 147146d96 15MarcoFalke: Merge #9766: Add --exclude option to rpc-tests.py...
108 2017-02-23 15:35:08	0|bitcoin-git|13bitcoin/06master 14c578408 15John Newbery: Add exclude option to rpc-tests.py
109 2017-02-23 15:35:32	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9766: Add --exclude option to rpc-tests.py (06master...06rpctestexclude) 02https://github.com/bitcoin/bitcoin/pull/9766
110 2017-02-23 15:40:20	0|bitcoin-git|13bitcoin/06master 143f95a80 15John Newbery: Fix docstrings in qa tests...
111 2017-02-23 15:40:20	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7146d96de3e1...d6064a89ac97
112 2017-02-23 15:40:21	0|bitcoin-git|13bitcoin/06master 14d6064a8 15MarcoFalke: Merge #9577: Fix docstrings in qa tests...
113 2017-02-23 15:40:35	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9577: Fix docstrings in qa tests (06master...06docstrings) 02https://github.com/bitcoin/bitcoin/pull/9577
114 2017-02-23 15:40:48	0|MarcoFalke|Great work on the test framework jnewbery!
115 2017-02-23 15:41:13	0|jnewbery|Thanks MarcoFalke!
116 2017-02-23 16:37:02	0|bitcoin-git|13bitcoin/06master 143333ad0 15MarcoFalke: qa: Set correct path for binaries in rpc tests
117 2017-02-23 16:37:02	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d6064a89ac97...a13a417cdcfd
118 2017-02-23 16:37:03	0|bitcoin-git|13bitcoin/06master 14a13a417 15MarcoFalke: Merge #9823: qa: Set correct path for binaries in rpc tests...
119 2017-02-23 16:37:22	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9823: qa: Set correct path for binaries in rpc tests (06master...06Mf1702-qaPath) 02https://github.com/bitcoin/bitcoin/pull/9823
120 2017-02-23 16:57:23	0|bitcoin-git|[13bitcoin] 15DannyHamilton opened pull request #9838: Update COPYING (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/9838
121 2017-02-23 16:58:48	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9838: Update COPYING (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/9838
122 2017-02-23 17:01:30	0|gmaxwell|https://tradeblock.com/bitcoin/tx/8d31992805518fd62daa3bdd2a5c4fd2cd3054c9b3dca1d78055e9528cff6adc > sha1 bounty redeemed.
123 2017-02-23 17:03:46	0|jouke_|:)
124 2017-02-23 17:07:43	0|BlueMatt|gmaxwell: is that a second sha1 collision, then?
125 2017-02-23 17:10:13	0|BlueMatt|gmaxwell: indeed, a second sha1 collision
126 2017-02-23 17:11:05	0|gmaxwell|smartbits is much nicer in its display: https://www.smartbit.com.au/tx/8d31992805518fd62daa3bdd2a5c4fd2cd3054c9b3dca1d78055e9528cff6adc
127 2017-02-23 17:12:09	0|BlueMatt|gmaxwell: oh, nvm, same sha1 collision
128 2017-02-23 17:12:39	0|BlueMatt|same prefix, just dropped the postfix
129 2017-02-23 17:20:33	0|Chris_Stewart_5|all of the inputs on that tx correspond to outputs that had SHA1 bounties?
130 2017-02-23 17:23:28	0|gmaxwell|Yes.
131 2017-02-23 18:03:52	0|warren|wumpus: I'd like behavior where during -reindex it can handle any existing blk*.dat files to be read-only, do not truncate during scan, and create new after it scanned whatever already exists there. That way I can hardlink shared files between multiple full archival node instances on the same machine.
132 2017-02-23 18:04:04	0|bitcoin-git|13bitcoin/06master 14692c9ed 15Wladimir J. van der Laan: Merge #9831: build: force a c++ standard to be specified...
133 2017-02-23 18:04:04	0|bitcoin-git|13bitcoin/06master 149829c54 15Cory Fields: build: force a c++ standard to be specified...
134 2017-02-23 18:04:04	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/a13a417cdcfd...692c9eddba67
135 2017-02-23 18:04:24	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9831: build: force a c++ standard to be specified (06master...06no-default-std) 02https://github.com/bitcoin/bitcoin/pull/9831
136 2017-02-23 18:04:46	0|wumpus|warren: heh yes, hardlinking block files works as long as you don't reindex, apparently
137 2017-02-23 18:05:09	0|wumpus|warren: I tend to hardlink both the block/utxo database files and the block files, so have never noticed that
138 2017-02-23 18:05:53	0|wumpus|warren: though: truncating the files to not contain any zero space at the end shouldn't affect any other users
139 2017-02-23 18:05:58	0|warren|which are the "block/utxo database files"
140 2017-02-23 18:06:29	0|wumpus|the ldb files: https://gist.github.com/laanwj/3c4614a23e072cbb3d39090da1834a68
141 2017-02-23 18:07:32	0|warren|wumpus: currently during *any* startup it fails if it cannot open a blk*.dat file writable, which is unnecessary.  If they can be read it should be adequate as long as new blk.dat files can be written after the read-only files.
142 2017-02-23 18:07:49	0|bitcoin-git|13bitcoin/060.14 1499fd85c 15Cory Fields: build: force a c++ standard to be specified...
143 2017-02-23 18:07:49	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.14: 02https://github.com/bitcoin/bitcoin/commit/99fd85cb44fe9983c64cfa376299e67b18568304
144 2017-02-23 18:07:50	0|wumpus|I agree, but that's not the case right now
145 2017-02-23 18:08:00	0|gmaxwell|wumpus: sounds like a trivial change to make it not open them writable.
146 2017-02-23 18:08:04	0|gmaxwell|er warren
147 2017-02-23 18:08:40	0|sipa|we could mark files in the block index as unwritable as well
148 2017-02-23 18:08:56	0|sipa|and then skip them when looking for files to append new blocks to
149 2017-02-23 18:09:19	0|wumpus|I remember luke-jr has an issue open about this https://github.com/bitcoin/bitcoin/issues/2039
150 2017-02-23 18:09:25	0|warren|I know.  currently it goes through a generic abstraction to open files
151 2017-02-23 18:10:13	0|wumpus|sipa: the problem in this case is not appending, but truncating. But yeah that'd help too
152 2017-02-23 18:11:03	0|wumpus|I like how pruning at least works with hardlinked block files, by pruning a block file at a time instead of messing with the contents
153 2017-02-23 18:11:23	0|warren|fopen failing on read-only and truncation are two related problems, following by marking which files should be not writable.  Anything else?
154 2017-02-23 18:12:23	0|warren|where should that read-only marking be written?
155 2017-02-23 18:12:39	0|wumpus|in the block index db
156 2017-02-23 18:19:27	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #9839: [qa] Make import-rescan.py watchonly check reliable (06master...06pr/travis-rescan) 02https://github.com/bitcoin/bitcoin/pull/9839
157 2017-02-23 18:49:07	0|wumpus|almost time to tag rc2?
158 2017-02-23 18:49:21	0|wumpus|well I guess it can wait until the meeting :)
159 2017-02-23 18:49:25	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #9840: Update sendfrom RPC help to correct coin selection misconception (06master...06pr/fromacct) 02https://github.com/bitcoin/bitcoin/pull/9840
160 2017-02-23 18:49:43	0|BlueMatt|heh
161 2017-02-23 18:49:46	0|BlueMatt|wumpus: i think so
162 2017-02-23 18:52:12	0|BlueMatt|cfields: where are we on #9787
163 2017-02-23 18:52:19	0|gribble|https://github.com/bitcoin/bitcoin/issues/9787 | release: add a few performance-related notes by theuni · Pull Request #9787 · bitcoin/bitcoin · GitHub
164 2017-02-23 18:52:32	0|BlueMatt|oh, wait, missed you updated part of it
165 2017-02-23 18:52:37	0|sdaftuar|#9814 looks potentially concerning?  unclear if its reproducible i guess
166 2017-02-23 18:52:47	0|gribble|https://github.com/bitcoin/bitcoin/issues/9814 | 0.14rc1 coredump in QScreen::handle() · Issue #9814 · bitcoin/bitcoin · GitHub
167 2017-02-23 18:53:04	0|BlueMatt|oh, did we not fix that yet? ugh, yea, probably need a fix for that before rc2
168 2017-02-23 18:53:21	0|wumpus|sdaftuar: I don't know. haven't heard any reports about that from anyone else
169 2017-02-23 18:53:58	0|wumpus|also no one seems to be able to reproduce it
170 2017-02-23 18:54:03	0|wumpus|so no, I don't think it should block rc2
171 2017-02-23 18:54:14	0|cfields|BlueMatt: yea, i need some clarification from you. Also, I assume there are some more obvious user-facing perf improvements that should be added, i just can't come up with any
172 2017-02-23 18:54:26	0|BlueMatt|wumpus: hmmm....I mean I'd tend to trust dooglus to not have some obviously-broken shit
173 2017-02-23 18:54:33	0|cfields|BlueMatt: we could do a quick call for additions in the meeting
174 2017-02-23 18:54:45	0|BlueMatt|wumpus: but, ok
175 2017-02-23 18:54:56	0|BlueMatt|wumpus: (I dont see much of a different option)
176 2017-02-23 18:55:10	0|wumpus|BlueMatt: also it seems like a qt issue
177 2017-02-23 18:55:15	0|BlueMatt|yes
178 2017-02-23 18:55:39	0|wumpus|and seems it's a custom built binary, not our static one from bitcoin.org
179 2017-02-23 18:56:12	0|BlueMatt|well i hope we support custom binaries with non-static qt :p
180 2017-02-23 18:56:30	0|BlueMatt|cfields: i think just the spelling issue sdaftuar mentioned and we can get it in for rc2?
181 2017-02-23 18:56:31	0|wumpus|but we can't support all broken configurations out there
182 2017-02-23 18:56:45	0|cfields|BlueMatt: sure, if you're good with the rest
183 2017-02-23 18:56:47	0|wumpus|:)
184 2017-02-23 18:56:47	0|wumpus|well at least I can't. Maybe you want to take that up, fine with me
185 2017-02-23 18:57:23	0|BlueMatt|wumpus: heh, indeed, if no one can figure out the issue then it shouldnt block rc2, I just want to make sure someone who actually knows qt has given it a super good look-over, because i certainliy cant help there :/
186 2017-02-23 18:57:26	0|cfields|wumpus: did you see my comment the other day about that smelling like an old touch/wacom bug? Not sure if you dug that up, but I'll have a look now if not
187 2017-02-23 18:58:01	0|wumpus|cfields: I vaguely remember that one, yes.
188 2017-02-23 18:58:08	0|gmaxwell|if it's an issue in an older QT we could disable building with versions that old.
189 2017-02-23 18:58:09	0|wumpus|cfields: it needed a qt patch
190 2017-02-23 18:58:39	0|cfields|wumpus: right. My thought was that because the crash comes from older system libs, that bug may be present
191 2017-02-23 18:58:46	0|cfields|looking it up to see if it could be the same thing
192 2017-02-23 18:59:13	0|wumpus|looks like even the filer cannot reproduce it
193 2017-02-23 18:59:28	0|wumpus|"Edit: I've tried repeating the same steps again and wasn't able to get the crash to happen again."
194 2017-02-23 19:00:28	0|wumpus|#startmeeting
195 2017-02-23 19:00:33	0|wumpus|#meetingstart
196 2017-02-23 19:00:35	0|lightningbot|Meeting started Thu Feb 23 19:00:31 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
197 2017-02-23 19:00:35	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
198 2017-02-23 19:01:09	0|gmaxwell|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
199 2017-02-23 19:01:15	0|jonasschnelli|hi
200 2017-02-23 19:01:26	0|wumpus|cfields: we could ask if dooglus is using a tablet/touch screen, or was using it at that time.
201 2017-02-23 19:01:44	0|cfields|wumpus: oh, haha, i didn't notice it was the same reporter
202 2017-02-23 19:01:54	0|kanzure|hi.
203 2017-02-23 19:02:15	0|sipa|present
204 2017-02-23 19:02:17	0|petertodd|hi
205 2017-02-23 19:02:27	0|jonasschnelli|wumpus: did you reproduce 9814 with the same setup? Ubuntu and Qt 5.3?
206 2017-02-23 19:02:30	0|cfields|oh, nm
207 2017-02-23 19:02:48	0|petertodd|so quick note re: git and SHA1 collisions: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013600.html
208 2017-02-23 19:02:56	0|wumpus|jonasschnelli: no, I did not reproduce it
209 2017-02-23 19:03:00	0|sipa|petertodd: i wanted to bring that up
210 2017-02-23 19:03:06	0|wumpus|#topic git and sha collisions
211 2017-02-23 19:03:30	0|petertodd|so while many people will say git isn't vulnerable if you trust a git repo's maintainers, that is *not* true as a pull-req could add a colliding file
212 2017-02-23 19:03:32	0|achow101|does git and github only support sha1?
213 2017-02-23 19:03:32	0|luke-jr|sounds like MD5 breakage
214 2017-02-23 19:03:44	0|sipa|achow101: yes
215 2017-02-23 19:03:52	0|sipa|i only read about this new sha1 attack an hour ago... how hard is it to create a collision?
216 2017-02-23 19:04:03	0|petertodd|probably only relevant with binary files, but we don't know 100% yet because details of the attack haven't been published
217 2017-02-23 19:04:04	0|luke-jr|achow101: IIRC, git is designed in such a way that changing SHA1 is very difficult
218 2017-02-23 19:04:06	0|achow101|sipa: still very hard
219 2017-02-23 19:04:21	0|gmaxwell|sipa: it's not a new attack its the one published from a coule years ago with about 2^64 complexity.  There were some estimates of a cost on EC2 of about $110k.
220 2017-02-23 19:04:21	0|sipa|i see
221 2017-02-23 19:04:26	0|wumpus|110 GPU-years or so
222 2017-02-23 19:04:32	0|gmaxwell|It's just actually been executed now.
223 2017-02-23 19:04:50	0|sipa|gmaxwell: no, it seems new research was done that simplifies it further
224 2017-02-23 19:04:52	0|gmaxwell|(at least thats my understanding)
225 2017-02-23 19:04:55	0|petertodd|gmaxwell: is it confirmed that google's efforts don't include any advances on what was already known to be possible?
226 2017-02-23 19:04:57	0|gmaxwell|oh. I missed that, okay!
227 2017-02-23 19:05:27	0|luke-jr|is the git project taking any action now?
228 2017-02-23 19:05:38	0|BlueMatt|luke-jr: doesnt look like it
229 2017-02-23 19:05:38	0|wumpus|Google and CWI, the dutch center for mathetmatics and informatics
230 2017-02-23 19:05:46	0|BlueMatt|luke-jr: (at least no movement as of this morning)
231 2017-02-23 19:05:54	0|gmaxwell|I think they already said they wouldn't before?
232 2017-02-23 19:06:11	0|sipa|i wonder how hard it is to create an overlay... that goes back in history, computes a sha256 for every tree and commit, and then include gpg signatures on those?
233 2017-02-23 19:06:25	0|jonasschnelli|sipa: great idea
234 2017-02-23 19:06:39	0|petertodd|sipa: I have code for something very similar to that in OpenTimestamps actually, and people have written tools to do that as well other than opentimestamps
235 2017-02-23 19:06:42	0|btcdrak|The exploit has a fancy name as usual http://shattered.io/
236 2017-02-23 19:06:46	0|gmaxwell|http://marc.info/?l=git&m=115678778717621&w=2 "The only _dangerous_ kind of collision is the inadvertent kind,
237 2017-02-23 19:06:49	0|gmaxwell|but that's obviously also the very very unlikely kind."
238 2017-02-23 19:06:54	0|BlueMatt|sipa: I was looking this morning to see if you could reasonably patch git to do so directly, looks hard.....still, we can update our dev scripts to do a sha256sum of all committed files and sign that as well
239 2017-02-23 19:07:16	0|sipa|BlueMatt: signing just the trees i guess is an easy first step
240 2017-02-23 19:07:28	0|btcdrak|according to the site "How is GIT affected?
241 2017-02-23 19:07:28	0|btcdrak|GIT strongly relies on SHA-1 for the identification and integrity checking of all file objects and commits. It is essentially possible to create two GIT repositories with the same head commit hash and different contents, say a benign source code and a backdoored one. An attacker could potentially selectively serve either repository to targeted users. This
242 2017-02-23 19:07:28	0|btcdrak|will require attackers to compute their own collision."
243 2017-02-23 19:07:30	0|wumpus|but the tree is a sha1 hash too, isn't it?
244 2017-02-23 19:07:32	0|BlueMatt|gmaxwell: yup, great, linus and associated kernel folks continue to willfully ignore that security matters even the slightest bit
245 2017-02-23 19:07:34	0|gmaxwell|what does the signed commit stuff sign? if it signs the commit message, then we can include a sha256 in it and have the verify check that too.
246 2017-02-23 19:07:43	0|BlueMatt|wumpus: yes, it would have to be a separate thing
247 2017-02-23 19:07:47	0|wumpus|if you don't trust SHA1 anymore, that rabbit hole goes deep
248 2017-02-23 19:07:55	0|BlueMatt|wumpus: eg the merge scripts could include a hash of sha256sum * in the commit message
249 2017-02-23 19:07:55	0|sdaftuar|is it worth periodically running https://github.com/cr-marcstevens/sha1collisiondetection on commits in our repo?
250 2017-02-23 19:08:09	0|BlueMatt|sdaftuar: I have a patch for git to use that as the hash function
251 2017-02-23 19:08:09	0|petertodd|gmaxwell: the signed commit stuff signs a SHA1 hash, but it's easy to extend that with a gnupg wrapper; I could take the code from OpenTimestamps and do that
252 2017-02-23 19:08:18	0|BlueMatt|and abort() if it detects a potentially-bad hash
253 2017-02-23 19:08:23	0|sipa|BlueMatt: sounds like a great idea
254 2017-02-23 19:08:33	0|kanzure|off-topic, but i wonder what git could change to make upgrading backwards-compatible in the future. for now i think it must be an incompatible upgrade to switch to another hash function?
255 2017-02-23 19:08:37	0|sipa|(including the sha256sum * in the merge commit message)
256 2017-02-23 19:08:43	0|wumpus|BlueMatt: if bad hashes are rare, that makes sense
257 2017-02-23 19:08:48	0|petertodd|gmaxwell: the one thing OpenTimestamps doesn't already do is recalculate hashes of *prior* commits with SHA256, but that'd be easy to add
258 2017-02-23 19:09:14	0|kanzure|i would also like the gh-meta repository maintainer to consider timestamping with opentimestamps at some point, i dunno who he is and i haven't pestered him yet
259 2017-02-23 19:09:26	0|BlueMatt|wumpus: the authors of that hash code claim 2**-90
260 2017-02-23 19:09:28	0|kanzure|er, the bitcoin-gh-meta repository person
261 2017-02-23 19:09:29	0|BlueMatt|(for random hits)
262 2017-02-23 19:09:34	0|luke-jr|detecting it after the fact seems like it would still be irrepairable?
263 2017-02-23 19:10:05	0|wumpus|kanzure: iwilcox on IRC
264 2017-02-23 19:10:11	0|petertodd|kanzure: git could easily have git commits simultaneously generate and sign two different hash functions; quite feasible to implement. I'll bet you I could pull that off in a week or two of work.
265 2017-02-23 19:10:13	0|kanzure|oh good, he is easily pesterable.
266 2017-02-23 19:10:47	0|kanzure|petertodd: yea but needs to be backwards compatible; and the bloat from two commits does not sound ideal. are they considering that btw?
267 2017-02-23 19:10:54	0|wumpus|BlueMatt: if the chance of an inadvertent match is that low, in that case, abort() /reject is a great solution
268 2017-02-23 19:11:26	0|luke-jr|kanzure: I'd guess you simply list the parent commit hashes twice?
269 2017-02-23 19:11:28	0|petertodd|kanzure: no bloat involved - the data can be shared across both commits
270 2017-02-23 19:12:05	0|kanzure|ah okay. well, i hadn't heard that proposal today, someone should check if git upstream is thinking about that.
271 2017-02-23 19:12:10	0|gmaxwell|probably said enough on this for now.
272 2017-02-23 19:12:17	0|btcdrak|There's a conversation on the git mailing list https://public-inbox.org/git/xmqqk28g92h7.fsf@gitster.mtv.corp.google.com/T/#t
273 2017-02-23 19:12:35	0|petertodd|gmaxwell: ack
274 2017-02-23 19:12:43	0|wumpus|yes, agreed
275 2017-02-23 19:13:00	0|petertodd|next topic
276 2017-02-23 19:13:07	0|wumpus|#topic help cfields with adding performance-related release notes
277 2017-02-23 19:13:09	0|wumpus|https://github.com/bitcoin/bitcoin/pull/9787
278 2017-02-23 19:13:15	0|cfields|quick call for 0.14 perf improvements on 9897
279 2017-02-23 19:13:20	0|cfields|heh, thanks :)
280 2017-02-23 19:13:54	0|cfields|err... #9787
281 2017-02-23 19:13:56	0|gribble|https://github.com/bitcoin/bitcoin/issues/9787 | release: add a few performance-related notes by theuni · Pull Request #9787 · bitcoin/bitcoin · GitHub
282 2017-02-23 19:13:58	0|jtimon|kanzure: yeah I assume changing the hash function would be a hardfork for old repositories :p
283 2017-02-23 19:14:18	0|cfields|if anyone added a big user-facing performance improvement for 0.14, please speak up
284 2017-02-23 19:14:48	0|gmaxwell|jtimon: please don't use bitcoin terms for other things especially non-consensus systems. The classic words "backwards incompatible" are fine. :P
285 2017-02-23 19:15:05	0|jtimon|gmaxwell: yep, sorry, was a bad joke
286 2017-02-23 19:15:31	0|wumpus|jtimon: dependso n how close the new hash function is to SHA-1. If it gets the same output 1-2**90 of the time, most repositories won't be affected
287 2017-02-23 19:15:32	0|gmaxwell|cfields: no measurements in the notes?
288 2017-02-23 19:16:39	0|cfields|gmaxwell: see the pr description. I've taken some measurements on the net stuff, but they're highly localized.
289 2017-02-23 19:17:21	0|gmaxwell|wish I realized no one was going to benchmark I could have started one last night. :P
290 2017-02-23 19:17:41	0|jeremyrubin|I would also note that the cuckoocache means nodes wanting to use more cores but had performance degrade should try more cores again
291 2017-02-23 19:18:14	0|sipa|right, cuckoocache has no effect at low parallellism, i think?
292 2017-02-23 19:18:51	0|morcos|sipa: no it's smarter about keepign the right signatures in the cache due to the generations and lazy eviction
293 2017-02-23 19:18:55	0|cfields|gmaxwell: i've done lots of benchmarking. But as I said, I'm not sure how to translate that into helpful figures
294 2017-02-23 19:19:22	0|gmaxwell|sipa: e.g. it will make reorgs much faster!
295 2017-02-23 19:19:24	0|cfields|well the alternative is to use a reference system/environment for each improvement
296 2017-02-23 19:19:47	0|gmaxwell|cfields: users don't care about each improvement.
297 2017-02-23 19:20:16	0|wumpus|it also doesn't need to be super precise
298 2017-02-23 19:20:26	0|gmaxwell|cfields: "Sync with least release takes N hours now, sync with new release takes Y now." would be nice.
299 2017-02-23 19:20:54	0|jonasschnelli|or syncs are rougle XYZ% faster...
300 2017-02-23 19:21:14	0|jonasschnelli|use the ~ and nobody will blame you afterwards. :)
301 2017-02-23 19:21:31	0|jeremyrubin|use two ~~ to be extra aproximate
302 2017-02-23 19:21:44	0|wumpus|it's marketing not science :p hehe
303 2017-02-23 19:21:49	0|gmaxwell|but ~~ will just give you the same number you put in!
304 2017-02-23 19:22:45	0|jeremyrubin|The is-approximately operator is non-involutive ;)
305 2017-02-23 19:22:51	0|gmaxwell|Well people just have no general idea of the impact.  Marketing would be saying that it's 2x faster rathern the 3x faster because 2x is more plausable. :P
306 2017-02-23 19:22:53	0|jeremyrubin|anyways
307 2017-02-23 19:23:22	0|cfields|ok, i'll add a vague 0.13 vs 0.14 sync time. The 0.13 will take time though, I haven't had the patience to finish one yet
308 2017-02-23 19:23:29	0|jeremyrubin|Could be cool to spin up a few different EC2 instances to compare...
309 2017-02-23 19:23:41	0|wumpus|EC is not a good comparison environment
310 2017-02-23 19:23:46	0|wumpus|sloooow i/o
311 2017-02-23 19:23:58	0|sipa|i'm syncing on a RPi3
312 2017-02-23 19:24:03	0|sipa|sloooow
313 2017-02-23 19:24:10	0|wumpus|what storage?
314 2017-02-23 19:24:15	0|luke-jr|lol
315 2017-02-23 19:24:16	0|sipa|microsd card
316 2017-02-23 19:24:20	0|jonasschnelli|uh
317 2017-02-23 19:24:22	0|cfields|i used EC for my sync benching because i figured it represented a very typical use-case
318 2017-02-23 19:24:34	0|wumpus|that's the cause of the slowness, likely
319 2017-02-23 19:24:36	0|jeremyrubin|Actually I like that. We should publish the worst system that can sync :p
320 2017-02-23 19:24:49	0|sipa|wumpus: absolutely
321 2017-02-23 19:25:03	0|jtimon|other topics?
322 2017-02-23 19:25:09	0|wumpus|sipa: if it's really CPU bound, don't forget to use the experimental ARM assembly secp256k1 :)
323 2017-02-23 19:25:24	0|wumpus|sipa: right, as I expected
324 2017-02-23 19:25:32	0|cfields|For reference, 0.14 sync took roughly 3 hours on ec2 w/ 4 cpu cores
325 2017-02-23 19:25:43	0|sipa|wumpus: i enabled it, but it's not nearly CPU bound
326 2017-02-23 19:25:53	0|achow101|topic: rc2 status?
327 2017-02-23 19:26:12	0|wumpus|#topic rc2 status
328 2017-02-23 19:26:26	0|wumpus|I think it should be ready to tag
329 2017-02-23 19:26:58	0|wumpus|well, need to update the translations and release notes to include changes since rc1, but I don't think there's anything that still needs to be solved
330 2017-02-23 19:27:05	0|achow101|there are still open prs in the milestone though
331 2017-02-23 19:27:24	0|achow101|(well 1 that actually does something)
332 2017-02-23 19:27:31	0|wumpus|achow101: one is release notes - that can go in any time before final
333 2017-02-23 19:27:59	0|wumpus|#9829 would be nice to get in, but it's breaking travis
334 2017-02-23 19:28:01	0|gribble|https://github.com/bitcoin/bitcoin/issues/9829 | Fix importmulti returning rescan errors for wrong keys by ryanofsky · Pull Request #9829 · bitcoin/bitcoin · GitHub
335 2017-02-23 19:28:50	0|jtimon|ryanofsky: ping
336 2017-02-23 19:29:22	0|ryanofsky|should i do something? bump travis?
337 2017-02-23 19:29:25	0|wumpus|(I've already tried to retrigger it so it's not one of today's intermittent problems)
338 2017-02-23 19:29:57	0|wumpus|ryanofsky: I don't think that helps
339 2017-02-23 19:30:17	0|gmaxwell|Does it pass locally?
340 2017-02-23 19:30:41	0|ryanofsky|yeah, the errors are the same "__pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed" things i've seen on other prs
341 2017-02-23 19:31:09	0|wumpus|ryanofsky: oh, https://github.com/bitcoin/bitcoin/issues/9825
342 2017-02-23 19:31:19	0|ryanofsky|i had to bump one of my prs last week 5-6 times to make travis pass
343 2017-02-23 19:31:24	0|wumpus|ryanofsky: okay, will respin
344 2017-02-23 19:32:36	0|bitcoin-git|13bitcoin/060.14 14847e375 15Wladimir J. van der Laan: qt: pre-rc2 translations update
345 2017-02-23 19:32:36	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.14: 02https://github.com/bitcoin/bitcoin/commit/847e3753a6d6a6ab4dd081e2945cb200faf730d4
346 2017-02-23 19:33:02	0|morcos|Can we figure out when these travis errors started?  Do we get them on personal travis instances?  Can we bisect?  Seems likely somethign changed on our end right?
347 2017-02-23 19:33:13	0|wumpus|#topic travis issues
348 2017-02-23 19:33:17	0|gmaxwell|do we have any idea whats causing that? I assume no one has hit it locally?  I left test bitcoin running in a loop when I first saw it on the off chance it was an ASLR mediated thing that was only hitting travis sometimes.
349 2017-02-23 19:33:34	0|gmaxwell|(no results, of course)
350 2017-02-23 19:33:38	0|jonasschnelli|We recently added a missing ecc_start to bitcoin-tx... but I can't see any relation
351 2017-02-23 19:33:52	0|gmaxwell|jonasschnelli: I don't even see why you mention that?
352 2017-02-23 19:33:52	0|wumpus|I tried to reproduce #9825 for hours on a trusty vm, with five threads for a few hours... but no dice
353 2017-02-23 19:33:53	0|gribble|https://github.com/bitcoin/bitcoin/issues/9825 | Intermittent FAIL: test/test_bitcoin in Travis · Issue #9825 · bitcoin/bitcoin · GitHub
354 2017-02-23 19:34:03	0|wumpus|to bitcoin-tx? yea, that won't make a difference
355 2017-02-23 19:34:27	0|jonasschnelli|gmaxwell: becuase of that "test_bitcoin: key.cpp:300: void ECC_Start(): Assertion `secp256k1_context_sign == __null' failed."?
356 2017-02-23 19:34:33	0|gmaxwell|It looks like test_bitcoin fails before it even really starts. So global constructors or somehting in the C libraries.
357 2017-02-23 19:34:45	0|jeremyrubin|I noticed that one of the builds seems to have some additional bounds checks enabled -- might be nice to enable those across travis tests? Hopefully no code relies on bounds checks/not
358 2017-02-23 19:34:45	0|wumpus|jonasschnelli: that's only a effect of the failure
359 2017-02-23 19:34:51	0|wumpus|jonasschnelli: *everything* after the initial failure fails
360 2017-02-23 19:34:56	0|wumpus|jonasschnelli: secp256k1 is innocent
361 2017-02-23 19:35:02	0|jonasschnelli|ah.. I see.
362 2017-02-23 19:35:24	0|jtimon|perhaps we're forgetting some EEC_stop() somewhere?
363 2017-02-23 19:35:33	0|gmaxwell|no. geesh
364 2017-02-23 19:35:48	0|wumpus|no, I'm fairly sure it doesn't have to do with secp256k1
365 2017-02-23 19:35:59	0|wumpus|it's something done with mutexes before mutexes are initialized
366 2017-02-23 19:36:21	0|jtimon|ok, I really have no idea what's happening
367 2017-02-23 19:36:25	0|wumpus|looks like some kind of race condition, but I have no idea where or what
368 2017-02-23 19:36:48	0|wumpus|if it happens it *always* happens in test_bitcoin, never in bitcoind, bitcoin-cli, bitcoin-tx
369 2017-02-23 19:37:07	0|gmaxwell|I wonder if we could make our travis build script rerun any failing case under gdb so it would print a backtrace?
370 2017-02-23 19:37:29	0|BlueMatt|gmaxwell: probably using coredumps?
371 2017-02-23 19:37:41	0|wumpus|if you rerun it it will probably pass
372 2017-02-23 19:37:44	0|jtimon|perhaps some of the globals initialized in test_bitcoin.cpp ?
373 2017-02-23 19:37:45	0|gmaxwell|or that.
374 2017-02-23 19:37:49	0|jeremyrubin|in theory boost test runner can start gdb
375 2017-02-23 19:37:54	0|jtimon|just thinking out loud again...
376 2017-02-23 19:37:55	0|jonasschnelli|Could it be related to the boost test framework?
377 2017-02-23 19:37:57	0|BlueMatt|eg if it crashes coredump and gdb print all backtraces
378 2017-02-23 19:38:11	0|wumpus|but yes, getting a core file would be useful
379 2017-02-23 19:38:15	0|jeremyrubin|boost test runner can start gdb. I wonder if it reads .gdbinit
380 2017-02-23 19:38:16	0|gmaxwell|BlueMatt: thats probably the right way to go there.
381 2017-02-23 19:38:26	0|wumpus|although you need the executable too, to debug it
382 2017-02-23 19:38:29	0|gmaxwell|jeremyrubin: yes, but if it crashes its probably not in a good state to do so. :P
383 2017-02-23 19:38:33	0|wumpus|and uploading from travis :(
384 2017-02-23 19:38:42	0|BlueMatt|wumpus: i mean we can at least print stack traces
385 2017-02-23 19:38:48	0|gmaxwell|wumpus: just detect the crash in the script and run gdb.
386 2017-02-23 19:38:54	0|gmaxwell|and print the backtraces.
387 2017-02-23 19:39:06	0|wumpus|ok, yes, backtrace would help
388 2017-02-23 19:40:04	0|gmaxwell|do we know when the first of these errors was?
389 2017-02-23 19:40:08	0|wumpus|jtimon: yes, it sounds ilke a global initialisation order fiasco
390 2017-02-23 19:40:29	0|jeremyrubin|could be nice to detect the failing case, and then re-run it under say, valgrind
391 2017-02-23 19:40:48	0|wumpus|no, I don't know. I started getting annoyed by them today, but it's been going on yesterday at least as well
392 2017-02-23 19:41:40	0|wumpus|bisecting this with travis would take *a lot* of patience
393 2017-02-23 19:41:55	0|gmaxwell|that kind of suggests that it's a change on travis' end, no? we haven't had any changes on 0.14 in the past two days that could have caused this?
394 2017-02-23 19:42:07	0|wumpus|I don't think so either.
395 2017-02-23 19:42:17	0|wumpus|the big locking changes are longer ago
396 2017-02-23 19:42:29	0|wumpus|and it didn't start after that
397 2017-02-23 19:42:51	0|jeremyrubin|topic suggest -- code reorganizing (renaming rpc tests, etc)
398 2017-02-23 19:43:06	0|gmaxwell|does something in the travis log report what hardware it ran on?
399 2017-02-23 19:43:07	0|wumpus|still, the question is whether it is a change at travis's end that exposes something in our code
400 2017-02-23 19:43:17	0|gmaxwell|e.g. so we could correlate failures with a specific host?
401 2017-02-23 19:43:18	0|wumpus|or something that is completely broken on their end
402 2017-02-23 19:43:32	0|wumpus|gmaxwell: I'm afraid not. Wasn't able to find it
403 2017-02-23 19:43:50	0|wumpus|I don't think they give access to that information
404 2017-02-23 19:44:01	0|jnewbery|wumpus: why is uploading from travis :( ? is it something you've tried before?
405 2017-02-23 19:44:15	0|wumpus|jnewbery: it's a pit of snakes, security-wise
406 2017-02-23 19:44:22	0|ryanofsky|this is older than 2 days, i first noticed these last friday on 9773: https://github.com/bitcoin/bitcoin/pull/9773#issuecomment-280684263
407 2017-02-23 19:44:41	0|wumpus|jnewbery: we could temporary have it submit files somewhere to debug an issue, I guess
408 2017-02-23 19:45:26	0|jnewbery|It can be configured it to upload artifacts to S3: https://docs.travis-ci.com/user/uploading-artifacts/
409 2017-02-23 19:45:31	0|gmaxwell|jeremyrubin: the issue there is just in terms of provisioning travis with secrets.
410 2017-02-23 19:45:39	0|kanzure|no private environment variables?
411 2017-02-23 19:45:42	0|gmaxwell|er darnit, too many js in here.
412 2017-02-23 19:45:55	0|wumpus|private environment variables don't work for pull requests, the test script could be replaced with anything
413 2017-02-23 19:45:58	0|jeremyrubin|gmaxwell: i was wat-ing :)
414 2017-02-23 19:46:07	0|gmaxwell|kanzure: PR's can steal them.
415 2017-02-23 19:46:09	0|jeremyrubin|Can you get a shell to travis
416 2017-02-23 19:46:22	0|wumpus|including echo $SECRET_CODE or wget https://host/secretcode?$SECRETCODE
417 2017-02-23 19:46:24	0|kanzure|cool. hm.
418 2017-02-23 19:46:31	0|jeremyrubin|(probably against TOS)
419 2017-02-23 19:46:53	0|MarcoFalke|I think you can specify secrets that are valid on branches only, but I might be wrong
420 2017-02-23 19:46:58	0|gmaxwell|jeremyrubin: A assume just open a PR that connects back to you. :P
421 2017-02-23 19:47:09	0|wumpus|lol a reverse shell in a PR
422 2017-02-23 19:47:15	0|BlueMatt|I assume you can, but, yea ToS (not to mention monopolizing their service....)
423 2017-02-23 19:47:33	0|gmaxwell|wait, you're all not mining bitcoins there already?
424 2017-02-23 19:47:42	0|jeremyrubin|I heard someone did that recently right?
425 2017-02-23 19:48:12	0|gmaxwell|in any case, we've wasted most of a perfectly good hour on this. :P
426 2017-02-23 19:48:19	0|wumpus|I like the idea of uploading the executable and core files more. They could be pushed to a private server, no need to openly host them, that meanst here's less reason for people up to no good to inject anything
427 2017-02-23 19:48:57	0|wumpus|the biggest security worry was with hosting the built binaries
428 2017-02-23 19:49:08	0|jtimon|topic code reorganizing?
429 2017-02-23 19:49:14	0|wumpus|bleh
430 2017-02-23 19:49:16	0|wumpus|okay :p
431 2017-02-23 19:49:24	0|wumpus|#topic code reorganizing
432 2017-02-23 19:49:26	0|jnewbery|suggested (marginally related) topic: code coverage and benchmark tracking
433 2017-02-23 19:49:29	0|gmaxwell|we should ask travis for a feature that sets an enviroment variable to H(project secret || commit hash) ... and then we could have something whitelist uploads from specific PRs (e.g. by known people)
434 2017-02-23 19:49:38	0|jtimon|it's 10 mins, so no time for a big topic I think
435 2017-02-23 19:50:05	0|jeremyrubin|I have a POC branch which moves most of the pure data structures  to a datastructures dir.
436 2017-02-23 19:50:08	0|gmaxwell|Rename rpctests to tests rename test_bitcoin to useless_thing_that_crashes_in_travis. Done.
437 2017-02-23 19:50:37	0|wumpus|gmaxwell: yep
438 2017-02-23 19:50:40	0|jtimon|jeremyrubin: you mean including things like CTransaction and CBlockHeader?
439 2017-02-23 19:50:42	0|luke-jr|jeremyrubin: that doesn't sound like the right direction
440 2017-02-23 19:50:45	0|jeremyrubin|no
441 2017-02-23 19:50:50	0|jeremyrubin|non-bitcoin specific ones
442 2017-02-23 19:50:52	0|gmaxwell|jeremyrubin: really? datastructures?  shall we have a file called functions.cpp and a file called variables.cpp too? :P
443 2017-02-23 19:50:59	0|jeremyrubin|E.g., prevector
444 2017-02-23 19:51:00	0|luke-jr|XD
445 2017-02-23 19:51:09	0|gmaxwell|oh you mean things like effective language extensions.
446 2017-02-23 19:51:09	0|luke-jr|jeremyrubin: oh, okay, that sounds less bad
447 2017-02-23 19:51:14	0|jtimon|I would prefer to move prevector to the consensus dir
448 2017-02-23 19:51:30	0|wumpus|yea, prevector is consensus critical
449 2017-02-23 19:51:33	0|gmaxwell|suggests that the name still isn't good in that luke and I misunderstood it immediately. :P
450 2017-02-23 19:51:42	0|jeremyrubin|so is secp256k1 ;)
451 2017-02-23 19:51:51	0|sipa|so is libc
452 2017-02-23 19:51:53	0|jtimon|like in https://github.com/bitcoin/bitcoin/pull/8328
453 2017-02-23 19:52:00	0|wumpus|yes, we're not renaming secp256k1 are we
454 2017-02-23 19:52:01	0|luke-jr|move prevector to boost
455 2017-02-23 19:52:03	0|gmaxwell|Okay, so step one we move libc under consensus/ ...
456 2017-02-23 19:52:34	0|jeremyrubin|Anyways, I think it would be nice to move things like that, which could later be made upstream repos
457 2017-02-23 19:52:40	0|wumpus|I don't think this is going anywhere, everyone has a different opinoin on what file to put where
458 2017-02-23 19:52:48	0|gmaxwell|lpad.js.
459 2017-02-23 19:53:12	0|luke-jr|Does prevector have any usage outside consensus?
460 2017-02-23 19:53:20	0|jeremyrubin|I think the reason I'd want that is it makes it easier to have more exhaustive testing and also allows other users to more easily use such datastructures
461 2017-02-23 19:53:31	0|sipa|luke-jr: it probably should :)
462 2017-02-23 19:53:41	0|wumpus|do we have any unique data structures that anyone else inthe world would want to use?
463 2017-02-23 19:53:43	0|jtimon|jeremyrubin: yeah I would like libconsensus to be an "upstream repo" like libsecp256k1, but we would need to complete it first
464 2017-02-23 19:53:56	0|gmaxwell|jeremyrubin: I don't think any of us care to maintain things like prevector for other usage. Making a good library takes a tremendous amount of work.
465 2017-02-23 19:54:01	0|wumpus|I don't think a bitcoin-datastructures library makes sense
466 2017-02-23 19:54:03	0|wumpus|right
467 2017-02-23 19:54:18	0|wumpus|if we offer a library it should be something useful to bitcoin users
468 2017-02-23 19:54:40	0|gmaxwell|Obviously if the author of something like that wants to create a library for other usage, thats fine! but not a project priority.
469 2017-02-23 19:54:41	0|wumpus|like a wallet library, or extend libconsensus, ...
470 2017-02-23 19:55:16	0|wumpus|sure, you can do whatever you want with the files in the repository, if you need it in your project you can make a library out of it for your own use, or just copy the file, etc
471 2017-02-23 19:55:20	0|gmaxwell|from a code org perspective I don't see a problem with moving things like prevector, limitedmap into a utility function directory.. With just the understanding that many of those are used in consensus code too.
472 2017-02-23 19:55:28	0|wumpus|not everything needs to be maintained as a library
473 2017-02-23 19:55:29	0|jtimon|but since each dev seems to have a different idea of what a "complete libconsensus" should look like...
474 2017-02-23 19:56:06	0|wumpus|gmaxwell: me neither
475 2017-02-23 19:56:09	0|kallewoof|Compartmentalizing bitcoin into separate modules seemed like a plan but maybe not shared by everyone. If it is a shared plan restructuring file places seems important.
476 2017-02-23 19:56:09	0|luke-jr|I don't mind it, but IMO more important to work toward more useful library splitting
477 2017-02-23 19:56:15	0|sipa|gmaxwell: agree, some things are generic enough that they can be seen as extensions of the standard libraries
478 2017-02-23 19:56:44	0|gmaxwell|sipa: e.g. someday libstdc++ could get something that generalizes prevector, if it did, we'd drop prevector and use that.
479 2017-02-23 19:57:00	0|sipa|c++23
480 2017-02-23 19:57:05	0|gmaxwell|(well STL technically, I guess, point remains)
481 2017-02-23 19:57:05	0|jonasschnelli|heh
482 2017-02-23 19:57:33	0|gmaxwell|sipa: C++23 will just integrate libconsensus of course.  template cryprocurrency.
483 2017-02-23 19:57:41	0|wumpus|hehe
484 2017-02-23 19:57:43	0|jeremyrubin|Well that's my point kinda
485 2017-02-23 19:57:53	0|jnewbery|suggested topic: code coverage and benchmark tracking
486 2017-02-23 19:57:54	0|jeremyrubin|the consensus things that aren't overly bitcoin-specific
487 2017-02-23 19:57:55	0|gmaxwell|Except I was making it as a joke. :P
488 2017-02-23 19:58:02	0|wumpus|jnewbery: next week
489 2017-02-23 19:58:12	0|jeremyrubin|Facebook's folly lib is kinda like that
490 2017-02-23 19:58:14	0|wumpus|the meeting is about to close
491 2017-02-23 19:58:24	0|sipa|anyone have any last words?
492 2017-02-23 19:58:28	0|gmaxwell|jnewbery: we can talk about about it after the meeting and discuss further next week. :)
493 2017-02-23 19:58:46	0|jnewbery|gmaxwell: sounds good
494 2017-02-23 19:58:49	0|wumpus|#endmeeting
495 2017-02-23 19:58:53	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-02-23-19.00.log.html
496 2017-02-23 19:58:53	0|lightningbot|Meeting ended Thu Feb 23 19:58:51 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
497 2017-02-23 19:58:53	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-02-23-19.00.html
498 2017-02-23 19:58:53	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-02-23-19.00.txt
499 2017-02-23 19:59:05	0|BlueMatt|ok, #topic code coverage and benchmark tracking
500 2017-02-23 19:59:22	0|jeremyrubin|I wrote a benchdiff tool a while back
501 2017-02-23 19:59:23	0|MarcoFalke|ACK on benchmark tracking
502 2017-02-23 19:59:28	0|gmaxwell|jeremyrubin: the history of corporate soup libraries isn't really good, a lot of them just become abandoneware... and we have some many things to worry about that cooking up more libraries is really ... not the project's priority even if it would be good in an abstract sense.
503 2017-02-23 20:00:00	0|gmaxwell|In some cases like libsecp256k1 it can be strategic to build something for general use. But thats case by case.
504 2017-02-23 20:00:05	0|wumpus|folly is unfocused
505 2017-02-23 20:00:18	0|jnewbery|is anyone doing coverage? Anyone tried using coveralls or codecov or ... for tracking code coverage?
506 2017-02-23 20:00:20	0|jeremyrubin|Sure, the point was not really about having it be a separate library
507 2017-02-23 20:00:26	0|jeremyrubin|but for increasing testing
508 2017-02-23 20:00:31	0|wumpus|'random grabbag of data structures' libraries don't tend to be used a lot
509 2017-02-23 20:00:33	0|kanzure|i thought it was already known that code coverage is low
510 2017-02-23 20:00:39	0|gmaxwell|jnewbery: we have configure script setup for lcov. It works.
511 2017-02-23 20:00:42	0|wumpus|even if the data structures in it are genius
512 2017-02-23 20:01:21	0|luke-jr|wumpus: we'd use it
513 2017-02-23 20:01:26	0|jnewbery|gmaxwell: it works is a good start. Which way does code coverage go over time?
514 2017-02-23 20:01:26	0|wumpus|jeremyrubin: the problem is that you also get lots of issues for unrelated uses
515 2017-02-23 20:01:40	0|gmaxwell|And our expirence from libsecp256k1 suggests that there has been relatively little project value from making it generally usable.  :(  basically many things that really should use it simply do not. And what does use it almost never reports interesting feedback or provides useful testing. :(
516 2017-02-23 20:01:42	0|luke-jr|wumpus: if nothing else, libraries can reduce the binary download size by not duplicating the code between our 4 or 5 programs
517 2017-02-23 20:01:49	0|kanzure|jnewbery: there's a lot of missing unit tests. they don't exist; go write them.
518 2017-02-23 20:01:57	0|wumpus|jeremyrubin: right now the code only supports our use case, it doens't have to balloon to everyone's features and favorite other things
519 2017-02-23 20:01:58	0|gmaxwell|jnewbery: it's been going up. well at least the 'rpc tests' improvements increased it considerably.
520 2017-02-23 20:02:02	0|luke-jr|gmaxwell: some things which really should use it seem to?
521 2017-02-23 20:02:07	0|cfields|kanzure: he has been :)
522 2017-02-23 20:02:14	0|kanzure|cfields: shows what i know
523 2017-02-23 20:02:20	0|jnewbery|cfields: :)
524 2017-02-23 20:02:47	0|wumpus|luke-jr:sure, internal libraries for organization without exposing them to the outside or making them official APIs
525 2017-02-23 20:02:52	0|wumpus|luke-jr: we already have those
526 2017-02-23 20:03:02	0|cfields|kanzure: you're right to point out that we're missing lots of coverage, ofc.
527 2017-02-23 20:03:15	0|gmaxwell|luke-jr: e.g. the horrific python stuff is used much more commonly.. and various embedded devices reinvented the wheel creating big sidechannel vulnerablities along the way.
528 2017-02-23 20:03:16	0|kanzure|cfields: prolly not a good excuse to not do constant coverage reports, hehe
529 2017-02-23 20:03:17	0|wumpus|luke-jr: turn them to dlls and you could reduce download size a bit
530 2017-02-23 20:03:29	0|cfields|heh
531 2017-02-23 20:03:33	0|jnewbery|kanzure: I'd like to do more. Doing coverage once is good. Tracking it across releases is better
532 2017-02-23 20:03:43	0|luke-jr|gmaxwell: eg JoinMarket seems to use it?
533 2017-02-23 20:03:49	0|wumpus|luke-jr: not by much I think as most of the duplication will tend to get compressed out
534 2017-02-23 20:03:50	0|luke-jr|or was it Electrum
535 2017-02-23 20:03:51	0|jnewbery|I'd also like to have historic data about benchmarks
536 2017-02-23 20:03:53	0|cfields|jnewbery: i'd be very curious to see if something like coveralls could be hooked up easily-ish
537 2017-02-23 20:04:06	0|gmaxwell|jnewbery: ideally we'd be at a point where travis could fail builds that drop coverage too much, but the existing tests do not have high enough coverage reliably to make the workthwhile.
538 2017-02-23 20:04:14	0|luke-jr|wumpus: IMO libconsensus will be more significant
539 2017-02-23 20:04:18	0|jeremyrubin|Benchdiff tool is here: https://github.com/JeremyRubin/bitcoin/tree/benchdiff
540 2017-02-23 20:04:25	0|gmaxwell|luke-jr: yes, after I nagged them to move off some crazily vulnerable python code that was found on the internet.
541 2017-02-23 20:04:32	0|luke-jr|XD
542 2017-02-23 20:04:44	0|gmaxwell|luke-jr: e.g. code they were using would accept the signature 0,0 as valid for any pubkey+message.
543 2017-02-23 20:04:49	0|jnewbery|gmaxwell: I'm not aiming for ideal just yet. Just a general sense of which direction we're moving in
544 2017-02-23 20:05:09	0|wumpus|comparing benchmarks would need a machine dedicated to just that
545 2017-02-23 20:05:50	0|jnewbery|cfields: do you know if anyone has tried hooking up coveralls?
546 2017-02-23 20:05:51	0|BlueMatt|benchmarks would have to happen on custom infrastructure, but coveralls or something would be nice
547 2017-02-23 20:05:51	0|gmaxwell|wumpus: we could run benchmarks in a cpu simulator... at glacial speed but get consistent results. :P (this is actually reasonable to do for things like in the benchmark tool)
548 2017-02-23 20:05:54	0|wumpus|comparing results from different machines or from VMs would be pointless
549 2017-02-23 20:06:04	0|BlueMatt|if its easy to hook up (and doesnt require stupid shit like write permissions on your repo), i dont see why not?
550 2017-02-23 20:06:35	0|cfields|jnewbery: not that i'm aware of. I think the gcov stuff on our side needs a bit of love first, I'd be happy to help out there.
551 2017-02-23 20:06:36	0|wumpus|gmaxwell: ah yes a cycle correct simulator
552 2017-02-23 20:06:41	0|gmaxwell|I've been trying to get a simulator restup for libsecp256k1, where we can use it to verify constant-timeness of the compiled result.
553 2017-02-23 20:07:19	0|sipa|restup?
554 2017-02-23 20:07:20	0|jnewbery|ok, I'll try to hook up coveralls on my repo before next week's meeting
555 2017-02-23 20:07:22	0|gmaxwell|(I have the test working locally but haven't figured out how to automate it, will likely need to modify the simulator)
556 2017-02-23 20:07:27	0|gmaxwell|sipa: setup.
557 2017-02-23 20:07:30	0|jeremyrubin|diff
558 2017-02-23 20:07:32	0|wumpus|riscv has a cycle-accurate simulator
559 2017-02-23 20:07:36	0|jeremyrubin|crap sorry
560 2017-02-23 20:08:18	0|gmaxwell|wumpus: yes, though it doesn't simulate dram so I found it wasn't good enough for my libsecp256k1 testing. :P there is a 'cycle accurate' simulator of abstract x86_64 which doesn't exactly match any particular cpu but it close enough.
561 2017-02-23 20:08:30	0|Chris_Stewart_5|jnewbery: would love to see that on our repo
562 2017-02-23 20:08:34	0|jeremyrubin|here's the POC of the move datastructures/utils to a separate dir btw https://github.com/JeremyRubin/bitcoin/tree/move-to-libraries (may need rebase)
563 2017-02-23 20:08:56	0|gmaxwell|(I also tried the riscv one though before realizing it didn't do dram... it's crazy, it's a seperate compile target for the HDL)
564 2017-02-23 20:09:01	0|wumpus|gmaxwell: I'll shut up, seems you did much more research into this :)
565 2017-02-23 20:09:23	0|Chris_Stewart_5|jnewbery: I know isle2983 is interested in this as well -- not sure how much free time he has but might be worth collaborating
566 2017-02-23 20:09:23	0|jeremyrubin|i only did a few things just as an example -- editing lots of files isn't super fun :p
567 2017-02-23 20:09:29	0|gmaxwell|wumpus: well my research is mostly for a weird thing, trying to setup a CI test that catches the compiler undermining the constant time behavior of libsecp256k1's private key operations.
568 2017-02-23 20:10:12	0|jnewbery|Chris_Stewart_5: thanks. I'll ping him
569 2017-02-23 20:10:28	0|wumpus|in any case +1 for hooking up coveralls, seems like a small thing to do with potentially large payoff
570 2017-02-23 20:10:42	0|Chris_Stewart_5|wumpus: strongly agree.
571 2017-02-23 20:11:05	0|jeremyrubin|gmaxwell: isn't that pretty tough to do given modern pipelining?
572 2017-02-23 20:12:31	0|wumpus|gmaxwell: that HDL tool is pretty neat in itself, allowing generating customized riscv cores on demand, but yes using it to generate c++ seems a bit crazy
573 2017-02-23 20:13:45	0|wumpus|jeremyrubin: and don't forget branch prediction
574 2017-02-23 20:14:18	0|jeremyrubin|wumpus: that's a part of the pipeline
575 2017-02-23 20:14:34	0|gmaxwell|jeremyrubin: libsecp256k1 private key operations are constant time on current intel cpus. It was not that hard. The code just has to be completely free of data dependant branches, data dependant memory accesses, etc.
576 2017-02-23 20:15:38	0|gmaxwell|for example, sha256's compression function is a function that is naturally constant time, even a trivial implementation gets that right.
577 2017-02-23 20:15:44	0|gmaxwell|Just write all your code to look like that. :P
578 2017-02-23 20:16:11	0|gmaxwell|Though the compiler could still screw you over if it gets too smart, which is why I want ci support for testing it.
579 2017-02-23 20:17:14	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #9842: Fix RPC failure testing (continuation of #9707) (06master...06rpctestassert2) 02https://github.com/bitcoin/bitcoin/pull/9842
580 2017-02-23 20:18:25	0|MarcoFalke|BlueMatt: Is coveralls the thing that spams a comment on every pull request?
581 2017-02-23 20:18:36	0|BlueMatt|MarcoFalke: I sure hope not?
582 2017-02-23 20:18:46	0|wumpus|I don't think that's necessary
583 2017-02-23 20:18:48	0|BlueMatt|I'd hope it can integrate with github's ci status thing
584 2017-02-23 20:18:51	0|wumpus|it can integrate into github
585 2017-02-23 20:19:40	0|MarcoFalke|Sound good when this is possible.
586 2017-02-23 20:20:00	0|MarcoFalke|re: test_bitcoin failures
587 2017-02-23 20:20:08	0|MarcoFalke|It is an uninitialized read
588 2017-02-23 20:20:21	0|MarcoFalke|because g_conman is not set up in the unit tests, I assume
589 2017-02-23 20:20:31	0|MarcoFalke|*g_connman
590 2017-02-23 20:23:44	0|wumpus|MarcoFalke: mh that could be it
591 2017-02-23 20:24:23	0|gmaxwell|perhaps someday bitcoin core can have coverage like: https://people.xiph.org/~greg/libsecp256k1-coverage/src/index.html
592 2017-02-23 20:25:16	0|wumpus|could you add it? :)
593 2017-02-23 20:26:07	0|wumpus|that's pretty similar to coveralls output
594 2017-02-23 20:26:13	0|Chris_Stewart_5|MarcoFalke: I think coverall is what you are thinking of wrt comments on pull requests, see: https://github.com/bitcoin-s/bitcoin-s-core/pull/60
595 2017-02-23 20:26:25	0|BlueMatt|wumpus: I think he meant the mostly-100% coverage indicators there :p
596 2017-02-23 20:26:29	0|Chris_Stewart_5|not sure if it is configurable or not, honestly haven't played with it too much
597 2017-02-23 20:26:45	0|wumpus|BlueMatt: oh okay
598 2017-02-23 20:26:52	0|Chris_Stewart_5|but I think it is extremely helpful for beginners to figure out where to contribute too
599 2017-02-23 20:26:55	0|MarcoFalke|Chris_Stewart_5: Yes, this is terrible
600 2017-02-23 20:26:58	0|jeremyrubin|Can implement the trump policy: every line of new code must test 2 other lines of code
601 2017-02-23 20:27:22	0|BlueMatt|jeremyrubin: do we, then, need to test tests?
602 2017-02-23 20:27:38	0|gmaxwell|the code is the test of the tests.
603 2017-02-23 20:27:42	0|gmaxwell|go break the code, tests should fail.
604 2017-02-23 20:27:56	0|BlueMatt|gmaxwell: yes, we should have test harnesses for that :P
605 2017-02-23 20:28:19	0|gmaxwell|I still have not found any good tools for C.  I have something that belongs in a lovecraftian horror novel...
606 2017-02-23 20:28:41	0|jeremyrubin|can we get rid of the code
607 2017-02-23 20:28:49	0|jeremyrubin|and just gen it from tests
608 2017-02-23 20:29:06	0|wumpus|mauling the source code in unspeakable ways to make tests fail
609 2017-02-23 20:29:15	0|jnewbery|gmaxwell: that report is a beautiful thing. So much green
610 2017-02-23 20:29:19	0|gmaxwell|(A script that systemtatically makes 1 byte changes to the source code, then sees if it compiles, and if it does checks if the stripped binary matches the original, and skips it.. and otherwise checks if tests fail....)
611 2017-02-23 20:29:38	0|BlueMatt|gmaxwell: yea..........
612 2017-02-23 20:29:56	0|gmaxwell|jnewbery: it's actually better than the report shows.. that report is only with running the tests at the defaults, they get a bit more coverage when cranked up.
613 2017-02-23 20:35:05	0|jeremyrubin|Is there any coverage tools that let you see if you execute a branch with multiple values?
614 2017-02-23 20:35:18	0|jeremyrubin|E.g., doing concolic execution of some kind would be cool
615 2017-02-23 20:35:33	0|jeremyrubin|klee?
616 2017-02-23 20:40:15	0|bitcoin-git|13bitcoin/060.14 143b2f7fd 15Wladimir J. van der Laan: doc: Add authors and changes since rc1 to release notes
617 2017-02-23 20:40:15	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.14: 02https://github.com/bitcoin/bitcoin/commit/3b2f7fdcaea36c8c5c93b21030d4e2327d2b6e8c
618 2017-02-23 20:41:55	0|wumpus|* [new tag]         v0.14.0rc2 -> v0.14.0rc2
619 2017-02-23 20:42:09	0|BlueMatt|hey-o
620 2017-02-23 20:42:34	0|achow101|yay
621 2017-02-23 20:42:57	0|sipa|wee
622 2017-02-23 20:43:21	0|achow101|I hope gitian works this time (but it probably won't)
623 2017-02-23 20:43:54	0|wumpus|well there were no changes to gitian since 0.14.0rc1, so if it didn't work for you it probably still won't
624 2017-02-23 20:44:10	0|wumpus|but you can try
625 2017-02-23 20:44:20	0|sipa|gmaxwell: it looks like the sha1 collision that google produced took 2^63 sha invocations
626 2017-02-23 20:44:43	0|cfields|damn, just pushed release notes spelling fix :(
627 2017-02-23 20:45:01	0|wumpus|cfields: there's no hurry ,release notes changes can go in until final
628 2017-02-23 20:45:19	0|wumpus|and between the last rc and final
629 2017-02-23 20:45:34	0|cfields|ok
630 2017-02-23 20:47:53	0|bitcoin-git|13bitcoin/060.14 1495e68df 15Cory Fields: release: add a few performance-related notes
631 2017-02-23 20:47:53	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 060.14: 02https://github.com/bitcoin/bitcoin/compare/3b2f7fdcaea3...f00429666c60
632 2017-02-23 20:47:54	0|bitcoin-git|13bitcoin/060.14 14f004296 15Wladimir J. van der Laan: Merge #9787: release: add a few performance-related notes...
633 2017-02-23 20:47:54	0|cfields|I'm doing a vanilla, all defaults, public p2p sync of 0.13/0.14 nodes on ec2 with 4cores/16gb ram. I think that's a common enough use-case. If anyone would like to bench under different conditions, please go for it
634 2017-02-23 20:50:27	0|wumpus|cfields: at least it's kind of standardized
635 2017-02-23 20:50:56	0|achow101|cfields: I think 8gb ram is a more likely scenario
636 2017-02-23 20:51:40	0|luke-jr|note 32-bit builds can't use much RAM, but I don't think we care so much about that
637 2017-02-23 20:54:42	0|wumpus|let's not start arguing his choice of benchmark machine
638 2017-02-23 20:55:00	0|wumpus|if you want to benchmark on something else, go ahead
639 2017-02-23 21:25:17	0|achow101|woohoo! First again! (but there's probably an issue with osx)
640 2017-02-23 21:49:51	0|jtimon|re style, I wish I could uncomment ;; (add-hook 'before-save-hook 'delete-trailing-whitespace)
641 2017-02-23 22:22:45	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #9843: Fix segwit getblocktemplate test (06master...06fixsegwitgetblocktemplate) 02https://github.com/bitcoin/bitcoin/pull/9843
642 2017-02-23 22:26:06	0|gmaxwell|I think we should not have that behavior. We should not make mining catch fire when segwit activates.
643 2017-02-23 22:33:30	0|luke-jr|gmaxwell: in other words, we should support non-segwit mining after it activates?
644 2017-02-23 22:33:58	0|luke-jr|(that'd be somewhat non-trivial FWIW)
645 2017-02-23 22:35:30	0|luke-jr|basically we'd need to teach CreateNewBlock to filter out segwit txs, and then do some magic with GBT caching
646 2017-02-23 22:38:02	0|luke-jr|IIRC last time it was discussed, the conclusion was to not support it; I forget where that convo was tho
647 2017-02-23 22:57:45	0|cfields|achow101: no match :(
648 2017-02-23 23:02:42	0|achow101|cfields: on osx? again?
649 2017-02-23 23:02:54	0|cfields|achow101: yep :(
650 2017-02-23 23:02:57	0|cfields|still building the rest
651 2017-02-23 23:03:17	0|achow101|*sigh* it's still a problem
652 2017-02-23 23:05:10	0|achow101|I'll see if it does the alternating thing like last time
653 2017-02-23 23:18:21	0|gmaxwell|luke-jr: yes, we should.
654 2017-02-23 23:18:39	0|gmaxwell|luke-jr: the only harm is you won't include segwit transactions... and we can whine at miners later to fix themselves.
655 2017-02-23 23:18:46	0|gmaxwell|better to have some segwit txn rather than none.
656 2017-02-23 23:19:03	0|gmaxwell|We should also set the version bit, even if you're not sending the flag.
657 2017-02-23 23:26:00	0|bitcoin-git|[13bitcoin] 15jtimon opened pull request #9845: RPC: cleanups in rpc/server (06master...060.15-extern-rpc-server) 02https://github.com/bitcoin/bitcoin/pull/9845
658 2017-02-23 23:26:27	0|jtimon|jonasschnelli: am I missing something about the wallet in ^^, I hope not
659 2017-02-23 23:56:39	0|fanquake|Speaking of benchmarking, can anyone tell me on "average" how much slower reindexing is compared to sync?
660 2017-02-23 23:57:28	0|fanquake|Ive managed to get qt reindexing at ~3%/hr, which seems very slow. This machine has performed a -reindex-chainstate in <3 hrs before.
661 2017-02-23 23:58:00	0|fanquake|* less than 3 hrs
662 2017-02-23 23:59:24	0|sipa|fanquake: reindex-chainstate should be strictly faster than sync