12016-11-16T00:05:21 *** fengling has quit IRC
22016-11-16T00:19:24 <thrasher`> thanks wumpus & sdaftuar :)
32016-11-16T00:27:38 *** Giszmo has joined #bitcoin-core-dev
42016-11-16T00:40:15 *** btcdrak has joined #bitcoin-core-dev
52016-11-16T00:48:34 *** Chris_Stewart_5 has joined #bitcoin-core-dev
62016-11-16T01:25:08 *** fengling has joined #bitcoin-core-dev
72016-11-16T02:02:38 *** Ylbam has quit IRC
82016-11-16T02:23:46 *** Giszmo has quit IRC
92016-11-16T03:16:19 *** LeMiner2 has joined #bitcoin-core-dev
102016-11-16T03:17:24 *** DigiByteDev has joined #bitcoin-core-dev
112016-11-16T03:18:40 *** jtimon has quit IRC
122016-11-16T03:18:40 *** LeMiner has quit IRC
132016-11-16T03:18:40 *** LeMiner2 is now known as LeMiner
142016-11-16T03:20:22 *** DigiByteDev_ has joined #bitcoin-core-dev
152016-11-16T03:20:30 *** Chris_Stewart_5 has quit IRC
162016-11-16T03:22:45 *** DigiByteDev has quit IRC
172016-11-16T03:22:45 *** DigiByteDev_ is now known as DigiByteDev
182016-11-16T03:27:06 *** Alopex has quit IRC
192016-11-16T03:28:11 *** Alopex has joined #bitcoin-core-dev
202016-11-16T03:37:20 *** DigiByteDev has quit IRC
212016-11-16T03:56:58 *** JackH has quit IRC
222016-11-16T04:04:24 *** DigiByteDev has joined #bitcoin-core-dev
232016-11-16T04:29:06 *** Alopex has quit IRC
242016-11-16T04:29:54 *** fengling has quit IRC
252016-11-16T04:30:11 *** Alopex has joined #bitcoin-core-dev
262016-11-16T04:39:44 *** DigiByteDev has quit IRC
272016-11-16T04:41:16 *** Alopex has quit IRC
282016-11-16T04:42:22 *** Alopex has joined #bitcoin-core-dev
292016-11-16T05:07:07 *** Alopex has quit IRC
302016-11-16T05:08:12 *** Alopex has joined #bitcoin-core-dev
312016-11-16T05:09:46 *** arowser has quit IRC
322016-11-16T05:11:11 *** arowser has joined #bitcoin-core-dev
332016-11-16T05:17:40 *** Chris_Stewart_5 has joined #bitcoin-core-dev
342016-11-16T05:20:32 *** arowser has quit IRC
352016-11-16T05:21:11 *** Alopex has quit IRC
362016-11-16T05:21:54 *** arowser has joined #bitcoin-core-dev
372016-11-16T05:22:17 *** Alopex has joined #bitcoin-core-dev
382016-11-16T05:25:17 *** xiangfu has quit IRC
392016-11-16T05:25:33 *** xiangfu has joined #bitcoin-core-dev
402016-11-16T05:30:07 *** arowser has quit IRC
412016-11-16T05:30:35 *** fengling has joined #bitcoin-core-dev
422016-11-16T05:31:33 *** arowser has joined #bitcoin-core-dev
432016-11-16T05:38:02 *** btcdrak has quit IRC
442016-11-16T05:38:11 *** Alopex has quit IRC
452016-11-16T05:39:17 *** Alopex has joined #bitcoin-core-dev
462016-11-16T05:47:53 <achow101> do any of the rpcs return how many blocks have signalled support for a soft fork?
472016-11-16T05:48:11 <sipa> getblockchaininfo
482016-11-16T05:48:18 <sipa> though i'm not sure it supports bip9
492016-11-16T05:48:23 *** DigiByteDev has joined #bitcoin-core-dev
502016-11-16T05:48:57 <achow101> it only gives a "since" block, not actual counts
512016-11-16T05:53:54 *** DigiByteDev has quit IRC
522016-11-16T06:07:07 *** Alopex has quit IRC
532016-11-16T06:08:12 *** Alopex has joined #bitcoin-core-dev
542016-11-16T06:08:24 *** DigiByteDev has joined #bitcoin-core-dev
552016-11-16T06:17:59 <sipa> achow101: http://bitcoin.sipa.be/ver9-10k.png
562016-11-16T06:18:20 <sipa> it's not counted exactly according to consensus
572016-11-16T06:21:24 *** wolfspraul has quit IRC
582016-11-16T06:22:17 *** wolfspraul has joined #bitcoin-core-dev
592016-11-16T06:27:25 *** DigiByteDev has quit IRC
602016-11-16T07:08:01 *** btcdrak has joined #bitcoin-core-dev
612016-11-16T07:09:01 *** fengling has quit IRC
622016-11-16T07:14:01 *** fengling has joined #bitcoin-core-dev
632016-11-16T07:15:33 *** justan0theruser has joined #bitcoin-core-dev
642016-11-16T07:18:17 *** justanotheruser has quit IRC
652016-11-16T07:35:20 *** jannes has joined #bitcoin-core-dev
662016-11-16T07:45:28 *** paveljanik has quit IRC
672016-11-16T08:03:21 * luke-jr cowers in fear of the new Bitcoin Core configure that yells at you :P
682016-11-16T08:15:09 <wumpus> bitcoin: where even the configure scripts yell at you
692016-11-16T08:17:36 *** Ylbam has joined #bitcoin-core-dev
702016-11-16T08:19:24 <wumpus> you think the build system is agressive? We'll introduce you to some of our community members :p
712016-11-16T08:21:34 <sipa> we have this guy called Travis who continuously yells at very active developers
722016-11-16T08:22:13 <wumpus> which reminds me, there is this guy called 'Coveralls' in some projects, maybe we should invite him too
732016-11-16T08:22:16 <luke-jr> lol
742016-11-16T08:22:49 <wumpus> I do think he's a bit on the spammy side tho, like our old pulltester
752016-11-16T08:23:27 * jonasschnelli likes Coveralls
762016-11-16T08:24:18 <jonasschnelli> It someone encourages contributors to write more tests (even if coverage does not prove correctness)
772016-11-16T08:27:06 <wumpus> yeah coverage is especially good in languages such as python where many typos and such are only found by executing some code
782016-11-16T08:27:22 <gmaxwell> speaking of yelling, would people be opposed to me adding a ifdef check so that if daemon is not either defined or failed to be detected the compiler errors out? I keep running into not-supported-on-your-OS when switching between master and 0.13. :) That fact that it completes the build and only fails at runtime is annoying (esp because the build takes a long time on my laptop)
792016-11-16T08:27:45 <wumpus> though it helps for C too I guess, having coverage in the first place is essential for complete tests, just not sufficient
802016-11-16T08:28:15 <gmaxwell> C++ makes smart coverage harder because all the boilerplate stuff often adds unreachable code. :(
812016-11-16T08:29:02 <wumpus> gmaxwell: no problem
822016-11-16T08:29:31 <wumpus> though you *really* should make a habit of re-running autogen when changing branches
832016-11-16T08:30:16 * wumpus has different repo checkouts for different major versions to avoid problems like that
842016-11-16T08:30:33 <wumpus> also saved me from committing a patch against the wrong branch at least once :)
852016-11-16T08:31:02 <gmaxwell> libsecp256k1's tests are something like 99.2% line coverage, 95.3% branch coverage. ... a few branches can't be reached without solving intractable crypto problems. alas. :(
862016-11-16T08:31:26 <gmaxwell> wumpus: I figure if it keeps hitting me it will hit random users who find it more surprising. :)
872016-11-16T08:32:39 <wumpus> I wish autoconf would just yell if your generated files are out of date with the build system files
882016-11-16T08:32:47 <jonasschnelli> For C: high coverage together with a CI valgrind memleak check is desirable IMO
892016-11-16T08:33:10 <wumpus> and fuzzing, of course
902016-11-16T08:33:30 <wumpus> gmaxwell: anyhow, no problem with adding that, it'd also catch problems with people forgetting to include configure.h
912016-11-16T08:33:37 <gmaxwell> memleak? seldom have memleaks in interesting code. Valgrind's undefined behavior checking, OTOH. Is super great. :)
922016-11-16T08:33:46 <gmaxwell> wumpus: thanks okay, I'll do so.
932016-11-16T08:34:20 *** DigiByteDev has joined #bitcoin-core-dev
942016-11-16T08:34:56 <gmaxwell> for bitcoin I do think we need DRD run on it more often, it's just a bit frustrating because its so slow.
952016-11-16T08:35:32 <wumpus> at least make sure you run valgrind against the optimized executable not the -O0 debugging one :-)
962016-11-16T08:36:51 <sipa> http://bitcoin.sipa.be/ver9-10k.png
972016-11-16T08:36:54 <wumpus> but yes valgrind is slow in any case, though it's surprisingly fast if you realize what it does in the background, converting executed code blocks to VEX and back to machine instructions on the fly
982016-11-16T08:37:08 <gmaxwell> yes, it's amazing.
992016-11-16T08:37:10 <sipa> (-ever, -50k, -2k also exist)
1002016-11-16T08:37:53 <wumpus> sipa: nice!
1012016-11-16T08:39:06 <TD-Linux> sipa, having them on the index page would also be nice :)
1022016-11-16T08:39:25 <gmaxwell> there is an index page?
1032016-11-16T08:39:37 <sipa> TD-Linux: that would involve loading my html knowledge back from swap space
1042016-11-16T08:40:19 <sipa> gmaxwell: http://bitcoin.sipa.be
1052016-11-16T08:41:05 <sipa> did we cross 2 exahash/s?
1062016-11-16T08:41:59 <jonasschnelli> sipa: come one! s/hash rate</a></li>/hash rate</a></li><li class="hilight"><a accesskey="h" href="http://bitcoin.sipa.be/ver9-10k.png">ver9-10k</a></li>/
1072016-11-16T08:42:24 <jonasschnelli> *come on :-)
1082016-11-16T08:42:27 <sipa> jonasschnelli: i'll want a separate page with thumbnails and stuffs
1092016-11-16T08:42:37 <wumpus> yes I was about to say, someone has got to have that knowledge in their ready memory and could provide a patch
1102016-11-16T08:42:55 *** CubicEarth has joined #bitcoin-core-dev
1112016-11-16T08:43:06 <sipa> https://github.com/sipa/bitcoin-stats
1122016-11-16T08:43:15 <jonasschnelli> Yeah. Migrate the non-pngs html stuff to bitcoincore.org
1132016-11-16T08:43:45 <wumpus> not me though, my html knowledge is in the 2000-2004 archive in deep storage
1142016-11-16T08:43:45 <jonasschnelli> Yeah. Perl. How did I missed this.
1152016-11-16T08:44:07 <sipa> also C
1162016-11-16T08:44:10 <sipa> and bash
1172016-11-16T08:44:19 <sipa> and bash that generates gnuplot
1182016-11-16T08:46:15 <sipa> ;;nethash
1192016-11-16T08:46:16 <gribble> 2049301157.56
1202016-11-16T08:50:46 <CubicEarth> 13.1, Ubuntu.... my client is passing transaction data, synced several dozen blocks on startup, but then stalled for almost 10 minutes before downloading the most recent blocks. Is it just that none of the connected peers were providing the blocks it needed? Or is it something else?
1212016-11-16T08:51:27 <sipa> how many blocks do you have in total?
1222016-11-16T08:51:47 <CubicEarth> I synced it this morning, so it was only about 10 hours behind... then it stalled at about 6 hours behind
1232016-11-16T08:52:15 <CubicEarth> chewed though the first 4 or 5 hours in 30 seconds
1242016-11-16T08:52:49 <sipa> if you had an abnormal shutdown before, that's normal
1252016-11-16T08:53:02 *** droark has quit IRC
1262016-11-16T08:53:04 <sipa> well, not normal, but known
1272016-11-16T08:53:48 <CubicEarth> interesting. Would just one abnormal shutdown ever be enough? The most recent one was normal (so far as I could tell)
1282016-11-16T08:54:00 <sipa> just the last one
1292016-11-16T08:54:14 <sipa> it was busy processing the blocks it had on disk but not applied to the database, and does that in the background while connecting to other peers, ignoring their block announcements
1302016-11-16T08:54:19 <sipa> s/was/would be/
1312016-11-16T08:54:35 <gmaxwell> an unclean shutdown will delay the initial headers fetch?
1322016-11-16T08:55:07 <sipa> no, it will cause skipping it
1332016-11-16T08:55:10 <sipa> we should fix that
1342016-11-16T08:59:42 <CubicEarth> I wasn't looking at cpu usage... but in the debug window the current number of blocks was not advancing either. I thought the 'current number of blocks' displayed the total that had been validated and added to the chain. Does it actually count them before they are fully processed and appended?
1352016-11-16T09:01:47 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6eeac6e30d65...918ea16dc08d
1362016-11-16T09:01:48 <bitcoin-git> bitcoin/master 70266e9 Cory Fields: build: fix qt5.7 build under macOS...
1372016-11-16T09:01:48 <bitcoin-git> bitcoin/master 918ea16 Wladimir J. van der Laan: Merge #9169: build: fix qt5.7 build under macOS...
1382016-11-16T09:02:03 <bitcoin-git> [bitcoin] laanwj closed pull request #9169: build: fix qt5.7 build under macOS (master...fix-objcxx-std) https://github.com/bitcoin/bitcoin/pull/9169
1392016-11-16T09:02:41 <sipa> CubicEarth: no
1402016-11-16T09:03:12 <sipa> CubicEarth: my theory is that your node downloaded a number of blocks, and stored them on disk, but didn't apply them to the main chain before crashing
1412016-11-16T09:03:32 <sipa> after restarting, it noticed those blocks, and applied them immediately in the background
1422016-11-16T09:04:46 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/918ea16dc08d...4333b1c4ea74
1432016-11-16T09:04:46 <bitcoin-git> bitcoin/master fa80ef8 MarcoFalke: [qa] proxy_test: Calculate hardcoded port numbers instead
1442016-11-16T09:04:47 <bitcoin-git> bitcoin/master 4333b1c Wladimir J. van der Laan: Merge #9151: [qa] proxy_test: Calculate hardcoded port numbers...
1452016-11-16T09:05:01 <bitcoin-git> [bitcoin] laanwj closed pull request #9151: [qa] proxy_test: Calculate hardcoded port numbers (master...Mf1611-qaPort) https://github.com/bitcoin/bitcoin/pull/9151
1462016-11-16T09:07:02 <CubicEarth> I'll watch cpu utilization next time I boot my node... I think this pattern of stalling has been happening often.
1472016-11-16T09:07:28 <gmaxwell> CubicEarth: do you use p2pool by any chance?
1482016-11-16T09:08:00 <CubicEarth> gmaxwell: No. I'm not mining.
1492016-11-16T09:08:23 <gmaxwell> okay, p2pool often ends up gobbling the initial headers sync attempt for me.
1502016-11-16T09:10:20 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4333b1c4ea74...62af16463833
1512016-11-16T09:10:20 <bitcoin-git> bitcoin/master 079142b Jonas Schnelli: fNetworkActive is not protected by a lock, use an atomic
1522016-11-16T09:10:21 <bitcoin-git> bitcoin/master 62af164 Wladimir J. van der Laan: Merge #9131: fNetworkActive is not protected by a lock, use an atomic...
1532016-11-16T09:10:30 <bitcoin-git> [bitcoin] laanwj closed pull request #9131: fNetworkActive is not protected by a lock, use an atomic (master...2016/11/net_toggle) https://github.com/bitcoin/bitcoin/pull/9131
1542016-11-16T09:12:04 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/62af16463833...434e683f7be6
1552016-11-16T09:12:04 <bitcoin-git> bitcoin/master 79f755d Alex Morcos: Unset fImporting for loading mempool
1562016-11-16T09:12:05 <bitcoin-git> bitcoin/master 434e683 Wladimir J. van der Laan: Merge #9133: Unset fImporting for loading mempool...
1572016-11-16T09:12:19 <bitcoin-git> [bitcoin] laanwj closed pull request #9133: Unset fImporting for loading mempool (master...noImportLoadMempool) https://github.com/bitcoin/bitcoin/pull/9133
1582016-11-16T09:17:57 <CubicEarth> separate question: does anyone know about a standard for multi-sig interoperability? Something so that wallets from different providers could talk to each other?
1592016-11-16T09:25:37 <wumpus> CubicEarth: this is not a channel for general bitcoin related questions, please use #bitcoin
1602016-11-16T09:28:09 <wumpus> I know of no such standard, though.
1612016-11-16T09:28:35 <CubicEarth> wumpus: ok. thanks.
1622016-11-16T09:30:49 <bitcoin-git> [bitcoin] jonasschnelli opened pull request #9171: Introduce out-of-band block requests (master...2016/11/spv_step_1) https://github.com/bitcoin/bitcoin/pull/9171
1632016-11-16T09:33:51 <wumpus> jonasschnelli: what is 'out of band' about out-of-band block requests? don't you mean something like 'asynchronous'?
1642016-11-16T09:34:29 <jonasschnelli> wumpus: not sure if its the right term. But with out-of-band, I mean not-in-the-IBD-sequence...
1652016-11-16T09:34:31 <wumpus> jonasschnelli: (just a question about terminology, I haven't seen 'out of band' used a lot except for some weird network protocols)
1662016-11-16T09:34:42 <gmaxwell> I had the same thought, fwiw.
1672016-11-16T09:35:03 <jonasschnelli> I see. Any better wordings?
1682016-11-16T09:35:10 <jonasschnelli> Asynchronous is probably also not ideal.
1692016-11-16T09:35:22 <jonasschnelli> Independent-block-requests?
1702016-11-16T09:35:37 *** Victorsueca has quit IRC
1712016-11-16T09:35:43 <jonasschnelli> prioritized-block-downloads?
1722016-11-16T09:35:55 *** DigiByteDev has quit IRC
1732016-11-16T09:35:56 <gmaxwell> "Third distinct block downloading mechenism" :P I would have called it 'unordered block fetching' perhaps.
1742016-11-16T09:36:01 <jonasschnelli> Though, its not always a download
1752016-11-16T09:36:15 <jonasschnelli> I like "unordered block fetching"
1762016-11-16T09:36:43 <gmaxwell> even that is confusing since the normal fetch isn't in strict order. :)
1772016-11-16T09:37:03 <jonasschnelli> Indeed...
1782016-11-16T09:37:16 <jonasschnelli> Seems to be hard to nail it in two or three words.
1792016-11-16T09:37:23 <wumpus> so this provides a separate interface to block downloading
1802016-11-16T09:37:27 *** Victorsueca has joined #bitcoin-core-dev
1812016-11-16T09:37:43 <jonasschnelli> wumpus: not really,.. it still uses the internal block download mechanism
1822016-11-16T09:38:00 <jonasschnelli> It just priories individual blocks.
1832016-11-16T09:38:43 <wumpus> yes it uses the same mechanism, but provides an interface that that other parts of the software (not directly associated to validation) can use
1842016-11-16T09:38:45 <jonasschnelli> And you have certainty that all these requested blocks get passed through the signals in the correct order
1852016-11-16T09:39:05 <gmaxwell> Block on Demand.
1862016-11-16T09:39:25 <jonasschnelli> Blocks on Demand?
1872016-11-16T09:39:42 <jonasschnelli> Otherwise people think this blocks something. :P
1882016-11-16T09:39:56 <gmaxwell> My node has hot and cold running blocks.
1892016-11-16T09:40:05 <jonasschnelli> heh
1902016-11-16T09:46:50 *** gielbier has joined #bitcoin-core-dev
1912016-11-16T09:48:48 *** arowser has quit IRC
1922016-11-16T09:49:55 <jonasschnelli> Someone mentioned auxiliary-block-requests?
1932016-11-16T09:50:10 <wumpus> sgtm
1942016-11-16T09:50:14 *** arowser has joined #bitcoin-core-dev
1952016-11-16T09:52:08 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/434e683f7be6...0a6d48d9ed60
1962016-11-16T09:52:08 <bitcoin-git> bitcoin/master 307acdd mrbandrews: [qa] add assert_raises_message to check specific error message
1972016-11-16T09:52:09 <bitcoin-git> bitcoin/master 0a6d48d MarcoFalke: Merge #9168: [qa] add assert_raises_message to check specific error message...
1982016-11-16T09:52:22 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9168: [qa] add assert_raises_message to check specific error message (master...ba-assert-raises) https://github.com/bitcoin/bitcoin/pull/9168
1992016-11-16T09:52:41 <bitcoin-git> [bitcoin] laanwj closed pull request #8747: [rpc] Fix transaction size comments and RPC help text. (master...rpc_comments) https://github.com/bitcoin/bitcoin/pull/8747
2002016-11-16T09:56:08 *** MarcoFalke has joined #bitcoin-core-dev
2012016-11-16T09:56:47 *** DigiByteDev has joined #bitcoin-core-dev
2022016-11-16T10:06:23 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0a6d48d9ed60...cb2ed300a89e
2032016-11-16T10:06:23 <bitcoin-git> bitcoin/master 07ede5d Brian Deery: update comments for tx weight
2042016-11-16T10:06:24 <bitcoin-git> bitcoin/master cb2ed30 MarcoFalke: Merge #9155: [trivial] update comments for tx weight...
2052016-11-16T10:06:40 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9155: [trivial] update comments for tx weight (master...master) https://github.com/bitcoin/bitcoin/pull/9155
2062016-11-16T10:24:42 *** gielbier has quit IRC
2072016-11-16T10:25:55 *** DigiByteDev has quit IRC
2082016-11-16T10:30:07 *** DigiByteDev has joined #bitcoin-core-dev
2092016-11-16T10:33:57 <bitcoin-git> [bitcoin] laanwj opened pull request #9172: Resurrect pstratem's "Simple fuzzing framework" (master...2016_11_fuzzing_framework) https://github.com/bitcoin/bitcoin/pull/9172
2102016-11-16T10:35:03 *** DigiByteDev has quit IRC
2112016-11-16T10:50:55 *** BLTS has joined #bitcoin-core-dev
2122016-11-16T10:51:48 <BLTS> Hi all, I need to outsource a BTC payment and validation program!
2132016-11-16T10:52:26 <jonasschnelli> BLTS: what do you mean with outsource?
2142016-11-16T10:55:29 <BLTS> I need to pay someone to help develop a BTC payment and verification software
2152016-11-16T10:56:02 <BLTS> jonasschnelli I need to pay someone to help develop a BTC payment and verification software
2162016-11-16T10:56:27 <jonasschnelli> BLTS: maybe #bitcoin or #bitcoin-dev but not #bitcoin-core-dev I guess
2172016-11-16T10:57:06 <BLTS> thank you
2182016-11-16T10:58:11 *** BLTS has quit IRC
2192016-11-16T11:08:14 *** cryptapus_afk has quit IRC
2202016-11-16T11:08:46 *** CubicEarth has quit IRC
2212016-11-16T11:09:38 <wumpus> travis is having issues
2222016-11-16T11:10:48 <wumpus> (nothing we can help, it doesn't even manage apt-get)
2232016-11-16T11:19:58 <wumpus> phantomcircuit: do you happen to have your directory of AFL inputs for #7940 somewhere?
2242016-11-16T11:20:00 <gribble> https://github.com/bitcoin/bitcoin/issues/7940 | [WIP] Fuzzing framework by pstratem · Pull Request #7940 · bitcoin/bitcoin · GitHub
2252016-11-16T11:20:24 *** CubicEarth has joined #bitcoin-core-dev
2262016-11-16T11:22:23 <MarcoFalke> !m travis
2272016-11-16T11:22:23 <[b__b]> You're doing good work, travis!
2282016-11-16T11:22:24 <gribble> Error: "m" is not a valid command.
2292016-11-16T11:24:55 *** cryptapus_afk has joined #bitcoin-core-dev
2302016-11-16T11:25:22 <MarcoFalke> seems to work, now
2312016-11-16T11:33:36 *** atroxes has quit IRC
2322016-11-16T11:34:42 *** CubicEarth has quit IRC
2332016-11-16T11:42:11 *** atroxes has joined #bitcoin-core-dev
2342016-11-16T11:55:29 *** arowser has quit IRC
2352016-11-16T11:57:32 *** arowser has joined #bitcoin-core-dev
2362016-11-16T12:12:39 *** MarcoFalke has left #bitcoin-core-dev
2372016-11-16T12:14:18 *** rabidus has quit IRC
2382016-11-16T12:14:26 *** rabidus has joined #bitcoin-core-dev
2392016-11-16T12:21:34 *** arowser has quit IRC
2402016-11-16T12:23:09 *** arowser has joined #bitcoin-core-dev
2412016-11-16T12:29:45 *** cryptapus has joined #bitcoin-core-dev
2422016-11-16T12:30:11 *** cryptapus has joined #bitcoin-core-dev
2432016-11-16T12:30:11 *** cryptapus has joined #bitcoin-core-dev
2442016-11-16T12:33:23 *** cryptapus has quit IRC
2452016-11-16T12:35:12 *** CubicEarth has joined #bitcoin-core-dev
2462016-11-16T12:35:19 *** cryptapus has joined #bitcoin-core-dev
2472016-11-16T12:35:19 *** cryptapus has joined #bitcoin-core-dev
2482016-11-16T12:39:59 *** CubicEarth has quit IRC
2492016-11-16T12:54:13 <jonasschnelli> wumpus: yes. I encountered the travis issue on other repos too
2502016-11-16T13:10:12 <luke-jr> sigh, looks like Travis is totally broken
2512016-11-16T13:14:35 <wumpus> yep.
2522016-11-16T13:36:30 *** CubicEarth has joined #bitcoin-core-dev
2532016-11-16T13:41:12 *** CubicEarth has quit IRC
2542016-11-16T13:45:09 <jonasschnelli> Hmm... utf8 in not mandatory for JSON.. right?
2552016-11-16T13:45:26 <jonasschnelli> RFC 4627 does state: "JSON text SHALL be encoded in Unicode. The default encoding is
2562016-11-16T13:45:27 <jonasschnelli> UTF-8."?
2572016-11-16T13:54:44 <luke-jr> I thought it was.. :x
2582016-11-16T14:00:09 *** MarcoFalke has joined #bitcoin-core-dev
2592016-11-16T14:08:52 *** Giszmo has joined #bitcoin-core-dev
2602016-11-16T14:10:47 <wumpus> yes, utf-8 is mandatory for JSON
2612016-11-16T14:11:20 <wumpus> and that is how everyone uses it. We're not going to support non-UTF-8 JSON in bitcoin core.
2622016-11-16T14:17:16 <wumpus> I'm 99% sure that the non-utf8 data he managed to get into the wallet database in #9166 is from the wx GUI, not from any JSON client
2632016-11-16T14:17:17 <gribble> https://github.com/bitcoin/bitcoin/issues/9166 | listtransactions returns invalid JSON when comment contain non-UTF8 special chars · Issue #9166 · bitcoin/bitcoin · GitHub
2642016-11-16T14:18:14 <wumpus> qt handles everything as UTF-8, but the wx GUI did not, the stable wx (at that point) didn't even support unicode IIRC
2652016-11-16T14:18:35 <timothy> who still uses wx?
2662016-11-16T14:18:53 <wumpus> no one,but wallets grandfathered in from that time still exist
2672016-11-16T14:28:12 <jonasschnelli> A fix would be to add a UTF8 filter at the deserialization of an CAccountingEntry
2682016-11-16T14:28:37 <jonasschnelli> Somewhere here: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.h#L524
2692016-11-16T14:28:48 <jonasschnelli> But not going to do this. It's just not worth...
2702016-11-16T14:29:44 <wumpus> I understand. THis is better handled on a per-case basis probably
2712016-11-16T14:30:41 <luke-jr> wumpus: wxBitcoin didn't support the stable wx, and required unicode XD
2722016-11-16T14:30:49 *** Guyver2 has joined #bitcoin-core-dev
2732016-11-16T14:31:06 <wumpus> luke-jr: ok. No clue then how he managed then :)
2742016-11-16T14:31:24 <luke-jr> did the RPC really prohibit it?
2752016-11-16T14:31:49 <wumpus> no, but no one uses JSON without unicode, the sane languages prohibit it
2762016-11-16T14:31:56 <luke-jr> CLI?
2772016-11-16T14:32:16 <wumpus> isn't cli usually unicode too?
2782016-11-16T14:32:28 <luke-jr> not always
2792016-11-16T14:32:49 <wumpus> no, not always, so it's possible, it'll just be very rare on all accounts
2802016-11-16T14:33:14 <luke-jr> I think it's more commonly non-Unicode outside the English-speaking area
2812016-11-16T14:33:24 <luke-jr> or was until some years ago
2822016-11-16T14:33:46 <luke-jr> but nobody else has reported a problem.. so maybe not
2832016-11-16T14:34:00 <wumpus> we're not talking about the 90's here
2842016-11-16T14:34:31 <wumpus> or original VT-100 terminals or whatnot :) bitcoin isn't that old
2852016-11-16T14:35:03 <wumpus> but yes it'll obviously be more common outside ENglish-speaking areas
2862016-11-16T14:37:04 *** CubicEarth has joined #bitcoin-core-dev
2872016-11-16T14:38:27 <jonasschnelli> I located the "issue" in the code.
2882016-11-16T14:38:42 <jonasschnelli> Its in univalue_read.cpp
2892016-11-16T14:38:49 <jonasschnelli> Univalue can't handle non UTF8
2902016-11-16T14:38:56 <jonasschnelli> (even if its allowed by the JSON RFC)
2912016-11-16T14:39:05 <wumpus> that's fine, we don't want it to
2922016-11-16T14:39:08 <jonasschnelli> the read() function will resturn false
2932016-11-16T14:39:13 <jonasschnelli> Yes. We don't want this
2942016-11-16T14:40:25 <wumpus> univalue, as well as bitcoind, will acquire lots of cruft if you want full character set handling. We don't need that as no one uses JSON that way. E.g. the "JSON is a minefield" tests assume the JSON parser strictly checks UTF-8
2952016-11-16T14:41:45 <wumpus> (neither did any of the previous JSON libraries that we used, but they didn't do any input validation, which is quite a bad thing)
2962016-11-16T14:41:55 *** CubicEarth has quit IRC
2972016-11-16T14:49:41 *** paveljanik has joined #bitcoin-core-dev
2982016-11-16T14:49:41 *** paveljanik has joined #bitcoin-core-dev
2992016-11-16T14:51:30 *** cysm has quit IRC
3002016-11-16T15:03:46 <bitcoin-git> [bitcoin] laanwj reopened pull request #8747: [rpc] Fix transaction size comments and RPC help text. (master...rpc_comments) https://github.com/bitcoin/bitcoin/pull/8747
3012016-11-16T15:11:38 <bitcoin-git> [bitcoin] demodun opened pull request #9173: demo (master...master) https://github.com/bitcoin/bitcoin/pull/9173
3022016-11-16T15:12:23 <bitcoin-git> [bitcoin] jonasschnelli closed pull request #9173: demo (master...master) https://github.com/bitcoin/bitcoin/pull/9173
3032016-11-16T15:15:15 *** cysm has joined #bitcoin-core-dev
3042016-11-16T15:37:58 *** CubicEarth has joined #bitcoin-core-dev
3052016-11-16T15:38:02 *** btcdrak has quit IRC
3062016-11-16T15:43:15 *** CubicEarth has quit IRC
3072016-11-16T15:43:56 <cfields> morcos: ping. gentle reminder about the prevector bench.
3082016-11-16T15:44:02 <instagibbs> in what situations would ENABLE_WALLET be defined but pwalletMain be null? Or any other combination.
3092016-11-16T15:45:11 <cfields> instagibbs: ./configure --enable-wallet && ./bitcoind --disablewallet
3102016-11-16T15:45:12 <cfields> (i think)
3112016-11-16T15:45:32 <instagibbs> cfields, ah that seems likely. Thanks!
3122016-11-16T15:46:05 *** jtimon has joined #bitcoin-core-dev
3132016-11-16T16:20:57 *** PaulCapestany has quit IRC
3142016-11-16T16:26:30 *** btcdrak has joined #bitcoin-core-dev
3152016-11-16T16:27:15 *** PaulCapestany has joined #bitcoin-core-dev
3162016-11-16T16:43:52 *** cryptapus_afk has quit IRC
3172016-11-16T17:01:27 *** paveljanik has quit IRC
3182016-11-16T17:02:13 *** cysm has quit IRC
3192016-11-16T17:02:39 *** cryptapus_afk has joined #bitcoin-core-dev
3202016-11-16T17:02:39 *** cryptapus_afk has joined #bitcoin-core-dev
3212016-11-16T17:04:53 *** paveljanik has joined #bitcoin-core-dev
3222016-11-16T17:04:54 *** paveljanik has joined #bitcoin-core-dev
3232016-11-16T17:28:08 *** jannes has quit IRC
3242016-11-16T17:31:22 *** cysm has joined #bitcoin-core-dev
3252016-11-16T17:31:42 *** cryptapus_afk has quit IRC
3262016-11-16T17:40:31 *** CubicEarth has joined #bitcoin-core-dev
3272016-11-16T17:45:09 *** CubicEarth has quit IRC
3282016-11-16T17:51:04 *** CubicEarth has joined #bitcoin-core-dev
3292016-11-16T17:55:35 *** cryptapus_afk has joined #bitcoin-core-dev
3302016-11-16T17:55:38 *** cryptapus_afk has joined #bitcoin-core-dev
3312016-11-16T18:12:19 *** abpa has joined #bitcoin-core-dev
3322016-11-16T18:22:54 *** Chris_Stewart_5 has quit IRC
3332016-11-16T18:26:04 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3342016-11-16T18:35:42 *** cryptapus_afk has quit IRC
3352016-11-16T18:35:44 *** bsm1175321 has quit IRC
3362016-11-16T18:37:58 *** bsm1175321 has joined #bitcoin-core-dev
3372016-11-16T18:46:24 *** cryptapus_afk has joined #bitcoin-core-dev
3382016-11-16T18:46:24 *** cryptapus_afk has joined #bitcoin-core-dev
3392016-11-16T18:48:01 *** BonyM1 has quit IRC
3402016-11-16T18:50:16 *** laurentmt has joined #bitcoin-core-dev
3412016-11-16T18:55:16 *** laurentmt has quit IRC
3422016-11-16T19:03:12 *** BonyM1 has joined #bitcoin-core-dev
3432016-11-16T19:18:12 *** theymos has joined #bitcoin-core-dev
3442016-11-16T19:19:30 <theymos> fyi, some apparently-popular antivirus is flagging Bitcoin Core 0.13.1: https://www.virustotal.com/en/file/c1726ccc50635795c942c7d7e51d979c4f83a3d17f8982e9d02a114a15fef419/analysis/
3452016-11-16T19:34:24 <arubi> "Additional information" -> "VirusTotal metadata" -> "File names" -> "KMS V.1.2.3.exe"
3462016-11-16T19:34:27 <arubi> weird.
3472016-11-16T19:50:35 *** Guest84529 has joined #bitcoin-core-dev
3482016-11-16T19:52:44 *** Guest84529 is now known as roidster
3492016-11-16T19:58:08 <morcos> cfields: sorry, will have to wait a bit longer. my initial results seem to show that maybe its a little bit of an improvement, but that the previous branch was a more significant improvement
3502016-11-16T19:58:20 <morcos> so i'd like to run longer tests to get rid of the noise...
3512016-11-16T19:59:30 <cfields> morcos: ok, np. thanks for testing
3522016-11-16T20:00:16 <cfields> morcos: i suppose it's possible that all of the changes just slowly added up to a noticeable speedup. I figured it was more likely that there was a single silver bullet.
3532016-11-16T20:01:45 <gmaxwell> btcdrak: any interest in trying to get that spurrious AV warning fixed?
3542016-11-16T20:03:48 <Victorsueca> theymos: Baidu lol
3552016-11-16T20:04:04 <Victorsueca> isn't that a Chinese page?
3562016-11-16T20:04:41 <Victorsueca> would bet Chinese government is behind that
3572016-11-16T20:08:29 *** CubicEarth has quit IRC
3582016-11-16T20:16:34 <morcos> cfields: yeah i'll keep running tests, but actually when i tried your old branch, i accidentally did it without the removal of the CScript copy constructor (b/c i didn't want to use the Transaction stuff in that second commit)
3592016-11-16T20:17:16 <morcos> once i re-removed the CScript copy contructor from the copy-move branch, its clearly much faster than the prevector-move branch
3602016-11-16T20:19:43 <cfields> morcos: interesting, that points to the speedup coming from less time copying
3612016-11-16T20:19:56 <btcdrak> gmaxwell: a job for a native chinese speaker I think.
3622016-11-16T20:19:57 <cfields> which is strange, because last i looked, there were very few of those copies
3632016-11-16T20:21:35 <cfields> morcos: hmm, though i suppose it could also come from construction/destruction. prevector as-is is pretty heavy on those
3642016-11-16T20:22:34 <cfields> grr, i should just bite the bullet and do a quick specialization of prevector for unsigned char. It should be simple enough.
3652016-11-16T20:23:21 *** roidster has quit IRC
3662016-11-16T20:26:07 *** arubi_ has joined #bitcoin-core-dev
3672016-11-16T20:27:21 *** arubi_ has left #bitcoin-core-dev
3682016-11-16T20:30:32 <sipa> cfields: can't use use a my_is_trivially_copyable predicate class instead, and define it just manually for char for old compilers, and use std::is_trivially_copyable for new ones?
3692016-11-16T20:30:45 *** jtimon has quit IRC
3702016-11-16T20:31:55 <cfields> sipa: yes, but i'm pretty sure it could be sped up substantially if written specifically for packed bytes
3712016-11-16T20:33:15 <cfields> sipa: for ex, no alignment concerns
3722016-11-16T20:34:35 <gmaxwell> maybe time would be better spent working on flat transactions (which rrequires finishing making them immutable first)?
3732016-11-16T20:35:45 <cfields> flat transactions?
3742016-11-16T20:36:05 <sipa> cfields: one malloc
3752016-11-16T20:36:37 <cfields> oh, accessing serialized fields on the fly, or so?
3762016-11-16T20:37:04 <gmaxwell> doesn't have to be (and probably shouldn't be) in the seralized form we use on the wire.
3772016-11-16T20:37:55 <cfields> right, you mentioned this the other day
3782016-11-16T20:40:34 <cfields> gmaxwell: you mentioned you'd doodled some notes about a possible format. Happen to have those around?
3792016-11-16T20:42:24 <gmaxwell> Well what I was working on is on the other side, improved serialization for disk and network that is more compact.
3802016-11-16T20:43:14 <gmaxwell> For use in memory, one would have no varints, for example, just just character arrays and primitive types, and a set of pointers to allow random access to every field even though some parts are variable length.
3812016-11-16T20:44:39 <sipa> doesn't sound hard
3822016-11-16T20:45:00 <sipa> concatenate all scripts into a single byte array, and have (begin_ptr, size) tuples to refer to them
3832016-11-16T20:45:34 <sipa> we'd need to modify the script interpreter to no longer use CScript anymore (which seems trivial, it doesn't need any of CScript's representation - even iteration is done byte by byte)
3842016-11-16T20:45:35 <gmaxwell> no, but it needs transaction to be immutable though.. since you can't make changes that would change the size or count of any scripts.
3852016-11-16T20:45:44 <sipa> of course
3862016-11-16T20:46:18 *** NielsvG has quit IRC
3872016-11-16T20:46:27 <gmaxwell> for the more effficent disk/wire format what I'd written up was https://people.xiph.org/~greg/compacted_txn.txt though one thing it doesn't achieve, which would be nice though I don't know if its realistic, is a very fast procedure to decide how much memory would be needed for a flat in memory rep... which would facilitate some later optimizations.
3882016-11-16T20:49:47 *** NielsvG has joined #bitcoin-core-dev
3892016-11-16T20:49:47 *** NielsvG has joined #bitcoin-core-dev
3902016-11-16T20:50:05 <cfields> thanks, will take a look
3912016-11-16T20:51:33 <Chris_Stewart_5> Why does this test fail for EVAL_FALSE and not WITNESS_PROGRAM_MISMATCH? https://github.com/bitcoin/bitcoin/blob/master/src/test/data/script_tests.json#L1257
3922016-11-16T20:51:34 <cfields> yes, i suppose in any scheme where all scripts are cat'd in memory, there'd be no need for something like prevector
3932016-11-16T20:55:04 <sipa> cfields: sure there is. prevector's primary benefit is in CCoins
3942016-11-16T20:57:29 <gmaxwell> but thats why I suggested that flattening transactions may be a better time investment than expanding prevector's use in transactions. I think with transaction const there is no reason to not flatten it all the way except that a lot of code may need to be adjusted to twiddle how accesses work. (Though perhaps enough C++ magic could keep the interface almost identical-- beyond my pay grade). Not
3952016-11-16T20:57:35 <gmaxwell> that prevector isn't useful, but just for const transactions its a half-step.
3962016-11-16T20:59:59 <cfields> sipa: i figured CCoins would use some similar monster allocation structure and indicies. But I suppose you'd run into crazy fragmentation issues quickly
3972016-11-16T21:00:21 <cfields> *indices
3982016-11-16T21:00:27 <sipa> cfields: for CCoins i want to move to a per-output model instead of per-tx
3992016-11-16T21:02:32 *** cryptapus has quit IRC
4002016-11-16T21:06:15 <sipa> Chris_Stewart_5: because 6e340b9cffb37a989ca544e6bb780a2c78901d3fb33738768511a30617afa01d is the hash of OP_0 (0x00) and not of OP_TRUE (0x51)
4012016-11-16T21:06:42 <sipa> Chris_Stewart_5: so it's a perfectly valid p2wsh output, for the OP_FALSE witness script (which is unspendable)
4022016-11-16T21:07:20 <cfields> makes sense, though admittedly i'm not very familiar with that code.
4032016-11-16T21:07:50 <sipa> cfields: it needs design, implementation, and benchmarking
4042016-11-16T21:08:37 <sipa> it's not trivial to do, but the current system has an ugly O(n^2) behaviour, where a transaction with n outputs needs O(n) database writes (one for each spend) each of size O(n) (because all unspent outputs are rewritten every time)
4052016-11-16T21:09:18 <cfields> ah, i see
4062016-11-16T21:09:29 *** theymos has left #bitcoin-core-dev
4072016-11-16T21:09:47 <sipa> the easiest solution is storing height/coinbaseness in each output
4082016-11-16T21:09:52 <sipa> and txid
4092016-11-16T21:09:57 <sipa> but that's a lot of duplication
4102016-11-16T21:10:52 <sipa> though leveldb does deduplication of identical prefixes in the database
4112016-11-16T21:11:18 <sipa> an alternative is a txid->{height,coinbase,id} map, with id a short sequentially-assigned local id
4122016-11-16T21:11:28 <sipa> and then use (id,index)->{utxo} map for the utxos
4132016-11-16T21:11:33 <sipa> but that's an extra indirection
4142016-11-16T21:16:52 <cfields> well the first potentially brings a nice read speedup, no? Since the outputs are then somewhat sorted by hotness
4152016-11-16T21:17:54 <sipa> leveldb sorts by key
4162016-11-16T21:18:39 <sipa> and the way we're using leveldb i think hardly results in actual levels
4172016-11-16T21:18:50 <sipa> the batches are so large we always trigger compactions
4182016-11-16T21:19:05 <cfields> heh
4192016-11-16T21:20:30 <Chris_Stewart_5> sipa: Thanks for the help, mistakenly assumed it was still HASH160(SHA256()), is there a reason it is only 1 SHA256()?
4202016-11-16T21:21:45 <sipa> Chris_Stewart_5: yes, 160 bits is too little
4212016-11-16T21:22:09 <sipa> (it's too little for P2SH as well, but we weren't aware of the collision attack against it at the time)
4222016-11-16T21:22:46 <Chris_Stewart_5> sipa: Is it a HF to change P2SH to a SHA256?
4232016-11-16T21:23:24 <sipa> Chris_Stewart_5: of course
4242016-11-16T21:24:48 <sipa> when done naively, at least
4252016-11-16T21:24:59 <sipa> just defining something new P2SH-like could be done
4262016-11-16T21:25:11 <sipa> ... but that's essentially what P2WSH is
4272016-11-16T21:26:45 *** ryanofsky has quit IRC
4282016-11-16T21:28:50 <Chris_Stewart_5> and with a versioning system now we can totally redefine the semantics of any witness scripts between versions, correct?
4292016-11-16T21:28:53 *** ryanofsky has joined #bitcoin-core-dev
4302016-11-16T21:29:24 <sipa> yes
4312016-11-16T21:29:37 *** ryanofsky has quit IRC
4322016-11-16T21:30:08 *** ryanofsky has joined #bitcoin-core-dev
4332016-11-16T21:30:26 <sipa> Chris_Stewart_5: my answer was wrong. any interpretation for "changing P2SH to SHA256" i can come up with would be a soft fork
4342016-11-16T21:30:36 <sipa> it would however also break any existing p2sh users
4352016-11-16T21:31:25 <Chris_Stewart_5> sipa: Isn't the P2SH flag a required flag at this point in script? Would it have to do with redefining the IsScriptHash function?
4362016-11-16T21:32:13 <sipa> that's an implementation detail
4372016-11-16T21:33:36 <sipa> you can just add an IsScriptHash2 function, and add a new flag that assigns sha256-p2sh behaviour to IsScriptHash2, and outlaws any older IsScriptHash results
4382016-11-16T21:34:02 <Chris_Stewart_5> Why would you need to outlaw?
4392016-11-16T21:34:19 <sipa> because that's how i interpret 'moving to sha256' :)
4402016-11-16T21:34:26 <Chris_Stewart_5> ahhh ok
4412016-11-16T21:34:37 <sipa> if you would have said 'adding p2sh-sha256 feature', yes :)
4422016-11-16T21:34:47 <sipa> but that's pretty much what p2wsh is... in a better way
4432016-11-16T21:35:07 <Chris_Stewart_5> ... but I want to make p2sh great again. I'll see myself out.
4442016-11-16T21:36:44 *** arubi has quit IRC
4452016-11-16T21:36:55 <sipa> hahaha
4462016-11-16T21:39:31 *** arubi has joined #bitcoin-core-dev
4472016-11-16T21:46:23 *** arubi has quit IRC
4482016-11-16T21:47:44 *** arubi has joined #bitcoin-core-dev
4492016-11-16T22:31:39 *** roidster has joined #bitcoin-core-dev
4502016-11-16T22:36:45 *** MarcoFalke has left #bitcoin-core-dev
4512016-11-16T22:40:05 *** nabu has joined #bitcoin-core-dev
4522016-11-16T22:52:48 *** nabu has quit IRC
4532016-11-16T23:13:41 *** droark has joined #bitcoin-core-dev
4542016-11-16T23:15:49 *** Guyver2 has quit IRC
4552016-11-16T23:20:58 *** jtimon has joined #bitcoin-core-dev
4562016-11-16T23:25:44 *** To7 has joined #bitcoin-core-dev
4572016-11-16T23:26:04 *** shangzhou has joined #bitcoin-core-dev
4582016-11-16T23:26:33 *** aalex has quit IRC
4592016-11-16T23:58:02 *** btcdrak has quit IRC