12020-10-20T00:00:02  *** lliehu has quit IRC
  22020-10-20T00:14:07  *** da39a3ee5e6b4b0d has joined #bitcoin-core-dev
  32020-10-20T00:15:55  *** promag has quit IRC
  42020-10-20T00:16:38  *** promag has joined #bitcoin-core-dev
  52020-10-20T00:22:20  *** bitprophet1 has joined #bitcoin-core-dev
  62020-10-20T00:25:56  <emzy> sipa: done
  72020-10-20T00:27:41  <sipa> dank
  82020-10-20T00:28:48  <emzy> :)
  92020-10-20T00:42:52  *** da39a3ee5e6b4b0d has quit IRC
 102020-10-20T00:44:19  <yanmaani> Are there any benchmarks on Bitcoin Core's RPC done?
 112020-10-20T00:44:29  <yanmaani> If I make a blockchain explorer, will it pose a problem?
 122020-10-20T00:52:41  *** ossifrage has joined #bitcoin-core-dev
 132020-10-20T00:56:42  *** mol_ has joined #bitcoin-core-dev
 142020-10-20T00:59:01  *** mol has quit IRC
 152020-10-20T00:59:54  *** mol has joined #bitcoin-core-dev
 162020-10-20T01:00:52  *** Mercury_Vapor has quit IRC
 172020-10-20T01:04:00  *** mol_ has quit IRC
 182020-10-20T01:05:46  *** Mercury_Vapor has joined #bitcoin-core-dev
 192020-10-20T01:05:47  *** sr_gi has quit IRC
 202020-10-20T01:06:18  *** sr_gi has joined #bitcoin-core-dev
 212020-10-20T01:08:36  *** willcl_ark has quit IRC
 222020-10-20T01:10:52  *** willcl_ark has joined #bitcoin-core-dev
 232020-10-20T01:16:54  <luke-jr> sipa: this doesn't look exploitable?
 242020-10-20T01:17:39  <luke-jr> yanmaani: no, you can't rely on deprecated getrawtransaction behaviour - enable txindex instead
 252020-10-20T01:26:01  <yanmaani> luke-jr: Thanks. Can I use that with a pruned blockchain? What RPC does that unlock?
 262020-10-20T01:26:58  <luke-jr> no, you can't..
 272020-10-20T01:27:11  <luke-jr> I'm not sure the deprecated functionality would work either
 282020-10-20T01:27:18  <luke-jr> getrawtransaction uses txindex
 292020-10-20T01:27:57  <yanmaani> So there's no alternative to getrawtransaction?
 302020-10-20T01:28:20  <luke-jr> to do what?
 312020-10-20T01:28:38  <yanmaani> Building a blockchain explorer
 322020-10-20T01:29:22  <yanmaani> So you want functionality like: start at txid X, look at addresses A, B, C, look at their txns Y, Z, and so on. So if I want info re: txid X, then I can do getrawtransaction <TXID>
 332020-10-20T01:29:26  *** justanotheruser has quit IRC
 342020-10-20T01:29:34  <aj> a pruned blockchain explorer?
 352020-10-20T01:29:56  <yanmaani> aj: Does pruning block me from doing txindex?
 362020-10-20T01:30:51  <yanmaani> (no pun intended)
 372020-10-20T01:31:04  <aj> pruning removes txs, so you can't explore the whole blockchain? afaik txindex requires a full history but not sure
 382020-10-20T01:32:59  <yanmaani> doesn't txindex copy it over to DB?
 392020-10-20T01:33:03  <luke-jr> yanmaani: an address should only ever have 1 transaction associated <.<
 402020-10-20T01:33:40  <yanmaani> I meant that A had txn Y, and B had txn Z, of course :)
 412020-10-20T01:36:15  <aj> yanmaani: txindex is an index -- it helps you find stuff in the database. if you remove stuff from the database it can't be found, no matter how good your index is
 422020-10-20T01:51:31  <yanmaani> Is there anything like txindex for addresses?
 432020-10-20T01:52:22  <aj> some PRs have been proposed for an address index
 442020-10-20T01:53:49  *** Eagle[TM] has joined #bitcoin-core-dev
 452020-10-20T01:55:38  *** EagleTM has quit IRC
 462020-10-20T02:05:33  <yanmaani> aj: anything merged?
 472020-10-20T02:06:27  <aj> nah
 482020-10-20T02:08:04  <yanmaani> hm, #14053 seems nice
 492020-10-20T02:08:08  <gribble> https://github.com/bitcoin/bitcoin/issues/14053 | Add address-based index (attempt 4?) by marcinja · Pull Request #14053 · bitcoin/bitcoin · GitHub
 502020-10-20T02:27:49  <aj> hmm, has anyone gotten llvm memory sanitizer to work? seems to give a pretty quick failure in boost test setup for me
 512020-10-20T02:28:12  <luke-jr> aj: Isn't that the one that requires you to rebuild all your libraries too?
 522020-10-20T02:29:11  <sipa> yes it is
 532020-10-20T02:31:36  *** S3RK has quit IRC
 542020-10-20T02:32:09  <aj> ah, that would explain it then
 552020-10-20T02:32:58  <sipa> generally you do (ubsan and asan) or (tsan) or (msan, including all libs)
 562020-10-20T02:35:02  <yanmaani> How come gettxout works with all txids, but gettransaction only does wallet txns?
 572020-10-20T02:40:56  *** S3RK has joined #bitcoin-core-dev
 582020-10-20T02:44:02  <yanmaani> Is there any PR/patch to add a TXO index?
 592020-10-20T02:54:08  <achow101> yanmaani: gettxout is a node rpc and accesses the txout set. it is limited to utxos. gettransaction is a wallet rpc, it accesses the wallet. it is limited to things in the wallet. you can use getrawtransaction to get arbitrary transactions, and enable txindex to get any arbitrary transaction
 602020-10-20T02:54:59  <achow101> note that getrawtransaction is also a node rpc and will not retrieve wallet transactions if they are not unspent and txindex isn't enabled
 612020-10-20T03:00:02  *** bitprophet1 has quit IRC
 622020-10-20T03:01:11  <yanmaani> achow101: getrawtransaction, that's the one thank you so much!
 632020-10-20T03:05:43  *** per has quit IRC
 642020-10-20T03:12:52  *** per has joined #bitcoin-core-dev
 652020-10-20T03:22:21  *** wilkie has joined #bitcoin-core-dev
 662020-10-20T03:27:09  *** S3RK_ has joined #bitcoin-core-dev
 672020-10-20T03:33:53  *** bitcoin-git has joined #bitcoin-core-dev
 682020-10-20T03:33:53  <bitcoin-git> [bitcoin] S3RK opened pull request #20191: wallet, refactor: make DescriptorScriptPubKeyMan agnostic of internal flag (master...remove_m_internal) https://github.com/bitcoin/bitcoin/pull/20191
 692020-10-20T03:33:54  *** bitcoin-git has left #bitcoin-core-dev
 702020-10-20T03:34:14  *** S3RK_ has quit IRC
 712020-10-20T03:42:09  *** glozow has quit IRC
 722020-10-20T03:45:50  *** promag_ has joined #bitcoin-core-dev
 732020-10-20T03:50:12  *** promag_ has quit IRC
 742020-10-20T04:39:59  *** jb55 has quit IRC
 752020-10-20T04:40:30  *** jb55 has joined #bitcoin-core-dev
 762020-10-20T05:15:19  *** andreacab has joined #bitcoin-core-dev
 772020-10-20T05:15:55  *** sr_gi has quit IRC
 782020-10-20T05:16:28  *** sr_gi has joined #bitcoin-core-dev
 792020-10-20T05:16:55  *** da39a3ee5e6b4b0d has joined #bitcoin-core-dev
 802020-10-20T05:28:49  *** jonatack has quit IRC
 812020-10-20T05:30:12  *** brianhoffman has quit IRC
 822020-10-20T05:33:26  *** S3RK has quit IRC
 832020-10-20T05:59:18  *** tripleslash has quit IRC
 842020-10-20T05:59:44  *** tripleslash has joined #bitcoin-core-dev
 852020-10-20T05:59:49  *** jonatack has joined #bitcoin-core-dev
 862020-10-20T06:00:02  *** wilkie has quit IRC
 872020-10-20T06:06:01  *** gribble has quit IRC
 882020-10-20T06:06:38  *** tralfaz has quit IRC
 892020-10-20T06:10:51  *** gribble has joined #bitcoin-core-dev
 902020-10-20T06:18:56  *** andreacab has quit IRC
 912020-10-20T06:22:07  *** JohninLex has joined #bitcoin-core-dev
 922020-10-20T06:30:26  *** JD2983 has joined #bitcoin-core-dev
 932020-10-20T06:31:03  *** nsh has quit IRC
 942020-10-20T06:32:37  *** JD2983_ has quit IRC
 952020-10-20T06:35:09  *** nsh has joined #bitcoin-core-dev
 962020-10-20T06:42:29  *** andreacab has joined #bitcoin-core-dev
 972020-10-20T06:49:37  *** Pavlenex has joined #bitcoin-core-dev
 982020-10-20T06:57:42  *** bitcoin-git has joined #bitcoin-core-dev
 992020-10-20T06:57:42  <bitcoin-git> [bitcoin] yash2121ja opened pull request #20192: README.md (master...master) https://github.com/bitcoin/bitcoin/pull/20192
1002020-10-20T06:57:43  *** bitcoin-git has left #bitcoin-core-dev
1012020-10-20T06:58:17  *** bitcoin-git has joined #bitcoin-core-dev
1022020-10-20T06:58:17  <bitcoin-git> [bitcoin] fanquake closed pull request #20192: README.md (master...master) https://github.com/bitcoin/bitcoin/pull/20192
1032020-10-20T06:58:18  *** bitcoin-git has left #bitcoin-core-dev
1042020-10-20T06:58:33  *** Livestradamus has quit IRC
1052020-10-20T06:58:54  *** Livestradamus has joined #bitcoin-core-dev
1062020-10-20T07:03:07  *** bitcoin-git has joined #bitcoin-core-dev
1072020-10-20T07:03:07  <bitcoin-git> [bitcoin] jonatack opened pull request #20193: p2p: improve onion detection in AttemptToEvictConnection  (master...evict-inbound-onions) https://github.com/bitcoin/bitcoin/pull/20193
1082020-10-20T07:03:08  *** bitcoin-git has left #bitcoin-core-dev
1092020-10-20T07:08:30  *** andreacab has quit IRC
1102020-10-20T07:08:58  *** andreacab has joined #bitcoin-core-dev
1112020-10-20T07:13:29  *** andreacab has quit IRC
1122020-10-20T07:24:19  *** BGL has quit IRC
1132020-10-20T07:32:23  *** Guyver2 has joined #bitcoin-core-dev
1142020-10-20T07:35:43  *** ghost43_ has quit IRC
1152020-10-20T07:36:15  *** ghost43 has joined #bitcoin-core-dev
1162020-10-20T07:43:31  *** bitcoin-git has joined #bitcoin-core-dev
1172020-10-20T07:43:31  <bitcoin-git> [bitcoin] fanquake closed pull request #20190: net: Hardcoded seeds update for 0.20.1 (master...seeds) https://github.com/bitcoin/bitcoin/pull/20190
1182020-10-20T07:43:32  *** bitcoin-git has left #bitcoin-core-dev
1192020-10-20T07:52:18  *** andreacab has joined #bitcoin-core-dev
1202020-10-20T08:00:44  *** promag has quit IRC
1212020-10-20T08:00:59  *** promag has joined #bitcoin-core-dev
1222020-10-20T08:02:44  *** mrostecki has joined #bitcoin-core-dev
1232020-10-20T08:08:46  *** tripleslash has quit IRC
1242020-10-20T08:09:33  *** andreacab has quit IRC
1252020-10-20T08:10:00  *** andreacab has joined #bitcoin-core-dev
1262020-10-20T08:10:08  *** tripleslash has joined #bitcoin-core-dev
1272020-10-20T08:12:28  *** worc3131 has quit IRC
1282020-10-20T08:13:36  *** mrostecki has quit IRC
1292020-10-20T08:13:46  *** worc3131 has joined #bitcoin-core-dev
1302020-10-20T08:13:55  *** mrostecki has joined #bitcoin-core-dev
1312020-10-20T08:14:25  *** andreacab has quit IRC
1322020-10-20T08:22:13  *** Guyver2 has quit IRC
1332020-10-20T08:22:22  *** BGL has joined #bitcoin-core-dev
1342020-10-20T08:22:30  *** kljasdfvv has quit IRC
1352020-10-20T08:24:34  *** kljasdfvv has joined #bitcoin-core-dev
1362020-10-20T08:31:02  <elichai2> Anyone else is getting a bunch of `-Wsuggest-override` warnings in the qt system headers?
1372020-10-20T08:31:32  *** reallll has joined #bitcoin-core-dev
1382020-10-20T08:32:19  <elichai2> It's all from the expansion of the `Q_OBJECT` macro
1392020-10-20T08:34:55  *** belcher_ has quit IRC
1402020-10-20T08:36:33  *** jonatack has quit IRC
1412020-10-20T08:37:15  *** reallll is now known as belcher
1422020-10-20T08:39:22  *** promag has quit IRC
1432020-10-20T08:39:56  *** promag has joined #bitcoin-core-dev
1442020-10-20T08:46:21  *** mol_ has joined #bitcoin-core-dev
1452020-10-20T08:46:39  *** andreacab has joined #bitcoin-core-dev
1462020-10-20T08:49:50  *** mol has quit IRC
1472020-10-20T08:55:47  *** andreacab has quit IRC
1482020-10-20T08:56:14  *** andreacab has joined #bitcoin-core-dev
1492020-10-20T08:56:38  *** promag has quit IRC
1502020-10-20T08:56:55  *** promag has joined #bitcoin-core-dev
1512020-10-20T08:57:44  *** promag_ has joined #bitcoin-core-dev
1522020-10-20T08:57:44  *** promag has quit IRC
1532020-10-20T08:57:52  <vasild> elichai2: yes, I think I got those
1542020-10-20T08:59:28  <vasild> elichai2: "./configure --enable-suppress-external-warnings" should silence them
1552020-10-20T09:00:02  *** JohninLex has quit IRC
1562020-10-20T09:00:38  *** andreacab has quit IRC
1572020-10-20T09:20:50  *** havenwood1 has joined #bitcoin-core-dev
1582020-10-20T09:24:15  <vasild> How to make a functional test that is skipped by default in CI, but make it easy to run it manually?
1592020-10-20T09:24:52  *** kyoo[m] has quit IRC
1602020-10-20T09:24:53  *** awesome_doge has quit IRC
1612020-10-20T09:24:54  *** rcrtn32002[m] has quit IRC
1622020-10-20T09:24:55  *** icota[m] has quit IRC
1632020-10-20T09:24:55  *** sethrogers23[m] has quit IRC
1642020-10-20T09:25:01  *** Pasta[m] has quit IRC
1652020-10-20T09:25:01  *** tianshi[m] has quit IRC
1662020-10-20T09:25:15  *** TheFuzzStone[m] has quit IRC
1672020-10-20T09:25:16  *** RaphalBentgeac[m has quit IRC
1682020-10-20T09:25:18  *** snowkeld[m] has quit IRC
1692020-10-20T09:25:27  *** davterra has joined #bitcoin-core-dev
1702020-10-20T09:32:41  *** awesome_doge has joined #bitcoin-core-dev
1712020-10-20T09:34:50  *** S3RK has joined #bitcoin-core-dev
1722020-10-20T09:35:33  <jnewbery> vasild: look at EXTENDED_SCRIPTS in test/functional/test_runner.py
1732020-10-20T09:36:23  <aj> jnewbery: hey, is p2p meeting in 5h30m ?
1742020-10-20T09:36:46  <fanquake> aj: that's what I've got
1752020-10-20T09:37:00  <jnewbery> Yes, it's in 5h30min
1762020-10-20T09:37:34  <jnewbery> Are you out of daylight savings? It might make sense to shift the time for summer/winter
1772020-10-20T09:37:35  <aj> sydney socratic's got daylight savings so suddenly i don't know what time anything is
1782020-10-20T09:38:01  <aj> jnewbery: no daylight savings here, just +1000 UTC all year
1792020-10-20T09:38:32  <fanquake> the east coast is a mess of daylight savings
1802020-10-20T09:38:35  <vasild> jnewbery: ci/test/00_setup_env_native_qt5.sh:13:export TEST_RUNNER_EXTRA="--previous-releases --coverage --extended --exclude feature_dbcrash"
1812020-10-20T09:39:01  *** jonasschnelli has quit IRC
1822020-10-20T09:39:01  *** jonasschnelli has joined #bitcoin-core-dev
1832020-10-20T09:39:04  <vasild> extended tests may still be run by this CI?
1842020-10-20T09:40:12  <jnewbery> aj: so I guess you're happy to keep it at the same time. It'll be an hour earlier for northern hemisphere folks, which might be upsetting for those on the US west coast
1852020-10-20T09:40:29  <jnewbery> vasild: ah, you'd also need to add the name of your test to the end of that config line
1862020-10-20T09:40:47  <vasild> What I tried is: I added a custom option to the script "--forcerun" and if it is not set then I raise SkipTest()
1872020-10-20T09:41:40  <vasild> but the test is still run by travis, and I have no clue why. It must have detected the option and run it with that option set...
1882020-10-20T09:42:28  <vasild> I tried running "test_runner.py --ci" locally, and the test is skipped as expected
1892020-10-20T09:43:05  <vasild> jnewbery: that would be quite ugly, no?
1902020-10-20T09:46:54  *** bitcoin-git has joined #bitcoin-core-dev
1912020-10-20T09:46:54  <bitcoin-git> [bitcoin] fanquake opened pull request #20195: build: fix mutex detection when building bdb on macOS (master...bdb_xcode12_implicit_function_decleration) https://github.com/bitcoin/bitcoin/pull/20195
1922020-10-20T09:46:55  *** bitcoin-git has left #bitcoin-core-dev
1932020-10-20T09:48:35  *** icota[m] has joined #bitcoin-core-dev
1942020-10-20T09:48:35  *** kyoo[m] has joined #bitcoin-core-dev
1952020-10-20T09:48:35  *** snowkeld[m] has joined #bitcoin-core-dev
1962020-10-20T09:48:35  *** TheFuzzStone[m] has joined #bitcoin-core-dev
1972020-10-20T09:48:35  *** sethrogers23[m] has joined #bitcoin-core-dev
1982020-10-20T09:48:35  *** Pasta[m] has joined #bitcoin-core-dev
1992020-10-20T09:48:35  *** rCapital-Surpris has joined #bitcoin-core-dev
2002020-10-20T09:48:41  *** tianshi[m] has joined #bitcoin-core-dev
2012020-10-20T09:48:41  *** RaphalBentgeac[m has joined #bitcoin-core-dev
2022020-10-20T09:52:39  <jnewbery> vasild: People can live with ugly travis config I think :)
2032020-10-20T09:53:30  *** Pavlenex has quit IRC
2042020-10-20T09:53:56  <vasild> jnewbery: ok, maybe ugly was not the right word, but it is also fragile because it means that the test will be run whenever "test_runner.py --extended" is executed
2052020-10-20T09:54:05  <vasild> and it will fail
2062020-10-20T09:54:20  <vasild> sometimes I run "test_runner.py --extended" locally
2072020-10-20T09:54:56  *** Pavlenex has joined #bitcoin-core-dev
2082020-10-20T09:54:59  <vasild> I guess other people also do and I do not want to impose "always run with --extended --exclude foo" otherwise you will get failure
2092020-10-20T10:02:08  *** bitcoin-git has joined #bitcoin-core-dev
2102020-10-20T10:02:08  <bitcoin-git> [bitcoin] vasild opened pull request #20196: net: fix GetListenPort() to derive the proper port (master...fix_GetListenPort) https://github.com/bitcoin/bitcoin/pull/20196
2112020-10-20T10:02:09  *** bitcoin-git has left #bitcoin-core-dev
2122020-10-20T10:05:28  *** promag_ has quit IRC
2132020-10-20T10:05:42  <vasild> jnewbery: I renamed the option from --forcerun to --ihave1111 and opened a PR, lets see if travis will still execute the code below this line: https://github.com/bitcoin/bitcoin/pull/20196/files#diff-6b91c5b0a9bd8c4d007ea9548808ae7ba98beb22ff236324d238815c68b3b8b1R62
2142020-10-20T10:06:00  *** promag has joined #bitcoin-core-dev
2152020-10-20T10:07:52  *** vasild_ has joined #bitcoin-core-dev
2162020-10-20T10:09:56  *** promag has quit IRC
2172020-10-20T10:10:08  *** promag has joined #bitcoin-core-dev
2182020-10-20T10:11:03  *** vasild has quit IRC
2192020-10-20T10:11:04  *** vasild_ is now known as vasild
2202020-10-20T10:11:05  *** andreacab has joined #bitcoin-core-dev
2212020-10-20T10:16:03  *** shesek has quit IRC
2222020-10-20T10:20:14  *** jeremyrubin has quit IRC
2232020-10-20T10:29:02  *** shesek has joined #bitcoin-core-dev
2242020-10-20T10:31:51  *** filchef has joined #bitcoin-core-dev
2252020-10-20T10:42:51  *** brianhoffman has joined #bitcoin-core-dev
2262020-10-20T10:43:19  *** andreacab has quit IRC
2272020-10-20T10:43:45  *** andreacab has joined #bitcoin-core-dev
2282020-10-20T10:45:06  *** andreaca_ has joined #bitcoin-core-dev
2292020-10-20T10:45:06  *** andreacab has quit IRC
2302020-10-20T10:47:54  *** andreaca_ has quit IRC
2312020-10-20T10:48:20  *** andreacab has joined #bitcoin-core-dev
2322020-10-20T10:50:48  *** andreacab has quit IRC
2332020-10-20T10:51:00  *** andreacab has joined #bitcoin-core-dev
2342020-10-20T10:52:02  *** S3RK has quit IRC
2352020-10-20T11:06:33  *** sethrogers23[m] has left #bitcoin-core-dev
2362020-10-20T11:22:48  *** murrayn has quit IRC
2372020-10-20T11:23:07  *** murray_ has joined #bitcoin-core-dev
2382020-10-20T11:29:02  *** shesek has quit IRC
2392020-10-20T11:29:18  *** andreacab has quit IRC
2402020-10-20T11:29:46  *** andreacab has joined #bitcoin-core-dev
2412020-10-20T11:30:19  *** andreaca_ has joined #bitcoin-core-dev
2422020-10-20T11:30:20  *** andreacab has quit IRC
2432020-10-20T11:32:25  *** andreaca_ has quit IRC
2442020-10-20T11:32:59  *** andreacab has joined #bitcoin-core-dev
2452020-10-20T11:33:26  *** andreacab has joined #bitcoin-core-dev
2462020-10-20T11:35:31  *** andreacab has quit IRC
2472020-10-20T11:36:00  *** andreacab has joined #bitcoin-core-dev
2482020-10-20T11:36:35  *** andreaca_ has joined #bitcoin-core-dev
2492020-10-20T11:36:35  *** andreacab has quit IRC
2502020-10-20T11:38:16  *** promag has quit IRC
2512020-10-20T11:38:39  *** andreaca_ has quit IRC
2522020-10-20T11:38:50  *** promag has joined #bitcoin-core-dev
2532020-10-20T11:39:40  *** andreacab has joined #bitcoin-core-dev
2542020-10-20T11:41:46  *** andreacab has quit IRC
2552020-10-20T11:42:47  *** andreacab has joined #bitcoin-core-dev
2562020-10-20T11:44:53  *** andreacab has quit IRC
2572020-10-20T11:45:54  *** andreacab has joined #bitcoin-core-dev
2582020-10-20T11:47:59  *** andreacab has quit IRC
2592020-10-20T11:48:29  *** andreacab has joined #bitcoin-core-dev
2602020-10-20T11:49:00  *** andreaca_ has joined #bitcoin-core-dev
2612020-10-20T11:49:00  *** andreacab has quit IRC
2622020-10-20T11:51:05  *** andreaca_ has quit IRC
2632020-10-20T11:52:08  *** andreacab has joined #bitcoin-core-dev
2642020-10-20T11:54:12  *** andreacab has quit IRC
2652020-10-20T11:54:40  *** andreacab has joined #bitcoin-core-dev
2662020-10-20T11:55:13  *** andreaca_ has joined #bitcoin-core-dev
2672020-10-20T11:55:14  *** andreacab has quit IRC
2682020-10-20T11:57:19  *** andreaca_ has quit IRC
2692020-10-20T11:57:45  *** andreacab has joined #bitcoin-core-dev
2702020-10-20T11:58:21  *** andreaca_ has joined #bitcoin-core-dev
2712020-10-20T11:58:21  *** andreacab has quit IRC
2722020-10-20T12:00:01  *** havenwood1 has quit IRC
2732020-10-20T12:00:26  *** andreaca_ has quit IRC
2742020-10-20T12:00:39  *** wishbone has joined #bitcoin-core-dev
2752020-10-20T12:00:59  *** andreacab has joined #bitcoin-core-dev
2762020-10-20T12:05:01  *** andreacab has quit IRC
2772020-10-20T12:09:42  <vasild> jnewbery: I figured it out - had to move the check earlier - from run_test() to setup_nodes()
2782020-10-20T12:19:50  *** brimstone1 has joined #bitcoin-core-dev
2792020-10-20T12:25:25  *** ctrlbreak has quit IRC
2802020-10-20T12:25:48  *** ctrlbreak has joined #bitcoin-core-dev
2812020-10-20T12:29:41  *** andreacab has joined #bitcoin-core-dev
2822020-10-20T12:49:38  *** jonatack has joined #bitcoin-core-dev
2832020-10-20T12:51:49  *** Ga1aCt1Cz00__ has joined #bitcoin-core-dev
2842020-10-20T12:51:55  *** bitcoin-git has joined #bitcoin-core-dev
2852020-10-20T12:51:55  <bitcoin-git> [bitcoin] jonatack closed pull request #20193: p2p: practicalswift would like review of 19972 (master...evict-inbound-onions) https://github.com/bitcoin/bitcoin/pull/20193
2862020-10-20T12:51:56  *** bitcoin-git has left #bitcoin-core-dev
2872020-10-20T12:55:27  *** Ga1aCt1Cz00_ has quit IRC
2882020-10-20T13:09:50  *** mol_ has quit IRC
2892020-10-20T13:17:41  *** andreacab has quit IRC
2902020-10-20T13:24:12  *** andreacab has joined #bitcoin-core-dev
2912020-10-20T13:28:36  *** mol has joined #bitcoin-core-dev
2922020-10-20T13:38:44  *** promag has quit IRC
2932020-10-20T13:38:57  *** promag has joined #bitcoin-core-dev
2942020-10-20T13:41:54  *** mol_ has joined #bitcoin-core-dev
2952020-10-20T13:43:36  <jnewbery> vasild: good!
2962020-10-20T13:45:36  *** mol has quit IRC
2972020-10-20T13:46:12  *** bitcoin-git has joined #bitcoin-core-dev
2982020-10-20T13:46:12  <bitcoin-git> [bitcoin] jonatack opened pull request #20197: p2p: improve onion detection in AttemptToEvictConnection() (master...AttemptToEvictConnection-identify-onions-with-m_inbound_onion) https://github.com/bitcoin/bitcoin/pull/20197
2992020-10-20T13:46:13  *** bitcoin-git has left #bitcoin-core-dev
3002020-10-20T13:59:38  <jonasschnelli> MarcoFalke: I saw that you have merged some PRs in the GUI repository. Are you going to open a PR on the main repository?
3012020-10-20T14:24:45  <jonasschnelli> with the settings.json file: is there a way to disable loading a specific wallet that has been stored in settings.json?
3022020-10-20T14:30:46  *** andreacab has quit IRC
3032020-10-20T14:31:15  *** glozow has joined #bitcoin-core-dev
3042020-10-20T14:33:27  *** davterra has quit IRC
3052020-10-20T14:37:31  *** andreacab has joined #bitcoin-core-dev
3062020-10-20T14:38:13  <ryanofsky> jonasschnelli, if you run with -nowallet on command line it resets the list and takes precedence, and you can add other wallets after like -nowallet -wallet=mywallet
3072020-10-20T14:40:22  <ryanofsky> also wallet is removed from settings if you unload it in the gui or call an rpc with load_on_startup=False
3082020-10-20T14:40:45  *** mol_ has quit IRC
3092020-10-20T14:41:00  <ryanofsky> and #20186 will avoid creating the wallet, if you are trying to avoid creating, not loading
3102020-10-20T14:41:02  <gribble> https://github.com/bitcoin/bitcoin/issues/20186 | wallet: Make -wallet setting not create wallets by ryanofsky · Pull Request #20186 · bitcoin/bitcoin · GitHub
3112020-10-20T14:41:05  <jonasschnelli> thanks ryanofsky
3122020-10-20T14:43:29  <jonasschnelli> ryanofsky: settings.json is only in conjunction with the GUI, right? RPC loadwallet will not make create that file?
3132020-10-20T14:43:29  <ryanofsky> no problem. also you can run with -nosettings to ignore the whole file
3142020-10-20T14:44:19  <ryanofsky> yes by default loadwallet doesn't modify settings unless you pass load_on_startup=true or load_on_startup=false
3152020-10-20T14:45:36  <jonasschnelli> I guess the issue if someone creates a wallet with --wallet=mywallet in bitcoin.conf or via cli parameter, unloaded it and loads it again in the GUI (or with load_on_startup), restarts bitcoin with the same parameter will lead to a halt due to a duplicate -wallet parameter?
3162020-10-20T14:45:50  <jonasschnelli> (the issue can be overlooked / edge-case)
3172020-10-20T14:48:05  <ryanofsky> i think ideally duplicate wallet error would not be triggered by that, but it is an edge case
3182020-10-20T14:50:45  <ryanofsky> there maybe be similar cases worth fixing. like if a bitcoin.conf specifies a wallet to load, and you unload it and reload it in the gui, that should not trigger any duplicate wallet error
3192020-10-20T14:52:09  <ryanofsky> but in general the idea is for the gui to simply reload the same wallets you loaded last time, so you can stop using bitcoin.conf
3202020-10-20T14:52:12  *** justanotheruser has joined #bitcoin-core-dev
3212020-10-20T14:55:57  <jonasschnelli> ryanofsky: the reason why I look at that issue is that probably some users have specified --wallet(s) in bitcoin.conf (or CLI parameter) and will eventually run into the load/unload issue
3222020-10-20T14:56:15  <jonasschnelli> They are potentially puzzled why the "duplicate error" pops up and core refuses to start
3232020-10-20T14:56:36  <ryanofsky> right, i'm agreeing that should be fixed
3242020-10-20T14:56:39  <jonatack> ryanofsky: i wonder if adding mention of -nowallet to -wallet would be helpful. like how -nosettings is documented in -settings.
3252020-10-20T14:56:47  <jonasschnelli> it's more an upgrade issue than a "I'm new to 0.21" thing
3262020-10-20T14:57:22  <jonasschnelli> ryanofsky: would it hurt to just de-duplicate those entries (ignore duplicates)?
3272020-10-20T14:58:29  <ryanofsky> jonatack, could be depending on the use case. I thought -nosettings was useful to document for a sysadmin who doesn't wants a static configuration and doesn't want dynamic settings being used
3282020-10-20T14:59:14  <ryanofsky> Use cases for -nowallet are more obscure as far as I know. We use them in the testing framework, and here we are talking about using it to work around a bug that should just be fixed
3292020-10-20T14:59:30  <jonatack> ryanofsky: oh ok. the "no" idiom is known, but TIL you can reset the wallet list with -nowallet
3302020-10-20T14:59:54  <ryanofsky> s/doesn't wants/just wants/ above
3312020-10-20T15:00:02  *** brimstone1 has quit IRC
3322020-10-20T15:00:45  <jonasschnelli> I also wasn't aware of the -nowallet reset in the parameter order jonatack
3332020-10-20T15:00:45  <jnewbery> #startmeeting
3342020-10-20T15:00:45  <lightningbot> Meeting started Tue Oct 20 15:00:45 2020 UTC.  The chair is jnewbery. Information about MeetBot at http://wiki.debian.org/MeetBot.
3352020-10-20T15:00:45  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3362020-10-20T15:00:54  <jnewbery> #bitcoin-core-dev P2P 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
3372020-10-20T15:01:00  <jnewbery> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
3382020-10-20T15:01:02  <jonasschnelli> hi
3392020-10-20T15:01:03  <jnewbery> hi folks!
3402020-10-20T15:01:08  <gleb> Hi
3412020-10-20T15:01:09  <fanquake> hi
3422020-10-20T15:01:09  <ryanofsky> yeah -noXXX for a list setting clears the list. hopefully you never have to rely on this!
3432020-10-20T15:01:10  <amiti> hi
3442020-10-20T15:01:11  <sipa> hi
3452020-10-20T15:01:12  <ariard> hi
3462020-10-20T15:01:19  *** da39a3ee5e6b4b0d has quit IRC
3472020-10-20T15:01:22  <jonatack> hallo
3482020-10-20T15:01:28  <sdaftuar> heya
3492020-10-20T15:01:31  <ajonas> hi
3502020-10-20T15:01:50  <jnewbery> first of all, congrats everyone for getting so many PRs reviewed and merged before feature freeze!
3512020-10-20T15:01:53  <awesome_doge> hi
3522020-10-20T15:02:16  <jnewbery> we got addrv2, transaction request overhaul, taproot and anchor connections all merged
3532020-10-20T15:02:37  <jnewbery> Just one proposed topic today: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#20-oct-2020
3542020-10-20T15:02:40  <gribble> https://github.com/bitcoin/bitcoin/issues/20 | JSON-RPC callback · Issue #20 · bitcoin/bitcoin · GitHub
3552020-10-20T15:02:54  <jnewbery> Before we do that, does anyone have any updates or want to share what they're working on/prioritising?
3562020-10-20T15:03:45  <jnewbery> ok, our single topic is:
3572020-10-20T15:03:46  <jnewbery> Remove timestamps from addr messages? It seems like the timestamp is only used to leak information about our recent connectivity. It doesn't look like we use it to make decisions about who to connect to. (sdaftuar/jnewbery)
3582020-10-20T15:03:57  <jnewbery> sdaftuar: do you want to explain?
3592020-10-20T15:04:03  <sdaftuar> oy, i can try
3602020-10-20T15:04:40  <sdaftuar> i guess the background here is around looking at how addrman works, and what information it might leak about our peers (and whether or not that is ok, i guess)
3612020-10-20T15:04:51  <emzy> hi
3622020-10-20T15:05:03  <sdaftuar> i was chatting with jnewbery about the interaction specifically with block-relay-only peers, where we really don't want to leak anything
3632020-10-20T15:05:40  <sdaftuar> and one observation was that right now in master, we basically directly leak the time at which we were connected to a block-relay-only peer after we disconnect from that peer and then include the address in a getaddr response
3642020-10-20T15:05:48  <gleb> It does indeed leak info, but I never thought about solving the issue in this fashion...
3652020-10-20T15:05:59  <sdaftuar> we can fix that, but it led to wondering: what good does this time do anyone, anyway?
3662020-10-20T15:06:24  <sipa> is it actually not used for anything?
3672020-10-20T15:06:32  <sdaftuar> our own software seems to barely use those times: we use it to sometimes filter out responses to getaddr requests, and we use to sometimes to evict things from the new table
3682020-10-20T15:06:33  <gleb> There is a check in IsTerrible
3692020-10-20T15:06:39  <gleb> Seeing if it’s older than a month
3702020-10-20T15:06:46  <ariard> the fact it's not used by core addrman doesn't mean it's not used by some other bitcoin clients to decide its peering
3712020-10-20T15:06:50  <sdaftuar> but we do not use it for determining who to connect to, as far as i can tell.
3722020-10-20T15:08:44  <gleb> From what I remember I think you are right, but those existing features are not nothing
3732020-10-20T15:08:44  <jnewbery> using timestamps is already a well-known way of infering network topology: https://www.cs.umd.edu/projects/coinscope/coinscope.pdf
3742020-10-20T15:08:46  <sdaftuar> ariard: agreed. but i thought it might be worth polling people about how much good these timestamps can do, as they are necessarily unverifiable data?
3752020-10-20T15:08:56  <jonatack> CAddrMan::Good: "nTime is not updated here, to avoid leaking information about currently-connected peers."
3762020-10-20T15:09:16  <sipa> sdaftuar: good question
3772020-10-20T15:09:48  <sdaftuar> gleb: i imagine we could replace their use in those two places without that much trouble
3782020-10-20T15:09:52  <gleb> I think the way we use them, an adversary can’t really manipulate, because the checks are very moderate
3792020-10-20T15:10:05  <sdaftuar> eg by using nlasttry/nlastsuccess
3802020-10-20T15:10:29  <gleb> even if someone bumps their own addrs too much, they don’t really become “better”
3812020-10-20T15:10:43  <gleb> sdaftuar: and that won’t propagate through the network?
3822020-10-20T15:10:54  <gleb> it will have effect only locally at every node
3832020-10-20T15:11:02  <sdaftuar> gleb: given that we don't use them for much, it seems there is only downside to us by potentially telling our peers who we were connected to and at what time?
3842020-10-20T15:12:16  <gleb> Telling that a given address we’re relaying is not one year old...
3852020-10-20T15:12:36  <sdaftuar> we could still use nlastsuccess to filter out old addresses from our getaddr responses, i think?
3862020-10-20T15:12:39  <ariard> sdaftuar: right,  unverifiable data doesn't mean it can be useful even if it's gentleman-style of enforcment
3872020-10-20T15:12:59  <ariard> a lot of alternatives p2p stack doesn't sanitize their addrs with a feeler connection
3882020-10-20T15:13:17  <gleb> and they can retell this fact to other peers without connecting by themselves. Just tell what we told
3892020-10-20T15:14:03  <sdaftuar> interestingly, we don't update that time field when we successfully connect to a peer via a feeler connection, i believe.
3902020-10-20T15:14:09  <gleb> I need to look better at the code. I’d be very happy to get rid of this stuff
3912020-10-20T15:14:27  <sipa> i'll also have a look in more detail
3922020-10-20T15:14:30  <jnewbery> ariard: tradeoff there seems to be between helping a [theoretical] alternative implementation make better decisions about who to connect to -vs- protecting our own privacy
3932020-10-20T15:14:33  <sipa> it's very appealing
3942020-10-20T15:14:58  *** promag has quit IRC
3952020-10-20T15:15:02  <jnewbery> by default we should always lean towards protecting our own privacy, unless doing so would be detrimental to the network as a whole
3962020-10-20T15:15:23  <ariard> jnewbery: I would favor protecting our own privacy, but as a good practice asking on the ml would be great, at least to warrant
3972020-10-20T15:15:30  *** promag has joined #bitcoin-core-dev
3982020-10-20T15:15:38  <gleb> jnewbery: I suggest ariard thinks more whether time stamps can help light clients a lot comparing to feeler strategy
3992020-10-20T15:16:16  <amiti> +1 I don't have a complete understanding of these timestamps, but when I've looked at them in the past I've come to similar conclusions where they aren't used for much since they are unreliable and are easy to accidentally leak information
4002020-10-20T15:16:17  <jnewbery> ariard: +1. This would be a de facto change to the p2p protocol. Circulating it on the mailing list would be good manners, at least
4012020-10-20T15:17:03  <gleb> They are unreliable, but they also can’t be exploited actively I think  (only leak info, passive exploit)
4022020-10-20T15:17:39  <sdaftuar> gleb: whether they can be exploited depends on how people are using them. i agree our software seems to be designed so that this is just an information leak
4032020-10-20T15:17:40  <jnewbery> I think another piece of (almost) useless data that we could stop sharing is the start_height in the version message, but that's maybe a different discussion
4042020-10-20T15:18:04  <amiti> yeah, exactly, they can't be exploited because we write logic to not rely on it
4052020-10-20T15:18:06  <ariard> Even assuming they're used by some lightclient p2p stack, inviting ecosystem-wise not relying on them due to their distrusted nature would be better
4062020-10-20T15:18:44  <sipa> we can stop using the nTime field without caring about what others do... if we'd start setting them differently (all zero? just the current time? random within some window?) we may want to seek opinions on the ml
4072020-10-20T15:19:02  *** andreacab has quit IRC
4082020-10-20T15:19:12  <sdaftuar> agreed
4092020-10-20T15:19:23  <sipa> i imagine we'd do those at different points in time anyway
4102020-10-20T15:20:03  <gleb> Sipa: but Most of their use is already about setting them differently, it seems we mainly discussing dropping that :)
4112020-10-20T15:20:12  *** andreacab has joined #bitcoin-core-dev
4122020-10-20T15:20:33  <gleb> or, well, using them to filter out responses I guess. We sort of “promised” to use them?
4132020-10-20T15:20:43  <gleb> whatever, i think we’re on the same page
4142020-10-20T15:20:49  <ariard> just set them to zero, in case of randomness source breakup that's not a fingerprint for your node
4152020-10-20T15:21:37  *** mol has joined #bitcoin-core-dev
4162020-10-20T15:21:43  <gleb> Setting them to 0 would break compatibility
4172020-10-20T15:21:44  *** grafa has joined #bitcoin-core-dev
4182020-10-20T15:21:46  <sipa> ariard: if our RNG has issues, we have bigger problems
4192020-10-20T15:22:03  <gleb> old nodes think that ntime < 10000000 is trash iirc
4202020-10-20T15:22:12  <sipa> ariard: and setting them to 0 would actively hurt relay chances on current code
4212020-10-20T15:22:48  <gleb> we probably should randomize them within a week window from now or so
4222020-10-20T15:22:59  <ariard> good to know, do we have other compatibility bounds to care about beyond ntime < 10000000 ?
4232020-10-20T15:23:07  <jnewbery> gleb: if time is < 100000000, we set it to some recent time: https://github.com/bitcoin/bitcoin/blob/f5bd46a4cc6d395ce71ecb99852c1774235a249c/src/net_processing.cpp#L2573-L2574
4242020-10-20T15:24:00  <gleb> Oh right, sorry, I’m on my phone
4252020-10-20T15:24:09  <jnewbery> maybe we just set it to MAX_UINT32
4262020-10-20T15:24:33  <sdaftuar> i have another related topic to mention while we're discussing addrman-- i opened a PR to fix some interactions between addrman and block-relay-only peers. it's a reversal from the direction i was leaning before about how this should work, so wanted to mention it in case anyone wanted to discuss
4272020-10-20T15:25:02  *** andreacab has quit IRC
4282020-10-20T15:25:05  <sdaftuar> cc amiti and jnewbery as this came up during a recent PR under review
4292020-10-20T15:26:06  <jnewbery> #20187
4302020-10-20T15:26:08  <gribble> https://github.com/bitcoin/bitcoin/issues/20187 | Addrman: test-before-evict bugfix and improvements for block-relay-only peers by sdaftuar · Pull Request #20187 · bitcoin/bitcoin · GitHub
4312020-10-20T15:26:58  <sdaftuar> the tl;dr is that after looking into how eviction works from the new and tried tables, i decided it all works better to make sure that our block-relay-only peers in fact get moved to the tried table
4322020-10-20T15:27:19  <sdaftuar> which necessitates invoking addrman functions on those addresses and changing addrman state of course
4332020-10-20T15:27:40  <jnewbery> the change in net_processing seems reasonable to me. I haven't looked at the changes in net.
4342020-10-20T15:27:44  <sipa> right
4352020-10-20T15:27:48  <sdaftuar> but lots of things to consider (particularly privacy issues that are hard to reason about) so if someone spots a problem i'd love to discuss
4362020-10-20T15:28:17  <sdaftuar> one particular problem is if the timestamps we return in getaddr messages for those peers will stick out somehow!
4372020-10-20T15:28:34  <sipa> it's a balance beteeen not updating addrman to minimize detectability of block-only connections, and updating it to make sure we keep good ones
4382020-10-20T15:28:40  *** bitcoin-git has joined #bitcoin-core-dev
4392020-10-20T15:28:40  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #20198: Show name, format and if uses descriptors in bitcoin-wallet tool (master...2020/10/wallet_tool_sqlite) https://github.com/bitcoin/bitcoin/pull/20198
4402020-10-20T15:28:40  <sdaftuar> yep
4412020-10-20T15:28:41  *** bitcoin-git has left #bitcoin-core-dev
4422020-10-20T15:28:51  <amiti> the idea makes sense, I'll take a closer look at the code
4432020-10-20T15:29:48  <sdaftuar> (that's all i've got)
4442020-10-20T15:30:37  <jnewbery> While we're on the subject of addrman, it seems strange to me that it's owned by CConnMan. I think it makes sense to pull it out into a separate component that's owned by the node context object, so other components can access it directly.
4452020-10-20T15:30:48  <sipa> sdaftuar: do you believe there are more issues than fixed by your PR?
4462020-10-20T15:30:57  <jnewbery> Is there areason not to do that?
4472020-10-20T15:31:15  <ariard> what other components need access to addrman ? or might need in the future?
4482020-10-20T15:31:18  <sipa> jnewbery: whatever works
4492020-10-20T15:31:26  <jnewbery> ariard: net_processing and rpc
4502020-10-20T15:31:35  <gleb> No opinion on moving components around
4512020-10-20T15:31:39  <sdaftuar> sipa: not at the moment, i dont' think.  the only other addrman-related thing i'm worrying about is addr relay i think
4522020-10-20T15:31:39  <sipa> and net
4532020-10-20T15:31:44  <sdaftuar> but that's a different type of issue
4542020-10-20T15:32:13  <jnewbery> currently net_processing access addrman through some forwarding functions in cconnman
4552020-10-20T15:32:50  <ariard> sounds good to move so
4562020-10-20T15:33:33  <jnewbery> any other topics before we wrap up? Anyone have any review begs?
4572020-10-20T15:34:16  <ariard> what outstanding p2p bugfixs/followups are required for current release ?
4582020-10-20T15:34:29  <jonatack> I plan to circle back soon to finish reviewing #19858 which looks pretty close
4592020-10-20T15:34:33  <gribble> https://github.com/bitcoin/bitcoin/issues/19858 | Periodically make block-relay connections and sync headers by sdaftuar · Pull Request #19858 · bitcoin/bitcoin · GitHub
4602020-10-20T15:34:48  *** promag has quit IRC
4612020-10-20T15:34:59  *** promag has joined #bitcoin-core-dev
4622020-10-20T15:35:01  <vasild> hi, I started looking into i2p support
4632020-10-20T15:35:02  <sdaftuar> jonatack: thanks -- guessing it won't be merged until after we branch off the next release though
4642020-10-20T15:35:04  <jnewbery> ariard: you can find current release issues/prs here: https://github.com/bitcoin/bitcoin/milestone/45
4652020-10-20T15:35:16  <sdaftuar> in case that affects your review priorities!
4662020-10-20T15:35:42  <jnewbery> (I have one review beg: the backport of wtxid relay to 0.20 #19606)
4672020-10-20T15:35:44  <gribble> https://github.com/bitcoin/bitcoin/issues/19606 | Backport wtxid relay to v0.20 by jnewbery · Pull Request #19606 · bitcoin/bitcoin · GitHub
4682020-10-20T15:36:23  <jnewbery> ok, seems like that's all. Thanks folks. See you in two weeks
4692020-10-20T15:36:25  <jonatack> vasild: nice! Oh, #20120 had 3 acks by vasild promag hebasto
4702020-10-20T15:36:26  <jnewbery> #endmeeting
4712020-10-20T15:36:26  <lightningbot> Meeting ended Tue Oct 20 15:36:26 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
4722020-10-20T15:36:26  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-10-20-15.00.html
4732020-10-20T15:36:26  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-10-20-15.00.txt
4742020-10-20T15:36:26  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-10-20-15.00.log.html
4752020-10-20T15:36:27  <gribble> https://github.com/bitcoin/bitcoin/issues/20120 | net, rpc, test, bugfix: update GetNetworkName, GetNetworksInfo, regression tests by jonatack · Pull Request #20120 · bitcoin/bitcoin · GitHub
4762020-10-20T15:37:08  <jonatack> (it's more net than p2p)
4772020-10-20T15:37:12  <jnewbery> oh sorry vasild. I missed your message. Did you have more you wanted to share/discuss?
4782020-10-20T15:37:22  <vasild> no :)
4792020-10-20T15:37:41  <jnewbery> ok, I look forward to hearing more about it in another meeting then :)
4802020-10-20T15:43:53  *** jeremyrubin has joined #bitcoin-core-dev
4812020-10-20T15:52:14  *** kexkey has joined #bitcoin-core-dev
4822020-10-20T15:57:10  *** bitcoin-git has joined #bitcoin-core-dev
4832020-10-20T15:57:10  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #20199: Ignoring (but warn) on dublicate -wallet parameters (master...2020/10/de-duplicate-wallets) https://github.com/bitcoin/bitcoin/pull/20199
4842020-10-20T15:57:11  *** bitcoin-git has left #bitcoin-core-dev
4852020-10-20T15:58:51  *** andreacab has joined #bitcoin-core-dev
4862020-10-20T16:03:40  *** andreacab has quit IRC
4872020-10-20T16:25:41  *** Talkless has joined #bitcoin-core-dev
4882020-10-20T16:26:01  *** mol_ has joined #bitcoin-core-dev
4892020-10-20T16:26:48  *** bitcoin-git has joined #bitcoin-core-dev
4902020-10-20T16:26:48  <bitcoin-git> [bitcoin] adamjonas opened pull request #20200: doc: Remove breaking line of CODEOWNERS file (master...102020-fix-codeowners) https://github.com/bitcoin/bitcoin/pull/20200
4912020-10-20T16:26:49  *** bitcoin-git has left #bitcoin-core-dev
4922020-10-20T16:29:00  *** mol has quit IRC
4932020-10-20T16:30:13  *** bitcoin-git has joined #bitcoin-core-dev
4942020-10-20T16:30:13  <bitcoin-git> [bitcoin] hebasto opened pull request #20201: build: pkg-config related cleanup (master...201020-pkg) https://github.com/bitcoin/bitcoin/pull/20201
4952020-10-20T16:30:14  *** bitcoin-git has left #bitcoin-core-dev
4962020-10-20T16:31:28  *** bitcoin-git has joined #bitcoin-core-dev
4972020-10-20T16:31:28  <bitcoin-git> [bitcoin] achow101 opened pull request #20202: wallet: Make BDB support optional (master...opt-sqlite-bdb) https://github.com/bitcoin/bitcoin/pull/20202
4982020-10-20T16:31:29  *** bitcoin-git has left #bitcoin-core-dev
4992020-10-20T16:31:58  *** andreacab has joined #bitcoin-core-dev
5002020-10-20T16:36:36  *** andreacab has quit IRC
5012020-10-20T16:38:22  *** andreacab has joined #bitcoin-core-dev
5022020-10-20T16:38:39  *** rabidus has joined #bitcoin-core-dev
5032020-10-20T16:42:49  <hebasto> jonasschnelli: around?
5042020-10-20T16:48:15  *** afk11 has quit IRC
5052020-10-20T17:12:58  *** ossifrage has quit IRC
5062020-10-20T17:15:14  *** owowo has quit IRC
5072020-10-20T17:19:33  *** owowo has joined #bitcoin-core-dev
5082020-10-20T17:20:57  *** lightlike has joined #bitcoin-core-dev
5092020-10-20T17:31:05  *** DeanGuss has quit IRC
5102020-10-20T17:31:37  *** DeanGuss has joined #bitcoin-core-dev
5112020-10-20T17:31:48  *** Guyver2 has joined #bitcoin-core-dev
5122020-10-20T17:33:32  *** morcos has quit IRC
5132020-10-20T17:33:46  *** morcos has joined #bitcoin-core-dev
5142020-10-20T17:37:30  *** andreacab has quit IRC
5152020-10-20T17:38:09  *** andreacab has joined #bitcoin-core-dev
5162020-10-20T17:42:59  *** andreacab has quit IRC
5172020-10-20T17:47:11  *** sr_gi has quit IRC
5182020-10-20T17:47:49  *** sr_gi has joined #bitcoin-core-dev
5192020-10-20T17:55:10  <luke-jr> achow101: did a UUID of some sort get in the SQLite wallet, to replace the BDB unique id?
5202020-10-20T17:55:41  <achow101> luke-jr: no. I think we determined it wasn't needed
5212020-10-20T17:55:44  <luke-jr> but it is
5222020-10-20T17:55:52  <luke-jr> ugh
5232020-10-20T17:55:54  <achow101> the BDB unique id is only needed to avoid some caching problem
5242020-10-20T17:55:59  <achow101> what is it needed for?
5252020-10-20T17:56:18  <luke-jr> prune locks, at least; who knows what else in the future
5262020-10-20T17:56:29  <achow101> how so?
5272020-10-20T17:56:56  <luke-jr> to uniquely identify a wallet no matter where the user moves/renames it
5282020-10-20T17:58:43  <achow101> it can be added in later
5292020-10-20T17:58:49  <luke-jr> not really
5302020-10-20T17:58:55  <luke-jr> backups made before the upgrade won't have it
5312020-10-20T18:00:01  *** grafa has quit IRC
5322020-10-20T18:03:21  <achow101> why do wallet files need to be uniquely identified?
5332020-10-20T18:03:38  <achow101> I remember looking at this before but I can't find the commit
5342020-10-20T18:06:12  <luke-jr> achow101: eg #19463
5352020-10-20T18:06:14  <gribble> https://github.com/bitcoin/bitcoin/issues/19463 | Prune locks by luke-jr · Pull Request #19463 · bitcoin/bitcoin · GitHub
5362020-10-20T18:06:31  <luke-jr> another example would be backup reminders
5372020-10-20T18:10:20  <achow101> i still don't see how not having a preexisting id is a problem. If you add the id to a wallet, and add the prune lock for that id, then we won't prune beyond the requirement for that wallet. when the backup is restored, sure a new id is generated, but we still haven't pruned too far
5382020-10-20T18:10:21  *** ossifrage has joined #bitcoin-core-dev
5392020-10-20T18:10:25  <achow101> it's just extra stuff in the db
5402020-10-20T18:17:07  <luke-jr> and have a poor UX because we have the wallet twice in prune locks confusing the user
5412020-10-20T18:17:24  <luke-jr> nevermind unknown future use cases
5422020-10-20T18:19:30  <achow101> sure, but a unique wallet id should not be at the db level
5432020-10-20T18:20:38  <sipa> having a warning for the user that two copies of the same wallets have been loaded seems moderately useful in any case
5442020-10-20T18:20:57  <achow101> we could make the id deterministic based on active spkman
5452020-10-20T18:21:21  <luke-jr> actually, right now users expect an error if they try to load two copies..
5462020-10-20T18:21:36  <achow101> for legacy, use the current seed, or default key for the non-hd wallets as they still have default key. for descriptor, hash the active descriptors
5472020-10-20T18:21:42  <sipa> luke-jr: i usually just find it annoying that i can't load them at the same time :)
5482020-10-20T18:21:48  <sipa> but a warning seems useful
5492020-10-20T18:22:14  <achow101> the error for loading duplicates is bec2020-10-21T05:57:58  *** jesseposner has joined #bitcoin-core-dev