12018-05-03T00:30:06 *** belcher has quit IRC
22018-05-03T00:44:36 *** AaronvanW has quit IRC
32018-05-03T00:45:12 *** AaronvanW has joined #bitcoin-core-dev
42018-05-03T00:49:33 *** AaronvanW has quit IRC
52018-05-03T00:50:23 *** promag has quit IRC
62018-05-03T01:00:50 *** harding has quit IRC
72018-05-03T01:03:10 *** boblee has quit IRC
82018-05-03T01:03:57 *** victorSN has quit IRC
92018-05-03T01:04:19 *** victorSN has joined #bitcoin-core-dev
102018-05-03T01:16:23 *** harding has joined #bitcoin-core-dev
112018-05-03T01:20:57 *** promag has joined #bitcoin-core-dev
122018-05-03T01:21:33 *** fanquake has joined #bitcoin-core-dev
132018-05-03T01:26:03 *** promag has quit IRC
142018-05-03T02:26:19 *** promag has joined #bitcoin-core-dev
152018-05-03T02:31:15 *** promag has quit IRC
162018-05-03T02:35:28 *** promag has joined #bitcoin-core-dev
172018-05-03T02:40:01 *** promag has quit IRC
182018-05-03T03:01:24 *** fanquake has quit IRC
192018-05-03T03:03:00 *** Victorsueca has quit IRC
202018-05-03T03:04:10 *** Victorsueca has joined #bitcoin-core-dev
212018-05-03T03:19:30 *** tralfaz has quit IRC
222018-05-03T03:25:01 *** promag has joined #bitcoin-core-dev
232018-05-03T03:30:09 *** promag has quit IRC
242018-05-03T03:53:14 *** Giszmo has quit IRC
252018-05-03T04:13:36 *** Giszmo has joined #bitcoin-core-dev
262018-05-03T04:14:46 *** jtimon has quit IRC
272018-05-03T04:27:08 *** meshcollider has quit IRC
282018-05-03T05:40:00 *** arowser has quit IRC
292018-05-03T05:40:17 *** arowser has joined #bitcoin-core-dev
302018-05-03T05:41:16 *** promag has joined #bitcoin-core-dev
312018-05-03T05:45:27 *** promag has quit IRC
322018-05-03T06:09:24 <wumpus> MarcoFalke: nice, since #13051 it's possible to run individual functional tests in an out-of-tree build without having to manually provide BITCOIND=...
332018-05-03T06:09:26 <gribble> https://github.com/bitcoin/bitcoin/issues/13051 | qa: Normalize executable location by MarcoFalke · Pull Request #13051 · bitcoin/bitcoin · GitHub
342018-05-03T06:15:17 <wumpus> though I'm confused how that manages to work, does it store the ini in the source directory?
352018-05-03T06:16:20 *** grafcaps has quit IRC
362018-05-03T06:21:31 *** promag has joined #bitcoin-core-dev
372018-05-03T06:21:47 *** isis_ is now known as isis
382018-05-03T06:26:09 *** promag has quit IRC
392018-05-03T06:40:10 *** skt has joined #bitcoin-core-dev
402018-05-03T06:40:35 *** skt has left #bitcoin-core-dev
412018-05-03T06:42:45 *** meshcollider has joined #bitcoin-core-dev
422018-05-03T07:22:47 *** tryphe has quit IRC
432018-05-03T07:23:36 *** tryphe has joined #bitcoin-core-dev
442018-05-03T07:34:31 *** brianhoffman has quit IRC
452018-05-03T07:35:27 *** brianhoffman has joined #bitcoin-core-dev
462018-05-03T07:43:10 *** belcher has joined #bitcoin-core-dev
472018-05-03T07:46:18 *** laurentmt has joined #bitcoin-core-dev
482018-05-03T07:56:11 *** arowser has quit IRC
492018-05-03T07:56:29 *** arowser has joined #bitcoin-core-dev
502018-05-03T07:58:36 *** SopaXorzTaker has joined #bitcoin-core-dev
512018-05-03T08:04:24 *** Victorsueca has quit IRC
522018-05-03T08:05:39 *** Victorsueca has joined #bitcoin-core-dev
532018-05-03T08:19:24 *** timothy has joined #bitcoin-core-dev
542018-05-03T08:23:51 *** drizztbsd has joined #bitcoin-core-dev
552018-05-03T08:24:36 *** timothy has quit IRC
562018-05-03T08:26:45 *** laurentmt has quit IRC
572018-05-03T08:28:52 *** grafcaps has joined #bitcoin-core-dev
582018-05-03T08:30:25 *** arowser has quit IRC
592018-05-03T08:30:42 *** arowser has joined #bitcoin-core-dev
602018-05-03T08:33:21 *** grafcaps has quit IRC
612018-05-03T08:37:02 *** Emcy has joined #bitcoin-core-dev
622018-05-03T08:39:37 *** arowser has quit IRC
632018-05-03T08:39:55 *** arowser has joined #bitcoin-core-dev
642018-05-03T08:42:01 *** d9b4bef9 has quit IRC
652018-05-03T08:43:07 *** d9b4bef9 has joined #bitcoin-core-dev
662018-05-03T08:46:22 *** vicenteH has joined #bitcoin-core-dev
672018-05-03T08:48:01 *** Amuza has joined #bitcoin-core-dev
682018-05-03T08:48:54 *** mistergold has joined #bitcoin-core-dev
692018-05-03T08:54:52 *** arowser has quit IRC
702018-05-03T08:55:08 *** arowser has joined #bitcoin-core-dev
712018-05-03T09:09:05 *** promag has joined #bitcoin-core-dev
722018-05-03T09:12:23 *** grafcaps has joined #bitcoin-core-dev
732018-05-03T09:16:27 *** grafcaps has quit IRC
742018-05-03T09:20:05 <promag> wumpus: should I close #12507 or it's something that can be merged?
752018-05-03T09:20:07 <gribble> https://github.com/bitcoin/bitcoin/issues/12507 | Interrupt rescan on shutdown request by promag · Pull Request #12507 · bitcoin/bitcoin · GitHub
762018-05-03T09:27:30 <wumpus> promag: looks mergeable to me
772018-05-03T09:28:13 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ef006d92845a...2afdc294039f
782018-05-03T09:28:13 <bitcoin-git> bitcoin/master c4fda76 João Barbosa: wallet: Interrupt rescan on shutdown request
792018-05-03T09:28:14 <bitcoin-git> bitcoin/master 2afdc29 Wladimir J. van der Laan: Merge #12507: Interrupt rescan on shutdown request...
802018-05-03T09:28:17 <wumpus> promag: I don't really like how everything is gaining a dependency on init.h for ShutdownRequested, but that's an architectural issue that can be solved separately
812018-05-03T09:28:55 <bitcoin-git> [bitcoin] laanwj closed pull request #12507: Interrupt rescan on shutdown request (master...2018-02-shutdown-on-rescan) https://github.com/bitcoin/bitcoin/pull/12507
822018-05-03T09:31:04 <promag> wumpus: yeah that's the way it is atm
832018-05-03T09:31:57 <promag> wumpus: I also think #12729 is mergeable
842018-05-03T09:32:00 <gribble> https://github.com/bitcoin/bitcoin/issues/12729 | Get rid of ambiguous OutputType::NONE value by ryanofsky · Pull Request #12729 · bitcoin/bitcoin · GitHub
852018-05-03T09:32:23 <wumpus> thanks will take a look
862018-05-03T09:53:55 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2afdc294039f...979150bc2388
872018-05-03T09:53:55 <bitcoin-git> bitcoin/master 1e46d8a Russell Yanofsky: Get rid of ambiguous OutputType::NONE value...
882018-05-03T09:53:56 <bitcoin-git> bitcoin/master 979150b Wladimir J. van der Laan: Merge #12729: Get rid of ambiguous OutputType::NONE value...
892018-05-03T09:54:39 <bitcoin-git> [bitcoin] laanwj closed pull request #12729: Get rid of ambiguous OutputType::NONE value (master...pr/nonone) https://github.com/bitcoin/bitcoin/pull/12729
902018-05-03T10:07:04 *** kinlo has quit IRC
912018-05-03T10:07:41 *** kinlo has joined #bitcoin-core-dev
922018-05-03T10:08:50 *** Victorsueca has quit IRC
932018-05-03T10:10:08 *** Victorsueca has joined #bitcoin-core-dev
942018-05-03T10:13:52 *** zautomata3 has joined #bitcoin-core-dev
952018-05-03T10:19:28 *** Arokh has quit IRC
962018-05-03T10:20:34 *** laurentmt has joined #bitcoin-core-dev
972018-05-03T10:20:46 *** Arokh has joined #bitcoin-core-dev
982018-05-03T10:21:11 *** laurentmt has quit IRC
992018-05-03T10:22:51 *** Amuza has quit IRC
1002018-05-03T10:23:49 *** antipovka_ has joined #bitcoin-core-dev
1012018-05-03T10:24:54 *** gfggg has joined #bitcoin-core-dev
1022018-05-03T10:24:58 <antipovka_> Someone asked me about this Satoshi Mine Bot and here it is! this bot simply automate your actions! It has a lot of settings and actually can help you being fast. But first you have to have your winning strategy! I am not going to explain about it, you are smart people, you are going to handle it! https://www.youtube.com/watch?v=ak-JKQvbDdc&t=7s
1032018-05-03T10:30:23 *** ChanServ sets mode: +o wumpus
1042018-05-03T10:30:51 *** wumpus sets mode: +b *!*@gateway/web/freenode/ip.193.169.125.174
1052018-05-03T10:30:55 *** antipovka_ was kicked by wumpus (Kindergarten is elsewhere!)
1062018-05-03T10:31:09 *** Arokh has quit IRC
1072018-05-03T10:31:42 *** Arokh has joined #bitcoin-core-dev
1082018-05-03T10:34:28 <promag> wumpus: updated #12639
1092018-05-03T10:34:29 <gribble> https://github.com/bitcoin/bitcoin/issues/12639 | Reduce cs_main lock in listunspent by promag · Pull Request #12639 · bitcoin/bitcoin · GitHub
1102018-05-03T10:40:37 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/979150bc2388...11adab39e601
1112018-05-03T10:40:37 <bitcoin-git> bitcoin/master 21f5680 Russell Yanofsky: Trivial: s/SetBestChain/ChainStateFlushed in comments after #13106
1122018-05-03T10:40:38 <bitcoin-git> bitcoin/master 11adab3 Wladimir J. van der Laan: Merge #13154: Trivial: s/SetBestChain/ChainStateFlushed in comments after #13106...
1132018-05-03T10:41:29 <bitcoin-git> [bitcoin] laanwj closed pull request #13154: Trivial: s/SetBestChain/ChainStateFlushed in comments after #13106 (master...pr/flushed) https://github.com/bitcoin/bitcoin/pull/13154
1142018-05-03T10:43:54 *** laurentmt has joined #bitcoin-core-dev
1152018-05-03T10:45:03 *** arowser has quit IRC
1162018-05-03T10:45:19 *** arowser has joined #bitcoin-core-dev
1172018-05-03T10:45:54 *** gfggg has quit IRC
1182018-05-03T10:52:38 *** drizztbsd is now known as timothy
1192018-05-03T10:52:52 *** mammonpan71 has quit IRC
1202018-05-03T10:54:30 <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/11adab39e601...b62b437acd44
1212018-05-03T10:54:31 <bitcoin-git> bitcoin/master 76f344d practicalswift: logging: Fix potential use-after-free in LogPrintStr(...)
1222018-05-03T10:54:31 <bitcoin-git> bitcoin/master 0bd4cd3 practicalswift: logging: remove unused return value from LogPrintStr...
1232018-05-03T10:54:32 <bitcoin-git> bitcoin/master b62b437 Wladimir J. van der Laan: Merge #13148: logging: Fix potential use-after-free in LogPrintStr(...)...
1242018-05-03T10:55:25 <bitcoin-git> [bitcoin] laanwj closed pull request #13148: logging: Fix potential use-after-free in LogPrintStr(...) (master...logprintstr-uaf) https://github.com/bitcoin/bitcoin/pull/13148
1252018-05-03T10:56:59 *** AaronvanW has joined #bitcoin-core-dev
1262018-05-03T10:58:45 *** Aaronvan_ has joined #bitcoin-core-dev
1272018-05-03T11:00:14 *** arowser has quit IRC
1282018-05-03T11:00:33 *** arowser has joined #bitcoin-core-dev
1292018-05-03T11:00:36 *** grafcaps has joined #bitcoin-core-dev
1302018-05-03T11:02:27 *** AaronvanW has quit IRC
1312018-05-03T11:05:05 *** grafcaps has quit IRC
1322018-05-03T11:09:07 *** ExtraCrispy has joined #bitcoin-core-dev
1332018-05-03T11:18:21 *** laurentmt has quit IRC
1342018-05-03T11:23:29 *** arowser has quit IRC
1352018-05-03T11:23:45 *** arowser has joined #bitcoin-core-dev
1362018-05-03T11:24:22 *** Giszmo has quit IRC
1372018-05-03T11:26:10 *** Giszmo has joined #bitcoin-core-dev
1382018-05-03T11:38:34 *** AaronvanW has joined #bitcoin-core-dev
1392018-05-03T11:39:40 *** arowser has quit IRC
1402018-05-03T11:40:00 *** arowser has joined #bitcoin-core-dev
1412018-05-03T11:42:05 *** Aaronvan_ has quit IRC
1422018-05-03T11:43:57 *** arowser has quit IRC
1432018-05-03T11:44:15 *** arowser has joined #bitcoin-core-dev
1442018-05-03T11:46:10 *** arowser has quit IRC
1452018-05-03T11:46:33 *** arowser has joined #bitcoin-core-dev
1462018-05-03T11:48:29 *** arowser has quit IRC
1472018-05-03T11:48:50 *** arowser has joined #bitcoin-core-dev
1482018-05-03T11:50:45 *** arowser has quit IRC
1492018-05-03T11:51:03 *** arowser has joined #bitcoin-core-dev
1502018-05-03T11:59:23 *** zautomata3 has quit IRC
1512018-05-03T12:03:55 <bitcoin-git> [bitcoin] laanwj opened pull request #13157: test: Handle timestamps without microseconds in combine_logs (master...2018_05_logcombine_timestamps) https://github.com/bitcoin/bitcoin/pull/13157
1522018-05-03T12:04:58 *** arowser has quit IRC
1532018-05-03T12:05:16 *** arowser has joined #bitcoin-core-dev
1542018-05-03T12:06:41 *** zautomata3 has joined #bitcoin-core-dev
1552018-05-03T12:08:11 *** arowser has quit IRC
1562018-05-03T12:08:28 *** arowser has joined #bitcoin-core-dev
1572018-05-03T12:10:25 *** promag has quit IRC
1582018-05-03T12:13:24 *** Giszmo has quit IRC
1592018-05-03T12:13:51 *** laurentmt has joined #bitcoin-core-dev
1602018-05-03T12:16:22 *** arowser has quit IRC
1612018-05-03T12:16:40 *** arowser has joined #bitcoin-core-dev
1622018-05-03T12:22:59 *** Victorsueca has quit IRC
1632018-05-03T12:24:23 *** Victorsueca has joined #bitcoin-core-dev
1642018-05-03T12:24:51 *** zivl has quit IRC
1652018-05-03T12:26:30 *** jtimon has joined #bitcoin-core-dev
1662018-05-03T12:27:55 *** lnostdal has quit IRC
1672018-05-03T12:30:15 *** laurentmt has quit IRC
1682018-05-03T12:34:35 *** arowser has quit IRC
1692018-05-03T12:34:51 *** arowser has joined #bitcoin-core-dev
1702018-05-03T12:39:45 *** arowser has quit IRC
1712018-05-03T12:40:02 *** arowser has joined #bitcoin-core-dev
1722018-05-03T12:40:35 *** larafale has joined #bitcoin-core-dev
1732018-05-03T12:50:54 *** lnostdal has joined #bitcoin-core-dev
1742018-05-03T12:57:58 *** arowser has quit IRC
1752018-05-03T12:58:15 *** arowser has joined #bitcoin-core-dev
1762018-05-03T13:00:21 *** aknb has joined #bitcoin-core-dev
1772018-05-03T13:03:24 *** aknb has left #bitcoin-core-dev
1782018-05-03T13:04:34 *** aknb has joined #bitcoin-core-dev
1792018-05-03T13:10:07 *** tryphe has quit IRC
1802018-05-03T13:15:59 *** Giszmo has joined #bitcoin-core-dev
1812018-05-03T13:16:00 *** tryphe has joined #bitcoin-core-dev
1822018-05-03T13:18:10 *** arowser has quit IRC
1832018-05-03T13:18:27 *** arowser has joined #bitcoin-core-dev
1842018-05-03T13:21:35 *** tryphe has quit IRC
1852018-05-03T13:25:42 *** tryphe has joined #bitcoin-core-dev
1862018-05-03T13:26:47 *** promag has joined #bitcoin-core-dev
1872018-05-03T13:34:13 *** laurentmt has joined #bitcoin-core-dev
1882018-05-03T13:34:34 *** tryphe_ has joined #bitcoin-core-dev
1892018-05-03T13:37:33 *** tryphe has quit IRC
1902018-05-03T13:38:07 *** grafcaps has joined #bitcoin-core-dev
1912018-05-03T13:38:35 <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/b62b437acd44...7eb7076f7007
1922018-05-03T13:38:36 <bitcoin-git> bitcoin/master d76962e João Barbosa: rpc: Reduce cs_main lock in listunspent
1932018-05-03T13:38:36 <bitcoin-git> bitcoin/master a59dac3 João Barbosa: refactor: Avoid extra lookups of mapAddressBook in listunspent RPC
1942018-05-03T13:38:37 <bitcoin-git> bitcoin/master 7eb7076 Wladimir J. van der Laan: Merge #12639: Reduce cs_main lock in listunspent...
1952018-05-03T13:39:11 <bitcoin-git> [bitcoin] laanwj closed pull request #12639: Reduce cs_main lock in listunspent (master...2018-03-reduce-cs_main_lock-listunspent) https://github.com/bitcoin/bitcoin/pull/12639
1962018-05-03T13:44:46 <promag> wumpus: another one in the same line #12151
1972018-05-03T13:44:48 <gribble> https://github.com/bitcoin/bitcoin/issues/12151 | Remove cs_main lock from blockToJSON and blockheaderToJSON by promag · Pull Request #12151 · bitcoin/bitcoin · GitHub
1982018-05-03T13:45:00 *** pergaminho has joined #bitcoin-core-dev
1992018-05-03T13:45:09 <wumpus> I'm done with locking refactors for a bit :)
2002018-05-03T13:45:26 <promag> ah! out of luck :D
2012018-05-03T13:45:49 <promag> maybe next month :D
2022018-05-03T13:46:34 *** tryphe_ has quit IRC
2032018-05-03T13:46:36 <wumpus> time to review #12979
2042018-05-03T13:46:38 <gribble> https://github.com/bitcoin/bitcoin/issues/12979 | Split validationinterface into paralell validation/mempool interfaces by TheBlueMatt · Pull Request #12979 · bitcoin/bitcoin · GitHub
2052018-05-03T13:46:46 *** vicenteH has quit IRC
2062018-05-03T13:47:11 *** vicenteH has joined #bitcoin-core-dev
2072018-05-03T13:47:26 *** tryphe has joined #bitcoin-core-dev
2082018-05-03T13:47:34 *** pergaminho has quit IRC
2092018-05-03T13:50:40 *** tryphe_ has joined #bitcoin-core-dev
2102018-05-03T13:51:26 <promag> allright :/ heh
2112018-05-03T13:53:03 *** pergaminho has joined #bitcoin-core-dev
2122018-05-03T13:53:46 *** tryphe has quit IRC
2132018-05-03T13:55:36 *** tryphe_000 has joined #bitcoin-core-dev
2142018-05-03T13:56:37 <BlueMatt> promag: that still makes a ton more sense after 11913
2152018-05-03T13:59:02 *** tryphe_ has quit IRC
2162018-05-03T13:59:28 <promag> BlueMatt: you mean 12979 after 11913 or 12151 after 11913?
2172018-05-03T14:00:42 <promag> if you mean #12151 then yeah for sure
2182018-05-03T14:00:45 <gribble> https://github.com/bitcoin/bitcoin/issues/12151 | Remove cs_main lock from blockToJSON and blockheaderToJSON by promag · Pull Request #12151 · bitcoin/bitcoin · GitHub
2192018-05-03T14:01:24 <BlueMatt> 12151, yea
2202018-05-03T14:01:26 <promag> BlueMatt: 11913 needs rebase
2212018-05-03T14:01:50 <BlueMatt> yea, I've been lazy about rebasing a few of my prs that arent getting review cause some of the other are
2222018-05-03T14:02:02 <BlueMatt> oh, no, that one i should rebase
2232018-05-03T14:02:02 *** tryphe_000 has quit IRC
2242018-05-03T14:02:03 <BlueMatt> ugh, k
2252018-05-03T14:02:26 *** tryphe_000 has joined #bitcoin-core-dev
2262018-05-03T14:19:38 <bitcoin-git> [bitcoin] marcoagner opened pull request #13158: [qt]: Improve sendcoinsdialog readability (master...improve_sendcoinsdialog_readability) https://github.com/bitcoin/bitcoin/pull/13158
2272018-05-03T14:19:54 *** pergaminho has quit IRC
2282018-05-03T14:25:06 *** Victorsueca has quit IRC
2292018-05-03T14:26:22 *** Victorsueca has joined #bitcoin-core-dev
2302018-05-03T14:36:03 *** promag has quit IRC
2312018-05-03T14:38:04 *** tryphe_000 has quit IRC
2322018-05-03T14:38:27 *** tryphe_000 has joined #bitcoin-core-dev
2332018-05-03T14:40:04 *** tryphe_000 has quit IRC
2342018-05-03T14:40:29 *** tryphe_000 has joined #bitcoin-core-dev
2352018-05-03T14:43:42 *** tryphe_000 has quit IRC
2362018-05-03T14:43:58 *** laurentmt has quit IRC
2372018-05-03T14:44:08 *** tryphe_000 has joined #bitcoin-core-dev
2382018-05-03T14:45:05 *** larafale has quit IRC
2392018-05-03T14:49:24 *** tryphe has joined #bitcoin-core-dev
2402018-05-03T14:52:33 *** tryphe_000 has quit IRC
2412018-05-03T14:57:53 *** tryphe_ has joined #bitcoin-core-dev
2422018-05-03T14:59:51 *** tryphe has quit IRC
2432018-05-03T15:01:21 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2442018-05-03T15:05:59 *** sdaftuar has joined #bitcoin-core-dev
2452018-05-03T15:08:53 *** mistergold has quit IRC
2462018-05-03T15:23:10 *** Randolf has joined #bitcoin-core-dev
2472018-05-03T15:23:23 *** ghost43 has quit IRC
2482018-05-03T15:23:23 *** intcat has quit IRC
2492018-05-03T15:23:23 *** arubi has quit IRC
2502018-05-03T15:23:42 *** ghost43 has joined #bitcoin-core-dev
2512018-05-03T15:23:51 *** arubi has joined #bitcoin-core-dev
2522018-05-03T15:25:14 *** sdaftuar has quit IRC
2532018-05-03T15:25:14 *** sdaftuar has joined #bitcoin-core-dev
2542018-05-03T15:25:21 *** intcat has joined #bitcoin-core-dev
2552018-05-03T15:36:37 *** Guyver2 has joined #bitcoin-core-dev
2562018-05-03T15:37:37 *** grafcaps has quit IRC
2572018-05-03T15:47:13 *** Randolf has quit IRC
2582018-05-03T15:52:23 <bitcoin-git> [bitcoin] laanwj closed pull request #13157: test: Handle timestamps without microseconds in combine_logs (master...2018_05_logcombine_timestamps) https://github.com/bitcoin/bitcoin/pull/13157
2592018-05-03T15:54:32 *** bsm1175321 has quit IRC
2602018-05-03T15:54:45 *** grafcaps has joined #bitcoin-core-dev
2612018-05-03T16:09:31 <bitcoin-git> [bitcoin] practicalswift opened pull request #13159: Don't close old debug log file handler prematurely when trying to re-open (on SIGHUP) (master...handle-reopen-failed) https://github.com/bitcoin/bitcoin/pull/13159
2622018-05-03T16:21:08 *** bsm1175321 has joined #bitcoin-core-dev
2632018-05-03T16:22:52 *** promag has joined #bitcoin-core-dev
2642018-05-03T16:28:32 *** Aaronvan_ has joined #bitcoin-core-dev
2652018-05-03T16:30:28 *** jtimon has quit IRC
2662018-05-03T16:30:57 *** AaronvanW has quit IRC
2672018-05-03T16:31:36 *** jtimon has joined #bitcoin-core-dev
2682018-05-03T16:37:02 <bitcoin-git> [bitcoin] promag opened pull request #13160: Unlock spent outputs (master...2018-05-unlock-spent-output) https://github.com/bitcoin/bitcoin/pull/13160
2692018-05-03T16:41:30 *** Randolf has joined #bitcoin-core-dev
2702018-05-03T16:42:38 <promag> rpc and wallet labels ^
2712018-05-03T16:42:48 *** promag has quit IRC
2722018-05-03T16:52:21 *** meshcollider has quit IRC
2732018-05-03T17:11:24 *** SopaXorzTaker has quit IRC
2742018-05-03T17:21:54 <bitcoin-git> [bitcoin] real-or-random opened pull request #13161: wallet: Reset BerkeleyDB handle after connection fails (master...bdb-reset) https://github.com/bitcoin/bitcoin/pull/13161
2752018-05-03T17:33:12 *** isis is now known as isis_
2762018-05-03T17:34:28 *** shesek has joined #bitcoin-core-dev
2772018-05-03T17:35:57 *** Randolf has quit IRC
2782018-05-03T17:36:15 *** riemann has joined #bitcoin-core-dev
2792018-05-03T17:40:22 *** riemann has quit IRC
2802018-05-03T17:42:29 *** Randolf has joined #bitcoin-core-dev
2812018-05-03T17:42:56 <MarcoFalke> wumpus: (re out of tree tests) It works because test_runner.py is aware of the srcdir
2822018-05-03T17:43:12 <bitcoin-git> [bitcoin] jnewbery opened pull request #13162: [logging] Don't incorrectly log that REJECT messages are unknown. (master...fix_reject_logging) https://github.com/bitcoin/bitcoin/pull/13162
2832018-05-03T17:43:28 <wumpus> but I eas not running test runner, that already worked before, but individual tests
2842018-05-03T17:43:30 <MarcoFalke> test_runner is linked from the srcdir, so we can follow that link
2852018-05-03T17:43:34 <MarcoFalke> hmm
2862018-05-03T17:43:53 <MarcoFalke> individual tests are not available in the build dir?
2872018-05-03T17:49:37 *** leval2 has joined #bitcoin-core-dev
2882018-05-03T17:49:52 *** timothy has quit IRC
2892018-05-03T17:50:51 *** SopaXorzTaker has joined #bitcoin-core-dev
2902018-05-03T17:51:17 *** promag has joined #bitcoin-core-dev
2912018-05-03T18:06:12 *** Randolf has quit IRC
2922018-05-03T18:09:03 *** larafale has joined #bitcoin-core-dev
2932018-05-03T18:11:45 *** tryphe_ has quit IRC
2942018-05-03T18:17:27 *** tryphe has joined #bitcoin-core-dev
2952018-05-03T18:21:32 <wumpus> MarcoFalke: indeed, so used the full path to the source dir, and it works, no matter whether the current directory is in the build directory or the source one
2962018-05-03T18:22:09 *** tryphe has quit IRC
2972018-05-03T18:23:10 <wumpus> MarcoFalke: apparently I have a test/config.ini in the source dir, pointing to the BUILDDIR
2982018-05-03T18:23:23 <wumpus> MarcoFalke: not sure this is the intention, will wipe it and reconfiguer
2992018-05-03T18:23:26 <MarcoFalke> Yeah, otherwise it would fail
3002018-05-03T18:23:39 <MarcoFalke> the config.ini is required now
3012018-05-03T18:24:05 <wumpus> shouldn't it be in the build dir, though?
3022018-05-03T18:24:46 <wumpus> to be clear I think this is convenient, but it probably breaks the case where one source directory is used with multiple build dirs
3032018-05-03T18:25:03 *** tryphe has joined #bitcoin-core-dev
3042018-05-03T18:29:53 *** tryphe has quit IRC
3052018-05-03T18:32:05 <wumpus> or when configuring from a read-only source dir
3062018-05-03T18:32:19 *** drexl has joined #bitcoin-core-dev
3072018-05-03T18:32:51 <wumpus> ok, after reconfiguring the config.ini appears in the build dir, not the source dir, seems to have been an anomaly
3082018-05-03T18:34:42 *** adiabat has quit IRC
3092018-05-03T18:36:23 *** adiabat has joined #bitcoin-core-dev
3102018-05-03T18:38:02 *** tryphe has joined #bitcoin-core-dev
3112018-05-03T18:41:08 *** tryphe has quit IRC
3122018-05-03T18:41:33 *** tryphe has joined #bitcoin-core-dev
3132018-05-03T18:43:05 <jamesob> cfields: would it make sense to at some point move logging into a separate thread? (about to look at your changes, but was just wondering)
3142018-05-03T18:43:23 <wumpus> MarcoFalke: it looks like 'make clean' does not delete config.ini
3152018-05-03T18:43:36 <MarcoFalke> oh
3162018-05-03T18:43:39 <cfields> jamesob: yea, I think just about everyone has proposed that at some point, but nobody's done it :)
3172018-05-03T18:43:40 <MarcoFalke> and make distclean?
3182018-05-03T18:43:54 <wumpus> MarcoFalke: what happened is probably: I configured the source dir, cleaned that, then configured in a separate build directory
3192018-05-03T18:44:08 <cfields> jamesob: might be a good topic for the meeting today, I'm sure there are lots of thoughts on that
3202018-05-03T18:44:08 <jamesob> cfields: welp, I'll add it to the list :)
3212018-05-03T18:44:13 <MarcoFalke> Yeah, that is what I assumed
3222018-05-03T18:44:25 <jamesob> cfields: cool, will bring it up
3232018-05-03T18:44:26 <wumpus> distclean does remove it
3242018-05-03T18:44:50 <MarcoFalke> Usually you are asked to disclean before doing an out of tree build, at least I am
3252018-05-03T18:45:06 *** tryphe has quit IRC
3262018-05-03T18:45:32 <wumpus> yes
3272018-05-03T18:45:40 <wumpus> I think that makes sense...
3282018-05-03T18:45:41 *** tryphe has joined #bitcoin-core-dev
3292018-05-03T18:55:01 <sipa> i'm going to be 10-15 min late for keeting
3302018-05-03T18:55:03 <sipa> meeting
3312018-05-03T18:57:43 <wumpus> ok
3322018-05-03T18:59:03 <MarcoFalke> Proposed short topic: Delete 0.8, 0.9 and 0.10 git branches
3332018-05-03T18:59:50 <wumpus> ack
3342018-05-03T18:59:58 <wumpus> oh
3352018-05-03T19:00:10 <wumpus> #startmeeting
3362018-05-03T19:00:10 <lightningbot> Meeting started Thu May 3 19:00:10 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3372018-05-03T19:00:10 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3382018-05-03T19:00:13 <promag> hi
3392018-05-03T19:00:26 <jamesob> hi
3402018-05-03T19:00:29 <wumpus> #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 jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
3412018-05-03T19:00:32 <jnewbery> hello
3422018-05-03T19:00:37 <kanzure> hi.
3432018-05-03T19:00:42 <achow101> hi
3442018-05-03T19:00:43 <cfields> hi
3452018-05-03T19:00:56 <jonasschnelli> hi
3462018-05-03T19:01:05 <jimpo> hi
3472018-05-03T19:01:07 <jcorgan> lurking as usual
3482018-05-03T19:01:23 <wumpus> any other proposed topics?
3492018-05-03T19:01:51 <jamesob> logging at some point?
3502018-05-03T19:02:04 <wumpus> what about logging?
3512018-05-03T19:02:16 <jamesob> I'd like to talk about moving it into a separate thread
3522018-05-03T19:02:25 <wumpus> ok
3532018-05-03T19:02:37 <BlueMatt> #12934
3542018-05-03T19:02:38 <jnewbery> +1 to moving logging to a separate thread
3552018-05-03T19:02:39 <gribble> https://github.com/bitcoin/bitcoin/issues/12934 | [WIP] [net] [validation] Call ProcessNewBlock() asynchronously by skeees · Pull Request #12934 · bitcoin/bitcoin · GitHub
3562018-05-03T19:02:41 <wumpus> let's start with the usual topic
3572018-05-03T19:03:06 <wumpus> even though it will piss off BlueMatt :)
3582018-05-03T19:03:07 <wumpus> #topic High prioriity for review
3592018-05-03T19:03:14 <wumpus> https://github.com/bitcoin/bitcoin/projects/8
3602018-05-03T19:03:52 <wumpus> only #12979 #12560 #10757 left now
3612018-05-03T19:03:55 <gribble> https://github.com/bitcoin/bitcoin/issues/12979 | Split validationinterface into paralell validation/mempool interfaces by TheBlueMatt · Pull Request #12979 · bitcoin/bitcoin · GitHub
3622018-05-03T19:03:59 <gribble> https://github.com/bitcoin/bitcoin/issues/12560 | [wallet] Upgrade path for non-HD wallets to HD by achow101 · Pull Request #12560 · bitcoin/bitcoin · GitHub
3632018-05-03T19:04:05 <gribble> https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub
3642018-05-03T19:04:16 <wumpus> anything to discuss about those?
3652018-05-03T19:04:25 <wumpus> anything new to add? or remove?
3662018-05-03T19:04:49 <jimpo> I'd like #12254 to get some review :-)
3672018-05-03T19:04:52 <gribble> https://github.com/bitcoin/bitcoin/issues/12254 | BIP 158: Compact Block Filters for Light Clients by jimpo · Pull Request #12254 · bitcoin/bitcoin · GitHub
3682018-05-03T19:04:56 *** LukeJr has joined #bitcoin-core-dev
3692018-05-03T19:05:22 <jnewbery> There's a whole series of sequential PRs on wallet load/create/unload. It'd be good to start moving through those, but I don't know how high priority they are for others
3702018-05-03T19:05:42 <wumpus> jnewbery: if it's blocking anyone, the first one on the list should be on there at least
3712018-05-03T19:05:48 <jtimon> perhaps put the load one in high priority?
3722018-05-03T19:05:52 <jnewbery> #10740
3732018-05-03T19:05:56 <gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] `loadwallet` RPC - load wallet at runtime by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
3742018-05-03T19:06:14 <jnewbery> It's only blocking because there are other ones queued behind it
3752018-05-03T19:06:25 <BlueMatt> jnewbery: that is the most common form of blocking
3762018-05-03T19:06:26 <wumpus> so it's blocking the continuation ones
3772018-05-03T19:06:33 <jimpo> That's basically the definition of blocking...
3782018-05-03T19:06:35 <wumpus> right, it's pretty much the definition of blocking
3792018-05-03T19:06:37 <wumpus> lol
3802018-05-03T19:06:39 <jonasschnelli> I agree that we should add 10740 to the list
3812018-05-03T19:06:46 <wumpus> #10740 given me an unicorn though
3822018-05-03T19:06:51 <gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] `loadwallet` RPC - load wallet at runtime by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
3832018-05-03T19:07:01 <jonasschnelli> has also a unicorn, reload solved
3842018-05-03T19:07:15 <wumpus> yes
3852018-05-03T19:07:16 <LukeJr> unicorns probably have a high street value
3862018-05-03T19:07:37 <wumpus> added
3872018-05-03T19:07:39 <jnewbery> not any more. The market's been flooded
3882018-05-03T19:07:49 <BlueMatt> topic: 0.15.1
3892018-05-03T19:07:50 <LukeJr> shows what I know of unicorn markets
3902018-05-03T19:07:52 <BlueMatt> err 16
3912018-05-03T19:08:12 <wumpus> LukeJr: yes, I"m trying to farm them and sell them, but I have more now than atoms in the knows universe so you could say the supply is more than the demand...
3922018-05-03T19:08:20 <promag> wumpus: could also add #13097 too?
3932018-05-03T19:08:22 <gribble> https://github.com/bitcoin/bitcoin/issues/13097 | ui: Support wallets loaded dynamically by promag · Pull Request #13097 · bitcoin/bitcoin · GitHub
3942018-05-03T19:08:57 <wumpus> promag: ok
3952018-05-03T19:09:11 <promag> ty
3962018-05-03T19:09:34 <wumpus> #topic Delete 0.8, 0.9 and 0.10 git branches
3972018-05-03T19:09:43 <MarcoFalke> Background: Those last tagged versions on those branches are EOL for more than a year now. The tags can be kept for archival reasons, but the branches are no longer required. See https://bitcoincore.org/en/lifecycle/#schedule
3982018-05-03T19:09:47 *** clarkmoody has joined #bitcoin-core-dev
3992018-05-03T19:09:49 <wumpus> yes
4002018-05-03T19:09:53 <BlueMatt> ack
4012018-05-03T19:09:57 <wumpus> bye
4022018-05-03T19:10:00 <achow101> ack
4032018-05-03T19:10:02 <jonasschnelli> ack
4042018-05-03T19:10:17 <jtimon> I didn't know we still had those
4052018-05-03T19:10:18 <LukeJr> is the latest commit of each tagged?
4062018-05-03T19:10:34 <LukeJr> If not, maybe a 0.n_final tag is appropriate
4072018-05-03T19:10:35 <jonasschnelli> LukeJr: i hope so
4082018-05-03T19:10:48 <wumpus> LukeJr: agree, will check that first
4092018-05-03T19:10:58 <cfields> er, are they not tagged from their respective branches?
4102018-05-03T19:11:06 <LukeJr> jonasschnelli: it wouldn't be the first time we have backported fixes and never released with them
4112018-05-03T19:11:06 <MarcoFalke> LukeJr: For the 0.8 one not
4122018-05-03T19:11:23 <MarcoFalke> The others are last tag == tip of branch, last time I checked
4132018-05-03T19:11:42 <wumpus> will create a v0.8_final for that
4142018-05-03T19:11:49 <wumpus> +tag
4152018-05-03T19:12:02 <LukeJr> maybe it can be a non-object tag, to avoid confusing users with a recent date
4162018-05-03T19:12:33 <wumpus> yes fine with me, just to avoid losing history
4172018-05-03T19:12:48 <MarcoFalke> Oh, and the 0.9 one is missing one commit (upnp)
4182018-05-03T19:13:06 <sipa> back
4192018-05-03T19:13:10 *** moneyball has joined #bitcoin-core-dev
4202018-05-03T19:13:27 <wumpus> MarcoFalke: so same for 0.9 then
4212018-05-03T19:14:03 <wumpus> #topic Moving logging to a separate thread (jamesob)
4222018-05-03T19:14:44 <jamesob> after working on #13099, I think it may be worthwhile to move logging into a separate thread
4232018-05-03T19:14:46 <gribble> https://github.com/bitcoin/bitcoin/issues/13099 | Use thread names in logs and deadlock diagnostics by jamesob · Pull Request #13099 · bitcoin/bitcoin · GitHub
4242018-05-03T19:15:03 <jamesob> esp. given instances like #12970
4252018-05-03T19:15:04 <BlueMatt> ACKACKACKACKACKACKACKACKACKACK (this is a surprisingly high lag-creator for miners, at least for those with spinning-disk-backed-or-cloud-hosted machines
4262018-05-03T19:15:06 <gribble> https://github.com/bitcoin/bitcoin/issues/12970 | logging: bypass timestamp formatting when not logging by theuni · Pull Request #12970 · bitcoin/bitcoin · GitHub
4272018-05-03T19:15:17 <wumpus> queue log messages to a ring buffer ?
4282018-05-03T19:15:26 <jamesob> wumpus: sure, something along those lines
4292018-05-03T19:15:32 <wumpus> gmaxwell has been proposing that for ages...
4302018-05-03T19:15:35 <BlueMatt> see-also commit which does this at https://github.com/bitcoinfibre/bitcoinfibre/commit/6b6a3aef0663775b63bac7d0aa07ec5fc4eb9fc9
4312018-05-03T19:15:45 <jnewbery> I started working on a branch for this last year, but didn't get very far
4322018-05-03T19:15:51 <jnewbery> definite concept ACK
4332018-05-03T19:15:56 <wumpus> yes, concept ACK
4342018-05-03T19:16:16 <BlueMatt> I did not propose it upstream as it means if we LogPrintf(); assert(false) we'll likely miss it
4352018-05-03T19:16:18 *** clarkmoody has quit IRC
4362018-05-03T19:16:18 <jnewbery> means the message processing thread can't be blocked on i/o hangs
4372018-05-03T19:16:21 <BlueMatt> and I figured folks wouldnt want that
4382018-05-03T19:16:30 <skeees> ACK - should point out that it could make crash debugging substantially more complicated
4392018-05-03T19:16:39 <BlueMatt> jnewbery: it still will be a ton cause it ReadBlockFromDisk()s
4402018-05-03T19:16:40 <wumpus> BlueMatt: we could have special priority log calls that always make it to disk?
4412018-05-03T19:16:41 *** clarkmoody has joined #bitcoin-core-dev
4422018-05-03T19:16:46 <jamesob> skeees: right, I think that's the only caveat I can think of
4432018-05-03T19:16:50 <LukeJr> BlueMatt: surely there's a way to run log flushing at assert
4442018-05-03T19:16:53 <wumpus> BlueMatt: CriticalLogPrintf?
4452018-05-03T19:16:53 <promag> +1 BlueMatt point
4462018-05-03T19:16:56 <cfields> are there any possible interactions where someone might be tailing the log and assume that it's synchronous?
4472018-05-03T19:17:04 <jonasschnelli> use gdb
4482018-05-03T19:17:15 <BlueMatt> wumpus: I mean the number of times its been helpful just to see which lines actually made it to debug.log when someone submitted a crash is super helpful
4492018-05-03T19:17:21 <LukeJr> cfields: it couldn't be?
4502018-05-03T19:17:25 <BlueMatt> and gdb isnt really an option when debugging remotely over github issues :/
4512018-05-03T19:17:32 <jimpo> Does anyone know the relative performance of logging to console vs debug log file?
4522018-05-03T19:17:50 <BlueMatt> jimpo: on non-serial-consoles, console logging should be fast, serial consoles can block
4532018-05-03T19:17:54 <LukeJr> in theory, we could fork() a logging-only process, but that feels ugly
4542018-05-03T19:17:56 <BlueMatt> (or vtt on a slow-refresh-monitor)
4552018-05-03T19:17:59 <sipa> We should fork a separate process for logging, and then open a FIFO with it and pipe the log data there. If bitcoind crashes, that process hopefully survives :)
4562018-05-03T19:18:02 <sipa> !hi5 LukeJr
4572018-05-03T19:18:03 <gribble> Error: "hi5" is not a valid command.
4582018-05-03T19:18:17 <wumpus> it's mostly a win for low priority debugging messages, I guess
4592018-05-03T19:18:21 <BlueMatt> or we could just make it optional
4602018-05-03T19:18:26 <wumpus> if logging is low volume it's never a bottleneck
4612018-05-03T19:18:35 <BlueMatt> miners can enable it, everyone else probably doesnt need to
4622018-05-03T19:18:47 <wumpus> only miners that have debug=net enabled?
4632018-05-03T19:18:51 <skeees> just throwing out some alternatives with a properly tuned buffer cache - logging shouldn't hit disk that often? if its still flushing frequently - could consider a more compact binary format for logs - though that means you'd need a special tool to read them
4642018-05-03T19:19:18 <jimpo> I feel like disabling logging to file and piping stdout through tee or something should work fine
4652018-05-03T19:19:38 <wumpus> skeees: well the logging is unbuffered at this moment so can't do much worse than that...
4662018-05-03T19:19:38 <BlueMatt> wumpus: I mean -debug should always mean non-async loggin, I think
4672018-05-03T19:19:50 <cfields> skeees: it's not just hitting disk, it's serialization as well. Though I guess we couldn't defer serialization if references are passed in.
4682018-05-03T19:19:51 <wumpus> even line-buffered would be better for performance
4692018-05-03T19:20:12 <jamesob> wumpus: I thought fwrite was buffered?
4702018-05-03T19:20:12 <wumpus> BlueMatt: right
4712018-05-03T19:20:15 <skeees> another option is to have debug logging compiled out
4722018-05-03T19:20:25 <skeees> instead of just disabled via flag as it is currently
4732018-05-03T19:20:30 <wumpus> jamesob: yes, but the buffer is disabled after opening
4742018-05-03T19:20:40 <BlueMatt> I mean I dont think people who want performance dont want a debug.log
4752018-05-03T19:20:48 <BlueMatt> they just dont want it to result in 8-ms pauses
4762018-05-03T19:20:50 *** SopaXorzTaker has quit IRC
4772018-05-03T19:21:00 <wumpus> skeees: that's not the issue; debug logging is already not executed if it's disabled
4782018-05-03T19:21:03 * LukeJr wonders if we skip serialization when the debug log level is such that it will not be logged
4792018-05-03T19:21:08 <wumpus> skeees: even formatting is bypassed in that case
4802018-05-03T19:21:19 <wumpus> LukeJr: yes
4812018-05-03T19:21:24 <skeees> LukeJr: yeah that's exactly the question i was trying to ask
4822018-05-03T19:21:26 <skeees> ah ok
4832018-05-03T19:21:58 <skeees> i dunno actually
4842018-05-03T19:22:02 <wumpus> tbh I don't think there's an actual issue here
4852018-05-03T19:22:09 <skeees> because theres a lot of uint256.ToString() stuff
4862018-05-03T19:22:15 <cfields> operations on incoming vars aren't skipped though, I believe. Like LogPrint("foo: %s", foo.get())
4872018-05-03T19:22:18 <BlueMatt> the only issue here is for folks who care a shitload about small disk pauses
4882018-05-03T19:22:22 <wumpus> although the ring buffer would be nice because of gmaxwell's argument (log at higher debug message, but don't log the messages to disk unless a crash)
4892018-05-03T19:22:22 <BlueMatt> hence why I use it in fibre
4902018-05-03T19:22:58 <BlueMatt> when we get ReadBlockFromDisk to be async for peer handling, then it may make more sense to revisit this
4912018-05-03T19:23:11 <wumpus> so a crash would log the last low-priority debug messages even if debugging is disabled.. then agian, it's not possible to bypass formatting anymore in that case
4922018-05-03T19:23:25 <BlueMatt> we'd have to swap assert() for dump_log_and_crash()
4932018-05-03T19:23:36 <wumpus> not sure that even requires logging to be in a sepaerate thread
4942018-05-03T19:23:41 <LukeJr> wumpus: not sure if formatting is a big deal tbh
4952018-05-03T19:23:50 <LukeJr> BlueMatt: or handle SIGABRT?
4962018-05-03T19:23:51 <BlueMatt> no, but then I dont get to upstream my lockless ring buffer logger :p
4972018-05-03T19:23:54 <wumpus> LukeJr: well some messages are extremely high volume
4982018-05-03T19:24:01 <BlueMatt> luke-jr: I dont think we want to do that much work in a signal handler
4992018-05-03T19:24:03 <wumpus> LukeJr: try enabling *all* debugging for fun
5002018-05-03T19:24:31 <BlueMatt> matt@bitcoin-seednode:~$ ls -lha ~/.bitcoin/debug.log
5012018-05-03T19:24:31 <BlueMatt> -rw------- 1 matt matt 8.6T May 3 19:24 /home/matt/.bitcoin/debug.log
5022018-05-03T19:24:41 <wumpus> heh
5032018-05-03T19:24:51 <sipa> how long?
5042018-05-03T19:24:54 <LukeJr> BlueMatt: if it's plain old C code, we can probably get away with it
5052018-05-03T19:25:04 <wumpus> hence my proposal at some point to split up net logging into low and high volume messages
5062018-05-03T19:25:14 * jamesob buys BlueMatt a pair of socks with the logrotate manpage on them
5072018-05-03T19:25:23 <BlueMatt> sipa: 2014-11-19 00:06:55
5082018-05-03T19:25:26 <wumpus> #12219
5092018-05-03T19:25:28 <gribble> https://github.com/bitcoin/bitcoin/issues/12219 | More granular net logging · Issue #12219 · bitcoin/bitcoin · GitHub
5102018-05-03T19:25:40 <cfields> wumpus: +1. Will have a look.
5112018-05-03T19:26:02 <BlueMatt> I do like the flush-debug-ring-to-disk-on-crash idea
5122018-05-03T19:26:09 <wumpus> yes
5132018-05-03T19:26:09 <jamesob> +1
5142018-05-03T19:26:24 <BlueMatt> (would mean serializing all debug messages, though)
5152018-05-03T19:26:28 *** echeveria has quit IRC
5162018-05-03T19:26:38 <LukeJr> maybe even on non-crash critical errors
5172018-05-03T19:26:57 <BlueMatt> non-crash critical errors should crash :p
5182018-05-03T19:27:09 <wumpus> it's in the word 'critical'
5192018-05-03T19:27:55 <jamesob> okay so unless anyone has any objections, I'll start working on a thread-consumes-from-ring-buffer implementation in the near future
5202018-05-03T19:28:04 <wumpus> I think I killed the topic
5212018-05-03T19:28:05 <wumpus> oh
5222018-05-03T19:28:10 <jnewbery> jamesob: ACK
5232018-05-03T19:28:21 <BlueMatt> jamesob: I think only as optional except for disabled-debug-messages
5242018-05-03T19:28:37 <jamesob> i.e. async logging should be opt-in?
5252018-05-03T19:28:38 <BlueMatt> jamesob: but if upstream wants to maintain by fibre patches, fine by me :p
5262018-05-03T19:28:41 <BlueMatt> yes
5272018-05-03T19:28:48 <BlueMatt> also, you may want to start with https://github.com/bitcoinfibre/bitcoinfibre/commit/6b6a3aef0663775b63bac7d0aa07ec5fc4eb9fc9
5282018-05-03T19:29:07 <jamesob> I'll give it a look, thanks
5292018-05-03T19:29:42 <wumpus> #topic 0.16.1 (BlueMatt)
5302018-05-03T19:30:06 <BlueMatt> so for those who weren't paying attention, skeees found some particularly novel races in block handling in #13092
5312018-05-03T19:30:07 <gribble> https://github.com/bitcoin/bitcoin/issues/13092 | ActivateBestChain concurrency issues · Issue #13092 · bitcoin/bitcoin · GitHub
5322018-05-03T19:30:21 <BlueMatt> cause they're threading issues they almost certainly wont effect anyone except submitblock users
5332018-05-03T19:30:29 <BlueMatt> ie miners, and only rare races
5342018-05-03T19:30:42 <BlueMatt> but, still, I think given that and some of the other various fixes we've had, it may be worth backporting
5352018-05-03T19:31:11 <wumpus> 13092 is an issue, not a PR, can't label it for backport
5362018-05-03T19:31:14 <BlueMatt> further, at least personally, I'd kinda like to see #11423 make some movement, and making that kind of policy change in a non-minor-version strikes me as weird
5372018-05-03T19:31:17 <gribble> https://github.com/bitcoin/bitcoin/issues/11423 | [Policy] Make OP_CODESEPARATOR and FindAndDelete in non-segwit scripts non-std by jl2012 · Pull Request #11423 · bitcoin/bitcoin · GitHub
5382018-05-03T19:31:25 <BlueMatt> yes, it needs a pr, sdaftuar has a branch, I believe, but not open
5392018-05-03T19:31:35 <sdaftuar> skeees has a pr, one sec
5402018-05-03T19:31:46 <skeees> #13023
5412018-05-03T19:31:46 <sdaftuar> #13023
5422018-05-03T19:31:48 <BlueMatt> was the skeees pr updated for the new method?
5432018-05-03T19:31:48 <gribble> https://github.com/bitcoin/bitcoin/issues/13023 | Always refresh most work chain when reacquiring cs_main in ActivateBestChain() by skeees · Pull Request #13023 · bitcoin/bitcoin · GitHub
5442018-05-03T19:31:50 <gribble> https://github.com/bitcoin/bitcoin/issues/13023 | Always refresh most work chain when reacquiring cs_main in ActivateBestChain() by skeees · Pull Request #13023 · bitcoin/bitcoin · GitHub
5452018-05-03T19:31:55 <sdaftuar> no we need to settle on the right fix
5462018-05-03T19:32:01 <skeees> still needs a bit of work - i need to pull in some fixes @sdaftuar made
5472018-05-03T19:32:09 <sdaftuar> i think the fix i proposed works, but maybe someone has a better idea
5482018-05-03T19:32:26 <wumpus> ok added tags
5492018-05-03T19:32:27 <BlueMatt> ok, yes, I think that is doable, however, and I think between that and making progress on the standardness changes from jl2012 probably are worth a minor bump
5502018-05-03T19:32:37 <skeees> there's also #12988 - which is a similar type of bug
5512018-05-03T19:32:40 <gribble> https://github.com/bitcoin/bitcoin/issues/12988 | Hold cs_main while calling UpdatedBlockTip() signal by skeees · Pull Request #12988 · bitcoin/bitcoin · GitHub
5522018-05-03T19:33:07 <BlueMatt> yes, indeed, that too
5532018-05-03T19:33:18 <sdaftuar> agreed
5542018-05-03T19:33:30 <wumpus> ok
5552018-05-03T19:33:55 <BlueMatt> (so, obviously, for those following along at home, next-milestone usually gets auto-high-priority-for-review status :p)
5562018-05-03T19:34:19 <wumpus> re: #11423, I rebased that one for jl2012, not sure if there's further things to be done there
5572018-05-03T19:34:22 <gribble> https://github.com/bitcoin/bitcoin/issues/11423 | [Policy] Make OP_CODESEPARATOR and FindAndDelete in non-segwit scripts non-std by jl2012 · Pull Request #11423 · bitcoin/bitcoin · GitHub
5582018-05-03T19:35:12 <wumpus> added 0.16.1 tag there too
5592018-05-03T19:35:18 <BlueMatt> I believe jl2012 wanted to add one more policy rule there, which should be done, there was a branch floating around but I cant find it atm
5602018-05-03T19:35:25 <BlueMatt> anyway, thats for discussion on that pr
5612018-05-03T19:35:47 <BlueMatt> I'll ping jl2012 since he's probably asleep
5622018-05-03T19:36:04 <BlueMatt> anyway, seems no disagreement, so next topic?
5632018-05-03T19:36:06 <wumpus> yes, but it is the open PR with the most (ut)ACKs so I thought it'd be almost ready for merge
5642018-05-03T19:36:34 <wumpus> that's why I rebased it with the idea to merge it after final review
5652018-05-03T19:36:38 <wumpus> but ok
5662018-05-03T19:36:54 <MarcoFalke> Yeah, would need some re-ACKs first, though
5672018-05-03T19:37:19 <wumpus> right, but if the goalposts keep moving
5682018-05-03T19:37:41 <wumpus> I think we've exhausted all proposed topics
5692018-05-03T19:37:45 *** cryptojanitor has joined #bitcoin-core-dev
5702018-05-03T19:37:52 <MarcoFalke> If there are minor fix ups, they should probably happen soon
5712018-05-03T19:38:21 <BlueMatt> oh, no, wait i had another topic
5722018-05-03T19:38:34 <BlueMatt> topic: activate segwit
5732018-05-03T19:38:38 <BlueMatt> topic 2: <BlueMatt> #12934
5742018-05-03T19:38:40 <gribble> https://github.com/bitcoin/bitcoin/issues/12934 | [WIP] [net] [validation] Call ProcessNewBlock() asynchronously by skeees · Pull Request #12934 · bitcoin/bitcoin · GitHub
5752018-05-03T19:39:23 <BlueMatt> its certainly not ready for review, but we should maybe have a discussion about what concurrency across peers is gonna look like
5762018-05-03T19:39:24 <wumpus> #topic Call ProcessNewBlock() asynchronously (skeees)
5772018-05-03T19:39:40 <BlueMatt> there are two main approaches, but both end up requiring similar refactors for the majority of their work
5782018-05-03T19:39:51 <BlueMatt> in the past I've looked at doing ProcessMessages() in parallel
5792018-05-03T19:40:07 <BlueMatt> in this pr skeees moves the validation processing of txn/blocks into a queue and does that in a separate thread
5802018-05-03T19:40:31 <sipa> how does that interact with eg sending a ping after a block, and expecting it to be processed after the pong returns?
5812018-05-03T19:40:34 <BlueMatt> in both cases, we end up building logic to "pause" processing of a peer until whatever message it just generated has been processed
5822018-05-03T19:40:36 <wumpus> that sounds sensible, though I'm really afraid of c++ threading
5832018-05-03T19:40:43 <BlueMatt> sipa: ^
5842018-05-03T19:40:51 <gmaxwell> Seems like it would add more locking overhead.
5852018-05-03T19:40:55 <BlueMatt> (which would also likely be useful for eg ReadBlockFromDisk moving to be more async)
5862018-05-03T19:41:31 <sipa> sound reasonable to me
5872018-05-03T19:41:32 <BlueMatt> and a ton of logic to move CNodeState out of cs_main (likely by creating a CNodeState2 during transision)
5882018-05-03T19:41:43 <BlueMatt> cfields: may have more thoughts
5892018-05-03T19:41:43 <sipa> that sounds even better
5902018-05-03T19:41:48 <skeees> the other side benefit of this approach is that ultimately it may simplify the concurrency model inside validation
5912018-05-03T19:41:53 <sipa> though everything depends on the details...
5922018-05-03T19:42:06 <BlueMatt> gmaxwell: indeed, thats a major difference between the skeees approach and the parallel ProcessMessages approach
5932018-05-03T19:42:09 <skeees> having a single thread processing from an ordered queue would have also solved the concurrency issues discussed before
5942018-05-03T19:42:21 <BlueMatt> ProcessMessages will still do the work on the processing thread, which should have a bit less locking overhead
5952018-05-03T19:42:21 <cfields> BlueMatt: just reading now. at a glance, this approach sounds similar to what I had in mind as well
5962018-05-03T19:42:28 <BlueMatt> but is definitely more complicated than the skeees approach
5972018-05-03T19:42:38 <BlueMatt> which draws a much cleaner boundary between validation and net_processing
5982018-05-03T19:42:41 <gmaxwell> The biggest gain I'm aware of from concurrency is that right now when connecting multiple blocks at a time (due to out of order fetching in IBD) we stop downloading new blocks, ... fixing that would be a big gain; so it might be worth prioritizing improvements that would let that happen.
5992018-05-03T19:42:54 <cfields> BlueMatt: I don't see why they'd be mutually exclusive?
6002018-05-03T19:43:07 <BlueMatt> gmaxwell: that and relaying compact block gettxn during block connection
6012018-05-03T19:43:25 <BlueMatt> which is the one big cheapish win left for block-relay-latency
6022018-05-03T19:43:29 <gmaxwell> (e.g. esp when fetching from slow peers, watching network traffic during IBD is comical... transfering at only a couple mbps for a while then nothing for seconds at a time while it connects)
6032018-05-03T19:43:34 <BlueMatt> cfields: well doing both is maybe not so useful
6042018-05-03T19:43:54 <BlueMatt> since they'd accomplish largely the same thing
6052018-05-03T19:44:11 *** leval2 has quit IRC
6062018-05-03T19:44:13 <gmaxwell> BlueMatt: Fair enough for gettxn, though right now my own node makes almost no gettxn requests... and orphaning rates appear to be exceptionally low.
6072018-05-03T19:44:30 <gmaxwell> (so what I'm saying is that at the moment I don't think of latency improvements as that critical)
6082018-05-03T19:44:33 <BlueMatt> gmaxwell: the skeees approach is certainly better for doing things like deserialization of blocks coming in from other peers while calling ProcessNewBlock/ActivateBestChain
6092018-05-03T19:44:52 <BlueMatt> indeed, right now (with mempool ~empty) compact block performance is ~perfect
6102018-05-03T19:44:55 <BlueMatt> its not always so, however
6112018-05-03T19:45:16 <gmaxwell> hm. interesting point that making deserialization concurrent would potentially be a multi-core gain.
6122018-05-03T19:45:17 <BlueMatt> also, fibre nodes see more getblocktxn than miners
6132018-05-03T19:45:17 <sipa> by "mempool ~empty" you mean "mempool is a perfect match" ?
6142018-05-03T19:45:33 <BlueMatt> which would be equally solved by miners delaying 1 second before including new txn in blocks....
6152018-05-03T19:45:54 <gmaxwell> sipa: if each block mostly clears the mempool, miner-specific prioritizaition of transactions doesn't cause as much surprise txn.
6162018-05-03T19:46:13 <gmaxwell> BlueMatt: and also making use of the CB facility for transmitting extra txn proactively.
6172018-05-03T19:46:24 <BlueMatt> yea, that too
6182018-05-03T19:46:52 <BlueMatt> anyway, so tl;dr: I was a bigger fan of the skeees approach and wanted a little bit of concept discussion on the idea of putting a queue in front of the entire validation stuff
6192018-05-03T19:46:59 <BlueMatt> since thats a huge departure from current operation
6202018-05-03T19:47:10 <BlueMatt> but I think the potential gain is nice
6212018-05-03T19:47:17 <BlueMatt> plus all our blocks are already passed in as shared_ptrs anyway.....
6222018-05-03T19:47:21 <gmaxwell> so right my point was that speading up IBD is probably a big win, .. improving latency and what not would be nice too but I think it's less important.
6232018-05-03T19:47:42 <LukeJr> +1
6242018-05-03T19:47:43 <BlueMatt> yes, right now that is definitely true
6252018-05-03T19:47:51 <BlueMatt> certainly this has the potential to address both, however
6262018-05-03T19:47:56 <gmaxwell> making use of more cores during sync would be nice too, e.g. if deserilization and hashing can happen on seperate threads async with connection.
6272018-05-03T19:48:13 <BlueMatt> we can do CheckBlock on the net_processing thread
6282018-05-03T19:48:27 <BlueMatt> (since, and sipa is gonna die a little bit inside, here, the result is cached in the CBlock structure)
6292018-05-03T19:48:44 <sdaftuar> that is kinda gross :)
6302018-05-03T19:48:52 <BlueMatt> its incredibly gross
6312018-05-03T19:48:59 <gmaxwell> (e.g. multiple message handling threads, which do deserialization and maybe stateless checks)
6322018-05-03T19:49:21 <wumpus> oh no...
6332018-05-03T19:49:24 <bitcoin-git> [bitcoin] practicalswift opened pull request #13163: Make it clear which functions that are intended to be translation unit local (master...internal-linkage) https://github.com/bitcoin/bitcoin/pull/13163
6342018-05-03T19:49:51 <gmaxwell> though I did a dumb hack a while back that reordered some of the block validation steps to interleave checks that operate per transaction and got a few percent sync speed improvement... we should be mindful of memory locality and not introduce even more passes over blocks.
6352018-05-03T19:50:05 <BlueMatt> gmaxwell: dunno about multiple message handling threads being doable in the immediate future, but doing CheckBlock on the message processing thread (which does merkle root verification, which is a good chunk of the work) may be worth a chunk
6362018-05-03T19:50:27 <skeees> cool - so if no strong objections or concerns with the approach i'll continue this and come back when its more ready for review
6372018-05-03T19:51:07 <gmaxwell> Funny, I would have thought handling seperate peers in seperate threads would almost just work now, vs stuff that handled messages from the same peer concurrently, which violates protocol assumptions about ordering without special work to add processing barriers.
6382018-05-03T19:51:25 <BlueMatt> gmaxwell: CNodeState requires cs_main, so....not even close :(
6392018-05-03T19:51:40 <gmaxwell> (almost just work, because the critical data structues have locks ... oh CNodeState)
6402018-05-03T19:51:45 <BlueMatt> I've got some old branches that do that, if you want to look
6412018-05-03T19:51:47 <gmaxwell> cs_main lite.
6422018-05-03T19:51:50 <BlueMatt> but they're....not small changes
6432018-05-03T19:52:03 <BlueMatt> and cfields hates them, though he's probably right
6442018-05-03T19:52:26 <BlueMatt> anyway, so </topic> </meeting> ["DIE", "XML"]?
6452018-05-03T19:52:29 <gmaxwell> in particular our most commons messages are transaction invs and get datas, and those should only need mempool stuff for much of their activity.
6462018-05-03T19:52:36 <gmaxwell> k.
6472018-05-03T19:52:44 <BlueMatt> gmaxwell: yes, I did all that in an old branch
6482018-05-03T19:52:51 <BlueMatt> that in particular is much closer than it used to be
6492018-05-03T19:53:00 <BlueMatt> cause now the HandleGetData stuff cant take cs_main at the top
6502018-05-03T19:53:10 <BlueMatt> IIRC that refactor landed for 0.16
6512018-05-03T19:54:08 <BlueMatt> https://github.com/TheBlueMatt/bitcoin/commits/2017-07-paralell-processmessages-redux
6522018-05-03T19:54:48 *** Victorsueca has quit IRC
6532018-05-03T19:55:13 <gmaxwell> Thanks.
6542018-05-03T19:55:44 <BlueMatt> (it got a bunch of time in helgrind, too, and got all the issues fixed, so I'm at least kinda confident in it, but its essentially unreviewable, even by my standards)
6552018-05-03T19:56:08 *** Victorsueca has joined #bitcoin-core-dev
6562018-05-03T19:56:24 *** moneyball has quit IRC
6572018-05-03T19:57:40 <wumpus> #endmeeting
6582018-05-03T19:57:40 <lightningbot> Meeting ended Thu May 3 19:57:40 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
6592018-05-03T19:57:40 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-03-19.00.html
6602018-05-03T19:57:40 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-03-19.00.txt
6612018-05-03T19:57:40 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-03-19.00.log.html
6622018-05-03T19:57:44 <gmaxwell> I think it would be simpler now, a lot of changes in the last year would have made it easier (I say this without having recently looked at that branch)
6632018-05-03T19:57:51 *** aknb has quit IRC
6642018-05-03T19:58:22 <BlueMatt> yes, I agree
6652018-05-03T19:58:26 <BlueMatt> rather significantly
6662018-05-03T19:58:58 <BlueMatt> and if we took the "split CNodeState" approach instead of "pull CNodeState above cs_main in global lock order and give it its own lock all in one go" approach that that branch takes, it'd likely be wayyy simpler
6672018-05-03T20:00:08 *** LukeJr has quit IRC
6682018-05-03T20:08:37 *** laurentmt has joined #bitcoin-core-dev
6692018-05-03T20:12:16 <bitcoin-git> [bitcoin] laanwj deleted 0.9 at 460ccfb: https://github.com/bitcoin/bitcoin/commit/460ccfb
6702018-05-03T20:12:34 <bitcoin-git> [bitcoin] laanwj deleted 0.10 at 9cea169: https://github.com/bitcoin/bitcoin/commit/9cea169
6712018-05-03T20:12:45 <wumpus> :x
6722018-05-03T20:12:59 <sdaftuar> neat
6732018-05-03T20:23:15 *** jpe_ has joined #bitcoin-core-dev
6742018-05-03T20:23:41 *** Krellan has joined #bitcoin-core-dev
6752018-05-03T20:28:41 *** belcher has quit IRC
6762018-05-03T20:29:06 *** promag has quit IRC
6772018-05-03T20:30:22 *** Randolf has joined #bitcoin-core-dev
6782018-05-03T20:34:53 *** jpe__ has joined #bitcoin-core-dev
6792018-05-03T20:37:31 *** jpe_ has quit IRC
6802018-05-03T20:39:29 *** Randolf has quit IRC
6812018-05-03T20:48:18 *** belcher has joined #bitcoin-core-dev
6822018-05-03T20:50:01 *** timothy has joined #bitcoin-core-dev
6832018-05-03T20:51:17 *** ExtraCrispy has quit IRC
6842018-05-03T21:02:09 *** jpe__ has quit IRC
6852018-05-03T21:20:42 <bitcoin-git> [bitcoin] jamesob closed pull request #13099: Use thread names in logs and deadlock diagnostics (master...2018-04-26-use-threadnames) https://github.com/bitcoin/bitcoin/pull/13099
6862018-05-03T21:23:00 <cfields> jamesob: noo!
6872018-05-03T21:23:27 *** Chris_Stewart_5 has quit IRC
6882018-05-03T21:25:28 <cfields> jamesob: I hope you don't think I'm being NIH about that PR, that wasn't my intention at all. Coding up an alternative myself helps me to understand the challenges better, it wasn't meant to replace your work.
6892018-05-03T21:26:01 *** Randolf has joined #bitcoin-core-dev
6902018-05-03T21:51:36 *** promag has joined #bitcoin-core-dev
6912018-05-03T22:00:27 *** Krellan has quit IRC
6922018-05-03T22:13:25 *** laurentmt has quit IRC
6932018-05-03T22:13:32 *** Guyver2 has quit IRC
6942018-05-03T22:16:53 *** spinza has quit IRC
6952018-05-03T22:20:22 <wumpus> "Note: GitHub Services are being deprecated. Please contact your integrator for more information on how to migrate or replace a service to webhooks or GitHub Apps. "
6962018-05-03T22:20:43 <wumpus> I wonder if that means the IRC notification bot will disappear
6972018-05-03T22:21:42 <luke-jr> isn't it a webhook?
6982018-05-03T22:22:46 <wumpus> no
6992018-05-03T22:23:04 <wumpus> it's under "integrations and services" which displays that
7002018-05-03T22:27:04 *** Krellan has joined #bitcoin-core-dev
7012018-05-03T22:28:38 *** spinza has joined #bitcoin-core-dev
7022018-05-03T22:32:33 *** lnostdal has quit IRC
7032018-05-03T22:35:43 *** tryphe has quit IRC
7042018-05-03T22:36:13 *** tryphe has joined #bitcoin-core-dev
7052018-05-03T22:42:11 *** Krellan has quit IRC
7062018-05-03T22:42:44 *** lnostdal has joined #bitcoin-core-dev
7072018-05-03T22:43:47 <luke-jr> IRC notifications of projects seems to have mostly died with CIA :<
7082018-05-03T22:46:25 *** Krellan has joined #bitcoin-core-dev
7092018-05-03T22:52:55 *** Krellan has quit IRC
7102018-05-03T22:57:15 *** jonhya has joined #bitcoin-core-dev
7112018-05-03T22:57:24 *** promag has quit IRC
7122018-05-03T23:00:15 *** jonhya has quit IRC
7132018-05-03T23:12:21 *** lnostdal has quit IRC
7142018-05-03T23:13:13 *** lnostdal has joined #bitcoin-core-dev
7152018-05-03T23:17:45 *** larafale has quit IRC
7162018-05-03T23:20:46 *** lnostdal has quit IRC
7172018-05-03T23:26:18 *** clarkmoody has quit IRC
7182018-05-03T23:27:28 *** drexl has quit IRC
7192018-05-03T23:29:51 *** grafcaps has quit IRC
7202018-05-03T23:31:34 *** lnostdal has joined #bitcoin-core-dev
7212018-05-03T23:39:10 <jamesob> cfields: oh no not at all! sorry if the PR close came off as me being upset
7222018-05-03T23:40:14 <jamesob> cfields: I just like your commits better :). Maybe I can cherry-pick them and then shuffle in my GetProcessName/SetProcessName stuff + some tests
7232018-05-03T23:40:50 <jamesob> if that sounds good, would it make sense to repurpose that same PR or open a new one?
7242018-05-03T23:43:53 *** grafcaps has joined #bitcoin-core-dev
7252018-05-03T23:44:33 <cfields> jamesob: ok, good
7262018-05-03T23:45:14 <cfields> jamesob: if you're going to do away with the suffix handling, I'd say just do a new PR
7272018-05-03T23:45:50 <cfields> jamesob: either way, my code is all yours if you like it
7282018-05-03T23:48:21 *** Emcy has quit IRC
7292018-05-03T23:53:30 <jamesob> cfields: yeah, should be easy to incorporate the suffix stuff inline as you suggest
7302018-05-03T23:57:10 <jamesob> just felt embarrassed I didn't see that earlier :)