--- Day changed Wed Nov 16 2016 00:03 * luke-jr cowers in fear of the new Bitcoin Core configure that yells at you :P 00:15 <@wumpus> bitcoin: where even the configure scripts yell at you 00:17 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rujcfyldlkzjyqpx] has joined #bitcoin-core-dev 00:19 <@wumpus> you think the build system is agressive? We'll introduce you to some of our community members :p 00:21 < sipa> we have this guy called Travis who continuously yells at very active developers 00:22 <@wumpus> which reminds me, there is this guy called 'Coveralls' in some projects, maybe we should invite him too 00:22 < luke-jr> lol 00:22 <@wumpus> I do think he's a bit on the spammy side tho, like our old pulltester 00:23 * jonasschnelli likes Coveralls 00:24 < jonasschnelli> It someone encourages contributors to write more tests (even if coverage does not prove correctness) 00:27 <@wumpus> yeah coverage is especially good in languages such as python where many typos and such are only found by executing some code 00:27 < 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) 00:27 <@wumpus> though it helps for C too I guess, having coverage in the first place is essential for complete tests, just not sufficient 00:28 < gmaxwell> C++ makes smart coverage harder because all the boilerplate stuff often adds unreachable code. :( 00:29 <@wumpus> gmaxwell: no problem 00:29 <@wumpus> though you *really* should make a habit of re-running autogen when changing branches 00:30 * wumpus has different repo checkouts for different major versions to avoid problems like that 00:30 <@wumpus> also saved me from committing a patch against the wrong branch at least once :) 00:31 < 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. :( 00:31 < gmaxwell> wumpus: I figure if it keeps hitting me it will hit random users who find it more surprising. :) 00:32 <@wumpus> I wish autoconf would just yell if your generated files are out of date with the build system files 00:32 < jonasschnelli> For C: high coverage together with a CI valgrind memleak check is desirable IMO 00:33 <@wumpus> and fuzzing, of course 00:33 <@wumpus> gmaxwell: anyhow, no problem with adding that, it'd also catch problems with people forgetting to include configure.h 00:33 < gmaxwell> memleak? seldom have memleaks in interesting code. Valgrind's undefined behavior checking, OTOH. Is super great. :) 00:33 < gmaxwell> wumpus: thanks okay, I'll do so. 00:34 -!- DigiByteDev [~JT2@203.145.94.245] has joined #bitcoin-core-dev 00:34 < gmaxwell> for bitcoin I do think we need DRD run on it more often, it's just a bit frustrating because its so slow. 00:35 <@wumpus> at least make sure you run valgrind against the optimized executable not the -O0 debugging one :-) 00:36 < sipa> http://bitcoin.sipa.be/ver9-10k.png 00:36 <@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 00:37 < gmaxwell> yes, it's amazing. 00:37 < sipa> (-ever, -50k, -2k also exist) 00:37 <@wumpus> sipa: nice! 00:39 < TD-Linux> sipa, having them on the index page would also be nice :) 00:39 < gmaxwell> there is an index page? 00:39 < sipa> TD-Linux: that would involve loading my html knowledge back from swap space 00:40 < sipa> gmaxwell: http://bitcoin.sipa.be 00:41 < sipa> did we cross 2 exahash/s? 00:41 < jonasschnelli> sipa: come one! s/hash rate/hash rate
  • ver9-10k
    • / 00:42 < jonasschnelli> *come on :-) 00:42 < sipa> jonasschnelli: i'll want a separate page with thumbnails and stuffs 00:42 <@wumpus> yes I was about to say, someone has got to have that knowledge in their ready memory and could provide a patch 00:42 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 00:43 < sipa> https://github.com/sipa/bitcoin-stats 00:43 < jonasschnelli> Yeah. Migrate the non-pngs html stuff to bitcoincore.org 00:43 <@wumpus> not me though, my html knowledge is in the 2000-2004 archive in deep storage 00:43 < jonasschnelli> Yeah. Perl. How did I missed this. 00:44 < sipa> also C 00:44 < sipa> and bash 00:44 < sipa> and bash that generates gnuplot 00:46 < sipa> ;;nethash 00:46 < gribble> 2049301157.56 00:50 < 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? 00:51 < sipa> how many blocks do you have in total? 00:51 < CubicEarth> I synced it this morning, so it was only about 10 hours behind... then it stalled at about 6 hours behind 00:52 < CubicEarth> chewed though the first 4 or 5 hours in 30 seconds 00:52 < sipa> if you had an abnormal shutdown before, that's normal 00:53 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Ping timeout: 265 seconds] 00:53 < sipa> well, not normal, but known 00:53 < CubicEarth> interesting. Would just one abnormal shutdown ever be enough? The most recent one was normal (so far as I could tell) 00:54 < sipa> just the last one 00:54 < 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 00:54 < sipa> s/was/would be/ 00:54 < gmaxwell> an unclean shutdown will delay the initial headers fetch? 00:55 < sipa> no, it will cause skipping it 00:55 < sipa> we should fix that 00:59 < 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? 01:01 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6eeac6e30d65...918ea16dc08d 01:01 < bitcoin-git> bitcoin/master 70266e9 Cory Fields: build: fix qt5.7 build under macOS... 01:01 < bitcoin-git> bitcoin/master 918ea16 Wladimir J. van der Laan: Merge #9169: build: fix qt5.7 build under macOS... 01:02 < 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 01:02 < sipa> CubicEarth: no 01:03 < 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 01:03 < sipa> after restarting, it noticed those blocks, and applied them immediately in the background 01:04 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/918ea16dc08d...4333b1c4ea74 01:04 < bitcoin-git> bitcoin/master fa80ef8 MarcoFalke: [qa] proxy_test: Calculate hardcoded port numbers instead 01:04 < bitcoin-git> bitcoin/master 4333b1c Wladimir J. van der Laan: Merge #9151: [qa] proxy_test: Calculate hardcoded port numbers... 01:05 < 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 01:07 < CubicEarth> I'll watch cpu utilization next time I boot my node... I think this pattern of stalling has been happening often. 01:07 < gmaxwell> CubicEarth: do you use p2pool by any chance? 01:08 < CubicEarth> gmaxwell: No. I'm not mining. 01:08 < gmaxwell> okay, p2pool often ends up gobbling the initial headers sync attempt for me. 01:10 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4333b1c4ea74...62af16463833 01:10 < bitcoin-git> bitcoin/master 079142b Jonas Schnelli: fNetworkActive is not protected by a lock, use an atomic 01:10 < bitcoin-git> bitcoin/master 62af164 Wladimir J. van der Laan: Merge #9131: fNetworkActive is not protected by a lock, use an atomic... 01:10 < 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 01:12 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/62af16463833...434e683f7be6 01:12 < bitcoin-git> bitcoin/master 79f755d Alex Morcos: Unset fImporting for loading mempool 01:12 < bitcoin-git> bitcoin/master 434e683 Wladimir J. van der Laan: Merge #9133: Unset fImporting for loading mempool... 01:12 < bitcoin-git> [bitcoin] laanwj closed pull request #9133: Unset fImporting for loading mempool (master...noImportLoadMempool) https://github.com/bitcoin/bitcoin/pull/9133 01:17 < 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? 01:25 <@wumpus> CubicEarth: this is not a channel for general bitcoin related questions, please use #bitcoin 01:28 <@wumpus> I know of no such standard, though. 01:28 < CubicEarth> wumpus: ok. thanks. 01:30 < 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 01:33 <@wumpus> jonasschnelli: what is 'out of band' about out-of-band block requests? don't you mean something like 'asynchronous'? 01:34 < jonasschnelli> wumpus: not sure if its the right term. But with out-of-band, I mean not-in-the-IBD-sequence... 01:34 <@wumpus> jonasschnelli: (just a question about terminology, I haven't seen 'out of band' used a lot except for some weird network protocols) 01:34 < gmaxwell> I had the same thought, fwiw. 01:35 < jonasschnelli> I see. Any better wordings? 01:35 < jonasschnelli> Asynchronous is probably also not ideal. 01:35 < jonasschnelli> Independent-block-requests? 01:35 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 240 seconds] 01:35 < jonasschnelli> prioritized-block-downloads? 01:35 -!- DigiByteDev [~JT2@203.145.94.245] has quit [Quit: DigiByteDev] 01:35 < gmaxwell> "Third distinct block downloading mechenism" :P I would have called it 'unordered block fetching' perhaps. 01:36 < jonasschnelli> Though, its not always a download 01:36 < jonasschnelli> I like "unordered block fetching" 01:36 < gmaxwell> even that is confusing since the normal fetch isn't in strict order. :) 01:37 < jonasschnelli> Indeed... 01:37 < jonasschnelli> Seems to be hard to nail it in two or three words. 01:37 <@wumpus> so this provides a separate interface to block downloading 01:37 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 01:37 < jonasschnelli> wumpus: not really,.. it still uses the internal block download mechanism 01:38 < jonasschnelli> It just priories individual blocks. 01:38 <@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 01:38 < jonasschnelli> And you have certainty that all these requested blocks get passed through the signals in the correct order 01:39 < gmaxwell> Block on Demand. 01:39 < jonasschnelli> Blocks on Demand? 01:39 < jonasschnelli> Otherwise people think this blocks something. :P 01:39 < gmaxwell> My node has hot and cold running blocks. 01:40 < jonasschnelli> heh 01:46 -!- gielbier [~michiel@unaffiliated/gielbier] has joined #bitcoin-core-dev 01:48 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.] 01:49 < jonasschnelli> Someone mentioned auxiliary-block-requests? 01:50 <@wumpus> sgtm 01:50 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 01:52 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/434e683f7be6...0a6d48d9ed60 01:52 < bitcoin-git> bitcoin/master 307acdd mrbandrews: [qa] add assert_raises_message to check specific error message 01:52 < bitcoin-git> bitcoin/master 0a6d48d MarcoFalke: Merge #9168: [qa] add assert_raises_message to check specific error message... 01:52 < 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 01:52 < 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 01:56 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 01:56 -!- DigiByteDev [~JT2@203.145.94.102] has joined #bitcoin-core-dev 02:06 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0a6d48d9ed60...cb2ed300a89e 02:06 < bitcoin-git> bitcoin/master 07ede5d Brian Deery: update comments for tx weight 02:06 < bitcoin-git> bitcoin/master cb2ed30 MarcoFalke: Merge #9155: [trivial] update comments for tx weight... 02:06 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9155: [trivial] update comments for tx weight (master...master) https://github.com/bitcoin/bitcoin/pull/9155 02:24 -!- gielbier [~michiel@unaffiliated/gielbier] has quit [Remote host closed the connection] 02:25 -!- DigiByteDev [~JT2@203.145.94.102] has quit [Quit: DigiByteDev] 02:30 -!- DigiByteDev [~JT2@203.145.94.102] has joined #bitcoin-core-dev 02:33 < 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 02:35 -!- DigiByteDev [~JT2@203.145.94.102] has quit [Ping timeout: 268 seconds] 02:50 -!- BLTS [3a40a1b4@gateway/web/freenode/ip.58.64.161.180] has joined #bitcoin-core-dev 02:51 < BLTS> Hi all, I need to outsource a BTC payment and validation program! 02:52 < jonasschnelli> BLTS: what do you mean with outsource? 02:55 < BLTS> I need to pay someone to help develop a BTC payment and verification software 02:56 < BLTS> jonasschnelli I need to pay someone to help develop a BTC payment and verification software 02:56 < jonasschnelli> BLTS: maybe #bitcoin or #bitcoin-dev but not #bitcoin-core-dev I guess 02:57 < BLTS> thank you 02:58 -!- BLTS [3a40a1b4@gateway/web/freenode/ip.58.64.161.180] has quit [Quit: Page closed] 03:08 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Remote host closed the connection] 03:08 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 03:09 <@wumpus> travis is having issues 03:10 <@wumpus> (nothing we can help, it doesn't even manage apt-get) 03:19 <@wumpus> phantomcircuit: do you happen to have your directory of AFL inputs for #7940 somewhere? 03:20 < gribble> https://github.com/bitcoin/bitcoin/issues/7940 | [WIP] Fuzzing framework by pstratem · Pull Request #7940 · bitcoin/bitcoin · GitHub 03:20 -!- CubicEarth [~cubiceart@2002:329f:7e15:0:6dcb:16b4:99d4:97e5] has joined #bitcoin-core-dev 03:22 < MarcoFalke> !m travis 03:22 < [b__b]> You're doing good work, travis! 03:22 < gribble> Error: "m" is not a valid command. 03:24 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 03:25 < MarcoFalke> seems to work, now 03:33 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Ping timeout: 244 seconds] 03:34 -!- CubicEarth [~cubiceart@2002:329f:7e15:0:6dcb:16b4:99d4:97e5] has quit [Remote host closed the connection] 03:42 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev 03:55 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.] 03:57 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 04:12 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev [] 04:14 -!- rabidus [~rabidus@uhiainen.com] has quit [Ping timeout: 250 seconds] 04:14 -!- rabidus [~rabidus@uhiainen.com] has joined #bitcoin-core-dev 04:21 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.] 04:23 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 04:29 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 04:30 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Client Quit] 04:30 -!- cryptapus [~cryptapus@87.254.202.201] has joined #bitcoin-core-dev 04:30 -!- cryptapus [~cryptapus@87.254.202.201] has quit [Changing host] 04:30 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 04:33 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Read error: Connection reset by peer] 04:35 -!- CubicEarth [~cubiceart@2002:329f:7e15:0:6dcb:16b4:99d4:97e5] has joined #bitcoin-core-dev 04:35 -!- cryptapus [~cryptapus@87.254.202.201] has joined #bitcoin-core-dev 04:35 -!- cryptapus [~cryptapus@87.254.202.201] has quit [Changing host] 04:35 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 04:39 -!- CubicEarth [~cubiceart@2002:329f:7e15:0:6dcb:16b4:99d4:97e5] has quit [Ping timeout: 256 seconds] 04:54 < jonasschnelli> wumpus: yes. I encountered the travis issue on other repos too 05:10 < luke-jr> sigh, looks like Travis is totally broken 05:14 <@wumpus> yep. 05:36 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 05:41 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Ping timeout: 260 seconds] 05:45 < jonasschnelli> Hmm... utf8 in not mandatory for JSON.. right? 05:45 < jonasschnelli> RFC 4627 does state: "JSON text SHALL be encoded in Unicode. The default encoding is 05:45 < jonasschnelli> UTF-8."? 05:54 < luke-jr> I thought it was.. :x 06:00 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 06:08 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev 06:10 <@wumpus> yes, utf-8 is mandatory for JSON 06:11 <@wumpus> and that is how everyone uses it. We're not going to support non-UTF-8 JSON in bitcoin core. 06:17 <@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 06: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 06:18 <@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 06:18 < timothy> who still uses wx? 06:18 <@wumpus> no one,but wallets grandfathered in from that time still exist 06:28 < jonasschnelli> A fix would be to add a UTF8 filter at the deserialization of an CAccountingEntry 06:28 < jonasschnelli> Somewhere here: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.h#L524 06:28 < jonasschnelli> But not going to do this. It's just not worth... 06:29 <@wumpus> I understand. THis is better handled on a per-case basis probably 06:30 < luke-jr> wumpus: wxBitcoin didn't support the stable wx, and required unicode XD 06:30 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 06:31 <@wumpus> luke-jr: ok. No clue then how he managed then :) 06:31 < luke-jr> did the RPC really prohibit it? 06:31 <@wumpus> no, but no one uses JSON without unicode, the sane languages prohibit it 06:31 < luke-jr> CLI? 06:32 <@wumpus> isn't cli usually unicode too? 06:32 < luke-jr> not always 06:32 <@wumpus> no, not always, so it's possible, it'll just be very rare on all accounts 06:33 < luke-jr> I think it's more commonly non-Unicode outside the English-speaking area 06:33 < luke-jr> or was until some years ago 06:33 < luke-jr> but nobody else has reported a problem.. so maybe not 06:34 <@wumpus> we're not talking about the 90's here 06:34 <@wumpus> or original VT-100 terminals or whatnot :) bitcoin isn't that old 06:35 <@wumpus> but yes it'll obviously be more common outside ENglish-speaking areas 06:37 -!- CubicEarth [~cubiceart@2002:329f:7e15:0:6dcb:16b4:99d4:97e5] has joined #bitcoin-core-dev 06:38 < jonasschnelli> I located the "issue" in the code. 06:38 < jonasschnelli> Its in univalue_read.cpp 06:38 < jonasschnelli> Univalue can't handle non UTF8 06:38 < jonasschnelli> (even if its allowed by the JSON RFC) 06:39 <@wumpus> that's fine, we don't want it to 06:39 < jonasschnelli> the read() function will resturn false 06:39 < jonasschnelli> Yes. We don't want this 06:40 <@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 06:41 <@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) 06:41 -!- CubicEarth [~cubiceart@2002:329f:7e15:0:6dcb:16b4:99d4:97e5] has quit [Ping timeout: 258 seconds] 06:49 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev 06:49 -!- paveljanik [~paveljani@79.98.72.176] has quit [Changing host] 06:49 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 06:51 -!- cysm [cysm@unaffiliated/paracyst] has quit [Ping timeout: 258 seconds] 07:03 < 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 07:11 < bitcoin-git> [bitcoin] demodun opened pull request #9173: demo (master...master) https://github.com/bitcoin/bitcoin/pull/9173 07:12 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #9173: demo (master...master) https://github.com/bitcoin/bitcoin/pull/9173 07:15 -!- cysm [cysm@unaffiliated/paracyst] has joined #bitcoin-core-dev 07:37 -!- CubicEarth [~cubiceart@2002:329f:7e15:0:6dcb:16b4:99d4:97e5] has joined #bitcoin-core-dev 07:38 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-wigihvkwbcatlrdi] has quit [Quit: Connection closed for inactivity] 07:43 -!- CubicEarth [~cubiceart@2002:329f:7e15:0:6dcb:16b4:99d4:97e5] has quit [Ping timeout: 258 seconds] 07:43 < cfields> morcos: ping. gentle reminder about the prevector bench. 07:44 < instagibbs> in what situations would ENABLE_WALLET be defined but pwalletMain be null? Or any other combination. 07:45 < cfields> instagibbs: ./configure --enable-wallet && ./bitcoind --disablewallet 07:45 < cfields> (i think) 07:45 < instagibbs> cfields, ah that seems likely. Thanks! 07:46 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 08:20 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:343f:32aa:26fa:66ed] has quit [Quit: .] 08:26 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-djndphyymhrasttf] has joined #bitcoin-core-dev 08:27 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:5c15:40e6:5986:2db4] has joined #bitcoin-core-dev 08:43 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Remote host closed the connection] 09:01 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 258 seconds] 09:02 -!- cysm [cysm@unaffiliated/paracyst] has quit [Ping timeout: 258 seconds] 09:02 -!- cryptapus_afk [~cryptapus@jupiter.osmus.org] has joined #bitcoin-core-dev 09:02 -!- cryptapus_afk [~cryptapus@jupiter.osmus.org] has quit [Changing host] 09:02 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 09:04 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev 09:04 -!- paveljanik [~paveljani@79.98.72.176] has quit [Changing host] 09:04 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 09:28 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving] 09:31 -!- cysm [cysm@unaffiliated/paracyst] has joined #bitcoin-core-dev 09:31 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Remote host closed the connection] 09:40 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 09:45 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Ping timeout: 248 seconds] 09:51 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 09:55 -!- cryptapus_afk [~cryptapus@jupiter.osmus.org] has joined #bitcoin-core-dev 09:55 -!- cryptapus_afk [~cryptapus@jupiter.osmus.org] has quit [Changing host] 09:55 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 10:12 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 10:22 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds] 10:26 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 10:35 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Remote host closed the connection] 10:35 -!- bsm1175321 [~mcelrath@38.121.165.30] has quit [Remote host closed the connection] 10:37 -!- bsm1175321 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev 10:46 -!- cryptapus_afk [~cryptapus@jupiter.osmus.org] has joined #bitcoin-core-dev 10:46 -!- cryptapus_afk [~cryptapus@jupiter.osmus.org] has quit [Changing host] 10:46 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 10:48 -!- BonyM1 [~BonyM-I@ua-83-227-211-4.cust.bredbandsbolaget.se] has quit [Ping timeout: 265 seconds] 10:50 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 10:55 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 11:03 -!- BonyM1 [~BonyM-I@ua-83-227-211-4.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev 11:18 -!- theymos [~theymos@unaffiliated/theymos] has joined #bitcoin-core-dev 11:19 < theymos> fyi, some apparently-popular antivirus is flagging Bitcoin Core 0.13.1: https://www.virustotal.com/en/file/c1726ccc50635795c942c7d7e51d979c4f83a3d17f8982e9d02a114a15fef419/analysis/ 11:34 < arubi> "Additional information" -> "VirusTotal metadata" -> "File names" -> "KMS V.1.2.3.exe" 11:34 < arubi> weird. 11:50 -!- Guest84529 [~chatzilla@71-84-219-33.dhcp.ccmn.ca.charter.com] has joined #bitcoin-core-dev 11:52 -!- Guest84529 is now known as roidster 11:58 < 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 11:58 < morcos> so i'd like to run longer tests to get rid of the noise... 11:59 < cfields> morcos: ok, np. thanks for testing 12:00 < 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. 12:01 < gmaxwell> btcdrak: any interest in trying to get that spurrious AV warning fixed? 12:03 < Victorsueca> theymos: Baidu lol 12:04 < Victorsueca> isn't that a Chinese page? 12:04 < Victorsueca> would bet Chinese government is behind that 12:08 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [] 12:16 < 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) 12:17 < morcos> once i re-removed the CScript copy contructor from the copy-move branch, its clearly much faster than the prevector-move branch 12:19 < cfields> morcos: interesting, that points to the speedup coming from less time copying 12:19 < btcdrak> gmaxwell: a job for a native chinese speaker I think. 12:19 < cfields> which is strange, because last i looked, there were very few of those copies 12:21 < cfields> morcos: hmm, though i suppose it could also come from construction/destruction. prevector as-is is pretty heavy on those 12:22 < cfields> grr, i should just bite the bullet and do a quick specialization of prevector for unsigned char. It should be simple enough. 12:23 -!- roidster [~chatzilla@71-84-219-33.dhcp.ccmn.ca.charter.com] has quit [Ping timeout: 268 seconds] 12:26 -!- arubi_ [~ese168@bzq-109-65-85-49.red.bezeqint.net] has joined #bitcoin-core-dev 12:27 -!- arubi_ [~ese168@bzq-109-65-85-49.red.bezeqint.net] has left #bitcoin-core-dev [] 12:30 < 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? 12:30 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 250 seconds] 12:31 < cfields> sipa: yes, but i'm pretty sure it could be sped up substantially if written specifically for packed bytes 12:33 < cfields> sipa: for ex, no alignment concerns 12:34 < gmaxwell> maybe time would be better spent working on flat transactions (which rrequires finishing making them immutable first)? 12:35 < cfields> flat transactions? 12:36 < sipa> cfields: one malloc 12:36 < cfields> oh, accessing serialized fields on the fly, or so? 12:37 < gmaxwell> doesn't have to be (and probably shouldn't be) in the seralized form we use on the wire. 12:37 < cfields> right, you mentioned this the other day 12:40 < cfields> gmaxwell: you mentioned you'd doodled some notes about a possible format. Happen to have those around? 12:42 < gmaxwell> Well what I was working on is on the other side, improved serialization for disk and network that is more compact. 12:43 < 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. 12:44 < sipa> doesn't sound hard 12:45 < sipa> concatenate all scripts into a single byte array, and have (begin_ptr, size) tuples to refer to them 12:45 < 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) 12:45 < 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. 12:45 < sipa> of course 12:46 -!- NielsvG [~Necrathex@unaffiliated/necrathex] has quit [Ping timeout: 245 seconds] 12:46 < 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. 12:49 -!- NielsvG [~Necrathex@2001:982:aa8:1:76d4:35ff:fe12:58d6] has joined #bitcoin-core-dev 12:49 -!- NielsvG [~Necrathex@2001:982:aa8:1:76d4:35ff:fe12:58d6] has quit [Changing host] 12:49 -!- NielsvG [~Necrathex@unaffiliated/necrathex] has joined #bitcoin-core-dev 12:50 < cfields> thanks, will take a look 12:51 < 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 12:51 < cfields> yes, i suppose in any scheme where all scripts are cat'd in memory, there'd be no need for something like prevector 12:55 < sipa> cfields: sure there is. prevector's primary benefit is in CCoins 12:57 < 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 12:57 < gmaxwell> that prevector isn't useful, but just for const transactions its a half-step. 12: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 13:00 < cfields> *indices 13:00 < sipa> cfields: for CCoins i want to move to a per-output model instead of per-tx 13:02 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 252 seconds] 13:06 < sipa> Chris_Stewart_5: because 6e340b9cffb37a989ca544e6bb780a2c78901d3fb33738768511a30617afa01d is the hash of OP_0 (0x00) and not of OP_TRUE (0x51) 13:06 < sipa> Chris_Stewart_5: so it's a perfectly valid p2wsh output, for the OP_FALSE witness script (which is unspendable) 13:07 < cfields> makes sense, though admittedly i'm not very familiar with that code. 13:07 < sipa> cfields: it needs design, implementation, and benchmarking 13:08 < 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) 13:09 < cfields> ah, i see 13:09 -!- theymos [~theymos@unaffiliated/theymos] has left #bitcoin-core-dev ["Leaving"] 13:09 < sipa> the easiest solution is storing height/coinbaseness in each output 13:09 < sipa> and txid 13:09 < sipa> but that's a lot of duplication 13:10 < sipa> though leveldb does deduplication of identical prefixes in the database 13:11 < sipa> an alternative is a txid->{height,coinbase,id} map, with id a short sequentially-assigned local id 13:11 < sipa> and then use (id,index)->{utxo} map for the utxos 13:11 < sipa> but that's an extra indirection 13:16 < cfields> well the first potentially brings a nice read speedup, no? Since the outputs are then somewhat sorted by hotness 13:17 < sipa> leveldb sorts by key 13:18 < sipa> and the way we're using leveldb i think hardly results in actual levels 13:18 < sipa> the batches are so large we always trigger compactions 13:19 < cfields> heh 13:20 < Chris_Stewart_5> sipa: Thanks for the help, mistakenly assumed it was still HASH160(SHA256()), is there a reason it is only 1 SHA256()? 13:21 < sipa> Chris_Stewart_5: yes, 160 bits is too little 13:22 < sipa> (it's too little for P2SH as well, but we weren't aware of the collision attack against it at the time) 13:22 < Chris_Stewart_5> sipa: Is it a HF to change P2SH to a SHA256? 13:23 < sipa> Chris_Stewart_5: of course 13:24 < sipa> when done naively, at least 13:24 < sipa> just defining something new P2SH-like could be done 13:25 < sipa> ... but that's essentially what P2WSH is 13:26 -!- ryanofsky [~russ@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Remote host closed the connection] 13:28 < Chris_Stewart_5> and with a versioning system now we can totally redefine the semantics of any witness scripts between versions, correct? 13:28 -!- ryanofsky [~russ@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 13:29 < sipa> yes 13:29 -!- ryanofsky [~russ@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Client Quit] 13:30 -!- ryanofsky [~russ@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 13:30 < 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 13:30 < sipa> it would however also break any existing p2sh users 13:31 < 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? 13:32 < sipa> that's an implementation detail 13:33 < 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 13:34 < Chris_Stewart_5> Why would you need to outlaw? 13:34 < sipa> because that's how i interpret 'moving to sha256' :) 13:34 < Chris_Stewart_5> ahhh ok 13:34 < sipa> if you would have said 'adding p2sh-sha256 feature', yes :) 13:34 < sipa> but that's pretty much what p2wsh is... in a better way 13:35 < Chris_Stewart_5> ... but I want to make p2sh great again. I'll see myself out. 13:36 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 260 seconds] 13:36 < sipa> hahaha 13:39 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev 13:46 -!- arubi [~ese168@unaffiliated/arubi] has quit [Quit: Leaving] 13:47 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev 14:31 -!- roidster [~chatzilla@71-84-219-33.dhcp.ccmn.ca.charter.com] has joined #bitcoin-core-dev 14:36 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev [] 14:40 -!- nabu [~jm@184.7.34.95.customer.cdi.no] has joined #bitcoin-core-dev 14:52 -!- nabu [~jm@184.7.34.95.customer.cdi.no] has quit [Ping timeout: 260 seconds] 15:13 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #bitcoin-core-dev 15:15 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection] 15:20 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 15:25 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has joined #bitcoin-core-dev 15:26 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-kpibxvzbqfkgmrbo] has joined #bitcoin-core-dev 15:26 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 256 seconds] 15:58 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-djndphyymhrasttf] has quit [Quit: Connection closed for inactivity] 16:37 -!- adiabat [~adiabat@67.205.158.84] has joined #bitcoin-core-dev 16:39 < jtimon> petertodd: regarding your last comment on the removign ISM thread...do you mean restoring ISM and then adding your new rule as a SF? 16:40 < jtimon> is the point to remove ISM later with a coordinated HF? 16:44 < BlueMatt> -rw------- 1 matt matt 1.7T Nov 16 16:44 /home/matt/.bitcoin/debug.log 16:44 < BlueMatt> lol 17:31 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-kpibxvzbqfkgmrbo] has quit [Quit: Connection closed for inactivity] 17:42 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rujcfyldlkzjyqpx] has quit [Quit: Connection closed for inactivity] 17:44 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-qricqiicuidykdau] has joined #bitcoin-core-dev 17:46 -!- ybit [~ybit@unaffiliated/ybit] has joined #bitcoin-core-dev 17:49 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 17:49 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 17:52 < shangzhou> gmaxwell: i did some search this morning at baidu. Searched "c1726ccc50635795c942c7d7e51d979c4f83a3d17f8982e9d02a114a15fef419" only one result (a thread http://8btc.com/thread-41510-1-5.html) someone use Avast complain that bitcoin 0.13.1 win exe downloaded from bitcoin.org was blocked by the avast. Search something like "bitcoin 0.13.1 win exe" top one is 17:52 < shangzhou> bitcoin.org's download link. 17:54 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Ping timeout: 250 seconds] 18:22 < bitcoin-git> [bitcoin] Christewart opened pull request #9174: Modifying incorrect comments from BIP66 -> BIP62 (master...master) https://github.com/bitcoin/bitcoin/pull/9174 18:59 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev 19:00 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.] 19:14 -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-core-dev 19:17 < veleiro> herro, tag release 13.1 on debian stretch 'make' gives me this: https://paste.debian.net/plain/896347 wat wrong :( 19:28 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-xsecnlwrykzdqdwh] has joined #bitcoin-core-dev 19:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds] 19:56 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev] 20:01 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-qricqiicuidykdau] has quit [Quit: Connection closed for inactivity] 20:07 -!- nickler [~nickler@185.12.46.130] has quit [Ping timeout: 244 seconds] 20:11 < sipa> veleiro: my guess is that you have too little memory 20:28 < veleiro> sipa: youre probably right. i'm so sure to doing make -j4? it uses too many resources is my guess 20:28 < veleiro> i just did a normal 'make' and it was a success.. 20:29 < veleiro> s/i'm so sure/i'm so use 20:29 < veleiro> thanks~ 20:39 < luke-jr> #bitcoin is the support channel btw 20:44 < veleiro> sorry luke-jr, its a big community now days. i didnt mean to bloat this chan 20:45 < luke-jr> np, just clarifying for next time 20:46 -!- nickler [~nickler@185.12.46.130] has joined #bitcoin-core-dev 20:47 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:5c15:40e6:5986:2db4] has quit [Quit: .] 20:49 < bitcoin-git> [bitcoin] mruddy opened pull request #9175: remove script checking dependency on checkpoints (master...script_check) https://github.com/bitcoin/bitcoin/pull/9175 20:49 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:5c15:40e6:5986:2db4] has joined #bitcoin-core-dev 21:08 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 21:12 -!- DigiByteDev [~JT2@218.250.11.174] has joined #bitcoin-core-dev 21:15 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds] 22:25 -!- rabidus [~rabidus@uhiainen.com] has quit [Remote host closed the connection] 22:32 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev 22:45 < bitcoin-git> [bitcoin] jtimon opened pull request #9176: Globals: Pass Consensus::Params through CBlockTreeDB::LoadBlockIndexGuts() (master...0.13-chainparams-loadblockindexguts) https://github.com/bitcoin/bitcoin/pull/9176 22:57 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-yqdqfcolkzapzhkm] has joined #bitcoin-core-dev 23:01 < bitcoin-git> [bitcoin] jtimon opened pull request #9177: NOMERGE: WIP: Support block signed custom testchains (master...0.13-blocksign) https://github.com/bitcoin/bitcoin/pull/9177 23:01 -!- rabidus [~rabidus@uhiainen.com] has joined #bitcoin-core-dev 23:12 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 23:12 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 256 seconds] 23:19 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 256 seconds] 23:21 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev 23:24 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Read error: Connection reset by peer] 23:26 -!- roidster [~chatzilla@71-84-219-33.dhcp.ccmn.ca.charter.com] has quit [Ping timeout: 268 seconds] 23:28 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev 23:32 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Remote host closed the connection] 23:38 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 23:43 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev 23:48 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 250 seconds] 23:49 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev