12017-05-18T00:00:35 *** niska has quit IRC
22017-05-18T00:00:51 *** abpa has quit IRC
32017-05-18T00:03:28 *** Giszmo has quit IRC
42017-05-18T00:04:23 *** Giszmo has joined #bitcoin-core-dev
52017-05-18T00:05:30 *** niska has joined #bitcoin-core-dev
62017-05-18T00:12:23 *** harrymm has joined #bitcoin-core-dev
72017-05-18T00:12:56 *** harrymm has joined #bitcoin-core-dev
82017-05-18T00:14:43 <bitcoin-git> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/bee35299716c...e317c0d19201
92017-05-18T00:14:44 <bitcoin-git> bitcoin/master 9f7341b Gregory Sanders: Add witness data output to TxInError messages
102017-05-18T00:14:44 <bitcoin-git> bitcoin/master 6e9e026 Gregory Sanders: Expand signrawtransaction.py to cover error witness checking
112017-05-18T00:14:45 <bitcoin-git> bitcoin/master e317c0d Pieter Wuille: Merge #8384: Add witness data output to TxInError messages...
122017-05-18T00:23:08 <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e317c0d19201...c33652576ce2
132017-05-18T00:23:08 <bitcoin-git> bitcoin/master 1b936f5 practicalswift: Replace boost::function with std::function (C++11)
142017-05-18T00:23:09 <bitcoin-git> bitcoin/master c336525 Pieter Wuille: Merge #10395: Replace boost::function with std::function (C++11)...
152017-05-18T00:23:38 <bitcoin-git> [bitcoin] sipa closed pull request #10395: Replace boost::function with std::function (C++11) (master...replace-boost-function) https://github.com/bitcoin/bitcoin/pull/10395
162017-05-18T00:28:11 *** goksinen has joined #bitcoin-core-dev
172017-05-18T00:28:22 *** kadoban_ has joined #bitcoin-core-dev
182017-05-18T00:28:29 *** kadoban has quit IRC
192017-05-18T00:28:53 *** sipa has joined #bitcoin-core-dev
202017-05-18T00:34:34 *** goksinen has quit IRC
212017-05-18T00:36:53 <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c33652576ce2...ae786098bc58
222017-05-18T00:36:53 <bitcoin-git> bitcoin/master ad415bc Thomas Snider: [net] Added SetSocketNoDelay() utility function
232017-05-18T00:36:54 <bitcoin-git> bitcoin/master ae78609 Pieter Wuille: Merge #10061: [net] Added SetSocketNoDelay() utility function...
242017-05-18T00:37:15 <bitcoin-git> [bitcoin] sipa closed pull request #10061: [net] Added SetSocketNoDelay() utility function (master...tjps_nodelay) https://github.com/bitcoin/bitcoin/pull/10061
252017-05-18T00:38:27 <bitcoin-git> [bitcoin] sipa closed pull request #8952: Add query options to listunspent RPC call (master...enhancement/improve-rpc-listunspent) https://github.com/bitcoin/bitcoin/pull/8952
262017-05-18T00:41:15 *** Ylbam has quit IRC
272017-05-18T00:44:32 *** Aaronvan_ has quit IRC
282017-05-18T00:45:05 *** AaronvanW has joined #bitcoin-core-dev
292017-05-18T00:47:26 *** Giszmo has quit IRC
302017-05-18T00:47:56 *** zooko has joined #bitcoin-core-dev
312017-05-18T00:48:09 *** justanotheruser has quit IRC
322017-05-18T00:49:27 *** AaronvanW has quit IRC
332017-05-18T00:51:10 *** justanotheruser has joined #bitcoin-core-dev
342017-05-18T00:52:09 *** goksinen has joined #bitcoin-core-dev
352017-05-18T00:56:27 *** goksinen has quit IRC
362017-05-18T01:05:50 *** Giszmo has joined #bitcoin-core-dev
372017-05-18T01:12:08 *** goksinen has joined #bitcoin-core-dev
382017-05-18T01:17:47 *** AaronvanW has joined #bitcoin-core-dev
392017-05-18T01:17:47 *** AaronvanW has joined #bitcoin-core-dev
402017-05-18T01:22:08 *** AaronvanW has quit IRC
412017-05-18T01:30:27 <bitcoin-git> [bitcoin] theuni closed pull request #10285: net: refactor the connection process. moving towards async connections. (master...connman-events6) https://github.com/bitcoin/bitcoin/pull/10285
422017-05-18T01:34:55 *** zooko has quit IRC
432017-05-18T01:37:22 *** Squidicuz has joined #bitcoin-core-dev
442017-05-18T01:38:39 *** Squidicc has quit IRC
452017-05-18T01:39:44 *** Squidicc has joined #bitcoin-core-dev
462017-05-18T01:39:58 *** owowo has quit IRC
472017-05-18T01:41:43 *** owowo has joined #bitcoin-core-dev
482017-05-18T01:42:09 *** Squidicuz has quit IRC
492017-05-18T01:42:27 *** Squidicuz has joined #bitcoin-core-dev
502017-05-18T01:45:09 *** Squidicc has quit IRC
512017-05-18T01:49:28 *** Squidicuz has quit IRC
522017-05-18T01:50:26 *** Squidicuz has joined #bitcoin-core-dev
532017-05-18T01:50:52 *** bitcoinreminder_ has joined #bitcoin-core-dev
542017-05-18T01:50:59 *** Squidicuz has quit IRC
552017-05-18T01:54:39 *** Dyaheon has quit IRC
562017-05-18T01:57:38 *** Dyaheon has joined #bitcoin-core-dev
572017-05-18T02:00:11 *** dermoth has quit IRC
582017-05-18T02:01:04 *** dermoth has joined #bitcoin-core-dev
592017-05-18T02:08:56 *** zooko has joined #bitcoin-core-dev
602017-05-18T02:23:31 *** kadoban_ is now known as kadoban
612017-05-18T02:32:14 *** cysm_ has quit IRC
622017-05-18T02:34:13 *** goksinen has quit IRC
632017-05-18T02:34:42 *** goksinen has joined #bitcoin-core-dev
642017-05-18T02:37:23 *** cysm_ has joined #bitcoin-core-dev
652017-05-18T03:09:09 *** spinza has quit IRC
662017-05-18T03:16:11 *** zooko has quit IRC
672017-05-18T03:18:11 *** zooko has joined #bitcoin-core-dev
682017-05-18T03:36:44 *** dermoth has quit IRC
692017-05-18T03:54:10 *** Victor_sueca has joined #bitcoin-core-dev
702017-05-18T03:56:57 *** Victorsueca has quit IRC
712017-05-18T03:57:11 *** zooko has quit IRC
722017-05-18T04:05:39 *** spinza has joined #bitcoin-core-dev
732017-05-18T04:17:13 *** bitcoinreminder_ has quit IRC
742017-05-18T04:18:22 *** Giszmo has quit IRC
752017-05-18T04:50:27 <bitcoin-git> [bitcoin] laanwj closed pull request #10417: BIP 148 support (master...master-BIP148) https://github.com/bitcoin/bitcoin/pull/10417
762017-05-18T04:57:11 *** juscamarena_ has quit IRC
772017-05-18T05:01:49 *** juscamarena_ has joined #bitcoin-core-dev
782017-05-18T05:25:21 *** LeMiner has quit IRC
792017-05-18T05:25:34 <paveljanik> ... the first night when my IRC log buffer doesn't show the whole night communication...
802017-05-18T05:25:59 <paveljanik> and more over it even rolled out my TODOs 8)
812017-05-18T05:28:19 *** LeMiner has joined #bitcoin-core-dev
822017-05-18T05:37:48 *** Dyaheon has quit IRC
832017-05-18T05:38:52 *** Dyaheon has joined #bitcoin-core-dev
842017-05-18T05:44:36 * wumpus made some people really angry
852017-05-18T05:46:47 *** cryptapus_afk has quit IRC
862017-05-18T05:49:51 *** goksinen has joined #bitcoin-core-dev
872017-05-18T05:50:52 *** goksinen has joined #bitcoin-core-dev
882017-05-18T05:51:59 <jcorgan> it think we need CAPRs (Contributor Activated Pull Requests) :-)
892017-05-18T05:54:18 <wumpus> heh
902017-05-18T05:54:57 *** goksinen has quit IRC
912017-05-18T06:27:59 *** justan0theruser has joined #bitcoin-core-dev
922017-05-18T06:28:22 *** Ylbam has joined #bitcoin-core-dev
932017-05-18T06:30:27 *** justanotheruser has quit IRC
942017-05-18T06:51:40 *** paveljanik has quit IRC
952017-05-18T06:54:20 *** BashCo has quit IRC
962017-05-18T07:10:24 *** AaronvanW has joined #bitcoin-core-dev
972017-05-18T07:10:28 *** AaronvanW has joined #bitcoin-core-dev
982017-05-18T07:11:13 *** AaronvanW has quit IRC
992017-05-18T07:11:48 *** AaronvanW has joined #bitcoin-core-dev
1002017-05-18T07:11:48 *** AaronvanW has joined #bitcoin-core-dev
1012017-05-18T07:16:35 *** BashCo has joined #bitcoin-core-dev
1022017-05-18T07:23:57 *** tripleslash has quit IRC
1032017-05-18T07:26:05 *** jtimon has quit IRC
1042017-05-18T07:27:29 *** tripleslash has joined #bitcoin-core-dev
1052017-05-18T07:38:07 *** cryptapus_afk has joined #bitcoin-core-dev
1062017-05-18T07:45:09 *** cryptapus_afk has quit IRC
1072017-05-18T07:52:18 *** Victor_sueca is now known as Victorsueca
1082017-05-18T07:53:00 <bitcoin-git> [bitcoin] practicalswift opened pull request #10419: [trivial] Fix two recently introduced typos (master...typos-201705) https://github.com/bitcoin/bitcoin/pull/10419
1092017-05-18T07:56:43 *** tripleslash has quit IRC
1102017-05-18T07:58:11 *** tripleslash has joined #bitcoin-core-dev
1112017-05-18T08:09:42 *** jannes has joined #bitcoin-core-dev
1122017-05-18T08:09:55 <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/ae786098bc58...2acface32aba
1132017-05-18T08:09:56 <bitcoin-git> bitcoin/master 64aa36e ããã³ ãã«: param variables made const
1142017-05-18T08:09:56 <bitcoin-git> bitcoin/master d60d54d ããã³ ãã«: merge with bitcoin core
1152017-05-18T08:09:57 <bitcoin-git> bitcoin/master 2acface Wladimir J. van der Laan: Merge #9750: Bloomfilter: parameter variables made constant...
1162017-05-18T08:10:10 <bitcoin-git> [bitcoin] laanwj closed pull request #9750: Bloomfilter: parameter variables made constant (master...bloomVar) https://github.com/bitcoin/bitcoin/pull/9750
1172017-05-18T08:10:29 *** fanquake has joined #bitcoin-core-dev
1182017-05-18T08:13:40 <fanquake> What we really need is a bot that picks out every typo, spurious include and incorrect space from every new PR, and embarrassingly notifies the contributor of their transgression
1192017-05-18T08:13:53 <fanquake> /s
1202017-05-18T08:14:17 <wumpus> in triplicate, of course
1212017-05-18T08:15:38 <wumpus> for typos in translation strings it could even be useful
1222017-05-18T08:15:43 <wumpus> but in comments, bleh
1232017-05-18T08:16:16 <wumpus> especially if the gist of the word is clear anyway
1242017-05-18T08:29:25 *** lichtamberg_ has joined #bitcoin-core-dev
1252017-05-18T08:29:39 *** Dyaheon has quit IRC
1262017-05-18T08:29:43 *** bitcoinreminder_ has joined #bitcoin-core-dev
1272017-05-18T08:30:17 *** Dyaheon has joined #bitcoin-core-dev
1282017-05-18T08:35:14 *** timothy has joined #bitcoin-core-dev
1292017-05-18T09:18:53 <bitcoin-git> [bitcoin] jonasschnelli pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/2acface32aba...962cd3f0587e
1302017-05-18T09:18:54 <bitcoin-git> bitcoin/master fbf385c Jonas Schnelli: [Qt] simple fee bumper with user verification
1312017-05-18T09:18:54 <bitcoin-git> bitcoin/master 2ec911f Jonas Schnelli: Add cs_wallet lock assertion to SignTransaction()
1322017-05-18T09:18:55 <bitcoin-git> bitcoin/master 2678d3d Jonas Schnelli: Show old-fee, increase a new-fee in Qt fee bumper confirmation dialog
1332017-05-18T09:19:13 <bitcoin-git> [bitcoin] jonasschnelli closed pull request #9697: [Qt] simple fee bumper with user verification (master...2017/02/qt_bumpfee) https://github.com/bitcoin/bitcoin/pull/9697
1342017-05-18T09:20:19 <jonasschnelli> Added https://github.com/bitcoin/bitcoin/pull/10240 to the "High-priority for review" project
1352017-05-18T09:26:40 *** lichtamberg_ has quit IRC
1362017-05-18T09:35:54 *** harrymm has quit IRC
1372017-05-18T09:36:55 *** lichtamberg_ has joined #bitcoin-core-dev
1382017-05-18T09:39:18 <timothy> hi, is there a max size for rev*.dat files?
1392017-05-18T09:40:23 *** Guyver2 has joined #bitcoin-core-dev
1402017-05-18T09:40:34 <wumpus> timothy: afaik no, the size of the rev depends on what is in the blk*.dat which is size-limited though
1412017-05-18T09:40:50 <timothy> yes, max size of blk is 128 MiB
1422017-05-18T09:41:18 <wumpus> I suppose the rev will always be smaller than the blk
1432017-05-18T09:41:44 <gmaxwell> wumpus: it could be larger if you did something absurd.
1442017-05-18T09:41:58 <timothy> gmaxwell: absurd like what?
1452017-05-18T09:42:15 <gmaxwell> wumpus: e.g. say early blocks make zillions of 9999 byte outputs, spendable with OP_TRUE. then later blocks spend them and do nothing else.
1462017-05-18T09:42:27 <gmaxwell> That will make the rev data larger than the related blocks.
1472017-05-18T09:43:01 <timothy> right
1482017-05-18T09:43:18 <gmaxwell> you could get them up to a ratio of perhaps 230 times larger.
1492017-05-18T09:44:14 <timothy> still less than 4GB (max file size of FAT32)
1502017-05-18T09:44:16 <gmaxwell> of course none of these txn would pass standardness tests and what not... not likely to see it in mainnet, but it's possible.
1512017-05-18T09:44:32 <timothy> uhm no, more than that
1522017-05-18T09:44:47 <timothy> 30 GB
1532017-05-18T09:46:36 <wumpus> oh wow that's pretty bad
1542017-05-18T09:47:25 <wumpus> so I guess ideally the logic should be: if *either* the rev or dat reaches 128MB, roll to the next file
1552017-05-18T09:51:27 *** JackH has quit IRC
1562017-05-18T09:52:01 <timothy> is there any reason to use 128 MiB instead of other values?
1572017-05-18T09:52:36 <gmaxwell> it should be relatively small because it preallocates to reduce fragmentation. (or otherwise windows users cry)
1582017-05-18T09:52:56 <timothy> NTFS doesn't support fallocate or similar?
1592017-05-18T09:52:59 <gmaxwell> but not so small that its making a kazillion files and causing poor file system performance.
1602017-05-18T09:53:18 <timothy> I mean, preallocation without really writing the bytes
1612017-05-18T09:53:45 <gmaxwell> I long since forgot what the tradeoff surface was on windows.
1622017-05-18T09:53:56 <gmaxwell> But I didn't think NTFS did sparse files.
1632017-05-18T09:54:08 <wumpus> I guess it could harmlessly be changed to 256, but I expect there to be no performance gain
1642017-05-18T09:54:25 <gmaxwell> wumpus: 60 GB rev files! :P
1652017-05-18T09:54:38 <wumpus> gmaxwell: yeah after rev files capped ofcourse
1662017-05-18T09:59:02 <wumpus> with a blow-up of 230, at least one block's undo data would fit into that :-)
1672017-05-18T10:00:32 <gmaxwell> sipa might have more accurate figures on the worst case, but it's something around that much.
1682017-05-18T10:02:58 <wumpus> "Most modern file systems support sparse files, including most Unix variants and NTFS, but notably not Apple's HFS+. Sparse files are commonly used for disk images, database snapshots, log files and in scientific applications."
1692017-05-18T10:03:08 <wumpus> so MacOS is the problem here, not windows
1702017-05-18T10:07:23 *** cryptapus_afk has joined #bitcoin-core-dev
1712017-05-18T10:10:14 <gmaxwell> The extra question though is if they prevent fragmentation.
1722017-05-18T10:12:13 <wumpus> I don't know, is there such a guarantee for UNIX filesystems?
1732017-05-18T10:14:41 <wumpus> oh I was confused, this isn't about sparse files at all but posix_fallocate
1742017-05-18T10:15:14 <wumpus> in which case the disk space is reserved explicitly
1752017-05-18T10:15:50 *** Aaronvan_ has joined #bitcoin-core-dev
1762017-05-18T10:17:30 <gmaxwell> sorry, confusion I caused, late here.
1772017-05-18T10:17:56 *** AaronvanW has quit IRC
1782017-05-18T10:18:38 *** chjj has quit IRC
1792017-05-18T10:19:22 <wumpus> we apparently do have an implementation of AllocateFileRange for windows, but as I understand from MSDN it might create a sparse file (SetEndOfFile sets the file size,but not the "allocation size"), so this confusion is more general :)
1802017-05-18T10:22:43 <wumpus> the documentation is confusing though so I'm not sure
1812017-05-18T10:23:45 *** chjj has joined #bitcoin-core-dev
1822017-05-18T10:23:58 *** mol has joined #bitcoin-core-dev
1832017-05-18T10:27:04 *** molz_ has quit IRC
1842017-05-18T10:29:17 *** riemann has joined #bitcoin-core-dev
1852017-05-18T10:39:33 *** bitcoinreminder_ has quit IRC
1862017-05-18T10:40:34 *** laurentmt has joined #bitcoin-core-dev
1872017-05-18T10:44:07 *** laurentmt has quit IRC
1882017-05-18T11:00:52 *** lichtamberg_ has left #bitcoin-core-dev
1892017-05-18T11:18:38 *** BashCo has quit IRC
1902017-05-18T11:19:50 *** BashCo has joined #bitcoin-core-dev
1912017-05-18T11:22:21 *** laurentmt has joined #bitcoin-core-dev
1922017-05-18T11:31:11 *** laurentmt has quit IRC
1932017-05-18T12:16:40 *** jtimon has joined #bitcoin-core-dev
1942017-05-18T12:35:20 *** str4d has joined #bitcoin-core-dev
1952017-05-18T12:56:52 *** harrymm has joined #bitcoin-core-dev
1962017-05-18T12:58:49 *** rgod has joined #bitcoin-core-dev
1972017-05-18T12:59:49 <bitcoin-git> [bitcoin] fanquake closed pull request #9427: Use compact blocks for blocks that have equal work to our active tip (master...UseCmpctBlockForCompetingBlocks) https://github.com/bitcoin/bitcoin/pull/9427
1982017-05-18T13:04:17 *** JackH has joined #bitcoin-core-dev
1992017-05-18T13:58:04 *** paveljanik has joined #bitcoin-core-dev
2002017-05-18T14:05:35 *** mol has quit IRC
2012017-05-18T14:06:09 *** moli_ has joined #bitcoin-core-dev
2022017-05-18T14:08:34 *** str4d has quit IRC
2032017-05-18T14:14:18 *** goksinen has joined #bitcoin-core-dev
2042017-05-18T14:15:12 *** fanquake has quit IRC
2052017-05-18T14:24:05 *** goksinen has quit IRC
2062017-05-18T14:26:48 *** goksinen has joined #bitcoin-core-dev
2072017-05-18T14:30:02 <bitcoin-git> [bitcoin] ryanofsky opened pull request #10420: Add Qt tests for wallet spends & bumpfee (master...pr/btest) https://github.com/bitcoin/bitcoin/pull/10420
2082017-05-18T14:30:54 *** Giszmo has joined #bitcoin-core-dev
2092017-05-18T14:42:44 *** timothy has quit IRC
2102017-05-18T14:58:06 *** riemann has quit IRC
2112017-05-18T15:24:03 *** BartokIT has joined #bitcoin-core-dev
2122017-05-18T15:24:54 *** zooko has joined #bitcoin-core-dev
2132017-05-18T15:25:01 *** BartokIT has joined #bitcoin-core-dev
2142017-05-18T15:27:15 <BartokIT> I want a clarification about the BIP32, is this the correct group
2152017-05-18T15:31:54 *** mol has joined #bitcoin-core-dev
2162017-05-18T15:32:55 <BartokIT> The BIP32 allow to audit sharing the master public key
2172017-05-18T15:33:17 <BartokIT> This is mentioned in the mediawiki
2182017-05-18T15:35:17 *** moli_ has quit IRC
2192017-05-18T15:35:37 <BartokIT> But if we use the hardened key this is impossible? Is this wrong?
2202017-05-18T15:39:48 *** BartokIT has quit IRC
2212017-05-18T15:46:56 *** abpa has joined #bitcoin-core-dev
2222017-05-18T15:54:31 *** zooko has quit IRC
2232017-05-18T15:57:13 *** zooko has joined #bitcoin-core-dev
2242017-05-18T16:03:31 *** goksinen has quit IRC
2252017-05-18T16:17:28 *** zooko has quit IRC
2262017-05-18T16:18:41 *** BashCo has quit IRC
2272017-05-18T16:19:34 *** zooko has joined #bitcoin-core-dev
2282017-05-18T16:36:57 <bitcoin-git> [bitcoin] practicalswift opened pull request #10421: [qt] Remove excess logic (master...if-expr-return-true-else-return-false) https://github.com/bitcoin/bitcoin/pull/10421
2292017-05-18T16:38:38 *** annanay25 has quit IRC
2302017-05-18T16:38:46 *** annanay25 has joined #bitcoin-core-dev
2312017-05-18T16:39:44 <bitcoin-git> [bitcoin] morcos opened pull request #10422: Fix timestamp in fee estimate debug message (master...fixtimeunits) https://github.com/bitcoin/bitcoin/pull/10422
2322017-05-18T16:39:46 *** harrymm has quit IRC
2332017-05-18T16:40:39 *** BashCo has joined #bitcoin-core-dev
2342017-05-18T16:42:22 *** harrymm has joined #bitcoin-core-dev
2352017-05-18T16:51:28 <sipa> wumpus, gmaxwell: the 128 MiB is a tradeoff between fragmentation overhead and granularity for pruning
2362017-05-18T16:51:49 <sipa> the very first versions of the patch that introduced it (ultraprune) just used a single file per block
2372017-05-18T16:51:57 <sipa> but that was very slow
2382017-05-18T16:54:31 <luke-jr> sipa: I wonder if pruning ought to perhaps consider punching sparse holes?
2392017-05-18T16:54:53 *** SopaXorzTaker has quit IRC
2402017-05-18T16:55:08 <sipa> luke-jr: i think we can also just reduce that 128MiB number significantly
2412017-05-18T16:55:25 <morcos> i think 128 works fine for now doesn't it?
2422017-05-18T16:55:34 <luke-jr> maybe. but some filesystems perform differently than others..
2432017-05-18T16:55:40 <morcos> perhaps if we properly introduce sharding, then we need to rethink the design
2442017-05-18T16:55:47 <luke-jr> btrfs is annoyingly slow, I've found.
2452017-05-18T16:56:04 *** SopaXorzTaker has joined #bitcoin-core-dev
2462017-05-18T17:03:15 <wumpus> sipa: yes, it seems a good compromise
2472017-05-18T17:03:55 <wumpus> AFAIK monero stores all blocks in a single lmdb
2482017-05-18T17:04:09 <wumpus> why reduce the 128? agree with morcosthat it works fine
2492017-05-18T17:06:36 *** rgod_ has joined #bitcoin-core-dev
2502017-05-18T17:06:38 <wumpus> for pruning granularity it's also good enough, given how much space the utxo database takes a variance of 128mb+~16mb (usual rev files) doesn't seem to bad
2512017-05-18T17:07:24 *** rgod has quit IRC
2522017-05-18T17:14:31 *** laurentmt has joined #bitcoin-core-dev
2532017-05-18T17:19:31 <wumpus> although it could be worse than that in some cases depending on how blocks are distributed over the files
2542017-05-18T17:21:38 *** rgod_ has quit IRC
2552017-05-18T17:27:25 *** laurentmt has quit IRC
2562017-05-18T17:31:53 <sipa> wumpus: ok
2572017-05-18T17:49:39 <wumpus> and 128mb is at most 128 blocks, less than a day of blocks, even less than that w/ witness data, it's not that much
2582017-05-18T17:49:48 *** goksinen has joined #bitcoin-core-dev
2592017-05-18T17:51:01 *** zooko has quit IRC
2602017-05-18T17:59:57 <bitcoin-git> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/962cd3f0587e...28c6e8d71b3a
2612017-05-18T17:59:58 <bitcoin-git> bitcoin/master d8e03c0 Jack Grigg: torcontrol: Improve comments
2622017-05-18T17:59:59 <bitcoin-git> bitcoin/master 29f3c20 Jack Grigg: torcontrol: Add unit tests for Tor reply parsers
2632017-05-18T17:59:59 <bitcoin-git> bitcoin/master d63677b Jack Grigg: torcontrol: Fix ParseTorReplyMapping...
2642017-05-18T18:00:31 <bitcoin-git> [bitcoin] laanwj closed pull request #10408: Net: Improvements to Tor control port parser (master...torcontrol-parser-patches) https://github.com/bitcoin/bitcoin/pull/10408
2652017-05-18T18:13:33 <luke-jr> wumpus: it's much more than 128 blocks early in the chain?
2662017-05-18T18:13:40 <sipa> yes
2672017-05-18T18:13:57 <wumpus> luke-jr: of course, but it blasts past that anyway
2682017-05-18T18:14:09 <wumpus> most pruning nodes will be - more or less - up to date
2692017-05-18T18:20:38 <wumpus> but yes it's easy to forget that once, blocks were that far from full
2702017-05-18T18:27:08 *** Sprh has joined #bitcoin-core-dev
2712017-05-18T18:39:36 *** d_t has quit IRC
2722017-05-18T18:41:45 *** zooko has joined #bitcoin-core-dev
2732017-05-18T18:51:35 *** MrHodl has joined #bitcoin-core-dev
2742017-05-18T18:51:36 *** MrHodl has left #bitcoin-core-dev
2752017-05-18T18:51:41 <bitcoin-git> [bitcoin] instagibbs closed pull request #9102: Really don't validate genesis block (master...dontvalidategenesis) https://github.com/bitcoin/bitcoin/pull/9102
2762017-05-18T18:55:19 *** SopaXorzTaker has quit IRC
2772017-05-18T19:01:19 *** Dyaheon has quit IRC
2782017-05-18T19:01:20 <luke-jr> meeting?
2792017-05-18T19:01:24 <jonasschnelli> jup
2802017-05-18T19:01:33 <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
2812017-05-18T19:01:37 <sdaftuar> hello
2822017-05-18T19:01:41 <instagibbs> here
2832017-05-18T19:01:41 <CodeShark> hi
2842017-05-18T19:01:43 <wumpus> #startmeeting
2852017-05-18T19:01:43 <lightningbot> Meeting started Thu May 18 19:01:43 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
2862017-05-18T19:01:43 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2872017-05-18T19:02:10 <kanzure> hi.
2882017-05-18T19:02:17 <sipa> yow
2892017-05-18T19:02:24 *** Dyaheon has joined #bitcoin-core-dev
2902017-05-18T19:02:26 <cfields> hi
2912017-05-18T19:02:26 <CodeShark> I just have one topic for today, but I'll let others suggest theirs
2922017-05-18T19:02:34 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/28c6e8d71b3a...ea6fde3f1d26
2932017-05-18T19:02:34 <bitcoin-git> bitcoin/master 618d07f Jorge Timón: MOVEONLY: tx functions to consensus/tx_verify.o...
2942017-05-18T19:02:35 <bitcoin-git> bitcoin/master ea6fde3 Wladimir J. van der Laan: Merge #8329: Consensus: MOVEONLY: Move functions for tx verification...
2952017-05-18T19:02:39 <wumpus> topics?
2962017-05-18T19:02:49 <CodeShark> #topic clientside filtering
2972017-05-18T19:02:55 <jonasschnelli> ack
2982017-05-18T19:03:26 <luke-jr> BIP148
2992017-05-18T19:03:33 <luke-jr> (after clientside filtering etc)
3002017-05-18T19:03:50 <wumpus> I don't think that works CodeShark, I think only the chair can set the topic
3012017-05-18T19:03:55 <wumpus> #topic clientside filtering
3022017-05-18T19:03:58 <CodeShark> :)
3032017-05-18T19:04:19 <CodeShark> so there are several filtering options with different performance tradeoffs
3042017-05-18T19:04:40 <CodeShark> bloom filters have been typically considered - but there are some other ideas that might be worth considering
3052017-05-18T19:04:56 <jonasschnelli> Filter for BDF, read gmaxwell's reply: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012637.html
3062017-05-18T19:05:00 <CodeShark> roasbeef has worked on an idea based on golomb coded sets
3072017-05-18T19:05:27 <jonasschnelli> «he most efficient data structure is similar to a bloom filter, but you use more bits and only one hash function. The result will be mostly zero bits. Then you entropy code it using RLE+Rice coding or an optimal binomial packer (e.g. https://people.xiph.org/~greg/binomial_codec.c).»
3082017-05-18T19:05:55 <sipa> yes?
3092017-05-18T19:05:56 <CodeShark> gcs sacrifices CPU for space
3102017-05-18T19:06:14 <jonasschnelli> I think what we would need is data about the filter size for the last 100000 blocks...
3112017-05-18T19:06:16 <CodeShark> filters are smaller, but queries are more computationally expensive
3122017-05-18T19:06:19 <gmaxwell> CodeShark: CPU for who when is always the question.
3132017-05-18T19:06:24 <roasbeef> jonasschnelli: I have that
3142017-05-18T19:06:32 <jonasschnelli> roasbeef: Oo... share?
3152017-05-18T19:06:33 <CodeShark> hey, roasbeef! :)
3162017-05-18T19:07:01 <gmaxwell> what BIP37 does is very cpu expensive for the serving party, which is why it leads to dos attacks.
3172017-05-18T19:07:17 <gmaxwell> with any of the map based proposals that goes away and the cost to construct is not very relevant.
3182017-05-18T19:07:24 <CodeShark> constructing a gcs isn't very computationally expensive
3192017-05-18T19:07:38 <sipa> more so than bip37
3202017-05-18T19:07:43 <gmaxwell> Similarly, cost to lookup is not very relevant, the reciever will decode one per block.
3212017-05-18T19:07:48 <CodeShark> the queries are a little more computationally expensive than bloom filters, but that is done on client
3222017-05-18T19:07:51 <roasbeef> jonasschnelli: i have a csv file of stats for the entire chain, can easily get the last 100k out of it, the csv file itself is 14MB
3232017-05-18T19:07:57 <gmaxwell> sipa: maybe the lots of hash functions make it more expensive than you might guess.
3242017-05-18T19:08:06 <jonasschnelli> roasbeef: I take the complete one,. thanks. :)
3252017-05-18T19:08:14 <CodeShark> but gcs only needs to be computed once per block
3262017-05-18T19:08:29 <sipa> CodeShark: do you suggest this as something that blocks commit to?
3272017-05-18T19:08:36 <sipa> or something that a full node would precompute and store?
3282017-05-18T19:08:42 <roasbeef> with bloom filters, there are several hash functions, with the gcs based approach, there's a single hash function. but the set itself is compressed, so you need to decompress as you query
3292017-05-18T19:08:43 <CodeShark> the latter for starters
3302017-05-18T19:08:44 <sipa> i suppose the last
3312017-05-18T19:08:46 <jonasschnelli> precomp and store
3322017-05-18T19:08:50 <roasbeef> sipe: something a node would precompute and store, to start
3332017-05-18T19:08:58 <sipa> okay
3342017-05-18T19:09:19 <sipa> what would be stored in the set?
3352017-05-18T19:09:23 <gmaxwell> I'm dubious that we'd get state of the art performance from golomb coding, but interested to see.
3362017-05-18T19:09:26 <jonasschnelli> Can be done after the block has been connected
3372017-05-18T19:10:04 <gmaxwell> sipa: I believe the discussion is the 'bloom map' proposal.
3382017-05-18T19:10:13 <CodeShark> roasbeef was suggesting two filters - one for super lightweight clients, another for clients that require more sophisticated queries
3392017-05-18T19:10:40 <jonasschnelli> What are the differences? The tx template types?
3402017-05-18T19:10:46 <CodeShark> the former would only encode UTXOs, the latter would also encode witness data
3412017-05-18T19:10:56 <gmaxwell> encode witness data?!
3422017-05-18T19:11:16 <CodeShark> well, if you want to query for whether a particular execution path has been taken - necessary for things like lightning
3432017-05-18T19:11:32 <roasbeef> basic has: outpoints, script data pushes. extended has: witness stack, sig script data pushes, txids
3442017-05-18T19:11:46 <sipa> but do you need to _search_ based on witness data?
3452017-05-18T19:11:51 <sipa> i understand you may want to see it
3462017-05-18T19:12:01 <sipa> but you know what UTXOs to query for, no?
3472017-05-18T19:12:35 <CodeShark> I'm guessing revocation enforcement might be outsourced to nodes that cannot know the exact transaction format - only some key
3482017-05-18T19:12:50 <CodeShark> roasbeef, wanna comment?
3492017-05-18T19:12:53 <gmaxwell> Yes, requesting it is fine, searching on it? Be careful: it has serious long term implications if you expect that data will even be readily available. I am doubtful five years from now most nodes will have any witness data from more than a year back.
3502017-05-18T19:13:22 <gmaxwell> (witness data also means non-utxo transaction data in that above comment)
3512017-05-18T19:13:54 <gmaxwell> aside, I'm glad to hear this discussion has moved past just replicating the BIP37 mechenism.
3522017-05-18T19:13:58 <roasbeef> rationale to include witness data was to allow light cleitns to efficielty scan for things like reusable addresses (stealth addresses), i think my model of how folks do that on-chain these days is dated thoughu, i guess they stuff a notification on Op_returns?
3532017-05-18T19:14:19 <sipa> i'm not sure that is worth the cost
3542017-05-18T19:14:30 <sipa> also, individual scriptPubKey pushes?
3552017-05-18T19:14:46 <sipa> if anything, my preference would just be outpoints and full scriptPubKeys
3562017-05-18T19:14:50 <roasbeef> they do make the extended filters quite a bit bigger (i have testnet data also)
3572017-05-18T19:14:54 <gmaxwell> well no one does those things in practice, and everyone who previously has implemented them that I'm aware of performed all scanning via a centeralized server, even though they could have matched on the OP_RETURN.
3582017-05-18T19:15:23 <CodeShark> we can always start with the simplest minimal filter and then add more if we find use cases
3592017-05-18T19:15:24 <roasbeef> gmaxwell: well the intention was to allow the new light client mode to actually make using them pratcical without delegating to a central server
3602017-05-18T19:15:41 <gmaxwell> roasbeef: that was already possible with BIP37 and the prior design.
3612017-05-18T19:15:47 <jonasschnelli> Can we start with adding the same elements that bip37 does?
3622017-05-18T19:15:48 <roasbeef> sipa: so including the op-codes?
3632017-05-18T19:16:02 <gmaxwell> Usuabilty of SPV clients that scan using BIP37 is really poor though, thus the rise of electrum.
3642017-05-18T19:16:04 <sipa> roasbeef: bah, and 1) further encourage op_returns and 2) make them even more expensive for full nodes?
3652017-05-18T19:16:26 <gmaxwell> jonasschnelli: the things BIP37 added largely turned out to be a mistake that really degraded BIP37 so I hope a new proposal would do less.
3662017-05-18T19:16:40 <sipa> well the degradation problem doesn't exist here
3672017-05-18T19:16:47 <sipa> as the filter is not cumulative
3682017-05-18T19:17:02 <luke-jr> sipa: is there a way to do it without OP_RETURN?
3692017-05-18T19:17:05 <gmaxwell> yes, but you still need a bigger filter for same FP ratio. It's just less awful. :)
3702017-05-18T19:17:14 <sipa> luke-jr: sure, payment protocol like systems
3712017-05-18T19:17:27 <luke-jr> well, true, but then you don't need the crypto stuff for it
3722017-05-18T19:17:42 <sipa> i think that's a separate discussion and probably not one for here
3732017-05-18T19:17:48 <luke-jr> k
3742017-05-18T19:17:58 <CodeShark> for starters we should look at the most basic use cases
3752017-05-18T19:18:00 <gmaxwell> Yea, we should have a subcommittee. :P
3762017-05-18T19:18:07 <sipa> jonasschnelli, CodeShark, roasbeef: is there a use case for individual pushes in scriptPubKeys?
3772017-05-18T19:18:13 <jonasschnelli> the action is probably define a set of filter and create a spec that leaves room for future filter types
3782017-05-18T19:18:22 <CodeShark> jonasschnelli: indeed
3792017-05-18T19:18:30 <sipa> especially in a world where everything is P2PKH/P2SH/P2WPKH/P2WSH
3802017-05-18T19:18:38 <CodeShark> once we have the framework for adding new filters, it should be easy to do
3812017-05-18T19:18:40 *** ajd_ has joined #bitcoin-core-dev
3822017-05-18T19:18:43 <gmaxwell> jonasschnelli: multiple filter types can result in n-fold overhead, which will be a significant pressure against defining many.
3832017-05-18T19:18:47 <roasbeef> sipa: sure, the filter is smaller if one doesn't include the op-code as well
3842017-05-18T19:19:00 <sipa> roasbeef: eh?
3852017-05-18T19:19:26 <sipa> i must be misunderstanding something then
3862017-05-18T19:19:27 <roasbeef> oh you mean insert the _entire_ thing
3872017-05-18T19:19:36 <sipa> yes, just the whole scriptPubKey
3882017-05-18T19:19:41 <sipa> 1 element per output
3892017-05-18T19:19:59 <sipa> well, and another one for the outpoint
3902017-05-18T19:20:08 <roasbeef> mhmm, only advtange to data pushes in that case is in a world where mbare multi-sig is actually used
3912017-05-18T19:20:16 <gmaxwell> sipa: wait why?
3922017-05-18T19:20:23 <sipa> gmaxwell: why what?
3932017-05-18T19:20:27 <gmaxwell> roasbeef: yes, which we don't expect that world to exist.
3942017-05-18T19:20:51 <sipa> roasbeef: yes, the reason it's in BIP37 is for bare multisig support... but i don't think that's very interesting now
3952017-05-18T19:20:52 <gmaxwell> sipa: I expect one insert per output. The scriptpubkey. Why would you insert anything else (for normal functionality)
3962017-05-18T19:21:01 *** justan0theruser is now known as justanotheruser
3972017-05-18T19:21:06 <gmaxwell> s/now/ever/ but hindsight is 20/20
3982017-05-18T19:21:18 <gmaxwell> blockchain isn't a message bus. :P
3992017-05-18T19:21:19 <sipa> i guess if you want to look for an outpoint, you can always search for its scriptPubKey
4002017-05-18T19:21:26 <gmaxwell> sipa: right.
4012017-05-18T19:21:27 <gmaxwell> okay.
4022017-05-18T19:21:58 <sipa> in BIP37 there was a reason to separate it, as it would be less bandwidth if you wanted a specific coutpoint, despite there being many scriptPubKeys with it
4032017-05-18T19:22:08 <sipa> but here, that reason doesn't really matter i think?
4042017-05-18T19:22:30 <sipa> roasbeef: what do you think? just a filter with scriptPubKeys?
4052017-05-18T19:22:33 <gmaxwell> sipa: the privacy leak from correlated data still exists in map proposals, based on what blocks you choose to scan further, though much less severe than BIP37. Keep that in mind.
4062017-05-18T19:22:58 <roasbeef> if it's just spk's, then how does one query the filters to see if an outoint has been spent?
4072017-05-18T19:23:35 <sipa> roasbeef: by querying for the scriptPubKey that outpoint created
4082017-05-18T19:23:41 <sipa> roasbeef: which you will always know, i think?
4092017-05-18T19:23:55 <gmaxwell> roasbeef: by looking for its spk.
4102017-05-18T19:24:09 <roasbeef> sipa: which would require adding parts of the witness/sigScript though?
4112017-05-18T19:24:14 <sipa> ?
4122017-05-18T19:24:26 <sipa> i'm confused
4132017-05-18T19:24:31 <roasbeef> me too :)
4142017-05-18T19:24:38 <CodeShark> txhash:txindex -> scriptPubKey
4152017-05-18T19:24:38 <sipa> maybe we should do this outside of the meeting
4162017-05-18T19:24:39 <gmaxwell> roasbeef: has nothing to do with the witness. You validate the transaction, you know the content of the outpoint.
4172017-05-18T19:24:51 <sipa> it seems we're doing protocol design here now
4182017-05-18T19:25:03 <gmaxwell> 12:17 < gmaxwell> Yea, we should have a subcommittee. :P
4192017-05-18T19:25:17 <CodeShark> anyhow, we don't need to decide the specifics of what goes in the filter right now
4202017-05-18T19:25:22 <sipa> agree
4212017-05-18T19:25:27 <roasbeef> ok, sure, to summarize: we have working code for the construction, have nearly finished integrating it into lnd, have a BIP draft that should be ready by next week-ish (will also integrate feedback from thjis discussion)
4222017-05-18T19:25:31 <CodeShark> I like the idea of creating a framework that allows us to arbitrarily define filters later on
4232017-05-18T19:25:32 <sipa> i think it's an interesting thing to research further
4242017-05-18T19:25:41 <sipa> not sure what else needs to be discussed here
4252017-05-18T19:25:41 <gmaxwell> well we aren't deciding anything right now... :)
4262017-05-18T19:25:43 <gmaxwell> CodeShark: I do not.
4272017-05-18T19:26:00 <jonasschnelli> BTW: kallewoof has an draft impl. on serving filters over the p2p (though bloom): https://github.com/kallewoof/bitcoin/pull/1/files (in case someone wants to drive this further)
4282017-05-18T19:26:05 <gmaxwell> CodeShark: there is an n-fold cost to additional filters. It is unlikely to me that nodes would be willing to carry arbritarily many in the future.
4292017-05-18T19:26:14 <gmaxwell> CodeShark: there might be a reasonable case for more than one, sure.
4302017-05-18T19:26:56 <gmaxwell> In any case, I think this is good to open up more discussion and participation.
4312017-05-18T19:27:09 <gmaxwell> I'm quite happy to hear that there is activity in this area and I'd like to help.
4322017-05-18T19:27:10 <jonasschnelli> gmaxwell: I see this point but I don't think it would hurt if the specs would allow new filter types
4332017-05-18T19:27:13 <CodeShark> gmaxwell: point is the code complexity to support adding arbitrary filters isn't that great and it avoids the bikeshed in writing up the initial BIP ;)
4342017-05-18T19:27:30 <gmaxwell> jonasschnelli: yea sure, whatever, but thats just a type paramter.
4352017-05-18T19:27:40 <jonasschnelli> gmaxwell: right.
4362017-05-18T19:28:12 <sipa> end of topic?
4372017-05-18T19:28:13 * roasbeef now uunderstands what sipa was referring to
4382017-05-18T19:28:31 <wumpus> I don't think any other have been proposed?
4392017-05-18T19:28:47 <gmaxwell> you're gonna regret saying that.. :P
4402017-05-18T19:29:07 <gmaxwell> quick: high priority PRs.
4412017-05-18T19:29:09 <wumpus> nearly halfway time
4422017-05-18T19:29:14 <jonasschnelli> kallewoof had also an approch that peers could serve digests of filters to check the integrity among different peers
4432017-05-18T19:29:15 <wumpus> #topic high priority PRs
4442017-05-18T19:29:33 <sipa> small topic for later: bytes_serialized
4452017-05-18T19:29:34 <gmaxwell> Congrats Morcos on the merge of the new fee estimator stuff.
4462017-05-18T19:29:43 <jonasschnelli> \o/
4472017-05-18T19:29:45 <sipa> it will need cleanups, but that's fine
4482017-05-18T19:29:56 <morcos> thanks, quick PSA.. if you run master now it'll blow away your old fee estimates, you might want to make a copy
4492017-05-18T19:30:01 <wumpus> quite a few high priority PRs were merged this week, so there's place for new ones, please speak up if there's any that block further work for you
4502017-05-18T19:30:04 <gmaxwell> "micros" not withstanding.
4512017-05-18T19:30:17 <morcos> i'm hoping to get an improvment which makes the transition more seamless before 0.15
4522017-05-18T19:30:46 <sdaftuar> sipa: i'm basically done reviewing per-txout (#10195), looks awesome! running some benchmarks now.
4532017-05-18T19:30:50 <gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
4542017-05-18T19:30:57 <sipa> sdaftuar: thank you so much
4552017-05-18T19:31:15 <gmaxwell> I've been testing per-txout. Survived a few crashes so far.
4562017-05-18T19:31:31 <wumpus> I've been testing #10195 for a while, haven't run into any problems
4572017-05-18T19:31:35 <gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
4582017-05-18T19:31:35 <instagibbs> morcos, dont look now but it's being used in anger on multiple large wallet services :)
4592017-05-18T19:31:46 <sipa> instagibbs: "in anger" ?
4602017-05-18T19:31:55 <instagibbs> "doing it live"
4612017-05-18T19:32:02 <gmaxwell> "hold my beer"
4622017-05-18T19:32:30 <morcos> heh.. fools, the whole reason to merge it into master was to get it some more testing
4632017-05-18T19:32:35 <gmaxwell> luke-jr: have you done the multiwallet rebasing?
4642017-05-18T19:32:44 <jtimon> there's not many explicit acks on https://github.com/bitcoin/bitcoin/pull/10339
4652017-05-18T19:32:48 <luke-jr> I didn't realise jtimon's PR was merged?
4662017-05-18T19:32:49 <instagibbs> morcos, well, other services were doing crazy things.. (ok enough off-topic)
4672017-05-18T19:33:03 <jtimon> luke-jr: which one?
4682017-05-18T19:33:05 <wumpus> so, ok, any new ones?
4692017-05-18T19:33:17 <luke-jr> jtimon: args refactor
4702017-05-18T19:33:17 <ryanofsky> i'd like more review on #10295, it is blocking my ipc prs
4712017-05-18T19:33:19 <gribble> https://github.com/bitcoin/bitcoin/issues/10295 | [qt] Move some WalletModel functions into CWallet by ryanofsky · Pull Request #10295 · bitcoin/bitcoin · GitHub
4722017-05-18T19:33:27 <sipa> ryanofsky: ack, i started reviewing that
4732017-05-18T19:33:32 <jonasschnelli> I have added #10240 today
4742017-05-18T19:33:34 <gribble> https://github.com/bitcoin/bitcoin/issues/10240 | Add HD wallet auto-restore functionality by jonasschnelli · Pull Request #10240 · bitcoin/bitcoin · GitHub
4752017-05-18T19:33:38 <sipa> jonasschnelli: sgtm
4762017-05-18T19:33:44 <jtimon> luke-jr: I see #9494
4772017-05-18T19:33:45 <gribble> https://github.com/bitcoin/bitcoin/issues/9494 | Introduce an ArgsManager class encapsulating cs_args, mapArgs and mapMultiArgs by jtimon · Pull Request #9494 · bitcoin/bitcoin · GitHub
4782017-05-18T19:33:50 <luke-jr> ok, looks like 4 days ago it was; I'll rebase multiwallet then
4792017-05-18T19:33:55 <sipa> luke-jr: thank you
4802017-05-18T19:34:02 <jonasschnelli> luke-jr: great. I promise to test
4812017-05-18T19:34:05 <gmaxwell> luke-jr: thank you!
4822017-05-18T19:35:02 <jonasschnelli> ryanofsky: will do the 10295 review. Thanks for the info
4832017-05-18T19:35:07 <sipa> short point: wrt the pruned-node-serving, see http://bitcoin.sipa.be/depths.png
4842017-05-18T19:35:11 <wumpus> added 10295 and 10339
4852017-05-18T19:35:21 *** stickcuck has joined #bitcoin-core-dev
4862017-05-18T19:35:22 <wumpus> #topic pruned-node serving
4872017-05-18T19:35:31 <sipa> see that graph, the title is wrong
4882017-05-18T19:35:33 <jonasschnelli> Currently overhauling the BIP
4892017-05-18T19:35:47 <sipa> it shows the relative depth of each block downloaded from my node _excluding_ compact blocks
4902017-05-18T19:36:10 <sipa> gmaxwell did some statistical analysis on it
4912017-05-18T19:36:30 *** BMRelayBot has joined #bitcoin-core-dev
4922017-05-18T19:36:38 <gmaxwell> Sipa's data is interesting. 144 is to small for sure. 1008 is fine. I'm of the view that we don't need more than a dozen or so blocks of headroom. I think the BIP should be written based on what you should keep. How you decide where to fetch depends on exactly what you're doing.
4932017-05-18T19:37:05 <stickcuck> hm
4942017-05-18T19:37:27 <gmaxwell> I found no really evidence of a real preference for N weeks in sipas data, but rather, advantages for doing 1-day 2-day 3-day ... etc. But 'day' is a lot more than 144 blocks, because of hashrate increases.
4952017-05-18T19:38:04 <gmaxwell> You can process the data to roughly remove IBDing peers and the fall off is pretty stark.
4962017-05-18T19:38:18 <gmaxwell> note sipas graph ignores depth 0.
4972017-05-18T19:38:33 <sipa> it'd be a hockeystick if it included 0
4982017-05-18T19:38:44 <jonasschnelli> What would you recommend for "day" instead 144, calc in the historical hashrate increase?
4992017-05-18T19:38:53 <gmaxwell> also 0 data is inaccurate because it excludes compact blocks
5002017-05-18T19:39:08 *** zooko has quit IRC
5012017-05-18T19:39:18 <sipa> gmaxwell: didn't you suggest 288?
5022017-05-18T19:39:20 <gmaxwell> jonasschnelli: I think we should make the first threshold 288. It's more than enough to cover a 'day' in practice.
5032017-05-18T19:39:39 <jonasschnelli> 288 and 1008...
5042017-05-18T19:39:59 <jonasschnelli> But then the current minimum (prune=550) would not allow to signal the LOW mode?
5052017-05-18T19:40:08 <morcos> the current minimum is 288
5062017-05-18T19:40:11 <gmaxwell> and then peers should estimate what they need (based on time, or headers if they have them) and choose where to connect. The estimate should be conservative but it doesn't need to be a 100 block headroom, a dozen blocks should be fine. If you get headers and find that you need more, you'll disconnect and go elsewhere.
5072017-05-18T19:40:13 <jonasschnelli> Or is 288 including headroom?
5082017-05-18T19:40:24 <morcos> the 550 is just so you don't set a prune limit which you have no hope of respecting
5092017-05-18T19:40:26 <gmaxwell> the minimum is 288 blocks.
5102017-05-18T19:40:30 <morcos> its out of date with segwit
5112017-05-18T19:40:44 <gmaxwell> and we'll blow over the prune setting to preserve 288 blocks.
5122017-05-18T19:40:55 <morcos> i think the calculation is presented in the code comments
5132017-05-18T19:41:03 <jonasschnelli> Yes. 288 is the minimum. So we should remove the BIP headroom/buffer from the BIP
5142017-05-18T19:41:22 <gmaxwell> I think eventually we should be changing the prune setting to be enum-like but thats another matter.
5152017-05-18T19:41:58 <gmaxwell> jonasschnelli: I think the BIP shouldn't have any buffer. "You store X from your tip" "You store Y from your tip" it can then make advice to users on how to choose connections. but the requirement is just what you promise to store.
5162017-05-18T19:42:13 <jonasschnelli> gmaxwell: ack
5172017-05-18T19:43:12 <gmaxwell> The advice can say to use the best info you have available (time or headers if you have them) to figure out what you need, and then give enough headroom maybe 6 or 12 blocks that you can fetch parents. The cost of connecting to someone that doesn't have what you need is not that great. You'll request headers from them, learn you need blocks they don't have and you'll disconnect them and connect
5182017-05-18T19:43:18 <gmaxwell> to someone else.
5192017-05-18T19:44:01 <jonasschnelli> For the 1008 I guess the BIP can no longer state blocks for 1 week. Now the question is to use 2016 or say it 3.5 days..
5202017-05-18T19:44:17 <sipa> ?
5212017-05-18T19:44:35 <sipa> i think it should just say 1008 or 2016 blocks or so, and not make any connection with time
5222017-05-18T19:44:44 <jonasschnelli> From what I understood is that 144 is to little for a day regarding the increasing hash-rate
5232017-05-18T19:44:54 <gmaxwell> jonasschnelli: I'll catch up with you later today, I don't have my processed results in front of me. But I think I found that after elimiating IBDs there were very few fetches in sipas data past 1000 blocks deep. And indeed, it shouldn't mention time.
5242017-05-18T19:45:37 <jonasschnelli> But light client implementations are really looking for "days" rather the blocks.. but, sure, they can do their homework... but would have been nice to mention day values in the BIP.
5252017-05-18T19:45:43 <jonasschnelli> But maybe they are to inaccurate
5262017-05-18T19:45:47 <gmaxwell> The bit(s) should just be defined as "I claim I will keep at least X blocks deep from my tip, maybe I keep more, maybe not."
5272017-05-18T19:45:54 <sipa> jonasschnelli: light clients know how many blocks they are behind after header sync
5282017-05-18T19:45:58 <gmaxwell> jonasschnelli: anyone using these bits will fetch headers.
5292017-05-18T19:46:15 <jonasschnelli> Indeed.... okay. Got it.
5302017-05-18T19:46:46 <gmaxwell> now, before you connect you won't have headers and you'll need to make a time based guess. If you guess wrong you'll need to disconnect and go elsewhere. Not the end of the world.
5312017-05-18T19:47:16 <jonasschnelli> Yes. I agree on that. Re-connecting should be hard.
5322017-05-18T19:47:37 <jonasschnelli> Maybe even an additional dns query may be involved (in case you filter)
5332017-05-18T19:48:10 <sipa> even if it happens, it'll happen just once
5342017-05-18T19:48:31 <jonasschnelli> Yeah,... shouldn't be a problem for clients
5352017-05-18T19:48:34 <sipa> because even if you connect to a peer that does not have enough blocks, they'll have the headers to teach you how many blocks you are behind
5362017-05-18T19:48:39 <sipa> so i don't think it's such a big issue
5372017-05-18T19:49:03 <sipa> done topic?
5382017-05-18T19:49:08 <gmaxwell> I think I mentioned it on the list, but it should be clear that these bits should still mean that you can serve headers for the whole chain.
5392017-05-18T19:49:33 <wumpus> #topic bytes_serialized (sipa)
5402017-05-18T19:49:38 <sipa> thanks
5412017-05-18T19:49:42 <gmaxwell> Kill with fire (sorry wumpus)
5422017-05-18T19:49:43 <jonasschnelli> gmaxwell: seems obvious.. but I'll mention it
5432017-05-18T19:49:43 <gmaxwell> :P
5442017-05-18T19:49:54 <sipa> so currently gettxoutsetinfo has a field called bytes_serialized
5452017-05-18T19:50:03 <sipa> which is based on some theoretical serialization of the utxo set data
5462017-05-18T19:50:09 <wumpus> I think there's something to be said for a neutral way of representing the utxo size, that doesn't represent on estimates of a specific database format
5472017-05-18T19:50:17 <sipa> wumpus: agree with that
5482017-05-18T19:50:20 <gmaxwell> what I said to sipa the other day was that if we list the total bytes in values and the txout counts, that lets you come up with whatever kind of seralized size estimate you want.
5492017-05-18T19:50:45 <sipa> but would you be fine with it just being the size of keys+values in a neutral format, _not_ accounting for the leveldb prefix compression?
5502017-05-18T19:50:51 <wumpus> sipa: yes
5512017-05-18T19:50:52 <gmaxwell> If you want you could multiply that count by 36 and add the values and that gives you the size for the dumbest seralization that hopefully no one would use.
5522017-05-18T19:50:52 <luke-jr> values counted as 8 bytes, or compressed?
5532017-05-18T19:51:08 <wumpus> sipa: that's be fine really, and the format change provides oppertunity to change the definition
5542017-05-18T19:51:14 <sipa> wumpus: agree
5552017-05-18T19:51:22 <gmaxwell> okay if wumpus and sipa agree I'll shutup.
5562017-05-18T19:51:31 <sipa> luke-jr: no strong opinion. do you?
5572017-05-18T19:51:42 <luke-jr> sipa: I don't think the compression should be exposed, ideally.
5582017-05-18T19:51:48 <sipa> luke-jr: seems fair
5592017-05-18T19:51:49 <gmaxwell> wumpus: the only concern I had with a really neutral figure is that it's misleading.
5602017-05-18T19:51:51 <luke-jr> not a strong opinion though
5612017-05-18T19:51:51 <wumpus> luke-jr: just a fixed size seems ok to me
5622017-05-18T19:52:01 <wumpus> luke-jr: that's more future proof likely
5632017-05-18T19:52:07 <wumpus> luke-jr: so we can have a statistic to compare over time
5642017-05-18T19:52:11 <morcos> can't we output more than one thing?
5652017-05-18T19:52:27 <luke-jr> wumpus: indeed
5662017-05-18T19:52:42 <gmaxwell> e.g. a naieve seralization would have 32 bytes for txid, but the reality is probably under 16 due to sharing. But as long as it doesn't require scanning that data I guess I don't care.
5672017-05-18T19:52:47 <sipa> morcos: so #10396 reports the actual disk usage
5682017-05-18T19:52:48 <gribble> https://github.com/bitcoin/bitcoin/issues/10396 | Report LevelDB estimate for chainstate size in gettxoutsetinfo by sipa · Pull Request #10396 · bitcoin/bitcoin · GitHub
5692017-05-18T19:52:53 <sipa> morcos: and the total number of utxos is also reported
5702017-05-18T19:53:15 <wumpus> we should definitely report the actual disk usage too!
5712017-05-18T19:53:23 <morcos> yeah i'm sorry if i'm behind, but i think actual disk usage is useful, even if we want this .. ok, that's all i was saying
5722017-05-18T19:53:30 <luke-jr> agreed
5732017-05-18T19:53:30 <sipa> yes yes, absolutely
5742017-05-18T19:53:44 <sipa> the point is that the current bytes_serialized tries to mimick disk usage, but fails
5752017-05-18T19:53:45 <gmaxwell> the leveldb usage is a noisy thing that goes up and down based on the mood of the table compacting gods.
5762017-05-18T19:53:47 <luke-jr> (although I guess users can just du the directory?)
5772017-05-18T19:53:50 <sipa> and will fail even more post per-txout
5782017-05-18T19:54:17 <sipa> so if we drop the requirement that bytes_serialized has anything to do with disk usage, all is good
5792017-05-18T19:54:25 <wumpus> gmaxwell: yep, it's less useful for reporting as statistics
5802017-05-18T19:54:34 <wumpus> sipa: indeed; I never assumed it did really
5812017-05-18T19:54:58 <wumpus> to me it was just 'serialization size of utxo in an arbitrary, but constant, format'
5822017-05-18T19:55:00 <phantomcircuit> huh what im here
5832017-05-18T19:55:19 <wumpus> sipa: would make sense to rename the field too
5842017-05-18T19:55:21 <sipa> wumpus: ok, so 10195 removes bytes_serialized - i'll create a separate PR afterwards to add a (new) bytes_serialized again
5852017-05-18T19:55:25 <sipa> wumpus: agree
5862017-05-18T19:55:32 <gmaxwell> wumpus: it will be odd if the serialized size is larger than the database but not that odd.
5872017-05-18T19:55:47 <sipa> gmaxwell: at least it will be obvious that it has nothing to do with it then!
5882017-05-18T19:55:49 <wumpus> (after all we don't want people to report weird jumps in statistics, renaming the field is ag ood hint)
5892017-05-18T19:56:07 <luke-jr> sipa: maybe it should be renamed?
5902017-05-18T19:56:13 <sipa> luke-jr: yes, it should be
5912017-05-18T19:56:17 <wumpus> "bogosize"
5922017-05-18T19:56:21 <gmaxwell> bogosize++
5932017-05-18T19:56:22 <sipa> hash_serialized is renamed too
5942017-05-18T19:56:28 <sipa> hahaha bogosize
5952017-05-18T19:56:34 <sipa> ok, deal
5962017-05-18T19:56:39 <gmaxwell> should be in nibbles.
5972017-05-18T19:56:42 <gmaxwell> :P
5982017-05-18T19:56:43 <luke-jr> lol
5992017-05-18T19:56:44 <wumpus> :D
6002017-05-18T19:56:46 <sipa> in nepers
6012017-05-18T19:56:49 <instagibbs> buy one get one size?
6022017-05-18T19:56:55 <gmaxwell> ehats the base e entropy unit?
6032017-05-18T19:56:58 <sipa> gmaxwell: yes
6042017-05-18T19:57:27 <luke-jr> can I add an OP_CHECKBOGOSIZE? *hides*
6052017-05-18T19:57:28 <gmaxwell> Good. (that was supposted to be a "Whats?" but seems you were a step ahead of me)
6062017-05-18T19:57:39 <sipa> ah, no, nats
6072017-05-18T19:57:47 <sipa> nepers are just for ratios, like db
6082017-05-18T19:57:53 <sipa> </offtopic>
6092017-05-18T19:58:02 <wumpus> time to close the meeting I think
6102017-05-18T19:58:02 <instagibbs> 2 minutes
6112017-05-18T19:58:04 <instagibbs> review begging?
6122017-05-18T19:58:09 <instagibbs> :P
6132017-05-18T19:58:11 <wumpus> we already did that one
6142017-05-18T19:58:13 <instagibbs> ah k
6152017-05-18T19:58:17 <luke-jr> defer BIP148 to next week?
6162017-05-18T19:58:22 <wumpus> (though if you have any proposals just say so)
6172017-05-18T19:58:24 <instagibbs> https://github.com/bitcoin/bitcoin/pull/10333 <-- my beg
6182017-05-18T19:58:33 <wumpus> luke-jr: oh forgot about that one
6192017-05-18T19:58:43 <luke-jr> it's okay, a week might be good anyway
6202017-05-18T19:58:50 <gmaxwell> I'm sure you can discuss it in one minute.
6212017-05-18T19:59:00 <gmaxwell> :P
6222017-05-18T19:59:03 <kanzure> we need a meeting extension block
6232017-05-18T19:59:04 * morcos refrains
6242017-05-18T19:59:09 <wumpus> #endmeeting
6252017-05-18T19:59:09 <lightningbot> Meeting ended Thu May 18 19:59:09 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
6262017-05-18T19:59:09 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-18-19.01.html
6272017-05-18T19:59:09 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-18-19.01.txt
6282017-05-18T19:59:09 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-18-19.01.log.html
6292017-05-18T19:59:15 <luke-jr> gmaxwell: well, to be fair, we've never had a formal time limit for meetings..
6302017-05-18T19:59:27 <luke-jr> :p
6312017-05-18T19:59:35 <instagibbs> it's a standardness rule...
6322017-05-18T19:59:40 <kanzure> it was to prevent spam
6332017-05-18T19:59:45 <gmaxwell> I like that they're limited. even though I always spend another half hour in resulting discussions.
6342017-05-18T19:59:54 <gmaxwell> kanzure: that limit was temporary!
6352017-05-18T20:00:00 <instagibbs> I think it's good to focus and respect people's time
6362017-05-18T20:00:06 <wumpus> agree
6372017-05-18T20:00:14 <sipa> we should revert to the original limit of 24 hours
6382017-05-18T20:00:21 <luke-jr> >_<
6392017-05-18T20:00:24 <gmaxwell> esp considering timezones don't put this meeting at good times of day for many.
6402017-05-18T20:00:39 <wumpus> so make sure that you have topics ready at the beginning, that makes it easier to schedule time for topics
6412017-05-18T20:00:41 <sipa> it's especially annoying for people in asia
6422017-05-18T20:00:49 <luke-jr> sipa: IMO the original limit was 5 hours
6432017-05-18T20:00:56 <sipa> i wonder if we should have the meeting alternate between two times
6442017-05-18T20:00:56 <luke-jr> sipa: since that's how long until the day changes in UTC
6452017-05-18T20:01:12 <gmaxwell> luke-jr: That isn't consistent with Craig Wright^W^WSatoshi's vision!
6462017-05-18T20:01:25 <luke-jr> gmaxwell: it's consistent with tonal though
6472017-05-18T20:01:33 <cfields> sipa: nah, let's just use an accounting trick and have meetings on a plane zooming through timezones.
6482017-05-18T20:01:49 <luke-jr> anyway, my parents showed up, so going to say hi and then get back to multiwallet
6492017-05-18T20:01:50 <kanzure> yes if you navigate the plane correctly, you can actually not spend any time at all in the meeting if you hop between timezones just right.
6502017-05-18T20:01:58 <cfields> I'm pretty sure we can cram 2 days into 1 that way :p
6512017-05-18T20:02:08 <luke-jr> cfields: rofl
6522017-05-18T20:02:09 <gmaxwell> too bad they stopped flying the concord.
6532017-05-18T20:02:24 <sipa> you just need a plane circeling the arctic
6542017-05-18T20:02:35 <kanzure> sounds like bip148 discussion is slightly blocked by luke-jr parental units
6552017-05-18T20:03:16 <wumpus> sipa: if there's interest from people from asia joining we should certainly do that; in practice I never had any concerete complains about the current meeting time though
6562017-05-18T20:03:45 <sipa> wumpus: we did, a long time ago
6572017-05-18T20:04:04 <gmaxwell> wumpus: jl2012 has lamented, and I believe kallewoof too.
6582017-05-18T20:04:07 <cfields> iirc it's prohibitive for jl2012, at least
6592017-05-18T20:04:16 <instagibbs> oh yeah, kalle too
6602017-05-18T20:04:35 <wumpus> ok good to know
6612017-05-18T20:04:55 <wumpus> maybe fanquake too (australia)
6622017-05-18T20:05:03 <instagibbs> he's a kiwi I thought
6632017-05-18T20:05:05 <jtimon> luke-jr: aug2017 seems to soon to me, I have no problems with bip149 on the other hand
6642017-05-18T20:05:18 <gmaxwell> we could also just look at the log data, determine a time when when most of us are already here that the asian people can meet, and maybe just setup a hour to talk to them when they know people will be around.
6652017-05-18T20:05:25 <sipa> 7am europe, 10pm westcoast, 1pm hongkong, 2pm japan?
6662017-05-18T20:05:39 <sipa> maybe too early in europe
6672017-05-18T20:05:43 <instagibbs> 1am East coast US, hmmm
6682017-05-18T20:05:49 <sipa> instagibbs: oops
6692017-05-18T20:05:57 <wumpus> I'm usualy up very early so that'd be ok with me
6702017-05-18T20:05:59 <gmaxwell> I think there is no time everyone can meet. But thats okay.
6712017-05-18T20:06:01 <gmaxwell> wumpus is up that early.
6722017-05-18T20:06:04 <gmaxwell> oh oops.
6732017-05-18T20:06:04 <wumpus> better than late at night
6742017-05-18T20:06:17 <instagibbs> I'll survive once a week if that works
6752017-05-18T20:06:43 <instagibbs> oh right Chaincode...
6762017-05-18T20:06:47 <instagibbs> :)
6772017-05-18T20:07:11 <sipa> damn timezones
6782017-05-18T20:07:14 <achow101> I'd rather not be up at 1 am
6792017-05-18T20:07:27 <sipa> achow101: you'll be on the west coast soon :)
6802017-05-18T20:07:33 <instagibbs> Maybe figuring a way to reliably rotate or something. I dunno.
6812017-05-18T20:08:02 <achow101> sipa: thinking ahead a bit past the summer :)
6822017-05-18T20:08:22 <gmaxwell> instagibbs: well Above I just suggested we have a second meeting at another time. It may be the case that the activity level in the meetings with asia are low enough that rotating wouldn't make sense.
6832017-05-18T20:08:40 <sipa> otherwise 4pm europe, 7am westcoast, 10am eastcoast, 10pm hongkong, 11pm japan?
6842017-05-18T20:08:43 <gmaxwell> instagibbs: if we pick at time when 'enough' people are here anyways, then it's not like setting aside the slot has a huge cost.
6852017-05-18T20:08:45 <instagibbs> hm yeah that makes more sense
6862017-05-18T20:08:58 <luke-jr> jtimon: well, it's already happening Aug 1 with BIP148..
6872017-05-18T20:09:44 <jtimon> luke-jr: right, I mean that seems too soon
6882017-05-18T20:10:00 <jtimon> so I don't think I will run bip148 myself
6892017-05-18T20:10:06 <gmaxwell> sipa: so there is like 3 hours between japan and auckland, so that might actually fail to get everyone in that part of the globe.
6902017-05-18T20:10:24 <luke-jr> jtimon: oh well. :<
6912017-05-18T20:11:38 <sipa> gmaxwell: yes, we need a slower earth rotation
6922017-05-18T20:11:53 <instagibbs> don't give kanzure any ideas
6932017-05-18T20:14:10 <gmaxwell> instagibbs: kanzure wants to destroy the moon I thought, that would reduce the slowing a lot.
6942017-05-18T20:14:15 *** vicenteH` has joined #bitcoin-core-dev
6952017-05-18T20:14:17 <gmaxwell> sipa: thats already happening, just wait a while.
6962017-05-18T20:14:57 *** BMRelayBot has quit IRC
6972017-05-18T20:15:13 <sipa> gmaxwell: 2ms per century isn't very much
6982017-05-18T20:15:45 <kanzure> yeah i have some plans but it's sort of off-topic
6992017-05-18T20:16:02 *** vicenteH has quit IRC
7002017-05-18T20:16:03 *** jtimon has quit IRC
7012017-05-18T20:16:21 *** jtimon has joined #bitcoin-core-dev
7022017-05-18T20:21:03 *** BMRelayBot has joined #bitcoin-core-dev
7032017-05-18T20:25:29 <stickcuck> ok
7042017-05-18T20:30:19 *** zooko has joined #bitcoin-core-dev
7052017-05-18T20:30:25 *** BartokIT has joined #bitcoin-core-dev
7062017-05-18T20:31:45 *** BMRelayBot has quit IRC
7072017-05-18T20:34:58 *** BMRelayBot has joined #bitcoin-core-dev
7082017-05-18T20:38:01 *** BartokIT has joined #bitcoin-core-dev
7092017-05-18T20:41:09 <bitcoin-git> [bitcoin] jnewbery opened pull request #10423: [tests] skipped tests should clean up after themselves (master...cleanup_skipped) https://github.com/bitcoin/bitcoin/pull/10423
7102017-05-18T20:45:29 *** zooko has quit IRC
7112017-05-18T20:55:36 *** BartokIT has quit IRC
7122017-05-18T21:01:12 *** d_t has joined #bitcoin-core-dev
7132017-05-18T21:04:31 <bitcoin-git> [bitcoin] morcos opened pull request #10424: Populate services in GetLocalAddress (master...notnodenone) https://github.com/bitcoin/bitcoin/pull/10424
7142017-05-18T21:10:28 *** freqry has joined #bitcoin-core-dev
7152017-05-18T21:18:49 *** fengling has quit IRC
7162017-05-18T21:18:50 *** [Author] has quit IRC
7172017-05-18T21:18:51 *** Magma has quit IRC
7182017-05-18T21:19:06 *** Sprh has quit IRC
7192017-05-18T21:56:20 <jtimon> travis tests seem to be stuck for https://github.com/bitcoin/bitcoin/pull/9176
7202017-05-18T22:06:52 *** freqry has quit IRC
7212017-05-18T22:11:25 *** jannes has quit IRC
7222017-05-18T22:12:18 *** kadoban has quit IRC
7232017-05-18T22:12:28 *** kadoban has joined #bitcoin-core-dev
7242017-05-18T22:12:56 *** Guyver2 has quit IRC
7252017-05-18T22:15:52 *** cryptapus_afk has quit IRC
7262017-05-18T22:16:14 *** cryptapus_afk has joined #bitcoin-core-dev
7272017-05-18T22:27:37 <kallewoof> Being able to participate in a meeting occasionally would be spiffy for sure.
7282017-05-18T22:36:36 *** zooko has joined #bitcoin-core-dev
7292017-05-18T22:52:07 *** vicenteH` has quit IRC
7302017-05-18T22:53:31 *** spinza has quit IRC
7312017-05-18T22:55:09 *** tripleslash has quit IRC
7322017-05-18T22:55:37 <bitcoin-git> [bitcoin] earonesty opened pull request #10425: 0.14 (0.14...0.14) https://github.com/bitcoin/bitcoin/pull/10425
7332017-05-18T22:59:20 *** spinza has joined #bitcoin-core-dev
7342017-05-18T23:16:04 *** goksinen has quit IRC
7352017-05-18T23:20:15 *** goksinen has joined #bitcoin-core-dev
7362017-05-18T23:23:51 *** goksinen has quit IRC
7372017-05-18T23:25:15 *** shockoo has joined #bitcoin-core-dev
7382017-05-18T23:44:54 <bitcoin-git> [bitcoin] sipa opened pull request #10426: Replace bytes_serialized with bogosize (master...bogosize) https://github.com/bitcoin/bitcoin/pull/10426
7392017-05-18T23:47:03 *** Aaronvan_ has quit IRC
7402017-05-18T23:47:14 *** goksinen has joined #bitcoin-core-dev
7412017-05-18T23:49:56 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #10241: Allow tests to pass even when stderr got populated (master...2017/04/test_stderr) https://github.com/bitcoin/bitcoin/pull/10241
7422017-05-18T23:52:08 *** goksinen has quit IRC
7432017-05-18T23:58:15 *** fanquake has joined #bitcoin-core-dev
7442017-05-18T23:59:13 *** fanquake has left #bitcoin-core-dev