12020-10-09T00:00:01 *** dorena has quit IRC
22020-10-09T00:00:24 *** DeanGuss has quit IRC
32020-10-09T00:05:43 *** DeanGuss has joined #bitcoin-core-dev
42020-10-09T00:10:49 *** davterra has joined #bitcoin-core-dev
52020-10-09T00:16:16 *** AaronvanW has quit IRC
62020-10-09T00:18:04 *** diogorsergio has quit IRC
72020-10-09T00:18:30 *** proofofkeags_ has quit IRC
82020-10-09T00:18:30 *** proofofkeags has quit IRC
92020-10-09T00:21:03 *** Wolfy87 has joined #bitcoin-core-dev
102020-10-09T00:21:57 *** molz_ has joined #bitcoin-core-dev
112020-10-09T00:24:31 *** bjkkkk has joined #bitcoin-core-dev
122020-10-09T00:25:24 *** mol_ has quit IRC
132020-10-09T00:27:13 *** rc_423 has quit IRC
142020-10-09T00:28:20 *** rc_423 has joined #bitcoin-core-dev
152020-10-09T00:40:35 *** placa has joined #bitcoin-core-dev
162020-10-09T00:44:40 *** bjkkkk has quit IRC
172020-10-09T00:46:12 *** S3RK has joined #bitcoin-core-dev
182020-10-09T00:53:40 *** AaronvanW has joined #bitcoin-core-dev
192020-10-09T00:58:07 *** AaronvanW has quit IRC
202020-10-09T01:01:49 *** S3RK has quit IRC
212020-10-09T01:05:08 *** diogorsergio has joined #bitcoin-core-dev
222020-10-09T01:11:54 *** nick108 has joined #bitcoin-core-dev
232020-10-09T01:23:50 *** nick108 has quit IRC
242020-10-09T01:25:28 *** sr_gi has quit IRC
252020-10-09T01:26:07 *** sr_gi has joined #bitcoin-core-dev
262020-10-09T01:26:28 *** pinheadmz has quit IRC
272020-10-09T01:33:26 *** pinheadmz has joined #bitcoin-core-dev
282020-10-09T01:53:22 *** pinheadmz has quit IRC
292020-10-09T01:59:51 *** pinheadmz has joined #bitcoin-core-dev
302020-10-09T02:07:46 *** proofofkeags_ has joined #bitcoin-core-dev
312020-10-09T02:07:46 *** proofofkeags has joined #bitcoin-core-dev
322020-10-09T02:09:58 *** AaronvanW has joined #bitcoin-core-dev
332020-10-09T02:15:04 *** AaronvanW has quit IRC
342020-10-09T02:21:47 *** pinheadmz has quit IRC
352020-10-09T02:43:35 *** AaronvanW has joined #bitcoin-core-dev
362020-10-09T02:47:47 *** AaronvanW has quit IRC
372020-10-09T03:00:01 *** Wolfy87 has quit IRC
382020-10-09T03:15:44 *** proofofkeags_ has quit IRC
392020-10-09T03:15:44 *** proofofkeags has quit IRC
402020-10-09T03:16:52 *** AaronvanW has joined #bitcoin-core-dev
412020-10-09T03:20:59 *** AaronvanW has quit IRC
422020-10-09T03:21:55 *** jpcw1 has joined #bitcoin-core-dev
432020-10-09T03:28:04 <sipa> vasild: https://github.com/sipa/bitcoin/commits/202010_compactsize_bound
442020-10-09T03:28:26 <sipa> use with Using<CompactSizeFormatter<false>>(obj) instead of COMPACTSIZE(obj)
452020-10-09T03:51:57 *** AaronvanW has joined #bitcoin-core-dev
462020-10-09T03:56:37 *** AaronvanW has quit IRC
472020-10-09T04:17:51 *** S3RK has joined #bitcoin-core-dev
482020-10-09T04:20:42 *** S3RK has quit IRC
492020-10-09T04:22:25 *** S3RK has joined #bitcoin-core-dev
502020-10-09T04:25:28 *** AaronvanW has joined #bitcoin-core-dev
512020-10-09T04:27:15 *** S3RK has quit IRC
522020-10-09T04:30:30 *** AaronvanW has quit IRC
532020-10-09T04:56:02 *** S3RK has joined #bitcoin-core-dev
542020-10-09T05:01:58 *** AaronvanW has joined #bitcoin-core-dev
552020-10-09T05:03:05 *** mol_ has joined #bitcoin-core-dev
562020-10-09T05:05:59 *** molz_ has quit IRC
572020-10-09T05:06:05 *** AaronvanW has quit IRC
582020-10-09T05:30:52 *** S3RK has quit IRC
592020-10-09T05:33:21 <hebasto> sipa: re "it's a protection for the case where CompactSize format is used to actually encode a size" in which cases? (`MAX_SIZE = 0x02000000` seems undocumented in the code)
602020-10-09T05:38:58 <hebasto> it was added with alert system in 401926283a200994ecd7df8eae8ced8e0b067c46
612020-10-09T05:39:06 <hebasto> right?
622020-10-09T05:42:24 *** AaronvanW has joined #bitcoin-core-dev
632020-10-09T05:42:33 <hebasto> as alert system has been removed could we just revert back s/MAX_SIZE/INT_MAX/ ?
642020-10-09T05:44:26 *** placa has quit IRC
652020-10-09T05:47:08 *** AaronvanW has quit IRC
662020-10-09T05:55:25 <sipa> hebasto: most satoshi commits were aggregates of a bunch of unrelated things
672020-10-09T05:55:41 <sipa> MAX_SIZE is the maximum size of serialized objects, 32 MiB
682020-10-09T05:56:22 <hebasto> I see. Thanks!
692020-10-09T06:00:02 *** jpcw1 has quit IRC
702020-10-09T06:00:39 <hebasto> sipa: do you think that `TxRequestTracker::CountCandidates` is really required to be a part of `TxRequestTracker` public interface?
712020-10-09T06:02:03 *** kristapsk has quit IRC
722020-10-09T06:03:36 <sipa> hebasto: it makes testing easier
732020-10-09T06:03:45 <sipa> but apart from that, it's unneeded - for now at least
742020-10-09T06:03:55 <sipa> it could be used as part of an overload check later
752020-10-09T06:11:24 *** brianhoffman has quit IRC
762020-10-09T06:11:30 *** brianhoffman_ has joined #bitcoin-core-dev
772020-10-09T06:19:53 *** AaronvanW has joined #bitcoin-core-dev
782020-10-09T06:22:09 *** BartK has joined #bitcoin-core-dev
792020-10-09T06:24:10 *** AaronvanW has quit IRC
802020-10-09T06:40:41 *** molz_ has joined #bitcoin-core-dev
812020-10-09T06:43:59 *** mol_ has quit IRC
822020-10-09T06:44:18 *** andreacab has joined #bitcoin-core-dev
832020-10-09T06:44:58 *** S3RK has joined #bitcoin-core-dev
842020-10-09T06:46:28 *** bitcoin-git has joined #bitcoin-core-dev
852020-10-09T06:46:28 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d9de00b3e067...380705ef4f00
862020-10-09T06:46:28 <bitcoin-git> bitcoin/master faf2999 MarcoFalke: cirrus: Use kvm to avoid spurious CI failures in the default virtualizatio...
872020-10-09T06:46:29 <bitcoin-git> bitcoin/master 380705e MarcoFalke: Merge #20106: cirrus: Use kvm to avoid spurious CI failures in the default...
882020-10-09T06:46:30 *** bitcoin-git has left #bitcoin-core-dev
892020-10-09T06:46:48 *** bitcoin-git has joined #bitcoin-core-dev
902020-10-09T06:46:48 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #20106: cirrus: Use kvm to avoid spurious CI failures in the default virtualization cluster (master...2010-ciOtherVirt) https://github.com/bitcoin/bitcoin/pull/20106
912020-10-09T06:46:49 *** bitcoin-git has left #bitcoin-core-dev
922020-10-09T06:57:34 *** AaronvanW has joined #bitcoin-core-dev
932020-10-09T06:59:13 *** jonatack has quit IRC
942020-10-09T07:01:56 *** AaronvanW has quit IRC
952020-10-09T07:14:52 *** bitcoin-git has joined #bitcoin-core-dev
962020-10-09T07:14:53 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #20103: test: Enable mocktime RPC for all test chains (master...2010-testMockAllChains) https://github.com/bitcoin/bitcoin/pull/20103
972020-10-09T07:14:53 <vasild> hi
982020-10-09T07:15:01 *** bitcoin-git has left #bitcoin-core-dev
992020-10-09T07:17:08 *** bitcoin-git has joined #bitcoin-core-dev
1002020-10-09T07:17:08 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #20112: test: Speed up wallet_resendwallettransactions with mockscheduler RPC (master...2010-testFasterMock) https://github.com/bitcoin/bitcoin/pull/20112
1012020-10-09T07:17:09 *** bitcoin-git has left #bitcoin-core-dev
1022020-10-09T07:18:10 <sipa> vasild: morning
1032020-10-09T07:18:31 <vasild> evening :)
1042020-10-09T07:18:33 <vasild> (for you)
1052020-10-09T07:19:23 <vasild> is it on purpose that WriteCompactSize() can write big numbers, but ReadCompactSize() cannot read them?
1062020-10-09T07:22:12 <sipa> vasild: i think in the compactsize-is-only-for-sizes setting we used to have, the issue just didn't occur
1072020-10-09T07:22:32 <sipa> as it's not possible to have such a big object to begin with
1082020-10-09T07:22:54 <vasild> yeah, so writecompactsize was never called with big numbers
1092020-10-09T07:23:02 <sipa> indeed
1102020-10-09T07:23:17 <sipa> (and the usage in bip152 is restricted to 16-bit numbers, which obviously won't have any problems)
1112020-10-09T07:23:22 <vasild> I will steal that commit https://github.com/sipa/bitcoin/commit/6edfab492aa67e421af556728c1b8b4d17826b80
1122020-10-09T07:27:34 <vasild> I am just curous - any idea what are those high service flags 0x800043d and 0x800000d that cannot be a result of bitwise-or-ing NODE_* flags?
1132020-10-09T07:27:59 <vasild> of course any peer is free to claim whatever they want in their service flags, including 0xfffff...
1142020-10-09T07:28:14 <sipa> some high bits are used for private extensions
1152020-10-09T07:28:18 <sipa> not sure what this is
1162020-10-09T07:28:41 <vasild> ok
1172020-10-09T07:29:07 <hebasto> sipa: good idea to rename CompactSize
1182020-10-09T07:29:26 <sipa> vasild: what software/user agent reports these?
1192020-10-09T07:29:58 <vasild> I did not record that
1202020-10-09T07:30:30 <vasild> just added printf() in CAddress::unserialize to see what is coming in from the network
1212020-10-09T07:32:25 *** AaronvanW has joined #bitcoin-core-dev
1222020-10-09T07:34:50 <vasild> now I did -addnode=62.107.200.30:8333 to see the user agent
1232020-10-09T07:34:59 <sipa> they're uninteresting
1242020-10-09T07:35:06 <sipa> my dns seed crawler sees them too
1252020-10-09T07:35:20 <sipa> but they're from a variaety of innocently-loking user agents
1262020-10-09T07:35:32 <vasild> but now getnetworkinfo shows
1272020-10-09T07:35:36 <vasild> "addr": "62.107.200.30:8333",
1282020-10-09T07:35:40 <vasild> "services": "000000000000040d",
1292020-10-09T07:35:44 <vasild> :-O
1302020-10-09T07:35:47 <sipa> hmm
1312020-10-09T07:35:50 *** jonatack has joined #bitcoin-core-dev
1322020-10-09T07:35:57 <vasild> yeah, and innocent "subver": "/Satoshi:0.20.1/",
1332020-10-09T07:36:06 <sipa> are they being rumoured with this bit set... but then not reported in the version message?
1342020-10-09T07:36:59 <hebasto> could this hurt the network?
1352020-10-09T07:37:00 *** AaronvanW has quit IRC
1362020-10-09T07:38:11 <vasild> sipa: must be that or something else I am missing
1372020-10-09T07:38:14 <sipa> i don't think so
1382020-10-09T07:38:15 <vasild> I just saw:
1392020-10-09T07:38:16 <vasild> CAddress::unser: time=1602210665, services=67109901, addr=178.128.96.96:8333
1402020-10-09T07:38:19 <vasild> from my printf
1412020-10-09T07:38:40 <vasild> shutdown, restart with -addnode=178.128.96.96:8333
1422020-10-09T07:38:56 <vasild> and getpeerinfo: "addr": "178.128.96.96:8333",
1432020-10-09T07:39:00 <vasild> "services": "000000000000000d",
1442020-10-09T07:40:10 <vasild> we don't do any "filter away any unknown service bits before displaying in getpeerinfo, right?
1452020-10-09T07:41:02 *** Pavlenex has joined #bitcoin-core-dev
1462020-10-09T07:41:26 <sipa> vasild: i don't think so
1472020-10-09T07:43:23 <vasild> just for reference, here is my dummy printf() in CAddress unserialize: https://bpa.st/JYYA
1482020-10-09T07:45:45 <sipa> looks right
1492020-10-09T07:48:28 <vasild> ok, assuming they get gossiped with the flags but are later not present in the version message when we actually connect
1502020-10-09T07:49:26 <sipa> perhaps some broken software is relaying them with that bit set
1512020-10-09T07:50:04 <vasild> wumpus: just to confirm - yes, 0.20 would start on a 0.21-modified-peers.dat as if that file was not present, I also think it is ok. Except the obscure/scary deserialize error messages
1522020-10-09T07:50:51 <sipa> perhaps we can give a nicer error message in the future for upgrades
1532020-10-09T07:50:56 <sipa> but for old software it's too late
1542020-10-09T07:50:57 <vasild> given I will be modifying #19954 I will add one line at the start of unserialize to check if the version is too high
1552020-10-09T07:51:00 <gribble> https://github.com/bitcoin/bitcoin/issues/19954 | tor: complete the TORv3 implementation by vasild · Pull Request #19954 · bitcoin/bitcoin · GitHub
1562020-10-09T07:51:02 <vasild> exactly
1572020-10-09T07:51:59 <vasild> and print something like "detected file format of peers.dat from the future: 4, I can only understand up to 3, starting operation as if peers.dat is empty"
1582020-10-09T07:52:40 <hebasto> sipa: if their software is broken should we discourage those peers?
1592020-10-09T07:54:45 *** S3RK has quit IRC
1602020-10-09T07:55:21 *** andreacab has quit IRC
1612020-10-09T07:55:27 <vasild> maybe a honest/legit/unbroken peer is just relaying some shi^H^Hstuff that was given to him by a broken/malicious guy
1622020-10-09T07:55:47 *** andreacab has joined #bitcoin-core-dev
1632020-10-09T07:56:01 <vasild> we don't want to flag the legit peer as misbehaving
1642020-10-09T07:56:07 <hebasto> right
1652020-10-09T07:56:40 *** andreacab has quit IRC
1662020-10-09T07:56:45 <vasild> or also those high service bits could have some purpose, I guess, it is not certain that they are due to broken or malicious software
1672020-10-09T07:56:48 *** andreacab has joined #bitcoin-core-dev
1682020-10-09T07:57:17 * hebasto "hidden service" :D
1692020-10-09T07:58:01 <vasild> did somebody develop a decentralized instant message chat application using bitcoin p2p network, sneaking the data via the service bits?
1702020-10-09T07:59:07 <MarcoFalke> it would be good to log the peer that sent the high bits
1712020-10-09T07:59:24 <sipa> MarcoFalke: unfortunately, they're most likely not the ones who introduced it
1722020-10-09T08:00:39 <vasild> what happens if a node receives via gossip the same address:port but with different service bits?
1732020-10-09T08:01:01 <MarcoFalke> does addrman correct the service bits when a version msg is received?
1742020-10-09T08:01:14 <vasild> that too!
1752020-10-09T08:01:34 <sipa> they get OR'ed together
1762020-10-09T08:01:43 <sipa> but i hope that on an actual connection, it's overwritten
1772020-10-09T08:02:06 *** Pavlenex has quit IRC
1782020-10-09T08:02:46 <vasild> they get OR'ed :( so a node cannot correct his by re-advertising it regularly. Once somebody adds some high bits to his addr:port, it is over.
1792020-10-09T08:02:57 <sipa> we should fix that
1802020-10-09T08:03:09 <sipa> whatever we receive from the node itself should be written exactly into addrman
1812020-10-09T08:03:12 <vasild> change to "newer one overwrites old one"?
1822020-10-09T08:03:28 <sipa> i think OR'ing makes sense for rumoured addr messages
1832020-10-09T08:04:02 <vasild> I agree that if we connect directly then whatever the peer says is to overwrite the other stuff
1842020-10-09T08:04:10 <sipa> but if we receive information from the IP itself (on an outgoing connection), it should overwrite
1852020-10-09T08:04:38 *** AaronvanW has joined #bitcoin-core-dev
1862020-10-09T08:04:38 *** S3RK has joined #bitcoin-core-dev
1872020-10-09T08:09:09 *** AaronvanW has quit IRC
1882020-10-09T08:13:13 <jonatack> catching up with the discussion... yes, the issue I reported is the DB:deserialise error messages and peers.dat being recreated; bitcoind operates fine otherwise. We can't fix the older software, but we can communicate the situation clearly to users (and hopefully fix it henceforth).
1892020-10-09T08:16:35 <wumpus> sipa: it's more of a warning message anyway isn't it, people that don't regaularly check the log won't even notice it
1902020-10-09T08:16:51 <wumpus> vasild: thanks for confirming, I think there's no problem in that case at all
1912020-10-09T08:17:39 <wumpus> if you say "error" I was expecting some kind of emergency shutdown, that *would* be scary, it simply saying that it's unable to load the file and start from scratch isn't scary as such
1922020-10-09T08:18:32 <vasild> y
1932020-10-09T08:18:36 <jonatack> well, anyone who greps the past log for errors will see
1942020-10-09T08:18:37 <jonatack> ERROR: DeserializeDB: Deserialize or I/O error - ReadCompactSize(): size too large: iostream error
1952020-10-09T08:18:53 <jonatack> Invalid or missing peers.dat; recreating
1962020-10-09T08:19:00 <wumpus> yes
1972020-10-09T08:19:09 <vasild> I though jonatack's disk has developed bad sectors :-D
1982020-10-09T08:19:20 <jonatack> that allcaps screaming ERROR is a bit worrisome :D
1992020-10-09T08:19:21 <vasild> thought
2002020-10-09T08:19:24 <wumpus> I agree it could have been avoided with a version marker
2012020-10-09T08:20:16 <wumpus> jonatack: that's nothing, those errors used to appear for malformed incoming *network packets*
2022020-10-09T08:20:21 <wumpus> ERRORS i mean
2032020-10-09T08:21:07 <wumpus> debug.log used to be one big file full of screaming :)
2042020-10-09T08:21:16 <jonatack> hehe
2052020-10-09T08:21:39 <jonatack> the halloween release
2062020-10-09T08:22:40 <wumpus> change the bitcoin logo for a ð
2072020-10-09T08:23:28 *** Pavlenex has joined #bitcoin-core-dev
2082020-10-09T08:23:30 <jonatack> fewer color change proposals :)
2092020-10-09T08:25:32 <fanquake> orange.bikeshed.com
2102020-10-09T08:32:49 *** worc3131 has joined #bitcoin-core-dev
2112020-10-09T08:39:06 *** andreacab has quit IRC
2122020-10-09T08:39:33 *** andreacab has joined #bitcoin-core-dev
2132020-10-09T08:42:58 *** AaronvanW has joined #bitcoin-core-dev
2142020-10-09T08:43:06 *** Klox048093 has joined #bitcoin-core-dev
2152020-10-09T08:43:06 *** worc3131 has quit IRC
2162020-10-09T08:44:04 *** Klox04809 has quit IRC
2172020-10-09T08:47:34 *** AaronvanW has quit IRC
2182020-10-09T08:49:25 *** andreacab has quit IRC
2192020-10-09T08:55:26 *** andreacab has joined #bitcoin-core-dev
2202020-10-09T08:55:55 *** andreaca_ has joined #bitcoin-core-dev
2212020-10-09T09:00:02 *** BartK has quit IRC
2222020-10-09T09:00:40 *** AaronvanW has joined #bitcoin-core-dev
2232020-10-09T09:03:47 <vasild> jonatack: https://github.com/bitcoin/bitcoin/pull/19954#discussion_r502280047 "I test if my suggestions compile before making them"... and I did not test that it does not compile before I replied :-/
2242020-10-09T09:04:14 <vasild> I guess it compiles because stream is a pointer which remains unmodified (the pointer itself) after the call to stream->ignore()
2252020-10-09T09:04:25 *** kexkey has quit IRC
2262020-10-09T09:04:58 <vasild> but anyway, semantically we do modify the state of the stream by the ignore() call, so I dont think it should be tagged with const
2272020-10-09T09:06:14 *** andreaca_ has quit IRC
2282020-10-09T09:06:40 *** andreacab has joined #bitcoin-core-dev
2292020-10-09T09:08:04 *** andreaca_ has joined #bitcoin-core-dev
2302020-10-09T09:10:47 *** andreacab has quit IRC
2312020-10-09T09:21:05 *** tw1sted1 has joined #bitcoin-core-dev
2322020-10-09T09:22:35 *** andreaca_ has quit IRC
2332020-10-09T09:24:20 *** andreacab has joined #bitcoin-core-dev
2342020-10-09T09:26:38 *** andreacab has quit IRC
2352020-10-09T09:27:06 *** andreacab has joined #bitcoin-core-dev
2362020-10-09T09:27:13 *** mrostecki has joined #bitcoin-core-dev
2372020-10-09T09:29:23 *** Pavlenex has quit IRC
2382020-10-09T09:31:23 *** andreacab has quit IRC
2392020-10-09T09:33:18 <jonatack> vasild: no worries, it's an edge case question, was just to learn
2402020-10-09T09:35:39 <vasild> jonatack: my reasoning is "if a method changes the object in a way that can be observed from outside, then it should not be const"
2412020-10-09T09:37:20 *** AaronvanW has quit IRC
2422020-10-09T09:37:38 *** AaronvanW has joined #bitcoin-core-dev
2432020-10-09T09:39:18 *** andreacab has joined #bitcoin-core-dev
2442020-10-09T09:39:59 <jonatack> right. looking at it led me to https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#con2-by-default-make-member-functions-const and http://www.cplusplus.com/forum/general/12087/
2452020-10-09T09:40:07 <jonatack> am re-reviewing 19954
2462020-10-09T09:44:57 *** mrostecki has quit IRC
2472020-10-09T09:46:45 *** sr_gi has quit IRC
2482020-10-09T09:47:32 *** sr_gi has joined #bitcoin-core-dev
2492020-10-09T09:52:14 *** tw1sted1 has quit IRC
2502020-10-09T10:00:11 <jonatack> vasild: nice, in my testing the patch has fixed the DB deserialize errors and peers.dat messages
2512020-10-09T10:01:11 <vasild> \o/
2522020-10-09T10:03:07 *** bitcoin-git has joined #bitcoin-core-dev
2532020-10-09T10:03:07 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/380705ef4f00...6854dbdc88d7
2542020-10-09T10:03:08 <bitcoin-git> bitcoin/master 2dc79c4 Hennadii Stepanov: doc: Update and improve files.md
2552020-10-09T10:03:08 <bitcoin-git> bitcoin/master 6854dbd fanquake: Merge #20076: doc: Update and improve files.md
2562020-10-09T10:03:19 *** bitcoin-git has left #bitcoin-core-dev
2572020-10-09T10:03:36 *** bitcoin-git has joined #bitcoin-core-dev
2582020-10-09T10:03:37 <bitcoin-git> [bitcoin] fanquake merged pull request #20076: doc: Update and improve files.md (master...201004-files) https://github.com/bitcoin/bitcoin/pull/20076
2592020-10-09T10:03:48 *** bitcoin-git has left #bitcoin-core-dev
2602020-10-09T10:05:41 *** belcher_ has joined #bitcoin-core-dev
2612020-10-09T10:05:53 <jonatack> vasild: restarting on, say, 0.18.1, I see "ERROR: DeserializeDB: Deserialize or I/O error - CAutoFile::read: end of file: iostream error" and "Invalid or missing peers.dat; recreating", as we mention in the new release notes, but not on 19954 after `cp onion_private_key onion_v3_private_key`
2622020-10-09T10:06:26 <jonatack> \o/ indeed :)
2632020-10-09T10:08:07 *** belcher has quit IRC
2642020-10-09T10:08:41 *** bitcoin-git has joined #bitcoin-core-dev
2652020-10-09T10:08:42 <bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/6854dbdc88d7...12a1c3ad1a43
2662020-10-09T10:08:43 <bitcoin-git> bitcoin/master 99992e7 MarcoFalke: doc: Collect release-notes snippets
2672020-10-09T10:08:43 <bitcoin-git> bitcoin/master faa0847 MarcoFalke: doc: Add release notes for #20101
2682020-10-09T10:08:44 <bitcoin-git> bitcoin/master 12a1c3a fanquake: Merge #20107: doc: Collect release-notes snippets
2692020-10-09T10:08:45 *** bitcoin-git has left #bitcoin-core-dev
2702020-10-09T10:09:01 *** bitcoin-git has joined #bitcoin-core-dev
2712020-10-09T10:09:02 <bitcoin-git> [bitcoin] fanquake merged pull request #20107: doc: Collect release-notes snippets (master...2010-docRelSnip) https://github.com/bitcoin/bitcoin/pull/20107
2722020-10-09T10:09:03 *** bitcoin-git has left #bitcoin-core-dev
2732020-10-09T10:10:23 *** vasild has quit IRC
2742020-10-09T10:12:21 *** vasild has joined #bitcoin-core-dev
2752020-10-09T10:13:48 *** shesek has quit IRC
2762020-10-09T10:18:29 *** Imogene64Boyer has joined #bitcoin-core-dev
2772020-10-09T10:20:36 *** andreacab has quit IRC
2782020-10-09T10:21:04 *** andreacab has joined #bitcoin-core-dev
2792020-10-09T10:25:37 *** andreacab has quit IRC
2802020-10-09T10:27:39 *** ericholscher has joined #bitcoin-core-dev
2812020-10-09T10:28:04 *** promag has joined #bitcoin-core-dev
2822020-10-09T10:44:14 *** promag has quit IRC
2832020-10-09T10:45:46 *** Imogene64Boyer has quit IRC
2842020-10-09T10:45:58 *** promag has joined #bitcoin-core-dev
2852020-10-09T10:46:00 *** andreacab has joined #bitcoin-core-dev
2862020-10-09T10:49:33 *** andreacab has quit IRC
2872020-10-09T10:49:59 *** andreacab has joined #bitcoin-core-dev
2882020-10-09T10:55:02 *** mrostecki has joined #bitcoin-core-dev
2892020-10-09T10:56:56 *** andreacab has quit IRC
2902020-10-09T10:58:41 *** andreacab has joined #bitcoin-core-dev
2912020-10-09T11:02:25 *** kyoo[m] has quit IRC
2922020-10-09T11:02:27 *** TheFuzzStone[m] has quit IRC
2932020-10-09T11:02:34 *** sethrogers23[m] has quit IRC
2942020-10-09T11:02:36 *** tianshi[m] has quit IRC
2952020-10-09T11:02:46 *** rcrtn32002[m] has quit IRC
2962020-10-09T11:02:46 *** snowkeld[m] has quit IRC
2972020-10-09T11:02:49 *** RaphalBentgeac[m has quit IRC
2982020-10-09T11:02:50 *** Pasta[m] has quit IRC
2992020-10-09T11:02:51 *** icota[m] has quit IRC
3002020-10-09T11:06:01 *** rh0nj has quit IRC
3012020-10-09T11:07:09 *** rh0nj has joined #bitcoin-core-dev
3022020-10-09T11:09:35 *** kristapsk has joined #bitcoin-core-dev
3032020-10-09T11:09:45 *** rcrtn32002[m] has joined #bitcoin-core-dev
3042020-10-09T11:12:43 *** TallTim has quit IRC
3052020-10-09T11:22:38 *** andreacab has quit IRC
3062020-10-09T11:23:04 *** andreacab has joined #bitcoin-core-dev
3072020-10-09T11:26:51 *** snowkeld[m] has joined #bitcoin-core-dev
3082020-10-09T11:26:51 *** TheFuzzStone[m] has joined #bitcoin-core-dev
3092020-10-09T11:26:52 *** icota[m] has joined #bitcoin-core-dev
3102020-10-09T11:26:52 *** Pasta[m] has joined #bitcoin-core-dev
3112020-10-09T11:26:52 *** kyoo[m] has joined #bitcoin-core-dev
3122020-10-09T11:26:52 *** sethrogers23[m] has joined #bitcoin-core-dev
3132020-10-09T11:26:58 *** tianshi[m] has joined #bitcoin-core-dev
3142020-10-09T11:26:58 *** RaphalBentgeac[m has joined #bitcoin-core-dev
3152020-10-09T11:27:07 *** andreacab has quit IRC
3162020-10-09T11:27:14 *** vincenzopalazzo has joined #bitcoin-core-dev
3172020-10-09T11:30:52 *** jonatack has quit IRC
3182020-10-09T11:32:37 *** andreacab has joined #bitcoin-core-dev
3192020-10-09T11:34:00 *** opsec_x122 has joined #bitcoin-core-dev
3202020-10-09T11:34:26 *** ericholscher has quit IRC
3212020-10-09T11:34:26 *** jeremyrubin has quit IRC
3222020-10-09T11:34:26 *** opsec_x12 has quit IRC
3232020-10-09T11:34:26 *** dergoegge has quit IRC
3242020-10-09T11:34:26 *** hsmiths has quit IRC
3252020-10-09T11:34:26 *** mariorz has quit IRC
3262020-10-09T11:34:26 *** noganoo has quit IRC
3272020-10-09T11:36:53 *** EagleTM has joined #bitcoin-core-dev
3282020-10-09T11:39:55 *** EagleTM has quit IRC
3292020-10-09T11:40:12 *** jeremyrubin has joined #bitcoin-core-dev
3302020-10-09T11:40:13 *** dergoegge has joined #bitcoin-core-dev
3312020-10-09T11:40:13 *** hsmiths has joined #bitcoin-core-dev
3322020-10-09T11:40:13 *** mariorz has joined #bitcoin-core-dev
3332020-10-09T11:40:13 *** noganoo has joined #bitcoin-core-dev
3342020-10-09T11:40:25 *** EagleTM has joined #bitcoin-core-dev
3352020-10-09T11:40:54 *** S3RK has quit IRC
3362020-10-09T11:41:49 *** S3RK has joined #bitcoin-core-dev
3372020-10-09T11:42:38 *** opsec_x122 is now known as opsec_x12
3382020-10-09T11:44:17 *** andreacab has quit IRC
3392020-10-09T11:46:05 *** S3RK has quit IRC
3402020-10-09T11:46:54 *** promag has quit IRC
3412020-10-09T11:47:50 *** promag has joined #bitcoin-core-dev
3422020-10-09T11:49:06 *** EagleTM has quit IRC
3432020-10-09T11:49:32 *** EagleTM has joined #bitcoin-core-dev
3442020-10-09T11:52:05 *** promag has quit IRC
3452020-10-09T11:52:34 *** EagleTM has quit IRC
3462020-10-09T11:52:58 *** EagleTM has joined #bitcoin-core-dev
3472020-10-09T11:53:23 *** mrostecki has quit IRC
3482020-10-09T11:57:15 *** EagleTM has quit IRC
3492020-10-09T11:57:38 *** EagleTM has joined #bitcoin-core-dev
3502020-10-09T11:59:56 *** Victorsueca has joined #bitcoin-core-dev
3512020-10-09T12:03:09 *** EagleTM has quit IRC
3522020-10-09T12:03:33 *** EagleTM has joined #bitcoin-core-dev
3532020-10-09T12:21:05 *** dholbach has joined #bitcoin-core-dev
3542020-10-09T12:21:41 *** pinheadmz has joined #bitcoin-core-dev
3552020-10-09T12:26:24 *** setpill has joined #bitcoin-core-dev
3562020-10-09T12:26:51 *** promag has joined #bitcoin-core-dev
3572020-10-09T12:27:26 *** EagleTM has quit IRC
3582020-10-09T12:27:48 *** EagleTM has joined #bitcoin-core-dev
3592020-10-09T12:31:05 *** promag has quit IRC
3602020-10-09T12:33:07 *** jonatack has joined #bitcoin-core-dev
3612020-10-09T12:36:07 *** EagleTM has quit IRC
3622020-10-09T12:36:33 *** EagleTM has joined #bitcoin-core-dev
3632020-10-09T12:37:40 *** Guyver2 has joined #bitcoin-core-dev
3642020-10-09T12:40:01 *** EagleTM has quit IRC
3652020-10-09T12:40:28 *** EagleTM has joined #bitcoin-core-dev
3662020-10-09T12:45:28 *** gloriazhao has quit IRC
3672020-10-09T12:49:08 *** S3RK has joined #bitcoin-core-dev
3682020-10-09T12:53:23 *** S3RK has quit IRC
3692020-10-09T12:54:11 *** EagleTM has quit IRC
3702020-10-09T12:54:38 *** EagleTM has joined #bitcoin-core-dev
3712020-10-09T12:59:52 *** EagleTM has quit IRC
3722020-10-09T13:00:15 *** EagleTM has joined #bitcoin-core-dev
3732020-10-09T13:07:12 *** molz_ has quit IRC
3742020-10-09T13:09:12 <achow101> #proposedwalletmeetingtopic: wallet.dat vs wallet.sqlite
3752020-10-09T13:11:25 *** Eagle[TM] has joined #bitcoin-core-dev
3762020-10-09T13:11:59 *** EagleTM has quit IRC
3772020-10-09T13:16:11 *** Eagle[TM] has quit IRC
3782020-10-09T13:18:15 *** mol has joined #bitcoin-core-dev
3792020-10-09T13:30:16 *** S3RK has joined #bitcoin-core-dev
3802020-10-09T13:34:50 *** Klox0480931 has joined #bitcoin-core-dev
3812020-10-09T13:35:10 *** S3RK has quit IRC
3822020-10-09T13:35:34 *** Klox048093 has quit IRC
3832020-10-09T13:36:33 <hebasto> gh silently fails to "Load more..." of "52 hidden items" on #19988 (
3842020-10-09T13:36:37 <gribble> https://github.com/bitcoin/bitcoin/issues/19988 | Overhaul transaction request logic by sipa · Pull Request #19988 · bitcoin/bitcoin · GitHub
3852020-10-09T14:01:46 *** setpill has quit IRC
3862020-10-09T14:01:58 *** mol_ has joined #bitcoin-core-dev
3872020-10-09T14:05:27 *** mol has quit IRC
3882020-10-09T14:06:20 *** molz_ has joined #bitcoin-core-dev
3892020-10-09T14:07:58 *** mol has joined #bitcoin-core-dev
3902020-10-09T14:09:19 *** mol_ has quit IRC
3912020-10-09T14:11:16 *** molz_ has quit IRC
3922020-10-09T14:29:34 <jonatack> hebasto: saw the same yesterday, i gave up trying to see the discussion :/
3932020-10-09T14:36:57 *** andreacab has joined #bitcoin-core-dev
3942020-10-09T14:37:39 *** luke-jr has quit IRC
3952020-10-09T14:39:55 *** luke-jr has joined #bitcoin-core-dev
3962020-10-09T14:40:27 *** andreacab has quit IRC
3972020-10-09T14:40:43 *** andreacab has joined #bitcoin-core-dev
3982020-10-09T15:00:02 *** dholbach has quit IRC
3992020-10-09T15:01:33 *** kexkey has joined #bitcoin-core-dev
4002020-10-09T15:03:13 *** andreacab has quit IRC
4012020-10-09T15:03:39 *** andreacab has joined #bitcoin-core-dev
4022020-10-09T15:05:20 *** andreaca_ has joined #bitcoin-core-dev
4032020-10-09T15:06:09 *** jonatack has quit IRC
4042020-10-09T15:07:11 *** Talkless has joined #bitcoin-core-dev
4052020-10-09T15:07:58 *** andreacab has quit IRC
4062020-10-09T15:10:55 *** luke-jr has quit IRC
4072020-10-09T15:10:57 <vasild> gh censorship!
4082020-10-09T15:11:14 *** jonatack has joined #bitcoin-core-dev
4092020-10-09T15:12:20 *** kristapsk has quit IRC
4102020-10-09T15:18:03 <michaelfolkson> I don't see how Core is still managed on GitHub in 10 years personally. But will be a massive headache whenever it does move. Ideally done when things are quiet (not with a potential soft fork on the horizon)
4112020-10-09T15:19:00 *** luke-jr has joined #bitcoin-core-dev
4122020-10-09T15:25:25 *** luke-jr has quit IRC
4132020-10-09T15:26:49 *** luke-jr has joined #bitcoin-core-dev
4142020-10-09T15:33:58 <jonatack> ISTM that GitHub is now starting to hide ACKs and re-ACKs as "one similar comment"
4152020-10-09T15:38:13 *** owowo has quit IRC
4162020-10-09T15:39:10 *** owowo has joined #bitcoin-core-dev
4172020-10-09T15:39:48 *** andreaca_ has quit IRC
4182020-10-09T15:40:16 *** andreacab has joined #bitcoin-core-dev
4192020-10-09T15:43:58 *** Talkless has quit IRC
4202020-10-09T15:44:29 *** Talkless has joined #bitcoin-core-dev
4212020-10-09T15:44:42 *** andreacab has quit IRC
4222020-10-09T15:49:45 *** Pavlenex has joined #bitcoin-core-dev
4232020-10-09T15:55:56 *** kers has joined #bitcoin-core-dev
4242020-10-09T15:56:23 *** vincenzopalazzo has quit IRC
4252020-10-09T15:59:51 <wumpus> I'm not sure moving is that much of a headache, many projects have done this, it's just that the only thing after github that makes sense is self-hosting something like gitlab or gitea, which has quite a lot issues of its own, e.g. who hosts the instance
4262020-10-09T16:02:17 <wumpus> I have a weird issue on my freebsd node: it kept making outgoing connections at a rate of ~2 per second, the whole log is full of it, and it wasn't accepting any new blocks. I hope it's not a problem with the TorV3 PR.
4272020-10-09T16:03:07 *** luke-jr has quit IRC
4282020-10-09T16:03:12 <wumpus> also, it segfaulted on shutdown (I can't reproduce this, unfortunately, so don't have a traceback)
4292020-10-09T16:03:15 *** proofofkeags_ has joined #bitcoin-core-dev
4302020-10-09T16:03:15 *** proofofkeags has joined #bitcoin-core-dev
4312020-10-09T16:03:53 *** Talkless has quit IRC
4322020-10-09T16:06:24 *** luke-jr has joined #bitcoin-core-dev
4332020-10-09T16:09:15 *** mol_ has joined #bitcoin-core-dev
4342020-10-09T16:10:20 *** mol has quit IRC
4352020-10-09T16:12:46 <sipa> wumpus: ugh
4362020-10-09T16:14:00 <wumpus> 2020-10-09T15:06:40Z New outbound peer connected: version: 70015, blocks=651964, peer=1018923 (full-relay)
4372020-10-09T16:14:20 <wumpus> that peer id says enough I think
4382020-10-09T16:15:50 <jonatack> wumpus: huh. i have not been seeing that issue with 19954 (on debian)
4392020-10-09T16:15:54 <wumpus> it's not happening on my other TorV3 node though so there's no clear correlation
4402020-10-09T16:16:19 <wumpus> jonatack: right, it might be a local issue for that node
4412020-10-09T16:16:28 <wumpus> currently building plain master
4422020-10-09T16:19:25 *** luke-jr has quit IRC
4432020-10-09T16:24:10 *** S3RK has joined #bitcoin-core-dev
4442020-10-09T16:25:52 *** luke-jr has joined #bitcoin-core-dev
4452020-10-09T16:28:37 *** S3RK has quit IRC
4462020-10-09T16:31:28 *** roconnor has joined #bitcoin-core-dev
4472020-10-09T16:32:53 <luke-jr> wumpus: I'm not sure self-hosting is really an improvement over GitHub, aside from the platform presumably being free software
4482020-10-09T16:33:08 <luke-jr> the goal is probably a decentralised system, but that doesn't exist yet afaik
4492020-10-09T16:34:13 <vasild> there were some attempts to make decentralized alternative of github
4502020-10-09T16:34:20 <wumpus> luke-jr: it's an improvement in that we'd have direct control over the software, so it can't say, start hiding consecutive ACKs behind our back
4512020-10-09T16:34:29 <vasild> wumpus: I have this sysctl on fbsd: kern.corefile=/coredumps/%U.%N.%P.core
4522020-10-09T16:35:02 <wumpus> vasild: good idea
4532020-10-09T16:35:21 <vasild> and /coredumps has 1777 perms so that anybody can plant files in it
4542020-10-09T16:35:26 <luke-jr> wumpus: whoever is hosting can, whether that's GitHub or â?
4552020-10-09T16:35:59 <wumpus> luke-jr: sure, but if it's one of us they're likely going to be more recentive to these kind of complaints than a big corporation
4562020-10-09T16:36:06 <vasild> ulimit -c is "unlimited" but I don't think I configured that myself, maybe it is the default
4572020-10-09T16:36:11 *** shesek has joined #bitcoin-core-dev
4582020-10-09T16:36:11 *** shesek has joined #bitcoin-core-dev
4592020-10-09T16:37:21 <wumpus> same here, it even said in dmesg that it had dumped core but couldn't find the core file
4602020-10-09T16:37:42 <sipa> it dumped Core
4612020-10-09T16:37:52 <luke-jr> they tend to be big files
4622020-10-09T16:38:09 <vasild> does bitcoind change the working directory at startup? to ~/.bitcoin? or to the root /?
4632020-10-09T16:38:10 <wumpus> sipa: heh
4642020-10-09T16:38:23 <wumpus> vasild: no, it doesn't
4652020-10-09T16:38:41 <wumpus> thinking of it, probably daemonize() does though
4662020-10-09T16:38:48 <vasild> so the core should probably in the current directory where you started it
4672020-10-09T16:38:54 <luke-jr> I know Linux is capable of dumping core into a gdb process directly
4682020-10-09T16:39:55 <wumpus> yes, daemon() changes the working directory to /, it has no write access there, so I guess it just lost it
4692020-10-09T16:43:46 <wumpus> I've set vasild's sysctl parameter now so next time it should go to /coredumps/
4702020-10-09T16:44:41 <vasild> mkdir /coredumps && chmod 1777 /coredumps
4712020-10-09T16:45:08 <sipa> comic relief: https://twitter.com/real_or_random/status/1314596135395262467
4722020-10-09T16:45:16 <vasild> remember to rm /coredumps/* periodically because it grows and grows over time ;)
4732020-10-09T16:46:32 *** andreacab has joined #bitcoin-core-dev
4742020-10-09T16:47:36 *** EagleTM has joined #bitcoin-core-dev
4752020-10-09T16:47:37 <vasild> wumpus: but if dmesg says something like "pid 94776 (conftest), jid 0, uid 0: exited on signal 11 (core dumped)
4762020-10-09T16:47:55 <vasild> with "(core dumped)" at the end then it must be somewhere
4772020-10-09T16:49:37 *** andreacab has quit IRC
4782020-10-09T16:50:03 *** andreacab has joined #bitcoin-core-dev
4792020-10-09T16:52:59 *** EagleTM has quit IRC
4802020-10-09T16:53:07 <wumpus> vasild: I couldn't find it at least, but, I 'make clean'ed so deleted the binary by now so I guess there's no point even if I still found it
4812020-10-09T16:53:25 *** EagleTM has joined #bitcoin-core-dev
4822020-10-09T16:53:33 *** cryptapus has quit IRC
4832020-10-09T16:54:21 <luke-jr> hmm
4842020-10-09T16:54:33 *** andreacab has quit IRC
4852020-10-09T16:54:39 <luke-jr> does C undefined behaviour extend to compile time?
4862020-10-09T16:54:56 <luke-jr> can the compiler explode the system when you try to compile it?
4872020-10-09T16:55:00 <sipa> luke-jr: no
4882020-10-09T16:55:16 <sipa> (afaik)
4892020-10-09T16:56:33 <wumpus> don't give compiler authors any ideas
4902020-10-09T16:58:07 <luke-jr> nuts, could have submitted a patch to GCC to erase everything when it encounters mem*
4912020-10-09T16:58:10 <luke-jr> XD
4922020-10-09T16:58:39 <luke-jr> wumpus: hey, at least I didn't suggest telemetrics on UB?
4932020-10-09T17:00:52 *** EagleTM has quit IRC
4942020-10-09T17:01:20 <wumpus> the most disappointing thing about the whole C UB sitution is how little, historically, C compilers have attempted to detect and reject it, I mean if mem* is only reserved for system functions, fair enough, but make it an error or warning.
4952020-10-09T17:01:56 <wumpus> but no they really like their random explosions :)
4962020-10-09T17:02:17 *** cryptapus has joined #bitcoin-core-dev
4972020-10-09T17:04:04 <sipa> the reason i suspect is that they don't want programs to misbehave if memslartbartfast suddenly becomes a new standard library function in C2043, and your code is already using it
4982020-10-09T17:06:58 <luke-jr> they probably would prefer a C22 compiler is C99-compatible too
4992020-10-09T17:07:20 <luke-jr> by making mem* UB, a C22 memfoo doesn't break C99 code
5002020-10-09T17:08:41 <luke-jr> (same thing, but from another angle)
5012020-10-09T17:09:07 <sipa> i guess a better alternative would be to have a way for the STL to declare "reserved but unused" name patterns to the compiler, so it can error if you use a reserved name, rather than needing to resort to the super-heavy "UB" hammer
5022020-10-09T17:09:41 <wumpus> looks like I have the same problem again after merging 19954: my node keeps making outgoing connections, but never gets any blocks
5032020-10-09T17:10:32 <sipa> hmm
5042020-10-09T17:10:35 <sipa> this looks familiar
5052020-10-09T17:10:36 <wumpus> somehow it's dropping all outgoing connections immediately, it stays at 1-3
5062020-10-09T17:10:55 <sipa> Murch: do you remember someone on bitcoin SE complaining about similar behavior?
5072020-10-09T17:10:56 <wumpus> it does succesfully accept incoming connections but that doesn't help
5082020-10-09T17:11:24 <luke-jr> wumpus: to clarify, you mean without 19954 it was okay?
5092020-10-09T17:11:36 <wumpus> luke-jr: yes, without that it seemed to be okay
5102020-10-09T17:11:43 <wumpus> it did receive a few blocks
5112020-10-09T17:12:23 <wumpus> but no crash at shutdown this time
5122020-10-09T17:13:02 <wumpus> but it does look like 19954 is the problem, will try again without that
5132020-10-09T17:13:35 <sipa> oh, ok
5142020-10-09T17:13:45 <sipa> in that case what i remember seeing must have been unrelated
5152020-10-09T17:13:56 <wumpus> probably, unless this triggers a similar condition
5162020-10-09T17:14:09 <wumpus> I did already try deleting peers.dat
5172020-10-09T17:16:47 <achow101> anyone ever see "corrupted size vs. prev_size in fastbins" on stderr before? it's showing up on a change to sqlite wallet that I'm working on
5182020-10-09T17:18:00 <sipa> achow101: i wouldn't know what prev_size or fastbins are
5192020-10-09T17:18:14 <wumpus> googling it, it's a glibc heap corruption error
5202020-10-09T17:18:22 <achow101> it seems to be coming out of libc
5212020-10-09T17:18:46 *** cryptapus has quit IRC
5222020-10-09T17:18:56 <wumpus> but to answer your questino, no, I've never seen it
5232020-10-09T17:19:02 *** cryptapus has joined #bitcoin-core-dev
5242020-10-09T17:19:11 <achow101> great..
5252020-10-09T17:19:13 <luke-jr> valgrind it
5262020-10-09T17:20:18 <achow101> good idea
5272020-10-09T17:23:48 *** mdunnio has joined #bitcoin-core-dev
5282020-10-09T17:28:34 <roconnor> very early on, the glasgow haskell compiler had an infamous bug where it would delete the source file if you tried to compile it and it had a type error.
5292020-10-09T17:28:51 *** mdunnio has quit IRC
5302020-10-09T17:29:27 *** mdunnio has joined #bitcoin-core-dev
5312020-10-09T17:32:01 <luke-jr> XD
5322020-10-09T17:37:33 <sipa> roconnor: type errors are *really* frowned upon
5332020-10-09T17:41:17 <achow101> ah, I had a double free
5342020-10-09T17:43:01 <sipa> achow101: see youtube link above
5352020-10-09T17:44:21 <achow101> heh
5362020-10-09T17:49:45 *** cryptapus has quit IRC
5372020-10-09T17:51:46 *** cryptapus has joined #bitcoin-core-dev
5382020-10-09T17:51:47 *** cryptapus has quit IRC
5392020-10-09T17:51:47 *** cryptapus has joined #bitcoin-core-dev
5402020-10-09T17:59:56 *** filchef has joined #bitcoin-core-dev
5412020-10-09T18:00:01 *** kers has quit IRC
5422020-10-09T18:04:27 *** jonatack has quit IRC
5432020-10-09T18:05:20 *** jonatack has joined #bitcoin-core-dev
5442020-10-09T18:22:14 *** ButterflyOfFire has joined #bitcoin-core-dev
5452020-10-09T18:27:54 *** GankMove has quit IRC
5462020-10-09T18:31:34 *** owowo has quit IRC
5472020-10-09T18:34:53 <wumpus> gah, the peer keeps disconnectiong outgoing connections without logging the reason at all (even with debug=net)
5482020-10-09T18:35:15 <sipa> wumpus: and just with #19954 ?
5492020-10-09T18:35:18 <gribble> https://github.com/bitcoin/bitcoin/issues/19954 | tor: complete the TORv3 implementation by vasild · Pull Request #19954 · bitcoin/bitcoin · GitHub
5502020-10-09T18:35:50 <wumpus> sipa: yes
5512020-10-09T18:35:59 <wumpus> without it, it makes outgoing connections succesfully
5522020-10-09T18:36:55 <sipa> bizarre, and ungood
5532020-10-09T18:37:26 *** owowo has joined #bitcoin-core-dev
5542020-10-09T18:38:21 *** Pavlenex has quit IRC
5552020-10-09T18:40:39 <Murch> sipa: I don't remember any recent posts to that effect.
5562020-10-09T18:44:57 <wumpus> curiously it even happens with listen=0
5572020-10-09T18:46:47 <wumpus> well maybe not so curiously because it's about outgoing connections but at least it's not the tor bind stuff itself that interferes
5582020-10-09T18:47:44 *** ares_ has quit IRC
5592020-10-09T18:50:39 <jonatack> wumpus: when did the issue start? since the latest 19954 pushes?
5602020-10-09T18:51:42 <wumpus> jonatack: I think so, do we have a previous version of the PR somewhere?
5612020-10-09T18:51:57 <wumpus> I'm pretty sure this node was running with TORv3 succesfully at some point
5622020-10-09T18:52:54 <wumpus> will try to bisect the commits
5632020-10-09T18:53:21 <jonatack> there were a couple of important changes this week: on tuesday and today, iirc
5642020-10-09T18:53:56 <wumpus> first I'll try testing the branch itself instead of the branch merged on top of master
5652020-10-09T18:54:51 <wumpus> to rule out a silent merge conflict
5662020-10-09T18:56:18 *** Pavlenex has joined #bitcoin-core-dev
5672020-10-09T18:57:00 *** bitcoin-git has joined #bitcoin-core-dev
5682020-10-09T18:57:01 <bitcoin-git> [bitcoin] jonatack opened pull request #20115: cli: -netinfo quick updates/fixups and release note (master...netinfo-fixups) https://github.com/bitcoin/bitcoin/pull/20115
5692020-10-09T18:57:02 *** bitcoin-git has left #bitcoin-core-dev
5702020-10-09T19:00:07 <meshcollider> #startmeeting
5712020-10-09T19:00:07 <lightningbot> Meeting started Fri Oct 9 19:00:07 2020 UTC. The chair is meshcollider. Information about MeetBot at http://wiki.debian.org/MeetBot.
5722020-10-09T19:00:07 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
5732020-10-09T19:00:14 <achow101> hi\
5742020-10-09T19:00:24 <meshcollider> #bitcoin-core-dev Wallet 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 ariard digi_james amiti fjahr
5752020-10-09T19:00:24 <meshcollider> jeremyrubin emilengler jonatack hebasto jb55 kvaciral ariard digi_james amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
5762020-10-09T19:00:31 <jonatack> hi
5772020-10-09T19:00:49 <hebasto> hi
5782020-10-09T19:00:55 <meshcollider> 2:09 AM <achow101> #proposedwalletmeetingtopic: wallet.dat vs wallet.sqlite
5792020-10-09T19:01:26 <meshcollider> #topic wallet.dat vs wallet.sqlite
5802020-10-09T19:01:50 <achow101> for sqlite wallets, there's been an ongoing question of whether the sqlite wallet files should be named wallet.dat or wallet.sqlite
5812020-10-09T19:02:52 <hebasto> what are pros and cons of each approach?
5822020-10-09T19:03:12 <achow101> the PR currently implements wallet.dat. ryanofsky has been arguing for wallet.sqlite in his review comments
5832020-10-09T19:03:19 <achow101> i wanted to hear what everyone else thinks
5842020-10-09T19:03:42 <Murch> hello
5852020-10-09T19:03:47 <hebasto> I've just started to review that pr, so have no opinion
5862020-10-09T19:03:50 <achow101> for wallet.dat, the arguments are to maintain backwards compatibility with external documentation and tooling, as well as not causing a problem with a specific downgrade scenario
5872020-10-09T19:04:44 <meshcollider> Yeah calling it wallet.dat has the advantage that automatic backup scripts, etc. will continue working fine, and also that users are already conditioned to protecting wallet.dat files
5882020-10-09T19:04:56 <achow101> for wallet.sqlite, it's a clearer naming convention, follows sqlite naming convention, and can't be confused with bdb
5892020-10-09T19:05:38 <jonatack> hm, good arguments for both
5902020-10-09T19:05:41 <achow101> wallet.sqlite also avoids a different set of compatibility prolems
5912020-10-09T19:05:47 <sipa> yeah, i'm very much in the middle
5922020-10-09T19:06:08 <sipa> some of the naming conventions and expectations around them were already broken when we moved to per-wallet directories
5932020-10-09T19:06:20 <sipa> and i don't recall that causing many issues for users
5942020-10-09T19:06:35 <achow101> relevant commens. for wallet.dat: https://github.com/bitcoin/bitcoin/pull/19077#issuecomment-705180018 for wallet.sqlite: https://github.com/bitcoin/bitcoin/pull/19077#pullrequestreview-504980287
5952020-10-09T19:06:43 <sipa> though, the specific "wallet.dat must be protected with your life" filename convention remained
5962020-10-09T19:06:50 <luke-jr> meshcollider: it is already wrong and risks corruption to copy wallet.dat directly
5972020-10-09T19:06:57 <fjahr> hi
5982020-10-09T19:07:00 <hebasto> if users adopted per-wallet dir, we could expect such adoption for .sqlite
5992020-10-09T19:07:03 <sipa> luke-jr: it doesn't if you do it while bitcoind is shut down
6002020-10-09T19:07:14 <meshcollider> luke-jr: that doesn't stop users doing it
6012020-10-09T19:07:24 <luke-jr> meshcollider: breaking such scripts would be an advantage to renaming
6022020-10-09T19:07:37 <sipa> luke-jr: i couldn't disagree more with that
6032020-10-09T19:07:39 <luke-jr> a possible issue is restoring though
6042020-10-09T19:07:56 <achow101> luke-jr: but breaking such scripts would probably result in backups not being made, which is dangerous
6052020-10-09T19:07:58 *** ares_ has joined #bitcoin-core-dev
6062020-10-09T19:08:11 <luke-jr> achow101: most likely would result in errors instead of possibly-corrupt backups
6072020-10-09T19:08:17 <achow101> I would be surprised if said scripts failed in a way that was obvious to the person running it
6082020-10-09T19:08:21 <luke-jr> O.o
6092020-10-09T19:08:26 <sipa> luke-jr: i agree that we should discourage bad practice, but (a) not by making decisions that can actually cause people to lose money and (b) i disagree this is unsupported - it's only supported when bitcoind is not running though
6102020-10-09T19:08:28 <meshcollider> And there are also other tools I imagine, not just backup scripts, which look for wallet.dat by default
6112020-10-09T19:08:34 <luke-jr> if a cronjob fails, typically you get an email
6122020-10-09T19:09:00 <luke-jr> sipa: at least some versions would reuslt in corruption even if bitcoind exited cleanly
6132020-10-09T19:09:07 <achow101> luke-jr: fwiw I have a system backup cronjob and I don't know when/if it fails until I check the logs, and that happens maybe once every 6 months
6142020-10-09T19:09:09 <sipa> how so?
6152020-10-09T19:09:17 <luke-jr> sipa: we used to not flush/close the db
6162020-10-09T19:09:32 <luke-jr> achow101: you should fix that :p
6172020-10-09T19:09:47 <sipa> luke-jr: i believe that was very briefly the case, in ancient times
6182020-10-09T19:09:50 <achow101> luke-jr: right, but that's an example of a backup script failing and the user not knowing
6192020-10-09T19:10:05 <luke-jr> I suppose people doing backups wrong, are also likely to do error notifications wrong
6202020-10-09T19:10:33 <sipa> people will do lots of things wrong
6212020-10-09T19:10:43 <sipa> doesn't mean we shouldn't do a best effort to avoid them losing money
6222020-10-09T19:10:55 <luke-jr> but wallet.dat are currently in a dedicated directory
6232020-10-09T19:11:00 <luke-jr> there's no need for that for sqlite, right?
6242020-10-09T19:11:10 <sipa> that's a good question
6252020-10-09T19:11:34 <achow101> luke-jr: yes, but I think it would be more confusing to users if we stopped doing that
6262020-10-09T19:11:42 <sipa> hmm
6272020-10-09T19:11:49 <jonatack> modulo the risk of users losing money if renamed, a risk i don't feel competent to evaluate, i tend to agree with ryanofsky's arguments
6282020-10-09T19:12:09 <sipa> to me, that'd be one of the advantages of sqlite... not needing a directory for every wallet anymore
6292020-10-09T19:12:51 <luke-jr> btw, even if it's wallet.sqlite, it's not like we're renaming without the user knowing
6302020-10-09T19:13:15 <luke-jr> wouldn't you expect anyone setting up a backup script to check that it works when they create the wallet, at least once? :P
6312020-10-09T19:13:20 <achow101> luke-jr: not necessarily. they'd need to read the release notes, and who the hell does that?
6322020-10-09T19:13:47 <luke-jr> achow101: you're seriously suggesting automatically transforming BDB to sqlite?
6332020-10-09T19:14:04 <luke-jr> without user interaction?
6342020-10-09T19:14:15 <achow101> luke-jr: there's no transformation
6352020-10-09T19:14:31 <achow101> what I mean is that sqlite would be default for descriptor wallets, but the only way you would know that is to read the release notes
6362020-10-09T19:14:32 <luke-jr> ok, so wallet.dat would remain wallet.dat even if new wallets are wallet.sqliteâ¦
6372020-10-09T19:14:51 <achow101> existing wallets are unaffected
6382020-10-09T19:15:17 <luke-jr> so the only way someone should lose data is if they never check for a successful backup ever..
6392020-10-09T19:15:31 <achow101> sipa: I suppose that getting rid of the wallet directory thing would solve both of these problems
6402020-10-09T19:15:33 <luke-jr> or maybe are backing up numerous wallets and expect newly created ones automatically included
6412020-10-09T19:16:57 <achow101> luke-jr: when we get around to implementing bdb to sqlite migration, there could be problems there with the rename
6422020-10-09T19:17:18 <luke-jr> achow101: but we get the chance to tell users when they opt into it
6432020-10-09T19:17:23 <achow101> true
6442020-10-09T19:17:46 <luke-jr> a reason not to rename: acting on file extensions has been kindof deprecated for a long time?
6452020-10-09T19:18:46 <achow101> there's also the problems with restoring, and that one downgrade case where a new wallet.dat is made
6462020-10-09T19:19:43 <meshcollider> IMO we should get rid of individual directories for sqlite, I don't think that would be confusing
6472020-10-09T19:21:29 <achow101> meshcollider: that still has the backup and restore problems, although not the downgrade one if we name the file as the wallet name
6482020-10-09T19:26:25 <achow101> any other comments on this topic?
6492020-10-09T19:27:13 <meshcollider> Did this help make a decision ;)
6502020-10-09T19:27:28 <achow101> not really
6512020-10-09T19:27:33 <fjahr> I'm undecided as well, sorry
6522020-10-09T19:28:14 <achow101> I'll experiment with a no wallet directory approach and see how big the diff is
6532020-10-09T19:28:25 <meshcollider> Yeah that sounds good
6542020-10-09T19:28:27 <meshcollider> Any other topics then?
6552020-10-09T19:29:56 <jonatack> fjahr: at some point, sometime, we should maybe discuss #18418
6562020-10-09T19:29:58 <gribble> https://github.com/bitcoin/bitcoin/issues/18418 | wallet: Increase OUTPUT_GROUP_MAX_ENTRIES to 100 by fjahr · Pull Request #18418 · bitcoin/bitcoin · GitHub
6572020-10-09T19:30:15 <jonatack> perhaps Murch can look at it
6582020-10-09T19:30:43 <jonatack> (just a thought, no need to duscuss now)
6592020-10-09T19:30:55 <fjahr> Yeah, thanks, I guess at the moment nobody has time but maybe in 2 weeks
6602020-10-09T19:32:30 <meshcollider> Ok let's discuss it next time then :)
6612020-10-09T19:32:38 <meshcollider> #endmeeting
6622020-10-09T19:32:38 <lightningbot> Meeting ended Fri Oct 9 19:32:38 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
6632020-10-09T19:32:38 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-10-09-19.00.html
6642020-10-09T19:32:38 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-10-09-19.00.txt
6652020-10-09T19:32:38 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-10-09-19.00.log.html
6662020-10-09T19:32:44 <jonatack> o/
6672020-10-09T19:32:45 <meshcollider> Thanks all
6682020-10-09T19:33:06 <meshcollider> \o
6692020-10-09T19:37:57 *** Pavlenex has quit IRC
6702020-10-09T19:58:17 <luke-jr> btw, I wonder if creating a wallet is really the right response to not finding one named :P
6712020-10-09T20:02:10 <roconnor> In a different program I complained where running an obviously read-only operation would create a new file if the required file didn't exist.
6722020-10-09T20:02:26 <achow101> luke-jr: it definitely isn't and we should remove that behavior
6732020-10-09T20:06:08 *** tripleslash has quit IRC
6742020-10-09T20:06:17 *** [\\\] has joined #bitcoin-core-dev
6752020-10-09T20:25:12 *** kristapsk has joined #bitcoin-core-dev
6762020-10-09T20:25:57 *** S3RK has joined #bitcoin-core-dev
6772020-10-09T20:30:35 *** S3RK has quit IRC
6782020-10-09T20:31:47 *** Guyver2_ has joined #bitcoin-core-dev
6792020-10-09T20:34:08 *** Guyver2 has quit IRC
6802020-10-09T21:00:02 *** ButterflyOfFire has quit IRC
6812020-10-09T21:02:19 *** filchef has quit IRC
6822020-10-09T21:03:02 *** Guyver2_ has quit IRC
6832020-10-09T21:05:05 *** Victorsueca has quit IRC
6842020-10-09T21:21:25 *** wright has joined #bitcoin-core-dev
6852020-10-09T21:31:53 *** brianhoffman has joined #bitcoin-core-dev
6862020-10-09T21:32:30 *** brianhoffman_ has quit IRC
6872020-10-09T21:37:23 *** k3tan has quit IRC
6882020-10-09T21:41:42 *** k3tan has joined #bitcoin-core-dev
6892020-10-09T21:54:43 *** Talkless has joined #bitcoin-core-dev
6902020-10-09T22:10:43 *** vasild has quit IRC
6912020-10-09T22:12:17 *** vasild has joined #bitcoin-core-dev
6922020-10-09T22:20:11 *** tryphe has quit IRC
6932020-10-09T22:20:57 *** tryphe has joined #bitcoin-core-dev
6942020-10-09T22:21:35 <sipa> wumpus: any progress?
6952020-10-09T22:51:45 *** mdunnio has quit IRC
6962020-10-09T22:56:42 *** mdunnio has joined #bitcoin-core-dev
6972020-10-09T22:59:22 *** S3RK has joined #bitcoin-core-dev
6982020-10-09T23:02:01 *** mdunnio has quit IRC
6992020-10-09T23:04:19 *** S3RK has quit IRC
7002020-10-09T23:05:38 *** Talkless has quit IRC
7012020-10-09T23:09:49 *** mol_ has quit IRC
7022020-10-09T23:23:41 *** mol has joined #bitcoin-core-dev
7032020-10-09T23:34:04 *** mdunnio has joined #bitcoin-core-dev
7042020-10-09T23:34:13 *** mol has quit IRC
7052020-10-09T23:39:22 *** mdunnio has quit IRC
7062020-10-09T23:47:14 *** mol has joined #bitcoin-core-dev
7072020-10-09T23:47:46 *** pinheadmz has quit IRC
7082020-10-09T23:52:03 *** pinheadmz has joined #bitcoin-core-dev
7092020-10-09T23:58:36 *** pinheadmz has quit IRC