12020-04-16T00:00:01 *** Frost1 has quit IRC
22020-04-16T00:12:18 *** mol_ has quit IRC
32020-04-16T00:13:05 *** mol has joined #bitcoin-core-dev
42020-04-16T00:18:29 *** AaronvanW has quit IRC
52020-04-16T00:21:49 *** jscarmona1 has joined #bitcoin-core-dev
62020-04-16T00:40:02 *** bitcoin-git has joined #bitcoin-core-dev
72020-04-16T00:40:03 <bitcoin-git> [bitcoin] saahilshangle opened pull request #18663: doc: Adding hyperlink to INSTALL.md in README.md (master...readme-build-instructions) https://github.com/bitcoin/bitcoin/pull/18663
82020-04-16T00:40:03 *** bitcoin-git has left #bitcoin-core-dev
92020-04-16T00:53:07 *** promag__ has quit IRC
102020-04-16T00:53:35 *** promag has quit IRC
112020-04-16T00:54:29 *** bitdex has joined #bitcoin-core-dev
122020-04-16T01:03:26 *** infernix has joined #bitcoin-core-dev
132020-04-16T01:08:34 *** DeanWeen has quit IRC
142020-04-16T01:14:46 *** DeanWeen has joined #bitcoin-core-dev
152020-04-16T01:16:28 *** Chris_Stewart_5 has quit IRC
162020-04-16T01:18:28 *** Chris_Stewart_5 has joined #bitcoin-core-dev
172020-04-16T01:20:12 *** AaronvanW has joined #bitcoin-core-dev
182020-04-16T01:27:44 *** promag has joined #bitcoin-core-dev
192020-04-16T01:32:37 *** mol_ has joined #bitcoin-core-dev
202020-04-16T01:32:44 *** promag has quit IRC
212020-04-16T01:33:31 *** lightlike has quit IRC
222020-04-16T01:33:43 *** mol has quit IRC
232020-04-16T01:46:03 *** unruly247 has joined #bitcoin-core-dev
242020-04-16T01:54:12 *** AaronvanW has quit IRC
252020-04-16T01:57:34 *** Highway61 has quit IRC
262020-04-16T02:03:36 *** captjakk has quit IRC
272020-04-16T02:08:03 *** bitdex has quit IRC
282020-04-16T02:08:10 *** captjakk has joined #bitcoin-core-dev
292020-04-16T02:08:12 *** captjakk has quit IRC
302020-04-16T02:08:24 *** captjakk has joined #bitcoin-core-dev
312020-04-16T02:08:28 *** bitdex has joined #bitcoin-core-dev
322020-04-16T02:16:23 *** owowo has quit IRC
332020-04-16T02:20:54 *** Deacyde has joined #bitcoin-core-dev
342020-04-16T02:21:12 *** owowo has joined #bitcoin-core-dev
352020-04-16T02:27:56 *** unruly247 has quit IRC
362020-04-16T02:29:44 *** unruly247 has joined #bitcoin-core-dev
372020-04-16T02:53:00 <meshcollider> So #18572 and #18550 are talking about being included in 0.20, but they're obviously not in rc1, so what exactly is happening there?
382020-04-16T02:53:02 <gribble> https://github.com/bitcoin/bitcoin/issues/18572 | Wallet: Accept "changedata" db key as an alias to "destdata" by luke-jr · Pull Request #18572 · bitcoin/bitcoin · GitHub
392020-04-16T02:53:03 <gribble> https://github.com/bitcoin/bitcoin/issues/18550 | Store destdata for change in separate key for backward compatibility by luke-jr · Pull Request #18550 · bitcoin/bitcoin · GitHub
402020-04-16T03:00:02 *** jscarmona1 has quit IRC
412020-04-16T03:14:13 *** go1111111 has quit IRC
422020-04-16T03:22:01 *** frank001 has joined #bitcoin-core-dev
432020-04-16T03:22:04 *** Eagle[TM] has joined #bitcoin-core-dev
442020-04-16T03:24:21 *** EagleTM has quit IRC
452020-04-16T03:36:11 *** BlueMatt has quit IRC
462020-04-16T03:36:29 *** BlueMatt has joined #bitcoin-core-dev
472020-04-16T03:37:26 *** BlueMatt has quit IRC
482020-04-16T03:37:44 *** BlueMatt has joined #bitcoin-core-dev
492020-04-16T03:39:14 *** promag has joined #bitcoin-core-dev
502020-04-16T03:43:55 *** promag has quit IRC
512020-04-16T03:50:45 *** AaronvanW has joined #bitcoin-core-dev
522020-04-16T03:58:05 *** Chris_Stewart_5 has quit IRC
532020-04-16T04:24:02 *** AaronvanW has quit IRC
542020-04-16T04:29:37 *** jarthur_ has joined #bitcoin-core-dev
552020-04-16T04:33:12 *** jarthur has quit IRC
562020-04-16T04:49:58 *** Talkless has joined #bitcoin-core-dev
572020-04-16T04:50:43 *** Talkless has quit IRC
582020-04-16T05:08:05 *** robot-visions has joined #bitcoin-core-dev
592020-04-16T05:14:22 *** jorijn has quit IRC
602020-04-16T05:15:02 *** robot-visions has quit IRC
612020-04-16T05:15:07 *** jorijn has joined #bitcoin-core-dev
622020-04-16T05:29:59 *** MarcoFalke has quit IRC
632020-04-16T05:30:18 *** MarcoFalke has joined #bitcoin-core-dev
642020-04-16T05:38:56 *** captjakk has quit IRC
652020-04-16T05:39:30 *** captjakk has joined #bitcoin-core-dev
662020-04-16T05:43:53 *** captjakk has quit IRC
672020-04-16T05:48:51 *** vincenzopalazzo has quit IRC
682020-04-16T06:00:02 *** frank001 has quit IRC
692020-04-16T06:04:48 *** niska has quit IRC
702020-04-16T06:12:06 *** niska has joined #bitcoin-core-dev
712020-04-16T06:19:29 *** captjakk has joined #bitcoin-core-dev
722020-04-16T06:21:10 *** nighmi has joined #bitcoin-core-dev
732020-04-16T06:21:33 *** AaronvanW has joined #bitcoin-core-dev
742020-04-16T06:21:34 *** nighmi is now known as Guest89944
752020-04-16T06:24:27 *** captjakk has quit IRC
762020-04-16T06:24:28 *** DeanWeen has quit IRC
772020-04-16T06:24:55 *** DeanWeen has joined #bitcoin-core-dev
782020-04-16T06:29:52 *** amsudeep has joined #bitcoin-core-dev
792020-04-16T06:36:34 *** gwillen has quit IRC
802020-04-16T06:37:44 *** gwillen has joined #bitcoin-core-dev
812020-04-16T06:49:53 *** Guyver2 has joined #bitcoin-core-dev
822020-04-16T06:54:02 *** AaronvanW has quit IRC
832020-04-16T07:00:53 *** promag has joined #bitcoin-core-dev
842020-04-16T07:10:23 *** captjakk has joined #bitcoin-core-dev
852020-04-16T07:15:26 *** captjakk has quit IRC
862020-04-16T07:21:16 *** AaronvanW has joined #bitcoin-core-dev
872020-04-16T07:44:43 *** vasild has quit IRC
882020-04-16T07:46:14 *** vasild has joined #bitcoin-core-dev
892020-04-16T07:46:43 <ryanofsky> meshcollider: i think both prs should be dropped, but first pr is basically harmless, only second pr has bad side effects
902020-04-16T07:56:29 *** AaronvanW has quit IRC
912020-04-16T07:56:45 *** AaronvanW has joined #bitcoin-core-dev
922020-04-16T08:04:48 *** promag has quit IRC
932020-04-16T08:07:38 *** brakmic has joined #bitcoin-core-dev
942020-04-16T08:11:56 *** brakmic has quit IRC
952020-04-16T08:12:34 *** brakmic has joined #bitcoin-core-dev
962020-04-16T08:14:00 *** brakmic_ has joined #bitcoin-core-dev
972020-04-16T08:17:16 *** brakmic has quit IRC
982020-04-16T08:20:47 *** marcoagner has joined #bitcoin-core-dev
992020-04-16T08:28:50 *** Kiminuo has quit IRC
1002020-04-16T08:37:19 *** emilengler has joined #bitcoin-core-dev
1012020-04-16T08:43:04 *** promag has joined #bitcoin-core-dev
1022020-04-16T08:43:08 *** promag_ has joined #bitcoin-core-dev
1032020-04-16T09:00:02 *** Guest89944 has quit IRC
1042020-04-16T09:00:59 *** Eagle[TM] has quit IRC
1052020-04-16T09:07:03 *** jonatack has quit IRC
1062020-04-16T09:09:09 *** jonatack has joined #bitcoin-core-dev
1072020-04-16T09:11:17 *** captjakk has joined #bitcoin-core-dev
1082020-04-16T09:16:17 *** captjakk has quit IRC
1092020-04-16T09:22:03 *** Mikaku1 has joined #bitcoin-core-dev
1102020-04-16T09:26:50 *** timothy has joined #bitcoin-core-dev
1112020-04-16T09:34:11 *** murray_ has joined #bitcoin-core-dev
1122020-04-16T09:34:21 *** murrayn has quit IRC
1132020-04-16T09:34:55 *** murray_ has left #bitcoin-core-dev
1142020-04-16T09:35:57 *** murrayn has joined #bitcoin-core-dev
1152020-04-16T09:44:25 <wumpus> meshcollider: the logic is like: *IF* we need a rc2, might as well include them, I think
1162020-04-16T09:44:34 <wumpus> I don't think they necessiate a rc2 by themselves
1172020-04-16T09:45:01 <wumpus> but generally for major releases we have around 4-5 rcs so ok
1182020-04-16T09:45:03 *** brakmic_ has quit IRC
1192020-04-16T09:45:24 *** brakmic has joined #bitcoin-core-dev
1202020-04-16T09:46:36 <wumpus> but we could remove the milestone from it if people prefer that (especially if they have bad side effects), or generally if they don't get enough ACKs
1212020-04-16T09:54:13 *** jonatack has quit IRC
1222020-04-16T09:55:06 *** jonatack has joined #bitcoin-core-dev
1232020-04-16T09:55:32 *** jonatack has joined #bitcoin-core-dev
1242020-04-16T09:59:06 *** justanotheruser has quit IRC
1252020-04-16T10:04:01 *** Celine59Mann has joined #bitcoin-core-dev
1262020-04-16T10:09:05 *** promag__ has joined #bitcoin-core-dev
1272020-04-16T10:09:11 *** promag_ has quit IRC
1282020-04-16T10:11:03 *** vasild has quit IRC
1292020-04-16T10:16:29 *** vasild has joined #bitcoin-core-dev
1302020-04-16T10:17:46 *** pinheadmz_ has joined #bitcoin-core-dev
1312020-04-16T10:18:48 <meshcollider> I don't think they've even got the milestone, it was just mentioned in the OP
1322020-04-16T10:19:28 <meshcollider> First PR is harmless but also pointless
1332020-04-16T10:20:34 *** pinheadmz has quit IRC
1342020-04-16T10:20:34 *** pinheadmz_ is now known as pinheadmz
1352020-04-16T10:23:23 <jonatack> meshcollider: fwiw #17824 has acks by kallewoof and myself and review by instagibbs and achow101
1362020-04-16T10:23:26 <gribble> https://github.com/bitcoin/bitcoin/issues/17824 | wallet: Prefer full destination groups in coin selection by fjahr · Pull Request #17824 · bitcoin/bitcoin · GitHub
1372020-04-16T10:23:52 <jonatack> it's a bugfix for #17603
1382020-04-16T10:23:53 <gribble> https://github.com/bitcoin/bitcoin/issues/17603 | partial spend avoidance makes partial spends and getbalances doesnt notice · Issue #17603 · bitcoin/bitcoin · GitHub
1392020-04-16T10:25:55 *** Celine59Mann has quit IRC
1402020-04-16T10:26:25 <meshcollider> jonatack: cool thanks, I'll look at it first thing tomorrow morning, it's getting late here :)
1412020-04-16T10:27:33 <jonatack> meshcollider: ð
1422020-04-16T10:29:15 <meshcollider> ryanofsky: After reading through your comments, I agree with you, I'll close both the PRs
1432020-04-16T10:29:48 <meshcollider> If Luke has a strong argument that we are missing, we can discuss in the meeting tomorrow
1442020-04-16T10:31:39 *** bitcoin-git has joined #bitcoin-core-dev
1452020-04-16T10:31:39 <bitcoin-git> [bitcoin] meshcollider closed pull request #18550: Store destdata for change in separate key for backward compatibility (master...changedata) https://github.com/bitcoin/bitcoin/pull/18550
1462020-04-16T10:31:40 *** bitcoin-git has left #bitcoin-core-dev
1472020-04-16T10:32:54 *** bitcoin-git has joined #bitcoin-core-dev
1482020-04-16T10:32:54 <bitcoin-git> [bitcoin] meshcollider closed pull request #18572: Wallet: Accept "changedata" db key as an alias to "destdata" (master...changedata_forwardcompat) https://github.com/bitcoin/bitcoin/pull/18572
1492020-04-16T10:32:55 *** bitcoin-git has left #bitcoin-core-dev
1502020-04-16T10:34:33 <jonatack> Next wallet meeting is April 24 (in 8 days) if not mistaken
1512020-04-16T10:35:03 <jonatack> (we did one last week)
1522020-04-16T10:36:47 <aj> on this side of the world, regular meeting is tomorrow
1532020-04-16T10:47:05 <fanquake> aj: tossing a coin on attendance
1542020-04-16T10:57:01 <meshcollider> Yeah sorry I mean the regular meeting which is "today"
1552020-04-16T11:13:34 *** IGHOR has quit IRC
1562020-04-16T11:26:40 *** DeanWeen has quit IRC
1572020-04-16T11:28:03 *** DeanWeen has joined #bitcoin-core-dev
1582020-04-16T11:28:52 *** bitcoin-git has joined #bitcoin-core-dev
1592020-04-16T11:28:53 <bitcoin-git> [bitcoin] jonatack opened pull request #18664: fuzz: fix unused variable compiler warning (master...fix-unused-variable-warning) https://github.com/bitcoin/bitcoin/pull/18664
1602020-04-16T11:28:53 *** bitcoin-git has left #bitcoin-core-dev
1612020-04-16T11:29:32 *** timothy has quit IRC
1622020-04-16T11:35:17 *** amsudeep has quit IRC
1632020-04-16T11:35:35 *** amsudeep has joined #bitcoin-core-dev
1642020-04-16T11:42:14 *** mytwocentimes has quit IRC
1652020-04-16T11:42:57 *** mytwocentimes has joined #bitcoin-core-dev
1662020-04-16T11:43:01 *** jonatack has quit IRC
1672020-04-16T11:47:24 *** captjakk has joined #bitcoin-core-dev
1682020-04-16T11:47:41 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1692020-04-16T11:51:35 *** mol_ has quit IRC
1702020-04-16T11:52:23 *** captjakk has quit IRC
1712020-04-16T11:55:02 *** Kiminuo has joined #bitcoin-core-dev
1722020-04-16T11:56:39 *** jonatack has joined #bitcoin-core-dev
1732020-04-16T11:58:08 *** mol has joined #bitcoin-core-dev
1742020-04-16T12:00:02 *** Mikaku1 has quit IRC
1752020-04-16T12:22:15 *** Dantman has joined #bitcoin-core-dev
1762020-04-16T12:31:12 *** Highway61 has joined #bitcoin-core-dev
1772020-04-16T12:33:06 *** bitcoin-git has joined #bitcoin-core-dev
1782020-04-16T12:33:06 <bitcoin-git> [bitcoin] hebasto opened pull request #18665: Do not expose -logthreadnames when it does not work (master...200416-logthreads) https://github.com/bitcoin/bitcoin/pull/18665
1792020-04-16T12:33:07 *** bitcoin-git has left #bitcoin-core-dev
1802020-04-16T12:33:50 *** mytwocentimes has quit IRC
1812020-04-16T12:34:05 *** mytwocentimes has joined #bitcoin-core-dev
1822020-04-16T12:44:48 *** fengling has quit IRC
1832020-04-16T12:54:05 *** bitcoin-git has joined #bitcoin-core-dev
1842020-04-16T12:54:05 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/544709763e1f...e16718a8b3db
1852020-04-16T12:54:06 <bitcoin-git> bitcoin/master f63dec1 Pieter Wuille: [REFACTOR] Initialize PrecomputedTransactionData in CheckInputScripts
1862020-04-16T12:54:06 <bitcoin-git> bitcoin/master e16718a MarcoFalke: Merge #18401: Refactor: Initialize PrecomputedTransactionData in CheckInpu...
1872020-04-16T12:54:07 *** bitcoin-git has left #bitcoin-core-dev
1882020-04-16T12:54:30 *** bitcoin-git has joined #bitcoin-core-dev
1892020-04-16T12:54:30 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18401: Refactor: Initialize PrecomputedTransactionData in CheckInputScripts (master...2020-03-precomputedtransactiondata) https://github.com/bitcoin/bitcoin/pull/18401
1902020-04-16T12:54:33 *** bitcoin-git has left #bitcoin-core-dev
1912020-04-16T13:30:58 *** timothy has joined #bitcoin-core-dev
1922020-04-16T13:48:16 *** captjakk has joined #bitcoin-core-dev
1932020-04-16T13:52:44 *** captjakk has quit IRC
1942020-04-16T14:01:30 *** bitcoin-git has joined #bitcoin-core-dev
1952020-04-16T14:01:30 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e16718a8b3db...79b0459648e3
1962020-04-16T14:01:31 <bitcoin-git> bitcoin/master a95af77 practicalswift: qt: Make bitcoin.ico non-executable
1972020-04-16T14:01:31 <bitcoin-git> bitcoin/master 79b0459 MarcoFalke: Merge #18650: qt: Make bitcoin.ico non-executable
1982020-04-16T14:01:33 *** bitcoin-git has left #bitcoin-core-dev
1992020-04-16T14:01:50 *** bitcoin-git has joined #bitcoin-core-dev
2002020-04-16T14:01:50 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18650: qt: Make bitcoin.ico non-executable (master...bitcoin.ico-executable-flag) https://github.com/bitcoin/bitcoin/pull/18650
2012020-04-16T14:01:51 *** bitcoin-git has left #bitcoin-core-dev
2022020-04-16T14:08:02 *** IGHOR has joined #bitcoin-core-dev
2032020-04-16T14:11:03 *** bitcoin-git has joined #bitcoin-core-dev
2042020-04-16T14:11:03 <bitcoin-git> [bitcoin] hebasto opened pull request #18667: ci: Limit cache size regardless of NO_DEPENDS (master...200416-ci-cache) https://github.com/bitcoin/bitcoin/pull/18667
2052020-04-16T14:11:04 *** bitcoin-git has left #bitcoin-core-dev
2062020-04-16T14:11:39 *** kristapsk has quit IRC
2072020-04-16T14:12:04 *** kristapsk has joined #bitcoin-core-dev
2082020-04-16T14:13:24 *** bitcoin-git has joined #bitcoin-core-dev
2092020-04-16T14:13:24 <bitcoin-git> [bitcoin] MarcoFalke pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/79b0459648e3...661e8df1b63b
2102020-04-16T14:13:25 <bitcoin-git> bitcoin/master 727b67e Jon Atack: test: add coverage for bitcoin-cli -rpcwait
2112020-04-16T14:13:26 <bitcoin-git> bitcoin/master becc8b9 Jon Atack: test: verify bitcoin-cli -version with node stopped
2122020-04-16T14:13:27 <bitcoin-git> bitcoin/master bb13f46 Jon Atack: test: verify cli.getwalletinfo in wallet section
2132020-04-16T14:13:36 *** bitcoin-git has left #bitcoin-core-dev
2142020-04-16T14:13:53 *** bitcoin-git has joined #bitcoin-core-dev
2152020-04-16T14:13:54 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18653: test: add coverage for bitcoin-cli -rpcwait (master...rpcwait-test-coverage) https://github.com/bitcoin/bitcoin/pull/18653
2162020-04-16T14:13:54 *** bitcoin-git has left #bitcoin-core-dev
2172020-04-16T14:14:16 *** fibo has joined #bitcoin-core-dev
2182020-04-16T14:14:35 *** fibo has quit IRC
2192020-04-16T14:15:01 *** fizo has joined #bitcoin-core-dev
2202020-04-16T14:28:36 *** fizo has quit IRC
2212020-04-16T14:39:36 *** theStack has joined #bitcoin-core-dev
2222020-04-16T14:40:46 *** dviola has quit IRC
2232020-04-16T14:56:36 *** Talkless has joined #bitcoin-core-dev
2242020-04-16T15:00:01 *** Dantman has quit IRC
2252020-04-16T15:02:20 *** TheRec_ has quit IRC
2262020-04-16T15:08:49 *** per is now known as wsm
2272020-04-16T15:14:27 *** bitcoin-git has joined #bitcoin-core-dev
2282020-04-16T15:14:27 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #18669: log: Use Join() helper when listing log categories (master...2004-logJoin) https://github.com/bitcoin/bitcoin/pull/18669
2292020-04-16T15:14:29 *** bitcoin-git has left #bitcoin-core-dev
2302020-04-16T15:15:33 *** captjakk has joined #bitcoin-core-dev
2312020-04-16T15:20:15 *** bitcoin-git has joined #bitcoin-core-dev
2322020-04-16T15:20:15 <bitcoin-git> [bitcoin] theStack opened pull request #18670: refactor: Remove unused method CBloomFilter::reset() (master...20200416-refactor-remove-unused-bloom-filter-reset) https://github.com/bitcoin/bitcoin/pull/18670
2332020-04-16T15:20:16 *** bitcoin-git has left #bitcoin-core-dev
2342020-04-16T15:20:41 *** kik1 has joined #bitcoin-core-dev
2352020-04-16T15:30:33 <theStack> i have a linking problem on the fuzz test http_request:
2362020-04-16T15:30:35 <theStack> /home/honeybadger/buidl/bitcoin_fuzz/src/test/fuzz/http_request.cpp:34: undefined reference to `evhttp_parse_firstline_'
2372020-04-16T15:31:10 <theStack> i found out though that i have libevent version 2.0.21, but the minimum required version is 2.0.22 (according to doc/dependencies.md)
2382020-04-16T15:31:24 <theStack> shouldn't the build process check for all minimum required versions?
2392020-04-16T15:32:06 <theStack> (without fuzzing enabled, everything compiles fine on master branch)
2402020-04-16T15:33:06 *** jarthur has joined #bitcoin-core-dev
2412020-04-16T15:43:34 *** unruly247 has quit IRC
2422020-04-16T15:44:31 *** unruly247 has joined #bitcoin-core-dev
2432020-04-16T15:45:41 *** unruly247 has quit IRC
2442020-04-16T15:46:10 *** bitcoin-git has joined #bitcoin-core-dev
2452020-04-16T15:46:11 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/661e8df1b63b...f4c0ad4aefe0
2462020-04-16T15:46:11 <bitcoin-git> bitcoin/master 9986608 Russell Yanofsky: test: Verify findCommonAncestor always initializes outputs
2472020-04-16T15:46:12 <bitcoin-git> bitcoin/master f4c0ad4 MarcoFalke: Merge #18660: test: Verify findCommonAncestor always initializes outputs
2482020-04-16T15:46:14 *** bitcoin-git has left #bitcoin-core-dev
2492020-04-16T15:46:20 *** unruly247 has joined #bitcoin-core-dev
2502020-04-16T15:46:31 *** bitcoin-git has joined #bitcoin-core-dev
2512020-04-16T15:46:31 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18660: test: Verify findCommonAncestor always initializes outputs (master...pr/commoninit) https://github.com/bitcoin/bitcoin/pull/18660
2522020-04-16T15:46:32 *** bitcoin-git has left #bitcoin-core-dev
2532020-04-16T15:46:54 *** unruly247 has quit IRC
2542020-04-16T15:49:34 *** unruly247 has joined #bitcoin-core-dev
2552020-04-16T15:52:56 *** TheRec has joined #bitcoin-core-dev
2562020-04-16T15:52:56 *** TheRec has joined #bitcoin-core-dev
2572020-04-16T15:54:12 *** andrewtoth has quit IRC
2582020-04-16T15:54:26 *** andrewtoth has joined #bitcoin-core-dev
2592020-04-16T15:56:59 *** captjakk has quit IRC
2602020-04-16T15:57:15 *** captjakk has joined #bitcoin-core-dev
2612020-04-16T16:01:08 *** Emcy has quit IRC
2622020-04-16T16:01:50 *** Emcy has joined #bitcoin-core-dev
2632020-04-16T16:03:37 *** bitcoin-git has joined #bitcoin-core-dev
2642020-04-16T16:03:37 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #18671: wallet: Add BlockUntilSyncedToCurrentChain to dumpwallet (master...2004-walletDumpChain) https://github.com/bitcoin/bitcoin/pull/18671
2652020-04-16T16:03:38 *** bitcoin-git has left #bitcoin-core-dev
2662020-04-16T16:26:30 *** Emcy has quit IRC
2672020-04-16T16:27:04 *** Emcy has joined #bitcoin-core-dev
2682020-04-16T16:29:52 *** mol_ has joined #bitcoin-core-dev
2692020-04-16T16:31:45 *** Emcy has quit IRC
2702020-04-16T16:32:20 *** Emcy has joined #bitcoin-core-dev
2712020-04-16T16:33:20 *** mol has quit IRC
2722020-04-16T16:36:30 *** alko89 has joined #bitcoin-core-dev
2732020-04-16T16:38:13 *** emilengler has quit IRC
2742020-04-16T16:41:14 *** jarthur has quit IRC
2752020-04-16T16:41:42 *** jarthur has joined #bitcoin-core-dev
2762020-04-16T16:42:35 *** andrewtoth has quit IRC
2772020-04-16T16:43:18 *** andrewtoth has joined #bitcoin-core-dev
2782020-04-16T16:43:52 *** emilengler has joined #bitcoin-core-dev
2792020-04-16T16:54:58 *** captjakk has quit IRC
2802020-04-16T16:55:30 *** captjakk has joined #bitcoin-core-dev
2812020-04-16T16:58:51 *** bitcoin-git has joined #bitcoin-core-dev
2822020-04-16T16:58:52 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f4c0ad4aefe0...d8dfcea5d956
2832020-04-16T16:58:52 <bitcoin-git> bitcoin/master bee88b8 James O'Beirne: tests: have coins simulation test also use CCoinsViewDB
2842020-04-16T16:58:53 <bitcoin-git> bitcoin/master d8dfcea MarcoFalke: Merge #17669: tests: have coins simulation test also use CCoinsViewDB
2852020-04-16T16:58:56 *** bitcoin-git has left #bitcoin-core-dev
2862020-04-16T16:59:41 *** bitcoin-git has joined #bitcoin-core-dev
2872020-04-16T16:59:41 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #17669: tests: have coins simulation test also use CCoinsViewDB (master...2019-12-coins-tests) https://github.com/bitcoin/bitcoin/pull/17669
2882020-04-16T16:59:42 *** bitcoin-git has left #bitcoin-core-dev
2892020-04-16T17:00:03 *** captjakk has quit IRC
2902020-04-16T17:07:42 *** bitcoin-git has joined #bitcoin-core-dev
2912020-04-16T17:07:43 <bitcoin-git> [bitcoin] theStack opened pull request #18672: test: add further BIP37 size limit checks to p2p_filter.py (master...20200416-test-add-further-bloom-filter-size-limit-checks) https://github.com/bitcoin/bitcoin/pull/18672
2922020-04-16T17:07:43 *** bitcoin-git has left #bitcoin-core-dev
2932020-04-16T17:09:24 *** molz_ has joined #bitcoin-core-dev
2942020-04-16T17:12:51 *** mol_ has quit IRC
2952020-04-16T17:13:27 *** mol has joined #bitcoin-core-dev
2962020-04-16T17:15:47 *** bitcoin-git has joined #bitcoin-core-dev
2972020-04-16T17:15:47 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #18673: scripted-diff: Sort test includes (master...2004-testSortIncludes) https://github.com/bitcoin/bitcoin/pull/18673
2982020-04-16T17:15:48 *** bitcoin-git has left #bitcoin-core-dev
2992020-04-16T17:16:24 *** molz_ has quit IRC
3002020-04-16T17:36:10 *** Kiminuo has quit IRC
3012020-04-16T17:36:52 *** Kiminuo has joined #bitcoin-core-dev
3022020-04-16T17:37:47 *** mytwocentimes has quit IRC
3032020-04-16T17:39:21 *** mytwocentimes has joined #bitcoin-core-dev
3042020-04-16T17:46:15 *** captjakk has joined #bitcoin-core-dev
3052020-04-16T17:48:17 *** luke-jr has joined #bitcoin-core-dev
3062020-04-16T17:54:44 <MarcoFalke> theStack: Maybe file an issue?
3072020-04-16T18:00:02 *** kik1 has quit IRC
3082020-04-16T18:05:14 *** andrewtoth_ has joined #bitcoin-core-dev
3092020-04-16T18:06:23 *** andrewtoth has quit IRC
3102020-04-16T18:08:42 *** justanotheruser has joined #bitcoin-core-dev
3112020-04-16T18:11:03 *** andrewtoth_ has quit IRC
3122020-04-16T18:14:49 *** berndj has quit IRC
3132020-04-16T18:15:52 *** captjakk has quit IRC
3142020-04-16T18:16:26 *** captjakk has joined #bitcoin-core-dev
3152020-04-16T18:16:46 *** mytwocentimes has quit IRC
3162020-04-16T18:16:59 *** mytwocentimes has joined #bitcoin-core-dev
3172020-04-16T18:21:15 *** captjakk_ has joined #bitcoin-core-dev
3182020-04-16T18:22:15 *** mikeyman77 has joined #bitcoin-core-dev
3192020-04-16T18:22:55 *** captjakk_ has quit IRC
3202020-04-16T18:23:57 *** captjakk_ has joined #bitcoin-core-dev
3212020-04-16T18:23:59 *** captjakk_ has quit IRC
3222020-04-16T18:24:13 *** captjakk_ has joined #bitcoin-core-dev
3232020-04-16T18:25:45 *** berndj has joined #bitcoin-core-dev
3242020-04-16T18:26:02 *** captjakk has quit IRC
3252020-04-16T18:28:18 *** DeanWeen has quit IRC
3262020-04-16T18:30:04 *** mol has quit IRC
3272020-04-16T18:30:26 *** DeanWeen has joined #bitcoin-core-dev
3282020-04-16T18:32:27 *** amsudeep has quit IRC
3292020-04-16T18:33:13 <wumpus> checking the minimum libevent version in configure would make sense
3302020-04-16T18:34:19 <wumpus> the build system has historically not checked minimum versions at all as far as I know, but it'd be a good thing to do, bigger chance that someone will figure out what is the problem in that way than having to check a separate documentation file
3312020-04-16T18:35:05 <wumpus> libevent 2.0.21 is *ancient* though
3322020-04-16T18:35:26 <wumpus> 8 years old now
3332020-04-16T18:35:35 *** berndj has quit IRC
3342020-04-16T18:36:07 <wumpus> things move on and we can't support old software forever, that's just not realistic
3352020-04-16T18:37:40 <luke-jr> the old version isn't what matters for such questions IMO
3362020-04-16T18:37:49 <luke-jr> but rather, how old/widespread is the new minimum?
3372020-04-16T18:37:55 *** mol has joined #bitcoin-core-dev
3382020-04-16T18:38:45 <wumpus> there is no new minimum
3392020-04-16T18:39:05 <wumpus> this is about enforcing the current minimum in configure.ac
3402020-04-16T18:39:46 *** berndj has joined #bitcoin-core-dev
3412020-04-16T18:40:34 *** brakmic has quit IRC
3422020-04-16T18:41:09 <wumpus> which has been 2.0.22 pretty much forever
3432020-04-16T18:41:30 <luke-jr> afaik that's pretty easy
3442020-04-16T18:41:34 <MarcoFalke> I don't understand how Bitcoin Core compiles fine, but the fuzz tests don't
3452020-04-16T18:41:53 *** kvaciral has joined #bitcoin-core-dev
3462020-04-16T18:43:46 <wumpus> I don't, either, but please just use a newer libevent version, many bugs have been fixed since
3472020-04-16T18:55:06 *** captjakk_ has quit IRC
3482020-04-16T18:55:42 *** captjakk has joined #bitcoin-core-dev
3492020-04-16T19:00:17 *** captjakk has quit IRC
3502020-04-16T19:00:35 <MarcoFalke> Yeah, fuzzing old libevent isn't that helpful
3512020-04-16T19:01:41 <meshcollider> Meeting?
3522020-04-16T19:02:25 <luke-jr> (let's get to the wallet issue this time)
3532020-04-16T19:03:39 <achow101> meeting?
3542020-04-16T19:03:58 <wumpus> #startmeeting
3552020-04-16T19:03:58 <lightningbot> Meeting started Thu Apr 16 19:03:58 2020 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3562020-04-16T19:03:58 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3572020-04-16T19:03:59 *** jb55 has quit IRC
3582020-04-16T19:04:01 <jonasschnelli> hi
3592020-04-16T19:04:03 <sipa> hi
3602020-04-16T19:04:06 <achow101> hi
3612020-04-16T19:04:08 <amiti> hi
3622020-04-16T19:04:10 <meshcollider> hi
3632020-04-16T19:04:13 <jonatack> hi
3642020-04-16T19:04:22 <cfields> hi
3652020-04-16T19:04:24 *** jb55 has joined #bitcoin-core-dev
3662020-04-16T19:04:28 <kanzure> hi
3672020-04-16T19:04:34 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james amiti fjahr
3682020-04-16T19:04:36 <wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55
3692020-04-16T19:04:39 <dongcarl> hi
3702020-04-16T19:04:51 <elichai2> Hi
3712020-04-16T19:04:53 <jb55> hi
3722020-04-16T19:05:14 <wumpus> one proposed topic: experimental libmultiprocess, next steps for multiprocess in general (MarcoFalke)
3732020-04-16T19:05:22 <MarcoFalke> hi
3742020-04-16T19:05:30 <luke-jr> wumpus: I proposed one last week.. which really should get addressed before 0.20
3752020-04-16T19:05:40 <phantomcircuit> hi
3762020-04-16T19:05:44 <jkczyz> hi
3772020-04-16T19:05:51 <fjahr> hi
3782020-04-16T19:05:56 <cfields> I know fanquake really wants to be part of the multiprocess conversation but he can't make the meeting today.
3792020-04-16T19:05:57 <hebasto> hi
3802020-04-16T19:06:19 <cfields> maybe we can introduce the issue here and pick it up on the PR?
3812020-04-16T19:07:31 <wumpus> luke-jr: can you be more specific? the last topic suggestion from you that I see is the PPA URL and we've spent half a meeting on that
3822020-04-16T19:07:43 <wumpus> #topic High priority for review
3832020-04-16T19:07:54 <luke-jr> wumpus: right now, the wallet implementation is still broken, and if we don't address it before 0.20, it complicates backward compatibility
3842020-04-16T19:08:05 <sipa> can i haz #185512
3852020-04-16T19:08:06 <gribble> https://github.com/bitcoin/bitcoin/issues/185512 | HTTP Error 404: Not Found
3862020-04-16T19:08:07 <jonasschnelli> may I add #18242 to the hp list?
3872020-04-16T19:08:08 <sipa> can i haz #18512
3882020-04-16T19:08:08 <midnight> hi!
3892020-04-16T19:08:11 <gribble> https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
3902020-04-16T19:08:14 <gribble> https://github.com/bitcoin/bitcoin/issues/18512 | Improve asmap checks and add sanity check by sipa · Pull Request #18512 · bitcoin/bitcoin · GitHub
3912020-04-16T19:08:21 <luke-jr> re #18192, #18550, #18572, and #18608
3922020-04-16T19:08:24 <gribble> https://github.com/bitcoin/bitcoin/issues/18192 | Bugfix: Wallet: Safely deal with change in the address book by luke-jr · Pull Request #18192 · bitcoin/bitcoin · GitHub
3932020-04-16T19:08:25 <gribble> https://github.com/bitcoin/bitcoin/issues/18550 | Store destdata for change in separate key for backward compatibility by luke-jr · Pull Request #18550 · bitcoin/bitcoin · GitHub
3942020-04-16T19:08:26 <gribble> https://github.com/bitcoin/bitcoin/issues/18572 | Wallet: Accept "changedata" db key as an alias to "destdata" by luke-jr · Pull Request #18572 · bitcoin/bitcoin · GitHub
3952020-04-16T19:08:27 <gribble> https://github.com/bitcoin/bitcoin/issues/18608 | refactor: Remove CAddressBookData::destdata by ryanofsky · Pull Request #18608 · bitcoin/bitcoin · GitHub
3962020-04-16T19:08:37 <wumpus> uhmm slow down a bit please
3972020-04-16T19:08:44 <jonasschnelli> ;-)
3982020-04-16T19:09:11 <luke-jr> (my list is not for high-prio-for-review topic)
3992020-04-16T19:10:53 <achow101> #18598 for 0.20 tag and backport (or merge now)
4002020-04-16T19:10:55 <gribble> https://github.com/bitcoin/bitcoin/issues/18598 | gitian: Add missing automake package to gitian-win-signer.yml by achow101 · Pull Request #18598 · bitcoin/bitcoin · GitHub
4012020-04-16T19:10:56 <wumpus> jonasschnelli: sipa added
4022020-04-16T19:11:03 <jonasschnelli> thanks
4032020-04-16T19:11:46 <MarcoFalke> achow101: Assigned milestone. I think this will be dealt with in rc2
4042020-04-16T19:12:13 <wumpus> yes, if it's required for windows signing on some environments it definitely needs to go into the next rc
4052020-04-16T19:12:24 <wumpus> I didn't need it for LXC fwiw
4062020-04-16T19:12:34 <jonasschnelli> me2
4072020-04-16T19:12:37 <MarcoFalke> happens only on docker/podman
4082020-04-16T19:12:42 <hebasto> yes, lxc does need it
4092020-04-16T19:12:58 <achow101> yeah, seems to be a virutaliation specific issue
4102020-04-16T19:13:12 <achow101> just wanted to make sure no one forgot about it
4112020-04-16T19:13:29 <hebasto> achow101: mind specify it in pr description?
4122020-04-16T19:13:32 <wumpus> yes, good point
4132020-04-16T19:13:51 <jonatack> i think i ran into it when win gitian signing with docker
4142020-04-16T19:14:17 <achow101> hebasto: done
4152020-04-16T19:14:19 <wumpus> makes sense
4162020-04-16T19:15:46 <wumpus> luke-jr: I think there have been some disagreements about your PRs, meshcollider was concerned about #18550 for example
4172020-04-16T19:15:47 <gribble> https://github.com/bitcoin/bitcoin/issues/18550 | Store destdata for change in separate key for backward compatibility by luke-jr · Pull Request #18550 · bitcoin/bitcoin · GitHub
4182020-04-16T19:16:11 <wumpus> it's probably too late in the release cycle to do changes like that
4192020-04-16T19:16:14 <luke-jr> wumpus: are we changing to that topic now? I can wait a bit
4202020-04-16T19:16:32 <luke-jr> it's a bugfix
4212020-04-16T19:17:24 <MarcoFalke> What bug is it fixing? You didn't include any regression tests
4222020-04-16T19:17:33 <meshcollider> ryanofsky should really be here for this discussion too
4232020-04-16T19:17:41 <ryanofsky> here
4242020-04-16T19:17:46 <luke-jr> MarcoFalke: I don't see how to make tests for this kind of thing
4252020-04-16T19:18:14 <ryanofsky> My summary of the destdata issue is https://github.com/bitcoin/bitcoin/pull/18550#issuecomment-612672886
4262020-04-16T19:18:16 <wumpus> so is it a regression in 0.20?
4272020-04-16T19:18:41 <MarcoFalke> Is this a bug that users can observe or is it only a developer issue?
4282020-04-16T19:19:09 <luke-jr> it's a wallet format issue
4292020-04-16T19:19:21 <luke-jr> if we don't fix it now, it complicates backward compatibility when we do fix it later
4302020-04-16T19:19:26 <wumpus> yes, if it's hard to write a test for and it's not a GUI issue that usually means it's very hard to observe
4312020-04-16T19:19:40 <luke-jr> it's hard to write a test, because the breaking is backward compatibility
4322020-04-16T19:19:49 <luke-jr> so we'd need a way to run an old version
4332020-04-16T19:20:06 <MarcoFalke> the python tests can do that
4342020-04-16T19:20:08 <meshcollider> It's not a new issue, the actual issue itself was fixed in #18192
4352020-04-16T19:20:10 <gribble> https://github.com/bitcoin/bitcoin/issues/18192 | Bugfix: Wallet: Safely deal with change in the address book by luke-jr · Pull Request #18192 · bitcoin/bitcoin · GitHub
4362020-04-16T19:20:11 <luke-jr> "destdata" was added in a manner that it only supported non-change
4372020-04-16T19:20:20 <ryanofsky> Luke, I'm not sure what the exact issue you are concerned about, your PR changes behavior in lots of ways, most of them bad
4382020-04-16T19:20:26 <luke-jr> but now we suddenly need to support it for change too
4392020-04-16T19:20:28 <wumpus> destdata has been in there since 2012 or so isn't it
4402020-04-16T19:20:37 <luke-jr> the problem remaining is that the fix in #18192 breaks compatibility
4412020-04-16T19:20:40 <gribble> https://github.com/bitcoin/bitcoin/issues/18192 | Bugfix: Wallet: Safely deal with change in the address book by luke-jr · Pull Request #18192 · bitcoin/bitcoin · GitHub
4422020-04-16T19:20:53 <sipa> luke-jr: can you give an exact scenario for reproducing the issue?
4432020-04-16T19:20:55 <luke-jr> wumpus: yes, 0.9
4442020-04-16T19:21:14 <luke-jr> sipa: set a destdata on change, then use the wallet in an older version
4452020-04-16T19:21:18 <sipa> assuming no further changes related to the topic go into 0.20
4462020-04-16T19:21:25 <wumpus> why does it now suddenly need to be changed before 0.20
4472020-04-16T19:21:31 <sipa> what does a user do to cause "set a destdata on change" ?
4482020-04-16T19:21:33 <ryanofsky> luke-jr, that is a pre-existing bug in 0.19
4492020-04-16T19:21:54 <luke-jr> sipa: currently, it is possible only be using an avoid-reuse wallet
4502020-04-16T19:21:55 <ryanofsky> it already sets destdata on change and then starts treating it as nonchange
4512020-04-16T19:21:58 <luke-jr> only by*
4522020-04-16T19:22:07 <achow101> luke-jr: IMO it isn't worth trying to fix this display bug with users who upgrade then downgrade
4532020-04-16T19:22:22 <MarcoFalke> I'd say that anything that is not a regression can wait for 0.20.1 or 0.21.0
4542020-04-16T19:22:24 <luke-jr> achow101: it will come back when downgrading 0.21 to 0.20
4552020-04-16T19:22:27 <ryanofsky> it'd be easy to backport a trivial fix for that issue in the 0.19 branch, but this PR only makes the bug and introduces other bugs
4562020-04-16T19:22:27 <achow101> because it's already an issue for those users using the old software, this isn't a regression
4572020-04-16T19:22:32 *** andrewtoth_ has joined #bitcoin-core-dev
4582020-04-16T19:22:34 <luke-jr> unless we specifically exclude "used" from the fix in 0.21
4592020-04-16T19:22:38 <ryanofsky> *masks the bug
4602020-04-16T19:22:49 <sipa> what is the impact? is it just the change address showing up in the address book, or more?
4612020-04-16T19:23:06 <luke-jr> sipa: just that, I think
4622020-04-16T19:23:18 <luke-jr> (which can be serious IMO)\
4632020-04-16T19:23:23 <achow101> sipa: it may have an effect on coin selection
4642020-04-16T19:23:30 *** ossifrage has quit IRC
4652020-04-16T19:23:33 <achow101> in particular trusted change vs untrusted non-change
4662020-04-16T19:23:38 <luke-jr> achow101: well, if it's spentâ¦
4672020-04-16T19:24:01 <sipa> my understanding is that it does not affect IsChange, unless a user also goes to set an explicit label on one of those (now shown) change addresses?
4682020-04-16T19:24:09 <wumpus> who uses the address book for receiving addresses anyhow
4692020-04-16T19:24:10 <luke-jr> sipa: it does
4702020-04-16T19:24:20 <luke-jr> sipa: when the change is used, it gets a "" label
4712020-04-16T19:24:27 <sipa> i see
4722020-04-16T19:24:29 <luke-jr> wumpus: uh, everyone?
4732020-04-16T19:25:00 <sipa> i certainly don't, but i don't think that's an important question; if we have an address book, it should work
4742020-04-16T19:25:02 <wumpus> luke-jr: I must admit I haven't used the address book *at all* for years, but last time I did it was to check an address I sent to
4752020-04-16T19:25:09 <luke-jr> sipa: this gets worse if we add any new features using destdata - for example, marking which destination are actually used to provide warnings on reuse
4762020-04-16T19:25:10 <ryanofsky> this is right but it's a preexisting bug, 0.19 already marks addresses used and has the same bug
4772020-04-16T19:25:17 <achow101> CAddressBook effects more than just the address book IIRC
4782020-04-16T19:25:27 <luke-jr> wumpus: how do you even receive without using it now?
4792020-04-16T19:25:35 <sipa> it affecting IsChange is more concerning to me
4802020-04-16T19:25:47 <wumpus> luke-jr: create new receiving address in the receive tab, give it out
4812020-04-16T19:25:54 <luke-jr> wumpus: that uses the address book..
4822020-04-16T19:26:09 <wumpus> no, it doesn't, the 'payment request' table is separate
4832020-04-16T19:26:18 <sipa> ok, this is a semantics discussion; this is not productive
4842020-04-16T19:26:28 <MarcoFalke> we should just remove the wallet and gui. Doesn't that solve the problem?
4852020-04-16T19:26:34 <luke-jr> -.-
4862020-04-16T19:26:54 <luke-jr> ryanofsky was proposing removing destdata entirely, but that breaks compatibility in new ways, and loses a big feature IMO
4872020-04-16T19:26:57 *** jarthur_ has joined #bitcoin-core-dev
4882020-04-16T19:27:08 <ryanofsky> no, that is not my proposal
4892020-04-16T19:27:21 <ryanofsky> my proposal is a refactoring that does not change behavior in any way
4902020-04-16T19:27:33 *** Landryl has joined #bitcoin-core-dev
4912020-04-16T19:27:36 <ryanofsky> and is meant to prevent bugs like this in the future, but it's basically orthogonal to what we are talking about
4922020-04-16T19:27:39 <achow101> I think the question is whether we will try to fix this in the future in a way that allows downgrading to 0.19
4932020-04-16T19:27:51 <ryanofsky> i described the bug https://github.com/bitcoin/bitcoin/pull/18550#issuecomment-612672886
4942020-04-16T19:27:51 <luke-jr> achow101: to 0.20*
4952020-04-16T19:27:54 <sipa> so am i correct that this triggers only if a user on 0.19 has avoid-reuse on, and then uses 0.19 or 0.20?
4962020-04-16T19:27:57 <ryanofsky> and have 3 solutions for dealing with it
4972020-04-16T19:27:58 <wumpus> destdata was mainly introduced to store payment request data and such, if it's no longer needed it should be removed
4982020-04-16T19:27:59 <wumpus> but not for 0.20
4992020-04-16T19:28:07 <ryanofsky> my PR is separate and compatible with all 3 approaches
5002020-04-16T19:28:21 <sipa> or also when they use 0.20 and then downgrades in certain cases?
5012020-04-16T19:28:27 <luke-jr> sipa: it's unfixable for already-released 0.19; my hope is to fix it so downgrading to 0.20 works
5022020-04-16T19:28:40 <luke-jr> wumpus: it's still needed
5032020-04-16T19:28:59 <luke-jr> destdata is nice because you don't need to upgrade wallets to get features using new metadata
5042020-04-16T19:29:07 <achow101> to be clear, is the issue *only* with downgrading?
5052020-04-16T19:29:22 <luke-jr> achow101: yes, which is something we've always tried to support for wallets
5062020-04-16T19:29:23 <tryphe> address book should be removed outright imo, metadeta that can be modified in a locked wallet is kind of silly
5072020-04-16T19:29:30 <achow101> If we didn't care about dowgrading at all, this would not be an issue?
5082020-04-16T19:29:34 <ryanofsky> the issue is not only with downgrading, but the fix only deals with downgrading, and is only partial
5092020-04-16T19:29:46 *** jarthur has quit IRC
5102020-04-16T19:29:58 <ryanofsky> and it introduces other bug of avoding-reuse feature in 0.19 being broken
5112020-04-16T19:30:12 *** bitcoin-git has joined #bitcoin-core-dev
5122020-04-16T19:30:13 <bitcoin-git> [bitcoin] jnewbery opened pull request #18675: tests: Don't initialize PrecomputedTransactionData in txvalidationcache tests (master...2020-04-precomputedtransactiondata-txvalidationcache) https://github.com/bitcoin/bitcoin/pull/18675
5132020-04-16T19:30:13 *** bitcoin-git has left #bitcoin-core-dev
5142020-04-16T19:30:27 <achow101> ryanofsky: what's your pr?
5152020-04-16T19:30:39 <sipa> can someone give me an exact user scenario that results in a user observing something incorrect, where they start with 0.20.0rc1 as we have now (and then do thing, or downgrade, or ...)
5162020-04-16T19:31:23 <ryanofsky> again my pr is orthogonal, refactoring only #18608, comptaible with any dataformat we chose now or in the future
5172020-04-16T19:31:23 <wumpus> tryphe: I think that's unrelated; wallet encryption in bitcoin core only protects private keys, nothing more. Labels and such are not part of that either and should definitely be kept.
5182020-04-16T19:31:24 <gribble> https://github.com/bitcoin/bitcoin/issues/18608 | refactor: Remove CAddressBookData::destdata by ryanofsky · Pull Request #18608 · bitcoin/bitcoin · GitHub
5192020-04-16T19:31:25 *** jarthur_ has quit IRC
5202020-04-16T19:32:07 <luke-jr> sipa: create avoid-reuse wallet; send a transaction that has change; spend that change; suddenly that change is no longer change
5212020-04-16T19:32:08 <ryanofsky> the scenario is just a change address gets used, and 0.19 software treats all addresses marked as used as nonchange
5222020-04-16T19:32:21 <ryanofsky> this is a pre-existing scenario that has been around since 0.19
5232020-04-16T19:32:29 <ryanofsky> and the only way to fix it reliably is with backports
5242020-04-16T19:32:30 <luke-jr> sipa: the last step is only in 0.19
5252020-04-16T19:32:34 <luke-jr> (the result)
5262020-04-16T19:32:53 <luke-jr> sipa: but if we fix this in 0.21, 0.20 would no longer see the "used" flag unless we special-case it
5272020-04-16T19:33:06 <sipa> luke-jr: that very much depends on how it is fixed
5282020-04-16T19:33:14 <ryanofsky> luke's pr is a partial fix for the the issue because it stops marking addresses as used in a way 0.19 understands, and marks them used in a different way it is blind to
5292020-04-16T19:33:17 <sipa> my concern right now is behavior that is observable with 0.20
5302020-04-16T19:33:28 <ryanofsky> there are 0 bugs observable with 0.20
5312020-04-16T19:33:29 <luke-jr> I don't see a way to fix it later, without special-casing 0.20 support
5322020-04-16T19:34:03 <wumpus> tbh if it's only a minor backwards compatibility issue that is only apparent in downgrading, I wouldn't want to do things substantially different because of it
5332020-04-16T19:34:05 <tryphe> wumpus, mostly agree, although allowing modification of metadata of someone's wallet while in cold storage that they might assume stays constant opens up a lot of doors for bad actors
5342020-04-16T19:34:06 *** captjakk has joined #bitcoin-core-dev
5352020-04-16T19:34:09 <achow101> How about we revert the "fix" in 0.20 and try again for 0.21? It seems like ~no one has complained about this bug in 0.19
5362020-04-16T19:34:26 <ryanofsky> the fix in 0.20 is correct and causes no backwards compatiability issues
5372020-04-16T19:34:29 <meshcollider> I don't think that's a good idea, the fix is still an improvement
5382020-04-16T19:34:29 <sipa> luke-jr: if after that scenario (create avoid-reuse in 0.20; create change in 0.20; spend change in 0.20; downgrade to 0.19; do things), the user upgrades again to 0.20, is the issue resolved, or might it persist?
5392020-04-16T19:34:39 <luke-jr> achow101: leaving it as-is now is strictly less bad than reverting I think
5402020-04-16T19:34:43 <sipa> tryphe: please stay on topic
5412020-04-16T19:34:44 <wumpus> tryphe: if that's your concern, encrypt the entire wallet file or store it on an encrypted file system, it's not something bitcoin core's wallet encyrption solves
5422020-04-16T19:34:46 <ryanofsky> the fix causes no issues whatsoever
5432020-04-16T19:34:57 *** jarthur has joined #bitcoin-core-dev
5442020-04-16T19:35:07 <ryanofsky> i mean the fix that's already been merged causes no issues, the new fix proposed is a different story
5452020-04-16T19:35:14 <luke-jr> sipa: the issue remains resolved in 0.20, provided the user doesn't see it in 0.19 and set a label or something
5462020-04-16T19:35:29 <sipa> luke-jr: thank you
5472020-04-16T19:35:57 <luke-jr> (in fact, I think 0.19 making the broken state itself, would also appear correct in 0.20)
5482020-04-16T19:36:07 <wumpus> okay
5492020-04-16T19:36:08 <sipa> that's good to hear as well
5502020-04-16T19:36:16 <wumpus> yes, that's good to hear
5512020-04-16T19:36:54 <sipa> i think we should document the issue in the release notes, with the point that if the issue appears, upgrading (again) to 0.20 will fix things unless a user manually set a label on an errorneously-shown address in 0.19
5522020-04-16T19:37:03 <luke-jr> my biggest "end result" concern, is that I don't think users should need to -upgradewallet to get address reuse warnings when we finally merge that ; but that's a few steps into the future
5532020-04-16T19:37:29 <sipa> for 0.21, we can discuss solutions - whether those involved -upgradewallet or special-casing the 0.20 behavior
5542020-04-16T19:37:30 <achow101> luke-jr: with what is currently merged, why is changing the fix necessary?
5552020-04-16T19:37:55 <achow101> as in why is your proposed 0.21 fix necessary
5562020-04-16T19:38:04 <luke-jr> achow101: it's one thing to break compatibility with <0.19 only for avoid-reuse wallets>, another entirely to break compatibiltiy with <normal wallets going back forever>
5572020-04-16T19:38:25 <luke-jr> achow101: since "used" destdata is only in avoid-reuse, we have the former situation right now
5582020-04-16T19:38:35 <luke-jr> but as soon as we add destdata for change on normal wallets, we get the latter
5592020-04-16T19:38:43 *** captjakk has quit IRC
5602020-04-16T19:39:02 <achow101> are we adding destdata for change on normal wallets?
5612020-04-16T19:39:12 <luke-jr> achow101: that's my plan for address reuse warnings
5622020-04-16T19:39:23 <ryanofsky> achow101, yes, we've been doing that since kallewoof implemented avoidreuse
5632020-04-16T19:39:32 <wumpus> just a reminder that we have to reserve some time for MarcoFalke's topic as well
5642020-04-16T19:39:39 <jonatack> i agree with sipa's proposals (and with meshcollider and ryanofsky that it's better to keep fix in luke-jr's merged pr)
5652020-04-16T19:39:41 <luke-jr> that's how it can avoid needing a -walletupgrade
5662020-04-16T19:39:53 <achow101> ryanofsky: that's only for avoid reuse
5672020-04-16T19:40:00 <achow101> luke-jr: i see, so what if we don't do that?
5682020-04-16T19:40:06 <achow101> and just don't change it
5692020-04-16T19:40:18 <luke-jr> achow101: I don't understand what you mean
5702020-04-16T19:40:32 <luke-jr> if we don't add address reuse warnigns, we don't have address reuse warnings..
5712020-04-16T19:40:46 <achow101> why do we have to add destdata on change for normal wallets
5722020-04-16T19:40:55 <luke-jr> to mark the change address as used
5732020-04-16T19:41:01 <achow101> if the wallet doesn't signal avoidreuse, then there's no need?
5742020-04-16T19:41:11 *** vasild_ has joined #bitcoin-core-dev
5752020-04-16T19:41:16 <luke-jr> address reuse warnings are for all wallets
5762020-04-16T19:41:36 <sipa> yeah, address reuse warnings != avoidreuse behavior
5772020-04-16T19:41:46 <achow101> ok i see
5782020-04-16T19:41:48 <sipa> but can't that be done with a different db record instead?
5792020-04-16T19:41:50 <achow101> there's the context I'm missing :)
5802020-04-16T19:41:58 <luke-jr> sipa: that's a wallet format change, and needs -upgradewallet
5812020-04-16T19:41:59 <ryanofsky> sipa, yes
5822020-04-16T19:42:11 <sipa> luke-jr: why? old wallets would just ignore the record
5832020-04-16T19:42:24 <ryanofsky> from https://github.com/bitcoin/bitcoin/pull/18550#issuecomment-612672886
5842020-04-16T19:42:31 <ryanofsky> option 1 is keep using "destdata" record
5852020-04-16T19:42:40 <ryanofsky> option 2 is switch to "changedata" record
5862020-04-16T19:42:45 <sipa> also, can't the usage data be computed at runtime from other wallet data?
5872020-04-16T19:42:45 <ryanofsky> option 3 is "useddata" record
5882020-04-16T19:43:00 <luke-jr> sipa: historical best practice?
5892020-04-16T19:43:07 <sipa> ?
5902020-04-16T19:43:16 <luke-jr> sipa: maybe in this case (I haven't looked into that option yet, but I plan to), but this will probably come up again either way
5912020-04-16T19:43:23 <meshcollider> Using a different record would be fine, only a minor code complication
5922020-04-16T19:43:33 <luke-jr> sipa: we've always tried to not change wallet format outside of an explicit -upgradewallet
5932020-04-16T19:43:34 <meshcollider> I dont think it would come up again luke-jr
5942020-04-16T19:43:49 <luke-jr> meshcollider: tax metadata for example
5952020-04-16T19:43:53 <sipa> luke-jr: it sounds to me like no wallet format change is needed *at all* for this functionality
5962020-04-16T19:44:01 <meshcollider> Again use a different record, not destdata
5972020-04-16T19:44:12 <luke-jr> meshcollider: what different record?
5982020-04-16T19:44:43 <sipa> i think this is taking us too far
5992020-04-16T19:44:43 *** vasild has quit IRC
6002020-04-16T19:44:44 *** vasild_ is now known as vasild
6012020-04-16T19:44:51 <luke-jr> meshcollider: adding a new one is a wallet format change..
6022020-04-16T19:45:06 <sipa> so be it?
6032020-04-16T19:45:09 <achow101> luke-jr: we've added/changed records before without needing upgradewallet
6042020-04-16T19:45:16 <wumpus> please wrap up this topic
6052020-04-16T19:45:19 <meshcollider> In a backwards compatible way if it's new
6062020-04-16T19:45:26 <sipa> if it's a record old wallets can just ignore, no need for upgradewallet
6072020-04-16T19:45:28 <luke-jr> achow101: we have?
6082020-04-16T19:45:29 <sipa> otherwise, use it
6092020-04-16T19:45:34 <luke-jr> ok then
6102020-04-16T19:45:42 <meshcollider> Yes the topic is done, the PRs are closed as noone else concept ACKs the change
6112020-04-16T19:45:48 <achow101> luke-jr: see UpgradeKeyMetadata
6122020-04-16T19:45:53 <wumpus> #topic experimental libmultiprocess, next steps for multiprocess in general (MarcoFalke)
6132020-04-16T19:45:55 <MarcoFalke> Background is that libmultiprocess has been added to ./depends , and libmultiprocess compile and link flags have been added to our makefile. Everything was opt-in but after merge discussion concluded that it was too early to do this step, so the change has been reverted. I (and ryanofsky) would like to hear and discuss everyone's concerns about libmultiprocess as part of the meeting for brainstorming.
6142020-04-16T19:46:09 <MarcoFalke> cc cfields
6152020-04-16T19:46:16 <cfields> ^^
6162020-04-16T19:46:22 <MarcoFalke> cc fanquake (probably sleeping)
6172020-04-16T19:46:34 <sipa> my impression is that we should only merge changes for this if the plan is that eventually this will end up in release binaries
6182020-04-16T19:46:52 <sipa> it's not clear to me if that's the case
6192020-04-16T19:46:57 <cfields> fanquake listed a bunch of really good questions, and ryanofsky has given good answers to on #18588.
6202020-04-16T19:46:58 <gribble> https://github.com/bitcoin/bitcoin/issues/18588 | Revert "Merge #16367: Multiprocess build support" by MarcoFalke · Pull Request #18588 · bitcoin/bitcoin · GitHub
6212020-04-16T19:46:59 <MarcoFalke> sipa: Eventually that was the goal (at least as I understood it)
6222020-04-16T19:47:12 <ryanofsky> that is the goal as far as i know
6232020-04-16T19:47:14 <MarcoFalke> sipa: Though, there was no timeline for it
6242020-04-16T19:47:22 <cfields> sipa: yes, that was exactly my concern as well. The path forward isn't clear enough to be merging it in in-parts, imo.
6252020-04-16T19:47:23 <wumpus> sipa: yes, I think that's obvious
6262020-04-16T19:48:05 <sipa> i haven't paid that much attention to the multiprocess project as i don't really care about it (and kind of dread pulling in extra dependencies like capnproto), but i assumed that it was something lots of people wanted - which is fine
6272020-04-16T19:48:15 <wumpus> though it's probably ok to have it experimental for a while before it ends up in release binaries
6282020-04-16T19:48:33 <ryanofsky> maybe relevant: it builds new binaries
6292020-04-16T19:48:34 <sipa> wumpus: sure
6302020-04-16T19:49:06 <wumpus> I'm not really sure I like importing capnproto either, just now we got rid of google serialization thing
6312020-04-16T19:49:14 <ryanofsky> so a theoretical release could include existing binaries, alongside new multiprocess binaries that let you start and stop node/gui/wallet separately and connect each other
6322020-04-16T19:49:35 <wumpus> then again it's probably better than hand-rolling everything
6332020-04-16T19:49:50 <MarcoFalke> The multiprocess and capnproto will stay opt-in unless it is decided to change it that
6342020-04-16T19:50:06 <luke-jr> ryanofsky: can the same binary do single-process and multiprocess?
6352020-04-16T19:50:23 <MarcoFalke> luke-jr: No, they are two binaries
6362020-04-16T19:50:30 <luke-jr> I mean hypothetically
6372020-04-16T19:50:42 <wumpus> ryanofsky: I'm not sure I like that solution, couldn't we emulate the old way using the new binaries without shipping everything twice?
6382020-04-16T19:50:47 <ryanofsky> yes, I just didn't add the option
6392020-04-16T19:50:56 <ryanofsky> there is lots of flexibility here
6402020-04-16T19:51:09 <wumpus> with the static builds we do that's expensive
6412020-04-16T19:51:15 <ryanofsky> I just built separate binaries because i meant I had to run ./configure less often
6422020-04-16T19:51:38 <ryanofsky> If we want unified binaries with a runtime options, that's easy too
6432020-04-16T19:51:52 <wumpus> ah yes like busybox
6442020-04-16T19:52:02 <luke-jr> eg, bitcoin-qt gets what we have now; bitcoin-qt -process=foo gets just the foo part in MP mode
6452020-04-16T19:52:34 <wumpus> that kinda makes sense
6462020-04-16T19:53:29 <ryanofsky> these are really just packaging questions, my question is how to make progress on getting code reviewed
6472020-04-16T19:53:53 <wumpus> well, 'just packaging questions' are kind of important to do this, I think
6482020-04-16T19:53:55 <luke-jr> review club? :P
6492020-04-16T19:54:12 <wumpus> if you split up things people are going to ask how to re-bundle them :)
6502020-04-16T19:54:28 <ryanofsky> i mean, packaging questions are the things you would be deciding on last, and maybe changing with trial and error
6512020-04-16T19:55:00 <cfields> ryanofsky: some of those packaging questions come down to language choices though, those things need to be decided on much earlier.
6522020-04-16T19:55:02 <ryanofsky> 99% of the code stays the same regardless
6532020-04-16T19:55:11 <wumpus> in any case if you want concept ACK on multiprocess, concept ACK, I think it's a good thing in the longer run
6542020-04-16T19:55:20 *** jarthur_ has joined #bitcoin-core-dev
6552020-04-16T19:55:27 <ryanofsky> cfields ?
6562020-04-16T19:55:50 <wumpus> security-wise process isloation is a good start as well
6572020-04-16T19:56:21 <cfields> ryanofsky: I'm curious to know, for example, what the downside of using the c++11 version libmultiprocess you've mentioned?
6582020-04-16T19:56:26 <jonasschnelli> looking forward to wireguard-tunnel the GUI to a remote node.
6592020-04-16T19:56:29 <cfields> does that mean dragging boost back in?
6602020-04-16T19:57:01 <wumpus> so maybe the packaging details is the only thing we can disagree on :)
6612020-04-16T19:57:01 <jonasschnelli> (but I guess that needs much more)
6622020-04-16T19:57:01 <ryanofsky> cfields, no downside, i can revert the vasild pr and replace std::optional with boost::optional again
6632020-04-16T19:57:33 <wumpus> wait, why?
6642020-04-16T19:57:58 <MarcoFalke> In about 6 months we'll have C++17
6652020-04-16T19:57:59 <ryanofsky> jonasschnelli, not too much, you can kind of do it with my existing branch if you use socat (existing branch only create UNIX socket)
6662020-04-16T19:57:59 <cfields> wumpus: I'm just trying to understand our options.
6672020-04-16T19:58:02 <wumpus> how can we be using std::optional in the first place we haven''t switched to C++17 yet right?
6682020-04-16T19:58:18 *** jarthur has quit IRC
6692020-04-16T19:58:20 <sipa> wumpus: libmultiprocess is using std::optional, but we're not using libmultiprocess yet
6702020-04-16T19:58:33 <ryanofsky> wumpus, we are not, libmultiprocess used it internally because vasild submitted a pr to get rid of boost, and i thought it was nice
6712020-04-16T19:58:51 <wumpus> I think the idea was to have 0.21 still c++11 compatible then go full c++17 for 0.22
6722020-04-16T19:58:52 <MarcoFalke> wumpus: libmultiprocess is compiled with c++14 flags in depends
6732020-04-16T19:58:55 <sipa> if it's just std::optional or boost::optional... that sounds like something we can just decide whenever it's merged
6742020-04-16T19:58:58 <wumpus> c++14??!
6752020-04-16T19:59:04 <wumpus> nooo
6762020-04-16T19:59:23 <MarcoFalke> s/is/was/
6772020-04-16T19:59:26 <luke-jr> do we need to fork upstream to get C++11 support?
6782020-04-16T19:59:27 <sipa> if multiprocess integration only lands with 0.22, we'd be fine
6792020-04-16T19:59:38 <ryanofsky> it works fine now...
6802020-04-16T19:59:42 <sipa> otherwise, it seems it can easily be turned into c++11 compatible
6812020-04-16T19:59:43 <MarcoFalke> sipa: Yes, that was my thinking
6822020-04-16T19:59:46 <wumpus> I doubt that has to depend on using boost::optional or std::optional they're kind of the same right?
6832020-04-16T19:59:51 <luke-jr> ryanofsky: with a non-C++14 compiler?
6842020-04-16T19:59:54 <wumpus> could use a wrapper or something like we do for fs.h
6852020-04-16T19:59:57 *** brakmic has joined #bitcoin-core-dev
6862020-04-16T20:00:07 <wumpus> but we intentionally skipped over C++14, we're not going to do that now
6872020-04-16T20:00:14 <achow101> don't we have an Optional wrapper already?
6882020-04-16T20:00:18 <luke-jr> yes
6892020-04-16T20:00:23 <wumpus> achow101: lol yes we do
6902020-04-16T20:00:30 <ryanofsky> i'm not sure what's not supposed to work here
6912020-04-16T20:01:19 <wumpus> in any case I agree these are all small details?
6922020-04-16T20:01:22 <MarcoFalke> I think boost::optional vs std::optional should be the least of our concerns in regard to multiprocess. This is just a sylistic issue
6932020-04-16T20:01:28 <MarcoFalke> wumpus: jup
6942020-04-16T20:01:30 <jonatack> ryanofsky: why not add the PR to blockers?
6952020-04-16T20:01:32 <wumpus> let's go forward with multiprocess imo
6962020-04-16T20:01:50 <wumpus> my biggest gripe is really the serialization lib dependency not boost
6972020-04-16T20:01:53 *** jarthur has joined #bitcoin-core-dev
6982020-04-16T20:02:13 <wumpus> everyone wants to get rid of boost but also not get rid of boost it's not going to happen any time soon
6992020-04-16T20:02:16 <ryanofsky> jonatack, #16367 has been in high priority list, and was even merged (then got reverted)
7002020-04-16T20:02:18 <gribble> https://github.com/bitcoin/bitcoin/issues/16367 | Multiprocess build support by ryanofsky · Pull Request #16367 · bitcoin/bitcoin · GitHub
7012020-04-16T20:02:49 <MarcoFalke> So I think people don't want a half-merged multiprocess? In which case we should focus on the main pr
7022020-04-16T20:03:04 <wumpus> we should wrap up the meeting btw
7032020-04-16T20:03:11 <wumpus> sorry for only leaving so little time for this
7042020-04-16T20:03:12 <cfields> MarcoFalke: I didn't want a half-decided multiprocess. If we've decided to move forward on defaulting it, I have no issue with the merge.
7052020-04-16T20:03:23 <luke-jr> it would be nice if there was a standard interface involved here, but lacking that, why not just use serialization.h?
7062020-04-16T20:03:24 <ryanofsky> wumpus, it's a valid concern. as much as possible I tried to make framework agnostic to serializtion and allow substituting in other implementations later
7072020-04-16T20:03:41 <jb55> wumpus: I've also ran into build issues with changing capnproto versions. is there a plan to rework that branch without capnproto?
7082020-04-16T20:03:46 <luke-jr> cfields: why do we need to default it?
7092020-04-16T20:04:00 <cfields> luke-jr: ship the binaries by default, sorry.
7102020-04-16T20:04:06 <luke-jr> ah
7112020-04-16T20:04:12 <wumpus> jb55: so the thing is, I think, that our own serialization framework is not powerful enough
7122020-04-16T20:04:17 <sipa> for the wallet<->node communication my big hope was that the protocol would be Bitcoin P2P, so that it can be substituted with whatever on either side... but it doesn't seem anyone's working on that
7132020-04-16T20:04:28 <jonatack> ryanofsky: yes; a re-opened PR when it's ready (since you mentioned review)
7142020-04-16T20:04:34 *** jarthur_ has quit IRC
7152020-04-16T20:04:58 <wumpus> jb55: also using consensus serialization for other things might not be the best idea, so people have used something else
7162020-04-16T20:05:02 <ryanofsky> sipa, we're maybe getting closer that that with ariard's prs
7172020-04-16T20:05:08 <sipa> ryanofsky: okay
7182020-04-16T20:05:11 <wumpus> but yes what particular library to use, no idea
7192020-04-16T20:05:17 <ryanofsky> he's stripping down the node/wallet interface so it's something more akin to p2p
7202020-04-16T20:05:22 *** Talkless has quit IRC
7212020-04-16T20:05:27 <MarcoFalke> sipa: Wouldn't that be dangerous to accidentally connect to a malicious remote p2p node?
7222020-04-16T20:05:28 <wumpus> ryanofsky: oh that's nice!
7232020-04-16T20:05:28 <jb55> what pr is that
7242020-04-16T20:05:48 <luke-jr> just to be clear: we're not planning on making the interfaces backward/forward compatible, right?
7252020-04-16T20:05:49 <sipa> MarcoFalke: well you'd have SPV security - which may be even desirable
7262020-04-16T20:06:08 <sipa> ryanofsky: (i didn't mean that as a "you shouldn't do what you're doing" - they're orthogonal ways of separating things; a P2P-protocol based one is just what i'm more interested in)
7272020-04-16T20:06:13 <ryanofsky> jb55, i think he only has locking PRs open now that make node/wallet more asynhrnous, but he has branches to do things like store block info in wallet i believe
7282020-04-16T20:06:41 <wumpus> but for an experimental thing it might be OK to rely on capnproto
7292020-04-16T20:06:46 <wumpus> I don't want to stand in the way of that
7302020-04-16T20:06:52 <ryanofsky> sipa, yes, I know that, that's the way I look at it too
7312020-04-16T20:07:11 <wumpus> we've often enough delayed things before some 'perfect solutoin' would appear which then would never happen
7322020-04-16T20:07:16 <sipa> agreed
7332020-04-16T20:07:21 <jb55> so experimental with plans to replace it eventually?
7342020-04-16T20:07:28 <wumpus> yess
7352020-04-16T20:07:34 <jb55> I'm ok with that
7362020-04-16T20:07:45 <sipa> ryanofsky: what specifically does capnproto offer that's hard to do in our own serialization.h?
7372020-04-16T20:07:48 <cfields> sgtm
7382020-04-16T20:07:56 <sipa> or is it just avoiding lots of boilerplate code
7392020-04-16T20:08:05 <sipa> (which may be a valid reason too)
7402020-04-16T20:08:11 <wumpus> boilerplate I think
7412020-04-16T20:08:17 *** timothy has quit IRC
7422020-04-16T20:08:19 <wumpus> capnproto autogenerates a lot
7432020-04-16T20:08:19 <ryanofsky> sipa, it's a whole io framework, more than just serialization
7442020-04-16T20:08:42 <ryanofsky> it's higher level even than things like grpc and thrift, it gives you object handles and supports callbacks
7452020-04-16T20:09:25 <wumpus> right, it's a real RPC mechanism, not just serialization
7462020-04-16T20:09:30 <sipa> i see
7472020-04-16T20:09:42 <wumpus> it goes further than protobuf in that regard
7482020-04-16T20:09:45 <ryanofsky> and i've found it just very nice to work with, but I've tried to make everything around it as flexible as possible so it could be swapped with something else
7492020-04-16T20:10:00 <luke-jr> so might be more apt to compare it to bitcoind's RPC server..
7502020-04-16T20:10:03 <wumpus> also it doesn't need to be compatible between differnt verisons
7512020-04-16T20:10:12 <wumpus> as it's only used for internal communication
7522020-04-16T20:10:16 <jb55> if its in in-tree as an experimental maybe we can get more people working on it... status has been ambiguous for so long
7532020-04-16T20:10:20 <wumpus> between components of the same release
7542020-04-16T20:10:30 <wumpus> luke-jr: nononono it's *NOT* an official API
7552020-04-16T20:10:40 <ryanofsky> wumpus, yes that is true, though capnproto does have same nice versioning / compatibility features as protobufs
7562020-04-16T20:10:44 <luke-jr> wumpus: I mean technically comparable, not supported the same
7572020-04-16T20:10:51 <wumpus> luke-jr: ok :)
7582020-04-16T20:11:10 <wumpus> agreed in that case
7592020-04-16T20:11:10 <luke-jr> wumpus: I too would be against a stable interface for this right now :P
7602020-04-16T20:11:20 <luke-jr> (unless we literally made it use bitcoind RPC maybe)
7612020-04-16T20:11:29 <wumpus> yes, maybe in the future
7622020-04-16T20:11:34 <wumpus> ok, let's wrap up the meeting
7632020-04-16T20:11:34 <cfields> Thanks for the discussion :)
7642020-04-16T20:11:38 <wumpus> thank you too
7652020-04-16T20:11:39 <ryanofsky> yes, the interfaces is just the headers in src/interfaces/, changes very often
7662020-04-16T20:11:39 <sipa> it's certainly hard to agree on a stable interface 2 major releases before we plan to have it available :p
7672020-04-16T20:11:49 <wumpus> sipa: lol exactly
7682020-04-16T20:12:09 <wumpus> #endmeeting
7692020-04-16T20:12:09 <lightningbot> Meeting ended Thu Apr 16 20:12:09 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
7702020-04-16T20:12:09 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-04-16-19.03.html
7712020-04-16T20:12:09 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-04-16-19.03.txt
7722020-04-16T20:12:09 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-04-16-19.03.log.html
7732020-04-16T20:12:29 *** jarthur_ has joined #bitcoin-core-dev
7742020-04-16T20:12:32 *** bitcoin-git has joined #bitcoin-core-dev
7752020-04-16T20:12:32 <bitcoin-git> [bitcoin] hebasto opened pull request #18676: build: Check libevent minimum version in configure script (master...200416-libevent) https://github.com/bitcoin/bitcoin/pull/18676
7762020-04-16T20:12:33 *** bitcoin-git has left #bitcoin-core-dev
7772020-04-16T20:14:14 *** owowo has quit IRC
7782020-04-16T20:14:16 *** jarthur has quit IRC
7792020-04-16T20:14:29 <wumpus> ^^ thanks hebasto
7802020-04-16T20:14:42 *** bitcoin-git has joined #bitcoin-core-dev
7812020-04-16T20:14:42 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d8dfcea5d956...447f8676b2e9
7822020-04-16T20:14:43 <bitcoin-git> bitcoin/master 0c63187 Hennadii Stepanov: ci: Limit cache size regardless of NO_DEPENDS
7832020-04-16T20:14:43 <bitcoin-git> bitcoin/master 447f867 MarcoFalke: Merge #18667: ci: Limit cache size regardless of NO_DEPENDS
7842020-04-16T20:14:45 *** bitcoin-git has left #bitcoin-core-dev
7852020-04-16T20:15:02 *** bitcoin-git has joined #bitcoin-core-dev
7862020-04-16T20:15:02 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18667: ci: Limit cache size regardless of NO_DEPENDS (master...200416-ci-cache) https://github.com/bitcoin/bitcoin/pull/18667
7872020-04-16T20:15:03 *** bitcoin-git has left #bitcoin-core-dev
7882020-04-16T20:15:10 <MarcoFalke> PSA: I will probably clear all travis caches now, because of this bug in the ci scripts ^
7892020-04-16T20:15:31 *** berndj has quit IRC
7902020-04-16T20:16:13 *** captjakk has joined #bitcoin-core-dev
7912020-04-16T20:19:12 <sipa> i forgot to bring it up again in the meeting, but i'd like some opinions on how to move forward with asmap... 0.20 will have (experimental?) support for it, but the user is responsible for constructing/finding/... the map file somewhere
7922020-04-16T20:20:41 <sipa> i have #18573 that adds a binary for constructing/decoding these map files, which is an approach i like, but perhaps it's better to keep this out of bitcoin core's scope for now, unsure
7932020-04-16T20:20:43 <gribble> https://github.com/bitcoin/bitcoin/issues/18573 | [RFC] bitcoin-asmap utility by sipa · Pull Request #18573 · bitcoin/bitcoin · GitHub
7942020-04-16T20:21:31 *** berndj has joined #bitcoin-core-dev
7952020-04-16T20:22:01 *** owowo has joined #bitcoin-core-dev
7962020-04-16T20:23:17 <wumpus> sipa: I'm not sure, on one hand it's useful to have encoding and decoding in one place, on the other I don't really like adding more and more binaries to the distribution
7972020-04-16T20:23:27 <wumpus> MarcoFalke: SGTM
7982020-04-16T20:24:19 <wumpus> sipa: we've intentionally kept all kinds of developer tools in bitcoin-maintainer-tools repo instead, but if you think this is something a lot of users are going to need we could ship it with bitcoin core itself sure
7992020-04-16T20:25:05 <wumpus> I mean, if everyone is going to generate their own asmap instead of downloading a pre-generated one
8002020-04-16T20:25:25 <wumpus> but that's your question I guess
8012020-04-16T20:26:00 <sipa> wumpus: or being able to verify a shipped one
8022020-04-16T20:27:39 <sipa> but yes, things depend on how these things get used, how distribution is handled, what expectations people have around the process...
8032020-04-16T20:28:08 <wumpus> right
8042020-04-16T20:28:23 *** bitcoin-git has joined #bitcoin-core-dev
8052020-04-16T20:28:23 <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/447f8676b2e9...8f2497941ef1
8062020-04-16T20:28:24 <bitcoin-git> bitcoin/master e44aeef Andrew Chow: gitian: Add missing automake package to gitian-win-signer.yml
8072020-04-16T20:28:25 <bitcoin-git> bitcoin/master 8f24979 Wladimir J. van der Laan: Merge #18598: gitian: Add missing automake package to gitian-win-signer.ym...
8082020-04-16T20:28:26 *** bitcoin-git has left #bitcoin-core-dev
8092020-04-16T20:28:43 *** bitcoin-git has joined #bitcoin-core-dev
8102020-04-16T20:28:43 <bitcoin-git> [bitcoin] laanwj merged pull request #18598: gitian: Add missing automake package to gitian-win-signer.yml (master...fix-gitian-win-signer) https://github.com/bitcoin/bitcoin/pull/18598
8112020-04-16T20:28:44 *** bitcoin-git has left #bitcoin-core-dev
8122020-04-16T20:33:16 <luke-jr> sipa: ideally we should keep it separate IMO - but does it need to share a lot of code?
8132020-04-16T20:33:47 <luke-jr> I hope the multiprocess eventually leads to a separate wallet/GUI repos too âº
8142020-04-16T20:33:53 <sipa> luke-jr: i think the primary advantage is that it allows testing/fuzzing the encoder together with the exact code bitcoin core is using for lookups
8152020-04-16T20:34:16 <luke-jr> sipa: no reason we can't test across repos?
8162020-04-16T20:34:49 <sipa> it could be a separate repository that's subtreed or otherwise included in the build of course
8172020-04-16T20:34:57 <sipa> but that's not really my question
8182020-04-16T20:35:36 <luke-jr> nah, just pull it in for QA?
8192020-04-16T20:36:09 <luke-jr> like Python
8202020-04-16T20:36:17 <sipa> i'm confused
8212020-04-16T20:36:46 *** jarthur_ is now known as jarthur
8222020-04-16T20:37:25 <luke-jr> sipa: we only need Python to run tests, not to build
8232020-04-16T20:37:46 <sipa> sure
8242020-04-16T20:37:47 <luke-jr> if bitcoin-asmap is available, we can use it for tests too, but still separate from the main repo
8252020-04-16T20:37:59 <luke-jr> no?
8262020-04-16T20:38:09 <sipa> luke-jr: you mean if the binary is available?
8272020-04-16T20:38:14 <luke-jr> sure
8282020-04-16T20:38:19 <sipa> that'd be extremely slow
8292020-04-16T20:38:23 <luke-jr> ?
8302020-04-16T20:38:29 <sipa> if you'd need to invoke the binary for every test case
8312020-04-16T20:38:59 <sipa> my fuzz test right now generates random inputs to the encoder function used by bitcoin-asmap directly
8322020-04-16T20:39:06 <sipa> that's orders of magnitude faster
8332020-04-16T20:39:17 <luke-jr> hmm
8342020-04-16T20:39:29 <sipa> and verifies them against the interpreter code used for lookup
8352020-04-16T20:39:42 *** bitcoin-git has joined #bitcoin-core-dev
8362020-04-16T20:39:43 <bitcoin-git> [bitcoin] MarcoFalke pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/8f2497941ef1...969ee8549496
8372020-04-16T20:39:43 <bitcoin-git> bitcoin/master fa2bc41 MarcoFalke: tools: Add unused argsman to bench_bitcoin
8382020-04-16T20:39:44 <bitcoin-git> bitcoin/master fa46aeb MarcoFalke: scripted-diff: Replace gArgs with local argsman in bench
8392020-04-16T20:39:45 <bitcoin-git> bitcoin/master fae00a7 MarcoFalke: bench: Remove unused argsman.ClearArgs
8402020-04-16T20:39:46 *** bitcoin-git has left #bitcoin-core-dev
8412020-04-16T20:39:53 <luke-jr> maybe encode+lookup should be a library? :x
8422020-04-16T20:40:02 *** bitcoin-git has joined #bitcoin-core-dev
8432020-04-16T20:40:02 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18662: test: Replace gArgs with local argsman in bench (master...2004-toolsArgsman) https://github.com/bitcoin/bitcoin/pull/18662
8442020-04-16T20:40:02 <luke-jr> or pair of libraries sharing a repo
8452020-04-16T20:40:03 *** bitcoin-git has left #bitcoin-core-dev
8462020-04-16T20:40:11 <sipa> yes, that's a possibility
8472020-04-16T20:40:27 <sipa> it's a bunch of overhead though
8482020-04-16T20:40:43 <sipa> as in, process/maintenance overhead
8492020-04-16T20:41:00 <sipa> if it's something that's more widely interesting, perhaps it makes sense
8502020-04-16T20:41:10 <luke-jr> it does sound potentially useful outside Bitcoin Core too
8512020-04-16T20:41:10 <sipa> i'm not sure to what extent it is
8522020-04-16T20:41:15 <sipa> i agree
8532020-04-16T20:42:04 <luke-jr> in fact, I think BitTorrent clients do something similar for banning copyright trolls?
8542020-04-16T20:42:11 <sipa> no idea
8552020-04-16T20:42:58 *** BlueMatt has quit IRC
8562020-04-16T20:44:14 *** BlueMatt has joined #bitcoin-core-dev
8572020-04-16T20:44:54 *** bitcoin-git has joined #bitcoin-core-dev
8582020-04-16T20:44:55 <bitcoin-git> [bitcoin] ryanofsky opened pull request #18677: Multiprocess build support (master...pr/ipc-build2) https://github.com/bitcoin/bitcoin/pull/18677
8592020-04-16T20:44:56 *** bitcoin-git has left #bitcoin-core-dev
8602020-04-16T20:45:35 *** TheRec has quit IRC
8612020-04-16T20:46:05 *** TheRec has joined #bitcoin-core-dev
8622020-04-16T20:46:06 *** TheRec has joined #bitcoin-core-dev
8632020-04-16T20:55:46 <jb55> sipa: is there a writeup about the asmap stuff somewhere? what's problems its trying to solve, how and why I need to generate those files, etc. as one of the people who maintains the bitcoin package on nixos, would I need to generate that and package it for users, etc?
8642020-04-16T20:56:42 <sipa> jb55: we really don't know
8652020-04-16T20:57:10 <sipa> it's a binary blob you can load into bitcoin core that affects how it selects outgoing peers and prioritizes incoming connections
8662020-04-16T20:57:16 <sipa> that's all there is for 0.20
8672020-04-16T20:58:00 <sipa> i have a repo with some python scripts that can generate the file (sipa/asmap), and there is a rust project that can take BGP dump files and produce input for those python scripts
8682020-04-16T20:58:42 <sipa> right now it's just an experimental feature as we don't really know what the process for distribution/generation will look like
8692020-04-16T20:59:24 *** emilengler has quit IRC
8702020-04-16T20:59:28 <sipa> maybe at some point it becomes part of gitian builds, or something similar
8712020-04-16T20:59:39 <sipa> maybe some day it's built into the binary even
8722020-04-16T20:59:41 <jb55> it's not much work for package maintainers to pull a signed binary blob from somewhere and include it as an option, or even generate it ourselves from the tools
8732020-04-16T21:00:02 <sipa> yes, but who would you trust to sign it
8742020-04-16T21:00:02 *** mikeyman77 has quit IRC
8752020-04-16T21:00:21 <jb55> if it was signed with the same key we're using for verifying bitcoin releases for instance
8762020-04-16T21:00:48 <sipa> ideally you verify gitian signatures :)
8772020-04-16T21:01:04 <sipa> so it's not a single party you're trusting
8782020-04-16T21:01:47 <sipa> but if we're talking about the entire process for building these map files... it's not deterministic, as the source material is BGP dumps that come from... somewhere
8792020-04-16T21:01:53 <sipa> and they change constantly
8802020-04-16T21:02:14 <sipa> so it's not really something that can be gitian-verified
8812020-04-16T21:02:18 <jb55> could those be poisoned somehow?
8822020-04-16T21:02:24 <jb55> don't know much about bgp
8832020-04-16T21:02:51 <sipa> well you need be your own ISP to have access to BGP dumps, and even then you only see "your view" of the internet
8842020-04-16T21:03:05 <sipa> you can download BGP dumps from various locations of course
8852020-04-16T21:04:09 <jb55> would a typical user want to generate these themselves? how would they verify they are legit? Is the point to prevent eclispe like attacks?
8862020-04-16T21:04:26 <sipa> and an attacker supplying you with an asmap file definitely would make eclipse attacks easier for them
8872020-04-16T21:04:36 <jb55> right
8882020-04-16T21:04:41 <sipa> jb55: better partition resistance, ... too
8892020-04-16T21:05:16 <sipa> jb55: i have more questions than answers about the correct procedure :)
8902020-04-16T21:05:46 <jb55> could you be attacked during the process of generating the maps? just trying to understand possible attacks here wrt. generating them on the package distro side
8912020-04-16T21:07:24 <sipa> so the process is (bgp dumps) -> mapping (currently, using gleb's rust tool); mapping -> asmap file (currently using some python scripts, or the bitcoin-asmap tool i'm adding in 18573)
8922020-04-16T21:08:52 <sipa> brb, lunch
8932020-04-16T21:08:59 <jb55> sipa: cool I'll take a look
8942020-04-16T21:16:37 *** SiAnDoG_ has quit IRC
8952020-04-16T21:17:05 *** brakmic_ has joined #bitcoin-core-dev
8962020-04-16T21:17:10 *** SiAnDoG_ has joined #bitcoin-core-dev
8972020-04-16T21:19:01 *** jarthur_ has joined #bitcoin-core-dev
8982020-04-16T21:20:27 *** brakmic has quit IRC
8992020-04-16T21:20:43 *** SiAnDoG_ has quit IRC
9002020-04-16T21:20:59 *** SiAnDoG_ has joined #bitcoin-core-dev
9012020-04-16T21:21:30 *** [42]1 has joined #bitcoin-core-dev
9022020-04-16T21:23:03 *** jarthur has quit IRC
9032020-04-16T21:23:39 *** SiAnDoG_ has quit IRC
9042020-04-16T21:24:01 *** SiAnDoG_ has joined #bitcoin-core-dev
9052020-04-16T21:36:12 *** brakmic_ has quit IRC
9062020-04-16T21:36:52 *** brakmic has joined #bitcoin-core-dev
9072020-04-16T21:39:43 <jonatack> jb55: there's an extensive review club writeup
9082020-04-16T21:40:30 <jonatack> jb55: https://bitcoincore.reviews/16702
9092020-04-16T21:40:37 <jb55> jonatack: thanks
9102020-04-16T21:42:44 *** AaronvanW has quit IRC
9112020-04-16T21:44:35 *** Emcy has quit IRC
9122020-04-16T21:45:16 *** AaronvanW has joined #bitcoin-core-dev
9132020-04-16T21:46:10 *** Emcy has joined #bitcoin-core-dev
9142020-04-16T21:47:36 <jonatack> jb55: fwiw i've been running a node with -asmap pointing to the file in a git cloned sipa/asmap repo since last December, you can see the ASN mappings via either getpeerinfo ("mapped_as") or in the GUI peers window ("Mapped AS")
9152020-04-16T21:49:34 <jb55> I assume you don't have to worry about this stuff if you run onlynet=onion?
9162020-04-16T21:50:33 <sipa> jb55: if you're reachable on public IPv4/IPv6 you may
9172020-04-16T21:50:49 <sipa> (onlynet only controls outgoing connections, iirc)
9182020-04-16T21:50:57 <jb55> ah
9192020-04-16T21:54:46 <jonatack> yes, as per doc/tor.md, incoming connections are not affected by onlynet=onion
9202020-04-16T21:54:48 *** DeanWeen has quit IRC
9212020-04-16T21:55:08 *** DeanWeen has joined #bitcoin-core-dev
9222020-04-16T21:55:33 <sipa> to clarify: asmap affects two things independently: the choice of outgoing connections to make, and prioritization of incoming connections when the max connection count is reached
9232020-04-16T21:55:45 <sipa> with onlynet=tor the first one disappears of course
9242020-04-16T22:00:50 *** ossifrage has joined #bitcoin-core-dev
9252020-04-16T22:01:15 *** Chris_Stewart_5 has quit IRC
9262020-04-16T22:01:33 *** Chris_Stewart_5 has joined #bitcoin-core-dev
9272020-04-16T22:01:39 <phantomcircuit> sipa, ip<->asn lookup is definitely something that would be useful outside of bitcoin, i've tried myself to do it in the past but without an active bgp session it's basically impossible to get the map at all
9282020-04-16T22:02:06 <sipa> that's good to know
9292020-04-16T22:02:08 <jonatack> sipa: that's a good point, and i didn't discuss inbounds in the writeup... may update it
9302020-04-16T22:03:41 <sipa> jonatack: i think the outbound selection is certainly the more impactful change
9312020-04-16T22:04:23 *** DeanWeen has quit IRC
9322020-04-16T22:04:25 <sipa> phantomcircuit: though asmap is really about efficiently encoding the map, *once you have a mapping* - i don't think there is a clear-cut optimal solution for building those maps
9332020-04-16T22:05:27 *** DeanWeen has joined #bitcoin-core-dev
9342020-04-16T22:08:17 <sipa> FWIW, the map with data from asmap-rs (sourced from RIPE NCC data) a week or two ago, with my latest optimized encoder, is 1210027 bytes
9352020-04-16T22:08:28 *** filchef has joined #bitcoin-core-dev
9362020-04-16T22:10:42 <sipa> however, we certainly don't want to go encourage everyone to go download from RIPE independently... i doubt they're set up for that
9372020-04-16T22:10:45 <BlueMatt> note that you probably want to preprocess the ripe ris data feed a bit - it includes a bunch of nonsense paths
9382020-04-16T22:10:56 <sipa> maybe we should ask them to publish hashes of their dumps
9392020-04-16T22:11:00 <wumpus> I do think this could be useful for other projects, on the other hand, making a library out of it before any other project expressed concrete interest might be scope creep
9402020-04-16T22:11:22 <sipa> BlueMatt: i've indeed noticed some bogus stuff in there
9412020-04-16T22:11:40 <sipa> fd58:9520:1361:6800::/126 AS136168
9422020-04-16T22:11:47 *** Guyver2 has quit IRC
9432020-04-16T22:11:52 <BlueMatt> heh, thats mild
9442020-04-16T22:11:54 <BlueMatt> but, ye
9452020-04-16T22:11:54 <BlueMatt> a
9462020-04-16T22:13:00 <sipa> BlueMatt: if you have ideas for some useful filtering, please open an issue on https://github.com/0ii/asmap-rs or so
9472020-04-16T22:13:19 <sipa> maybe it already does some processing, don't know
9482020-04-16T22:13:48 <BlueMatt> hmm, probably a) < /24 /48 v6, b) gotta compare with others, probably
9492020-04-16T22:13:57 <BlueMatt> would have to look at differences to figure out whts really broken
9502020-04-16T22:14:52 *** jarthur_ is now known as jarthur
9512020-04-16T22:34:19 <sipa> another reason for keeping asmap inline for now is that the format is really designed for the specific use case we have (it's only really efficient when you're allowed to remap unused ranges arbitrarily) and isn't super extensible (only AS numbers up to 2^25 i think)
9522020-04-16T22:34:39 <sipa> if the codebase is kept in one place it's probably easier to introduce changes
9532020-04-16T22:34:47 *** brakmic has quit IRC
9542020-04-16T22:41:13 *** marcoagner has quit IRC
9552020-04-16T22:42:40 *** jarthur has quit IRC
9562020-04-16T22:58:01 <wumpus> agree, though 'as part of the bitcoin core project' is in one place, more or less, it doesn't necessarily mean one repository
9572020-04-16T23:16:40 *** captjakk has quit IRC
9582020-04-16T23:17:14 *** captjakk has joined #bitcoin-core-dev
9592020-04-16T23:19:31 *** captjakk has quit IRC
9602020-04-16T23:19:44 *** captjakk has joined #bitcoin-core-dev
9612020-04-16T23:21:57 *** tryphe has quit IRC
9622020-04-16T23:22:23 *** tryphe has joined #bitcoin-core-dev
9632020-04-16T23:24:07 *** bitcoin-git has joined #bitcoin-core-dev
9642020-04-16T23:24:07 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #18612: script: Remove undocumented and unused operator+ (master...2004-scriptNoAdd) https://github.com/bitcoin/bitcoin/pull/18612
9652020-04-16T23:24:08 *** bitcoin-git has left #bitcoin-core-dev
9662020-04-16T23:24:27 *** bitcoin-git has joined #bitcoin-core-dev
9672020-04-16T23:24:27 <bitcoin-git> [bitcoin] MarcoFalke reopened pull request #18612: script: Remove undocumented and unused operator+ (master...2004-scriptNoAdd) https://github.com/bitcoin/bitcoin/pull/18612
9682020-04-16T23:24:28 *** bitcoin-git has left #bitcoin-core-dev
9692020-04-16T23:31:22 <sipa> wumpus: yeah
9702020-04-16T23:32:19 <fanquake> monorepo is the way
9712020-04-16T23:40:06 *** shaunsun has joined #bitcoin-core-dev
9722020-04-16T23:58:39 *** rjected has quit IRC
9732020-04-16T23:58:43 *** mytwocentimes has quit IRC
9742020-04-16T23:59:18 *** mytwocentimes has joined #bitcoin-core-dev
9752020-04-16T23:59:32 *** rjected has joined #bitcoin-core-dev