--- Log opened Tue Nov 03 00:00:05 2020
00:03 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev
00:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:18 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/8387f832d693...5174b534da57
00:18 < bitcoin-git> bitcoin/master c2cf8a1 practicalswift: fuzz: Check for addrv1 compatibility before using addrv1 serializer on CSe...
00:18 < bitcoin-git> bitcoin/master 5174b53 MarcoFalke: Merge #20289: fuzz: Check for addrv1 compatibility before using addrv1 ser...
00:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:18 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #20289: fuzz: Check for addrv1 compatibility before using addrv1 serializer/deserializer on CService (master...fuzzers-service_deserialize-addrv2) https://github.com/bitcoin/bitcoin/pull/20289
00:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:21 -!- greypw [~greypw@unaffiliated/greypw] has quit [Quit: I'll be back!]
00:22 -!- greypw [~greypw@unaffiliated/greypw] has joined #bitcoin-core-dev
00:24 -!- sr_gi [~sr_gi@static-77-88-225-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
00:25 -!- sr_gi [~sr_gi@static-77-88-225-77.ipcom.comunitel.net] has joined #bitcoin-core-dev
00:32 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-dev
00:32 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
00:51 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:51 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/5174b534da57...218fe60d91a9
00:51 < bitcoin-git> bitcoin/master 28f8cb1 practicalswift: fuzz: Fix DecodeHexTx fuzzing harness issue
00:51 < bitcoin-git> bitcoin/master 218fe60 MarcoFalke: Merge #20290: fuzz: Fix DecodeHexTx fuzzing harness issue
00:51 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:51 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:51 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #20290: fuzz: Fix DecodeHexTx fuzzing harness issue (master...fuzzers-decode_tx-fixup) https://github.com/bitcoin/bitcoin/pull/20290
00:51 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:53 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Quit: Leaving]
00:57 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #bitcoin-core-dev
01:00 -!- secdragon [~secdragon@178.162.209.171] has quit []
01:10 -!- promag_ [~promag@188.251.225.32] has joined #bitcoin-core-dev
01:13 < MarcoFalke> the meeting topics link in the IRC topic of this channel is no longer being updated. I created a wiki entry to collect meeting topics: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/General-IRC-meeting 
01:14 < jonatack> MarcoFalke: http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt
01:15 < MarcoFalke> jonatack: Oh thanks. Didn't know this existed
01:16 < jonatack> MarcoFalke: same, I saw achow101 mention it a couple weeks ago
01:16 < MarcoFalke> Well, could make sense to adjust the link for that then ;)
01:16 < jonatack> MarcoFalke: maybe add http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt too
01:19 < MarcoFalke> anyone know who can edit the IRC topic? ping wumpus sipa
01:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:20 < bitcoin-git> [bitcoin] jnewbery opened pull request #20291: [net] Consolidate logic around calling CAddrMan::Connected() (master...2020-11-consolidate-addrman-connect) https://github.com/bitcoin/bitcoin/pull/20291
01:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:21 < bitcoin-git> [bitcoin] jonatack closed pull request #20288: script, doc: contrib/seeds updates (master...contrib-seeds-fixups) https://github.com/bitcoin/bitcoin/pull/20288
01:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:21 -!- superfly1 [~superfly@84.39.116.180] has joined #bitcoin-core-dev
01:38 -!- jesseposner [~jesse@98.37.146.62] has joined #bitcoin-core-dev
01:45 -!- jesseposner [~jesse@98.37.146.62] has quit [Ping timeout: 264 seconds]
02:00 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Quit: Leaving]
02:06 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #bitcoin-core-dev
02:08 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
02:11 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
02:11 -!- vasild_ is now known as vasild
02:20 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
02:23 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #bitcoin-core-dev
02:24 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Client Quit]
02:27 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #bitcoin-core-dev
02:35 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Quit: Leaving]
02:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:39 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #20292: test: Fix intermittent feature_taproot issue (master...2011-testFixes) https://github.com/bitcoin/bitcoin/pull/20292
02:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:39 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #bitcoin-core-dev
02:41 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Quit: Pavlenex]
02:41 -!- promag_ [~promag@188.251.225.32] has quit [Remote host closed the connection]
02:52 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #bitcoin-core-dev
02:54 -!- jonasschnelli [~jonasschn@2a01:4f9:2a:2510::2] has quit [Changing host]
02:54 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #bitcoin-core-dev
02:55 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Client Quit]
02:55 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #bitcoin-core-dev
03:04 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Quit: Leaving]
03:10 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #bitcoin-core-dev
03:18 -!- Gunner5Pollich [~Gunner5Po@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-dev
03:21 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Quit: Pavlenex]
03:39 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.9]
03:40 -!- Gunner5Pollich [~Gunner5Po@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 264 seconds]
03:42 -!- jesseposner [~jesse@98.37.146.62] has joined #bitcoin-core-dev
03:47 -!- jesseposner [~jesse@98.37.146.62] has quit [Ping timeout: 264 seconds]
03:52 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
03:52 -!- da39a3ee5e6b4b0d [~textual@n11211935170.netvigator.com] has joined #bitcoin-core-dev
03:55 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds]
04:00 -!- superfly1 [~superfly@84.39.116.180] has quit []
04:06 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 264 seconds]
04:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:14 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #20294: ci: Run more ci configs on cirrus (master...2011-ciCirrus) https://github.com/bitcoin/bitcoin/pull/20294
04:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:18 -!- Kiminuo [~mix@141.98.103.76] has joined #bitcoin-core-dev
04:21 -!- mdrjr1 [~mdrjr@195.140.213.38] has joined #bitcoin-core-dev
05:00 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
05:01 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
05:13 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
05:18 -!- rich [rich@2600:3c00::f03c:92ff:fe8e:dce6] has left #bitcoin-core-dev []
05:19 -!- PaulTroon [rich@2600:3c00::f03c:92ff:fe8e:dce6] has joined #bitcoin-core-dev
05:21 -!- belcher_ is now known as belcher
05:31 -!- ctrlbreak [~ctrlbreak@159.2.182.106] has quit [Remote host closed the connection]
05:31 -!- ctrlbreak [~ctrlbreak@159.2.182.106] has joined #bitcoin-core-dev
05:33 -!- glozow [uid453516@gateway/web/irccloud.com/x-fnmzdyejosltdszp] has joined #bitcoin-core-dev
05:37 -!- filchef [~filchef@212.104.97.177] has quit [Read error: Connection reset by peer]
05:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:39 < bitcoin-git> [bitcoin] Sjors opened pull request #20295: rpc: getblockfrompeer (master...2020/11/getblockfrompeer) https://github.com/bitcoin/bitcoin/pull/20295
05:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:43 -!- jesseposner [~jesse@98.37.146.62] has joined #bitcoin-core-dev
05:43 < wumpus> MarcoFalke: I can, what would you like to change?
05:49 -!- jesseposner [~jesse@98.37.146.62] has quit [Ping timeout: 256 seconds]
05:56 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
06:04 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:04 < bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/218fe60d91a9...95bde34a7186
06:04 < bitcoin-git> bitcoin/master 36e875b RandyMcMillan: contrib: Add new versions to makeseeds.py and update gitignore
06:04 < bitcoin-git> bitcoin/master 6866259 Wladimir J. van der Laan: net: Hardcoded seeds update for 0.21
06:04 < bitcoin-git> bitcoin/master 95bde34 Wladimir J. van der Laan: Merge #20237: net: Hardcoded seeds update for 0.21
06:04 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:05 < bitcoin-git> [bitcoin] laanwj merged pull request #20237: net: Hardcoded seeds update for 0.21  (master...2020_10_seeds_update) https://github.com/bitcoin/bitcoin/pull/20237
06:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:11 -!- kexkey [~kexkey@static-198-54-132-118.cust.tzulo.com] has joined #bitcoin-core-dev
06:23 -!- jesseposner [~jesse@98.37.146.62] has joined #bitcoin-core-dev
06:24 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
06:28 -!- jesseposner [~jesse@98.37.146.62] has quit [Ping timeout: 256 seconds]
06:33 < MarcoFalke> wumpus: replace https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a with http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
06:33 < wumpus> ok
06:33 -!- mode/#bitcoin-core-dev [+o wumpus] by ChanServ
06:34 < jnewbery> Hi folks. Reminder that we have a P2P irc meeting in just under half an hour. Proposed topics are here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#03-nov-2020
06:34 < gribble> https://github.com/bitcoin/bitcoin/issues/03 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
06:37 -!- ChanServ changed the topic of #bitcoin-core-dev to: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
06:37 -!- mode/#bitcoin-core-dev [-o wumpus] by ChanServ
06:44 < MarcoFalke> thanks
06:47 -!- nickler [~nickler@static.219.205.69.159.clients.your-server.de] has quit [Ping timeout: 246 seconds]
06:47 -!- nickler [~nickler@static.219.205.69.159.clients.your-server.de] has joined #bitcoin-core-dev
06:54 -!- Netsplit *.net <-> *.split quits: corollari__, TheV01d
06:56 -!- Netsplit over, joins: corollari__, TheV01d
06:57 -!- kyoo[m] [kyoomatrix@gateway/shell/matrix.org/x-bbpxarfwoqwpngyc] has quit [Ping timeout: 240 seconds]
06:59 -!- rCapital-Surpris [crtn32002m@gateway/shell/matrix.org/x-cjjnwfskkjjjiccx] has quit [Ping timeout: 240 seconds]
07:00 -!- sdaftuar_ is now known as sdaftuar
07:00 -!- mdrjr1 [~mdrjr@195.140.213.38] has quit []
07:00 < sdaftuar> hi
07:00 -!- RaphalBentgeac[m [raphaelben@gateway/shell/matrix.org/x-ngiqrfyaklwgnpqv] has quit [Ping timeout: 244 seconds]
07:00 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-psjyqsyrkhlykggg] has quit [Ping timeout: 244 seconds]
07:00 -!- lightlike [~lightlike@p200300c7ef1af100fc8fbb65fc69f44f.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
07:00 -!- snowkeld[m] [snowkeldma@gateway/shell/matrix.org/x-sbfuejevikgxhirq] has quit [Ping timeout: 246 seconds]
07:00 < jnewbery> #startmeeting
07:00 < 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 
07:00 -!- awesome_doge [awesome-do@gateway/shell/matrix.org/x-tfhrfhquwmimigoi] has quit [Ping timeout: 244 seconds]
07:00 < vasild> hi
07:00 < jnewbery> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
07:00 < phantomcircuit> hi
07:00 < emzy> hi
07:01 < aj> hi
07:01 < jnewbery> that ping thing is like a blockchain. It only gets longer, never shorter
07:01 < ariard> hi
07:01 < lightlike> hi
07:01 < wumpus> hi
07:01 < jonatack> hi
07:01 < kanzure> hi
07:01 < jnewbery> proposed topics are here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#03-nov-2020
07:01 < gribble> https://github.com/bitcoin/bitcoin/issues/03 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
07:02 < jnewbery> Does anyone have any more topics that they want to propose now, or any general updates they want to give?
07:02 < sdaftuar> i just wanted to review beg #19858
07:02 < gribble> https://github.com/bitcoin/bitcoin/issues/19858 | Periodically make block-relay connections and sync headers by sdaftuar · Pull Request #19858 · bitcoin/bitcoin · GitHub
07:03 < sdaftuar> i've started to now page that PR out of my memory, so would like to make progress before i totally forget what ti is :)
07:03 < jnewbery> I think we haven't branched 0.21 yet, so we're still in feature freeze, right?
07:03 < wumpus> right
07:03 < aj> branch is due pretty soon though?
07:03 < sdaftuar> i assume so -- but i think if we collect acks now it could merge shortly after?
07:03 < amiti> hi
07:04 < luke-jr> kinda curious about the status of p2p encryption
07:04 < luke-jr> but jonas isn't here
07:04 < ariard> noted, I'll reack it
07:04 < jonatack> #18242 was just rebased and it builds cleanly
07:04 < wumpus> yes, feature freeze is only about what is merged, not what is reviewed :)
07:04 < gribble> https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
07:04 < aj> "2020-11-01 split off 0.21" per 18947
07:04 < jonatack> (would be good to move it forward for 0.22)
07:04 < jnewbery> wumpus: while you're here, what's your expectation for when 0.21 will be branched?
07:05 < wumpus> there's still quite a list of PRs tagged with 0.21.0, these either need to be merged or removed from the milestone first https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.21.0
07:06 < wumpus> but I hope some time next week
07:06 < jnewbery> thanks!
07:06 < wumpus> next general meeting we should go over the list
07:06 < jnewbery> ok, onto the topics
07:06 < jnewbery> #topic addrman file versioning
07:07 -!- da39a3ee5e6b4b0d [~textual@n11211935170.netvigator.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
07:07 < vasild> jnewbery: how did you suddenly come to the realization that old versions are not guaranteed to fail the parsing, out of the blue?
07:08 < jnewbery> #19954 meant that in future it won't be possible to do forwards-compatible changes to the peers.dat format. #20284 is suggested as a way to allow that again.
07:08 < gribble> https://github.com/bitcoin/bitcoin/issues/19954 | Complete the BIP155 implementation and upgrade to TORv3 by vasild · Pull Request #19954 · bitcoin/bitcoin · GitHub
07:08 < gribble> https://github.com/bitcoin/bitcoin/issues/20284 | addrman: ensure old versions dont parse peers.dat by vasild · Pull Request #20284 · bitcoin/bitcoin · GitHub
07:08 < jnewbery> vasild: I hadn't reviewed 19954 before
07:08 < jnewbery> I started looking at the addrman code this weekend
07:09 < vasild> actually in the future it will be possible to make forward-compatible changes, but the format version must not be incremented
07:09 < sdaftuar> forwards compatible? do you mean backwards compatible?
07:09 < sdaftuar> i'm confused why we can't write future code to parse whatever we need to
07:09 < vasild> backward compatible
07:09 < jnewbery> sdaftuar: I mean forwards compatible, i.e. you can upgrade, make changes to peers.dat and then downgrade and still parse peers.dat
07:10 < sdaftuar> that really sounds like backwards compatible to me, but thanks for clarifying what you mean
07:10 < jnewbery> I believe we generally want to allow people to downgrade at least one version, right? So people can back out upgrades
07:10 < vasild> the current code supports maximum format=3 and if it sees format=4 it will refuse to parse it
07:10 < hebasto> hi
07:10 < jnewbery> I think backwards compatible would mean that we're able to read old versions of peers.dat, which obviously we can always guarantee
07:10 < jnewbery> forwards compatible means that we're flexible with future peers.dat formatting
07:11 < jonatack> jnewbery: yes, i was reporting issues with that (upgrading, then downgrading) in 19954 iirc
07:11 < jnewbery> vasild: right, so the current code on master is not forwards compatible with formats > 4
07:12 < vasild> >= 4
07:12 < jnewbery> sorry yes, >= 4
07:12 -!- bosch-0 [~igloo@122-148-254-95.sta.wbroadband.net.au] has joined #bitcoin-core-dev
07:12 < vasild> yes, if changes are made to the format it must stay at format=3 if we want 0.21 to parse it
07:12 < vasild> (as of the current master)
07:13 < luke-jr> it would be annoying if users lost their addrman upgrading or downgrading
07:13 < vasild> pr20284 changes that
07:13 -!- joerodgers [~joerodger@86.106.121.56] has joined #bitcoin-core-dev
07:13 < jnewbery> luke-jr: they already lost part of their addrman upgrading to 0.20 because of https://github.com/bitcoin/bitcoin/pull/16702#discussion_r515608294, but I guess no-one noticed
07:13 < luke-jr> :/
07:15 < vasild> pr20284 makes it possible to say in peers.dat "this is format=5, but anybody who can read format=3 can also read this one"
07:16 < luke-jr> maybe the filename should just be changed if that's not the case, in the future?
07:16 < jnewbery> vasild: yes, that's the functionality we want before the 0.21 release. Just want to make sure people are happy with repurposing nKeySize for versioning.
07:17 < sdaftuar> jnewbery: sorry if this is a digression, but i might be misunderstanding the issue in #16702 -- it looks like the version check there just causes potential rebucketing, not losing addresses?
07:17 < gribble> https://github.com/bitcoin/bitcoin/issues/16702 | p2p: supplying and using asmap to improve IP bucketing in addrman by naumenkogs · Pull Request #16702 · bitcoin/bitcoin · GitHub
07:17 < wumpus> I think it's a hack but also a clever way of doing so, and he also introduces a real versioning mechanism for next time, so it's only for once
07:17 < sdaftuar> so the issue that does appear to be there is that downgrading after running 0.20 may be a problem
07:18 < jnewbery> sdaftuar: it means that entries in new tables can only appear in one new table (or even zero if there's a collision)
07:18 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
07:18 < wumpus> definitely don't have any alternative proposals
07:18 < jnewbery> the point of the serialization format is that entries can appear in multiple new tables
07:18 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Ping timeout: 240 seconds]
07:18 < vasild> luke-jr: right, filename change is another option
07:18 < sdaftuar> wumpus: we could rename the peers.dat file for 0.21, and migrate data from the old file to the new one?
07:19 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #bitcoin-core-dev
07:19 < wumpus> sdaftuar: that's a good suggestion too
07:19 < sdaftuar> jnewbery: hmm i need to read that more carefully then.
07:19 < jnewbery> sdaftuar: that would definitely prevent being able to keep your addrman data over a downgrade
07:20 < wumpus> though it'd require updating a lot of documentation all over the place describing bitcoin core's files
07:20 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Client Quit]
07:20 < wumpus> everyone is used to "peers.dat"
07:20 < luke-jr> how often does anyone mess with peers.dat directly?
07:20 < wumpus> I have no idea
07:21 < vasild> btw, I did consider the file name change, but preferred the versioning inside the file, instead of using the filesystem for versioning
07:21 < wumpus> yes, I slightly prefer this as well
07:21 -!- jackgassett [~jackgasse@185.163.110.116] has joined #bitcoin-core-dev
07:21 < sdaftuar> i think it's okay if once in a while we have to give users annoying instructions for downgrading.
07:21 < luke-jr> IMO it depends on compatibility
07:22 < luke-jr> if downgrading doesn't lose the address book, same filename is good; otherwise, a new name avoids losing the old addrman for the old ver
07:22 < jnewbery> what would the annoying instructions be?
07:22 < sdaftuar> we could add a tool that either converts formats, or an RPC or something
07:22 < luke-jr> ^
07:22 < wumpus> sdaftuar: as I understand older versions will just ignore the incompatible peers.dat, and create a new empty one. But yes I agree. Downgrading is quite a rare event anyhow.
07:22 < luke-jr> ew
07:23 -!- bosch-0 [~igloo@122-148-254-95.sta.wbroadband.net.au] has quit [Remote host closed the connection]
07:23 < sdaftuar> what did we do the last time we changed block file name conventions?
07:23 < wumpus> sdaftuar: no one is going to go through that much work for their peers table
07:23 < luke-jr> sdaftuar: iirc hard linked
07:23 < sdaftuar> luke-jr: that doesn't sound backwards compatible?
07:23 < luke-jr> why not?
07:24 < jonatack> I must have lost my peers.dat a couple dozen times while testing the addrv2 PRs. within the next year, anyone still using tor v2 will be forced to upgrade to 0.21 anyway.
07:24 < sdaftuar> oh we hardlinked new and old filenames together, i see
07:24 < wumpus> I'm not sure it makes sense to extensively describe alternatives here, we have vasild's work, unless someone really strongly disagrees with it let's review it and get it merged asap
07:24 < jonatack> unless they don't use tor
07:24 < jnewbery> I don't think there's any need to change file names. It should be perfectly possible to have internal versioning for changes that are forwards compatible and not forwards compatible. I think that's what 20284 does, but I haven't reviewed it yet.
07:25 < wumpus> assuming this really needs to go in for 0.21.0-otherwise there's no hurry
07:25 < aj> afaics, for forwards compatible changes, we just don't bump the version number?
07:25 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #bitcoin-core-dev
07:25 < sipa> argh, timezones
07:26 < vasild> I started a 0.20.1 node on my new peers.dat and it parsed it without emitting errors, so it is not just "theoretical"
07:26 < vasild> surely it parsed everything as garbage
07:26 < wumpus> it's definitely not theoretical
07:27 < vasild> I don't know why during testing of that change, some weeks ago I always got some read/parse error, which fooled me that old versions fail to parse always
07:27 < jonatack> vasild: same
07:27 < vasild> :-D
07:28 < jnewbery> aj: I think there needs to be versioning to show that there are semantic changes, even if they are forwards compatible
07:28 < wumpus> garbage addresses would be kind of nasty, especially if they might also be gossiped and thus pollute the rest of the network too
07:28 < luke-jr> jnewbery: point being if it isn't forwards compatible, the rename keeps the old file for the old version if you downgrade
07:29 < jnewbery> luke-jr: that's a good point
07:30 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Client Quit]
07:30 < jnewbery> So the action is to review 20284, unless anyone has anything important to add
07:31 < jnewbery> #topic I2P support, some background at vasild/bitcoin/wiki/I2P-connectivity (vasild)
07:31 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #bitcoin-core-dev
07:31 < jonatack> When you lose your peers.dat, a new one doesn't seem to take very long to get up to a decent size (40-50k peers) 
07:31 < vasild> https://github.com/vasild/bitcoin/wiki/I2P-connectivity
07:32 < jnewbery> jonatack: it probably takes longer for your tried tables to get populated
07:32 < sdaftuar> jonatack: the whole network losing their peers.dat in the event of downgarde might be a scary idea though (imagine a bug in 0.21, say)
07:32 < sipa> jonatack: that may be deceptive though; just because you have a lot of rumoured IP addresses, they aren't necessarily good
07:32 < jonatack> good points, thanks
07:32 -!- kyoo[m] [kyoomatrix@gateway/shell/matrix.org/x-nmqjpumkebfumgzt] has joined #bitcoin-core-dev
07:32 < aj> jnewbery: if you bump the version from 5 to 6 (eg), and 6 is "unknown" it will be treated as non-supported, so won't be forward compatible. you need major/minor versions if you want to do that
07:33 < jnewbery> aj: I think that's effectively what 20284 does
07:33 < sipa> can we imagine any backward but not forward compatible change?
07:33 < vasild> aj: 
07:33 < vasild> 16:15 < vasild> pr20284 makes it possible to say in peers.dat "this is format=5, but anybody who can 
07:34 < vasild>                 read format=3 can also read this one"
07:34 < aj> vasild, jnewbery: i believe you're both mistaken... it just supports a range: "this code supports versions 3..5". introducing version 6 won't make old code support it
07:34 < jnewbery> sipa: after #19954, all changes are not forward compatible (because 0.21 onwards will reject any version greater than the one they know)
07:34 < gribble> https://github.com/bitcoin/bitcoin/issues/19954 | Complete the BIP155 implementation and upgrade to TORv3 by vasild · Pull Request #19954 · bitcoin/bitcoin · GitHub
07:35 -!- TheHoliestRoger [~TheHolies@unaffiliated/theholiestroger] has quit [Ping timeout: 258 seconds]
07:35 < aj> sipa: backward compatible is easy: if version == 4: ... elif version == 5: ...
07:35 < jnewbery> aj: +1
07:35 < sipa> jnewbery: yes, i mean semantically
07:35 < sipa> is there any change we can imagine to peers.dat that would remain readable by new versions?
07:36 < aj> sipa: readable by old code, you mean?
07:36 < sipa> oh
07:36  * sdaftuar is super confused
07:36 -!- Kiminuo [~mix@141.98.103.76] has quit [Ping timeout: 264 seconds]
07:36 < sipa> do i have my forward/backward mixed up?
07:36 < aj> new code, old peers.dat == backwards compatible
07:36 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-dev
07:37 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-tawsjbyfoxfwvssz] has joined #bitcoin-core-dev
07:37 < sdaftuar> sipa: i thought john has his forward/backward mixed up, for what it's worth.  and maybe aj too.
07:37 < aj> old code, new peers.dat == forwards compatible
07:37 < vasild> awkward
07:37 < sdaftuar> vasild: +1
07:37 < aj> "the format is ___ compatible" is how i'm interpreting it
07:37 -!- RaphalBentgeac[m [raphaelben@gateway/shell/matrix.org/x-inttwipmaihlkdap] has joined #bitcoin-core-dev
07:37 -!- awesome_doge [awesome-do@gateway/shell/matrix.org/x-tpifxrmkoneyrnwp] has joined #bitcoin-core-dev
07:37 < sipa> the goal here is to make sure that new versions can keep reading old files?
07:38 < jnewbery> sdaftuar: wikipedia seems to agree with our definitions: Backward compatibility (sometimes known as backwards compatibility) is a property of a system, product, or technology that allows for interoperability with an older legacy system, or with input designed for such a system
07:38 < vasild> no
07:38 < jnewbery> where the input here is peers.dat
07:38 < vasild> sipa: new code can always read old files
07:38 < jnewbery> old peers.dat, new addrman is backwards compatibility
07:38 < jnewbery> new peers.dat, old addrman is forwards compatibility
07:38 < sipa> ok so this is about new files being readable by old code? can we imagine a change where that's useful?
07:38 < sdaftuar> sipa: it's about being able to downgrade
07:39 < sdaftuar> and not losing all your data
07:39 < jnewbery> i.e. you right the code in a way that it can handle future changes to format that you don't know about, which is potentially important for downgrades
07:40 < sipa> sdaftuar: yes, my question is: can we imagine any change to peers.dat where that's even feasible?
07:40 < luke-jr> sipa: if you don't use Tor, this change is?
07:40 < sdaftuar> sipa: well it depends on what's on the table? eg if we wrote out the old format for the addresses that are supported by the old format in a file that is readable by old software, then sure
07:40 < jnewbery> yes, for example the change from 0 to 1 and 1 to 2 both allowed old versions to read new files
07:41 < sipa> jnewbery: ah, indeed!
07:41 < sipa> thanks
07:41 < vasild> sipa: you authored that! :-)
07:41 < luke-jr> hmm, we could in theory even split a peers-torv3.dat for those, and keep peers.dat as-is and compatibel?
07:41 < sipa> vasild: it's early
07:42 < sdaftuar> luke-jr: interesting idea
07:42 < aj> or put the torv3 addresses as an add-on at the end of the file or something?
07:42 < wumpus> where does that stop, though... would we have peers-i2p.dat as well?
07:42 < jonatack> if anyone following along is wondering, we're talking about enum class Format in addrman.h::L269
07:42 < luke-jr> wumpus: why not?
07:43 < sipa> this seems hard
07:43 < luke-jr> is there a reason to throw it all in the same file?
07:43 < jnewbery> jonatack: well more generally about the Serialize and Unserialize methods for CAddrMan
07:43 < sdaftuar> wumpus: perhaps eventually files get merged, once old software no longer is a plausible downgrade target?
07:43 < sipa> peers.dat files aren't just lists of addresses
07:43 < sipa> they dump the tables and their layout too
07:43 < jnewbery> we could replace peers.dat with sqlite :)
07:43 < wumpus> I'm really not sure this is worth so much worrying about, if we're really worried about people downgrading why not make a backup at first run with 0.21.0?
07:44 < wumpus> then if people downgrade they can restore the backup and *shrug*
07:44 < sipa> if you split the file in two, you can't just merge them back without losing informatiom
07:44 < luke-jr> jnewbery: that might not be a bad idea
07:44 < sdaftuar> wumpus: yes i agree with that type of suggestion too, along the lines of "sometimes it can be annoying to downgrade"
07:44 < luke-jr> wumpus: how is that different from just using a new filename, except requiring an extra step to downgrade?
07:45 < wumpus> luke-jr: it keeps the filename the same for the bulk of the users
07:45 < wumpus> the non-downgrading path is likely be far most popular, or at least one'd hope :)
07:45 < wumpus> in any case, we needa solution here fairly quickly
07:46 < jnewbery> wumpus: I agree that it's more likely, but I think we should strive to make downgrades across a single version seamless, just in case we ship a bad bug and need people to roll back
07:46 < jnewbery> *upgrading is the more likely path than downgrading
07:46 < jnewbery> ok, we're running out of time and there are a couple more topics, so perhaps we should move on
07:46 < wumpus> I'm not sure last-minute changes lke 'sort peers.dat per network' or other complete changes to handling peers database
07:47 -!- kyoo[m] [kyoomatrix@gateway/shell/matrix.org/x-nmqjpumkebfumgzt] has quit [Quit: Bridge terminating on SIGTERM]
07:47 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-tawsjbyfoxfwvssz] has quit [Quit: Bridge terminating on SIGTERM]
07:47 -!- awesome_doge [awesome-do@gateway/shell/matrix.org/x-tpifxrmkoneyrnwp] has quit [Quit: Bridge terminating on SIGTERM]
07:47 -!- RaphalBentgeac[m [raphaelben@gateway/shell/matrix.org/x-inttwipmaihlkdap] has quit [Quit: Bridge terminating on SIGTERM]
07:47 < sipa> wumpus: agree
07:47 < jnewbery> vasild: did you have anything you wanted to add about I2P support?
07:47 < ariard> jnewbery: I'm fine to report mine next time
07:48 < jnewbery> ariard: thanks. Maybe a good idea so people have some time to think about it before the meeting
07:48 < vasild> Anybody interested in I2P support - see https://github.com/vasild/bitcoin/wiki/I2P-connectivity and discuss here, I guess after the meeting or anytime
07:48 < sdaftuar> i've got a question about i2p (applies to any new exotic network, even tor stuff that we're doing) - what is our undestanding for how these addresses get gossiped to peers that support the network type?
07:48 < wumpus> jnewbery: yes, agree, it's kind of nasty that this issue comes up so last minute
07:49 < sipa> sdaftuar: i2p/cjdns do not get rumoured by the current code, at all
07:50 < vasild> sipa: no, they would get rumored if the node has connectivity to i2p
07:50 < vasild> or am I mistaken...
07:50 < wumpus> cjdns not because it uses IPv6 addresses in a range we consider local / unroutable?
07:50 < sipa> vasild: which isn't possible.on the current code :)
07:50 < sipa> see #20119
07:50 < gribble> https://github.com/bitcoin/bitcoin/issues/20119 | BIP155 follow-ups by sipa · Pull Request #20119 · bitcoin/bitcoin · GitHub
07:50 < sdaftuar> so the basic idea is that if we know how to reach a network, we'll rumor it to 2 peers or so
07:51 < sdaftuar> and if we don't, it still goes to 1 i think? is that correct?
07:51 < sipa> sdaftuar: there are classes now
07:51 < vasild> sdaftuar: yes
07:51 < jnewbery> sdaftuar: 1.5 now I think
07:51 < sipa> 1) reachable networks get rumoured 2x
07:51 < vasild> sdaftuar: see RelayAddress() in the case fReachable==true
07:52 < sipa> 2) unreachable ipv4/ipv6/torv2/torv3 get rumoured 1.5x
07:52 < jonatack> see #19728
07:52 < gribble> https://github.com/bitcoin/bitcoin/issues/19728 | Increase the ip address relay branching factor for unreachable networks by sipa · Pull Request #19728 · bitcoin/bitcoin · GitHub
07:52 < sipa> 3) unreachable others do not get rumoured at all
07:52 < vasild> #20254 makes i2p reachable
07:52 < gribble> https://github.com/bitcoin/bitcoin/issues/20254 | Add I2P support using statically configured destinations by vasild · Pull Request #20254 · bitcoin/bitcoin · GitHub
07:54 < vasild> btw, in I2P we can see the peer's address and be sure data comes from him (the address is a hash of his public key)
07:54 < sdaftuar> sipa: thanks. one more question, how do we decide what address to advertise ourselves as, if we're reachable in multiple ways?
07:54 < luke-jr> vasild: same for Tor? :p
07:55 < vasild> luke-jr: no, in Tor we don't see the address of the peer that connected to us
07:55 < luke-jr> oh, right
07:55 < sipa> "tor has no from address"
07:56 < luke-jr> XD
07:56 < wumpus> heh
07:56 < vasild> so in I2P we have P2P encryption by default :-)
07:56 < jnewbery> sdaftuar: that logic is in AdvertiseLocal() in net.cpp
07:56 < sipa> vasild: with public identities, though :(
07:56 < vasild> yes
07:57 < luke-jr> kinda by design in i2p?
07:57 < vasild> yes
07:57 < sipa> sdaftuar: among the local addresses compatible with that peer, the one that has received the most mentions in incomimg version messages
07:58 < sipa> which reminds me: we can't put torv3/i2p/cjdns in version messages, so those will never receive any mentions
07:58 < sdaftuar> sipa: it seems like for something like adding a new newtork type, sometimes we'll want to advertise our i2p address instead right?
07:58 < sdaftuar> sipa: oh taht seems important
07:58 < jnewbery> do we need a new version version? :)
07:59 < sdaftuar> jnewbery: i think we can just add data on to the end and no one will mind
07:59 -!- Pasta[m] [pastapas1@gateway/shell/matrix.org/x-kjhgribcrumcadtw] has joined #bitcoin-core-dev
07:59 < sipa> i'm not sure this is useful for those networks
08:00 < sipa> as there isn't any useful compatibility matrix for them
08:00 -!- Pasta[m] [pastapas1@gateway/shell/matrix.org/x-kjhgribcrumcadtw] has quit [Client Quit]
08:00 < jnewbery> that's time!
08:00 < jnewbery> #endmeeting
08:00 < sdaftuar> sipa: address rumoring isn't useful, or something else?
08:00 < jonasschnelli> oh.. I missed the meeting.
08:00 < wumpus> sipa: there was the idea to add that address in the 'sendaddrv2' message
08:00 < vasild> I guess sipa means the "voting"
08:00 < sdaftuar> ah
08:01 < vasild> or how many times the address receives "mentions"
08:01 < aj> zzz
08:01  * luke-jr gives jonasschnelli the mic
08:01 < jonasschnelli> I wanted to ask about BIP324's rekeying
08:01 < sipa> sdaftuar: scoring your local addresses using incoming version mentions isn't useful for these separate networls
08:01 < sipa> jonasschnelli: ongoing discussion, it seems!
08:01 < sdaftuar> yeah i was thinking that if we are trying to bootstratp a new type of address, we need to proactively advertise that address even to peers who don't understand it
08:01 < jonasschnelli> sipa: may you have 10 minutes for discussion the 1s rekey approach
08:01 < sdaftuar> so that eventually peers that do support it, receive it
08:01 < sipa> sdaftuar: that's a good point
08:01 < wumpus> sipa: (which would be easier to add new things to than the version message, and is relevant to the same functionality)
08:02 < vasild> sdaftuar: my thought exactly, but we decided to not relay i2p addresses by nodes that are not connected to i2p; at least in 0.21
08:02 < jonasschnelli> sipa: indeed... its ongoing. But assume a 1s rekeying interval would imply some sort of a rekey-message,.. right?
08:02 < sipa> jonasschnelli: my current thinking is that doing rekeying at the key stream level is super cheap and simple
08:03 < jonasschnelli> rekey on every ping/pong would be less complicated to implement (rather then time based)
08:03 < sipa> jonasschnelli: and i see no reason to have it at the application level as well if we do that
08:03 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
08:03 < sipa> jonasschnelli: i absolutely don't suggest rekeying every secomd :)
08:04 < jonasschnelli> sipa: at stream level would be something like basically rekey on after message?
08:04 < vasild> there is already one bitcoin node listening at yfsvsy467mt5xafaq7zaukkjyzehvmew445yaaejvrwpk53acejq.b32.i2p (irc gossip :-D)
08:04 < jonasschnelli> "after every message
08:04 < sipa> jonasschnelli: no, every X bytes
08:04 < sdaftuar> vasild: nice :)
08:04 < jonasschnelli> sipa: okay. What we have now.. but probably smaller than 1GB
08:04 < sipa> jonasschnelli: no!
08:05 < sipa> it's currently done at the layer above
08:05 < sipa> this would let you just build it inside chacha
08:05 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
08:05 < jonasschnelli> ah. Built into the AEAD
08:05 < ariard> jonasschnelli: I think  you can pick up a value based on blocks frequency if you want something to happen every Y period of time?
08:05 < sipa> without having a bit to signal rekeying or so
08:05 < sipa> ariard: that's just as hard
08:06 < sipa> jonasschnelli: this would give you forward secrecy (also a weird term
08:06 < jonasschnelli> What if the byte limit hits in the middle of a message payload?
08:06 < sipa> for ~free, at the byte level if you wanted to
08:06 < sipa> jonasschnelli: yes, so what?
08:06 < sipa> the stream cipher does it automatically
08:07 < ariard> sipa: do you mean byte-accounting is hard to get right?
08:07 < sipa> ariard: no, byte-accounting is trivial
08:07 < jonasschnelli> sipa: hmm... but the mAC?
08:07 < sipa> jonasschnelli: the mac keys don't cycle
08:07 < sipa> only the encryption keys
08:08 < jonasschnelli> but the current MAC key is derived from the chacha20 stream
08:09 < sipa> jonasschnelli: yes that'll need to change
08:09 -!- lightlike [~lightlike@p200300c7ef1af100fc8fbb65fc69f44f.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
08:09 < jonasschnelli> sipa: hmm...
08:09 < sipa> have a separate stream where the mac keys are drawn from, for example
08:10 < sipa> but it means you can drop the signalling of rekeying etc
08:10 < sipa> and concerns about peers not doing it, or doing it too often
08:12 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
08:12 -!- kljasdfvv [~flack@p200300d46f24de007887c37597c774bc.dip0.t-ipconnect.de] has quit [Ping timeout: 268 seconds]
08:13 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
08:14 < sipa> as long as we don't worry about secrecy in the other direction (which the current bip324 writeup doesn't, afaik), i think this is very much preferable
08:14 < jonasschnelli> sipa: do the benefits of this justify further deviation from the "well tested" ChaCha20Poly1305@openssh?
08:14 < sipa> jonasschnelli: we're already deviating from it
08:14 < jonasschnelli> sipa: but in a pretty minor way
08:15 -!- Kiminuo [~mix@141.98.103.76] has joined #bitcoin-core-dev
08:15 < sipa> jonasschnelli: maybe superficially... but openssh rekeys by redoing DH, no?
08:16 < jonasschnelli> sipa: what do you think are the benefits over a rekeying signal (where we can detect DoS or exceeded limits)?
08:16 < jonasschnelli> sipa: probably... haven't looked at their rekeying.
08:16 < jonasschnelli> but the AEAD has no rekeying (@openssh and @Bitcoin)
08:17 < sipa> so doing rekeying by redoing DH makes sense, as it gives you secrecy in both directions
08:17 < jonasschnelli> Yes. Our rekeying does a independent rekey per direction,... whenever the limits are reached.
08:18 < sipa> rekeying by hashing only gives you forward secrecy, not the other direction
08:18 < sipa> but as long as we only care about forward secrecy... doing the whole signalling thing is kind of overkill
08:18 < jonasschnelli> I see
08:18 < jonasschnelli> I see what you mean with direction noew
08:18 < jonasschnelli> *now
08:19 < sipa> you can get cheap forward secrecy at the byte level, instead of at the 1 GB level
08:19 < sipa> (by generating 4096 bytes of stream cipher ahead of time, rekeying, and then throwing the stream cipher bytes away as they get used)
08:20 < sipa> you can't do that with 1 GB of material, and can't do that if you don't know when the other party is going to reky
08:21 < sipa> anyway, my point is: not redoing DH is already a big conceptual departure from the existing protocol
08:21 < jonasschnelli> I think I understand this... I'm just unsure about the MAC construct... and concerned about complication of the implementation (with its risks)
08:22 < sipa> yeah
08:23 < sipa> to be honest, i habe difficulty remember the exact way the stream/keys are constructed now too
08:23 < sipa> this may simplify it...
08:23 < jonasschnelli> sipa: we rekey with SHA256(SHA256(session ID || old_symmetric_cipher_key))... wouldn't an attacker stealing the symmetric be unable to go in both directions?
08:23 < jonasschnelli> since the "session ID" requires the ECDH key
08:23 < sipa> jonasschnelli: if an attacker knows the old key, they can also apply the hashing
08:24 -!- jesseposner [~jesse@98.37.146.62] has joined #bitcoin-core-dev
08:24 < jonasschnelli> sipa: the attacked doesn't know the session ID, right?
08:24 < sipa> well in this scenario they do!
08:24 -!- TheHoliestRoger [~TheHolies@unaffiliated/theholiestroger] has joined #bitcoin-core-dev
08:25 < jonasschnelli> sipa: So the scenario is that ECDH is broken?
08:25 < sipa> jonasschnelli: or they broke into your machine and dumped its memory
08:26 < sipa> forward secrecy protects against that case... if an attacker does that, they *still* can't decrypt old messages
08:27 < jonasschnelli> okay.. got it
08:27 < sipa> but the other direction... you can't prevent an attacker who read your RAM from decrypting future messages, unless you redo DH
08:27 < jonasschnelli> including re-generation of emphemeral keys,.. right?
08:27 < sipa> yes, that's what DH does
08:28 < jonasschnelli> indeed. :)
08:28 -!- tralfaz [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-dev
08:29 < jonasschnelli> and you think that backward secrecy (probably called different) can be achived by altering the AEAD and including a deterministic rekeying?
08:29 -!- jesseposner [~jesse@98.37.146.62] has quit [Ping timeout: 260 seconds]
08:29 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Disconnected by services]
08:29 -!- tralfaz is now known as davterra
08:30 < jonasschnelli> or has the AEAD-inner-rekeyng nothing to do with the secrecy directions?
08:30 < sipa> that only provides forward secrecy
08:30 < sipa> but it can do it at the byte level
08:31 < jonasschnelli> more elegant but same level of security as the current proposal?
08:31 < sipa> indeed
08:31 < jonasschnelli> okay... got it.
08:31 < sipa> perhaps we want some affordance for redoing DH too, but we can probably just disconnect and reconnect for that...
08:32 < jonasschnelli> I haven't seen BIP324 discussion about the missing backward secrecy of the current rekeying approach.
08:32 < sipa> i think it's less of a concern
08:32 < sipa> but i'll try to summerize
08:32 < sipa> on githun
08:32 < jonasschnelli> great,... thanks.
08:33 < jonasschnelli> I'd like to not loose to much momentum on the implementation. But also,... not urging to stop improving the protocol. :)
08:34 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Quit: Pavlenex]
08:34 < jonasschnelli> However... thanks sipa for explaining!
08:34 -!- rCapital-Surpris [crtn32002m@gateway/shell/matrix.org/x-tiujvomwsqovicqc] has joined #bitcoin-core-dev
08:34 -!- snowkeld[m] [snowkeldma@gateway/shell/matrix.org/x-sctramrejhkepioh] has joined #bitcoin-core-dev
08:34 -!- awesome_doge [awesome-do@gateway/shell/matrix.org/x-uxpvzzgmfufkdehc] has joined #bitcoin-core-dev
08:34 -!- TheFuzzStone[m] [thefuzzsto@gateway/shell/matrix.org/x-fdqmwngbisvjvofx] has joined #bitcoin-core-dev
08:34 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-zawdlorjbkpbblko] has joined #bitcoin-core-dev
08:34 -!- kyoo[m] [kyoomatrix@gateway/shell/matrix.org/x-bpoimagdjgyeoxrb] has joined #bitcoin-core-dev
08:35 -!- tianshi[m] [tianshimat@gateway/shell/matrix.org/x-mpipzilseonjtdcn] has joined #bitcoin-core-dev
08:35 -!- RaphalBentgeac[m [raphaelben@gateway/shell/matrix.org/x-soiqapnxaxpgdwts] has joined #bitcoin-core-dev
08:39 -!- roconnor [~roconnor@host-192.252-162-14.dyn.295.ca] has quit [Ping timeout: 246 seconds]
08:45 -!- greypw [~greypw@unaffiliated/greypw] has quit [Quit: I'll be back!]
08:46 -!- greypw [~greypw@unaffiliated/greypw] has joined #bitcoin-core-dev
08:53 -!- baldur [~baldur@pool-173-56-240-14.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
08:57 -!- spinza [~spin@102.132.245.16] has quit [Quit: Coyote finally caught up with me...]
08:58 -!- baldur [~baldur@pool-173-56-240-14.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
08:59 -!- spinza [~spin@102.132.245.16] has joined #bitcoin-core-dev
09:20 -!- pergaminho [~Cleber@189.26.121.248] has joined #bitcoin-core-dev
09:25 -!- roconnor [~roconnor@host-192.252-162-14.dyn.295.ca] has joined #bitcoin-core-dev
09:28 < wumpus> vasild: here is already one bitcoin node listening at yfsvsy467mt5xafaq7zaukkjyze hvmew445yaaejvrwpk53acejq.b32.i2p (irc gossip :-D) <- good to know, i'll have a look at setting up I2P too
09:29 -!- jesseposner [~jesse@98.37.146.62] has joined #bitcoin-core-dev
09:35 -!- jesseposner [~jesse@98.37.146.62] has quit [Ping timeout: 264 seconds]
09:35 -!- spinza [~spin@102.132.245.16] has quit [Quit: Coyote finally caught up with me...]
09:37 -!- spinza [~spin@102.132.245.16] has joined #bitcoin-core-dev
09:42 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
09:56 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
10:00 -!- jackgassett [~jackgasse@185.163.110.116] has quit []
10:10 -!- promag_ [~promag@188.250.84.129] has joined #bitcoin-core-dev
10:14 -!- promag_ [~promag@188.250.84.129] has quit [Ping timeout: 272 seconds]
10:19 -!- kristapsk_ is now known as kristapsk
10:20 -!- hardaker [~hardaker@139.28.218.148] has joined #bitcoin-core-dev
10:31 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 256 seconds]
10:36 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
10:41 -!- jesseposner [~jesse@98.37.146.62] has joined #bitcoin-core-dev
10:46 -!- jesseposner [~jesse@98.37.146.62] has quit [Ping timeout: 240 seconds]
10:53 -!- joerodgers [~joerodger@86.106.121.56] has quit [Read error: Connection reset by peer]
10:55 -!- filchef [~filchef@212.104.97.177] has joined #bitcoin-core-dev
11:02 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]
11:03 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
11:10 -!- roconnor [~roconnor@host-192.252-162-14.dyn.295.ca] has quit [Ping timeout: 256 seconds]
11:21 -!- jesseposner [~jesse@98.37.146.62] has joined #bitcoin-core-dev
11:32 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
11:33 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
11:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
11:39 -!- lightlike [~lightlike@p200300c7ef1af100d5d5bc5b312eacaf.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
11:44 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
11:47 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
12:08 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:16 -!- troygiorshev [~troygiors@d67-193-140-136.home3.cgocable.net] has joined #bitcoin-core-dev
12:32 -!- lightlike [~lightlike@p200300c7ef1af100d5d5bc5b312eacaf.dip0.t-ipconnect.de] has quit [Quit: Leaving]
13:00 -!- hardaker [~hardaker@139.28.218.148] has quit []
13:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
13:13 -!- pergaminho [~Cleber@189.26.121.248] has quit [Quit: Saindo]
13:20 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
13:21 -!- zelazny [~zelazny@178.162.209.171] has joined #bitcoin-core-dev
13:28 < jonatack> vasild: i think i'm connected to your i2p peer
13:28 -!- robert_spigler[m [robertspig@gateway/shell/matrix.org/x-uhbimzzqyjwxnyqr] has joined #bitcoin-core-dev
13:30 -!- promag [~promag@188.250.84.129] has quit [Ping timeout: 272 seconds]
13:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds]
13:45 -!- justanotheruser is now known as mrdulus
13:45 -!- robert_spigler[m [robertspig@gateway/shell/matrix.org/x-uhbimzzqyjwxnyqr] has left #bitcoin-core-dev []
13:46 -!- mrdulus is now known as justan0theruser
13:51 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
13:56 < amiti> hi! does anyone actively use `-loadblock` / have current use cases?
13:57 -!- tryphe_ is now known as tryphe
13:58 < sipa> amiti: did yiu see my response on the issue?
13:58 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Quit: Leaving]
13:59 < amiti> yeah, you said "I don't know if those see much use still", so I thought I'd ask more people :) 
13:59 < sipa> amiti: right
13:59 < amiti> (for anyone wondering, #19594)
13:59 < gribble> https://github.com/bitcoin/bitcoin/issues/19594 | refactor: Make mapBlocksUnknownParent local, and rename it by hebasto · Pull Request #19594 · bitcoin/bitcoin · GitHub
14:00 < sipa> i mean: it was intended for supporting bootstrap.dat, and i think that's the only use case
14:00 < sipa> if there is anyone actively relying on that feature i don't know
14:00 < amiti> gotcha. ok maybe I could rephrase the question as- does anyone actively use bootstrap.dat?
14:02 < luke-jr> it's not even maintained anymore
14:03 < sipa> not by us
14:03 < sipa> though some sites provide them
14:04 < luke-jr> updated? O.o
14:04 < sipa> since the improved block download logic in 0.10 there is much less use for it, as just syncing from random peers is likely faster than downloading + processing in sequence
14:04 < sipa> https://flo.sh/download-bitcoin-blockchain-bootstrap/ apparently has a fairly recent one
14:04 < luke-jr> TIL
14:05 < luke-jr> I suppose it might be handy for people syncing offline PCs
14:05 < sipa> TIL also
14:06 < luke-jr> hmm, I should probably stop parsing my entire debug.log every hour
14:06 < luke-jr> it's getting behind XD
14:07 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Ping timeout: 240 seconds]
14:08 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
14:10 -!- roconnor [~roconnor@host-192.252-162-14.dyn.295.ca] has joined #bitcoin-core-dev
14:10 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-sbxxrzmtejfxourc] has joined #bitcoin-core-dev
14:12 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
14:12 -!- vasild_ is now known as vasild
14:12 < amiti> do I understand correctly: the idea of bootstrap.dat  / loadblock is that you input a file with the sequential blocks to process. in the current state, what are the differences from importing the datadir and reindexing? / would there be any advantage? (ofc one difference is that loadblock requires the blocks to be in order) 
14:13 < sipa> i expect you can just rename a bootstrap.dat file to be blk00000.dat, and run -reindex
14:14 < sipa> amiti: i think part is that you don't want to encourage people copying entire datadirs, as chainstates don't get re-verified
14:15 < sipa> and anything that involves manually messing with the datadir is probably reserved for people who know what they're doing anyway
14:16 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #bitcoin-core-dev
14:17 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-sbxxrzmtejfxourc] has left #bitcoin-core-dev []
14:18 -!- filchef [~filchef@212.104.97.177] has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
14:19 < amiti> oh I see, so loadblock does more verification than reindexing? ok I'm not super familiar with reindexing so I'll go learn more 
14:19 < luke-jr> loadblock just treats the file as an untrusted peer
14:20 < sipa> amiti: no, it's exactly the same
14:20 < sipa> amiti: but if you copy a *chainstate* from someone (not just block files), they don't get re-verified (because your node wouldn't know it's operating on an imported copy)
14:20 < amiti> ahhhh I see 
14:22 < sipa> still, i don't have a good answer for whether it's worth supporting -loadblock if it is a burden to maintain... i suspect not
14:22 < sipa> i also don't think it's a large burden, thoug
14:23  * midnight makes use of loadblocks still fwiw
14:23 < sipa> good to know!
14:23 < amiti> yeah, for me the first question is "is it still useful". then the next question is "is it a higher burden to maintain, or to remove?" 
14:23 < sipa> i don't think i've personally used it for many years
14:23 < amiti> midnight: ooo, willing to tell us more about how/why you use it? 
14:32 < midnight> sure. I use it as a way of explicitly migrating block data between machines; also occasionally to (expensively) explore early blocks and early large-block-number reorgs. Mostly as a way to ensure migrated block data is reverified with modern versions as my node instances are typically very long-lived.
14:33 < midnight> I'd be completely fine with just a network-based block injector if it exists.
14:35 < amiti> okay gotcha. thanks! 
14:35 < midnight> \o  I wouldn't be too broken-up about it being removed, as long as it's still possible for me to help seed my friends with a copy of current block data from my own nodes somehow.
14:36 < midnight> (so, I test it first before handing it to them)
14:36 -!- Kiminuo [~mix@141.98.103.76] has quit [Ping timeout: 260 seconds]
14:41 < amiti> 👍
14:53 -!- quijote_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 272 seconds]
14:53 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-njtrdildhtememmh] has joined #bitcoin-core-dev
14:55 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
14:57 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection]
14:58 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
15:03 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Remote host closed the connection]
15:04 -!- da39a3ee5e6b4b0d [~textual@n11211935170.netvigator.com] has joined #bitcoin-core-dev
15:09 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
15:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
15:13 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 240 seconds]
15:15 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-dev
15:16 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
15:20 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 240 seconds]
15:23 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
15:24 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
15:28 -!- Tennis [~Tennis@unaffiliated/tennis] has joined #bitcoin-core-dev
15:28 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 264 seconds]
15:29 -!- da39a3ee5e6b4b0d [~textual@n11211935170.netvigator.com] has quit [Ping timeout: 272 seconds]
15:29 -!- kexkey [~kexkey@static-198-54-132-118.cust.tzulo.com] has quit [Ping timeout: 256 seconds]
15:33 -!- flag [~flag@net-93-66-105-239.cust.vodafonedsl.it] has quit [Ping timeout: 264 seconds]
15:39 -!- windsok_ [~windsok@rarepepe.cash] has quit [Changing host]
15:39 -!- windsok_ [~windsok@unaffiliated/windsok] has joined #bitcoin-core-dev
15:39 -!- windsok_ is now known as windsok
16:00 -!- zelazny [~zelazny@178.162.209.171] has quit []
16:03 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
16:03 -!- mmitech___ [sid446259@gateway/web/irccloud.com/x-ahtithmervvrwkwv] has quit [Read error: Connection reset by peer]
16:03 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-cszzgperrruoampp] has quit [Read error: Connection reset by peer]
16:03 -!- endogenic [sid145991@gateway/web/irccloud.com/x-xcgcwegchesgvdlf] has quit [Read error: Connection reset by peer]
16:03 -!- digi_james [sid281632@gateway/web/irccloud.com/x-hproigixxjvgxexh] has quit [Ping timeout: 240 seconds]
16:03 -!- mariorz [sid490@gateway/web/irccloud.com/x-acbkcczxvtaosnpg] has quit [Read error: Connection reset by peer]
16:03 -!- robot-dreams [sid463268@gateway/web/irccloud.com/x-fpigosjmajlqgawx] has quit [Ping timeout: 272 seconds]
16:04 -!- mariorz [sid490@gateway/web/irccloud.com/x-nxqogopxarpvmmvp] has joined #bitcoin-core-dev
16:04 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-omjebovvyrpmsatz] has joined #bitcoin-core-dev
16:04 -!- endogenic [sid145991@gateway/web/irccloud.com/x-exsqacbpsifyewgw] has joined #bitcoin-core-dev
16:04 -!- robot-dreams [sid463268@gateway/web/irccloud.com/x-pktvdeifsbsukigk] has joined #bitcoin-core-dev
16:05 -!- digi_james [sid281632@gateway/web/irccloud.com/x-ktiktfplrpnflhdn] has joined #bitcoin-core-dev
16:05 -!- mmitech___ [sid446259@gateway/web/irccloud.com/x-fhextgvoqodorrau] has joined #bitcoin-core-dev
16:05 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds]
16:07 -!- AdulrunaRedviva [c3d69d22@195.214.157.34] has quit [Remote host closed the connection]
16:12 -!- jonatack [~jon@109.202.107.5] has quit [Ping timeout: 272 seconds]
16:14 -!- jonatack [~jon@213.152.161.101] has joined #bitcoin-core-dev
16:17 -!- jesseposner [~jesse@98.37.146.62] has quit [Quit: Lost terminal]
16:20 -!- miconda [~miconda@195.140.213.38] has joined #bitcoin-core-dev
16:26 < fanquake> wumpus / sipa: please block khokho1986
16:28 < sipa> done
16:39 -!- Tennis [~Tennis@unaffiliated/tennis] has quit [Quit: Leaving]
16:46 -!- ctrlbreak [~ctrlbreak@159.2.182.106] has quit [Remote host closed the connection]
16:46 -!- ctrlbreak [~ctrlbreak@159.2.182.106] has joined #bitcoin-core-dev
16:54 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
16:55 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-dev
16:57 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
16:57 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-dev
17:13 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Ping timeout: 240 seconds]
17:21 -!- willcl_ark [~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net] has joined #bitcoin-core-dev
17:22 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
17:25 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
17:47 -!- alko89 [~alko89@unaffiliated/alko89] has quit [Quit: ZNC 1.7.5 - https://znc.in]
17:49 -!- alko89 [~alko89@unaffiliated/alko89] has joined #bitcoin-core-dev
17:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
17:52 < bitcoin-git> [bitcoin] meshcollider pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/95bde34a7186...17c6fb176a07
17:52 < bitcoin-git> bitcoin/master 2ead31f Sishir Giri: [wallet] Return object from upgradewallet RPC
17:52 < bitcoin-git> bitcoin/master 17c6fb1 Samuel Dobson: Merge #20282: wallet: change upgradewallet return type to be an object
17:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
17:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
17:52 < bitcoin-git> [bitcoin] meshcollider merged pull request #20282: wallet: change upgradewallet return type to be an object (master...2020-11-upgrade-wallet-return) https://github.com/bitcoin/bitcoin/pull/20282
17:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
18:08 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
18:09 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 2.9]
18:11 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 256 seconds]
18:14 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
18:40 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
18:43 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds]
18:44 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 256 seconds]
19:00 -!- miconda [~miconda@195.140.213.38] has quit []
19:05 -!- molz_ [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer]
19:05 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
19:06 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
19:10 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 258 seconds]
19:13 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
19:16 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 258 seconds]
19:24 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-core-dev
19:29 < shesek> I'm sometimes getting an invalid json reply from `getwalletinfo` when scanning is in progress, that looks like that: `"scanning":{"duration":19,"progress":}}` (with no value for `progress`). I can't reliably reproduce this, but I did manage to run into this 3 times now (once every 20 attempts or so). seems like something racey is going on.
19:29 < shesek> I'm running v0.20.0 and testing against a regtest instance. this happened while doing a batched `importmulti` of 2000 addresses, none of which have any history.
19:31 < shesek> any pointers for diagnosing this? what useful information can I provide to help understand the cause?
19:36 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
19:36 < bitcoin-git> [bitcoin] meshcollider pushed 12 commits to master: https://github.com/bitcoin/bitcoin/compare/17c6fb176a07...5d32009f1a3b
19:36 < bitcoin-git> bitcoin/master 052427e Jon Atack: wallet, bugfix: fix bumpfee with explicit fee rate modes
19:36 < bitcoin-git> bitcoin/master fc57217 Jon Atack: wallet: fix SetFeeEstimateMode() error message
19:36 < bitcoin-git> bitcoin/master 1697a40 Jon Atack: wallet: improve bumpfee error/help, add explicit fee rate coverage
19:36 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
19:36 < sipa> shesek: my theory is that somehow the begin and end of the rescan have the same progress value, so there is a division by zero
19:36 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
19:36 < bitcoin-git> [bitcoin] meshcollider merged pull request #20220: wallet, rpc: explicit fee rate follow-ups/fixes for 0.21 (master...explicit-feerate-follow-ups) https://github.com/bitcoin/bitcoin/pull/20220
19:36 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
19:37 < sipa> and infinity doesn't exist in JSON
19:38 < luke-jr> are we not doing #20250 then?
19:38 < gribble> https://github.com/bitcoin/bitcoin/issues/20250 | Bugfix: RPC/Wallet: Make BTC/kB and sat/B fee modes work sanely by luke-jr · Pull Request #20250 · bitcoin/bitcoin · GitHub
19:40 < shesek> what sipa is referring to is here if anyone else is interested: https://github.com/bitcoin/bitcoin/blob/26d7941224bcfe4f6ce9d4462610f300c9bd029a/src/wallet/wallet.cpp#L1781
19:42 < shesek> so if I'm reading things correctly, when current and end are equal it should report the progress as 1?
19:43 < sipa> shesek: but if begin and end are equal, it gives infinity
19:44 < shesek> right, I meant what it should do conceptually, not what it currently does
19:49 -!- jonatack [~jon@213.152.161.101] has quit [Ping timeout: 256 seconds]
19:51 -!- jonatack [~jon@88.124.242.136] has joined #bitcoin-core-dev
19:56 -!- Snowstormer [~Snowstorm@195.206.169.184] has joined #bitcoin-core-dev
20:03 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 260 seconds]
20:05 -!- queip_ [~queip@unaffiliated/rezurus] has joined #bitcoin-core-dev
20:06 -!- queip_ is now known as queip
20:18 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 258 seconds]
20:36 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 264 seconds]
20:40 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
20:43 -!- mdunnio_ [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
20:45 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 272 seconds]
20:48 -!- mdunnio_ [~mdunnio@208.59.170.5] has quit [Ping timeout: 272 seconds]
21:27 < S3RK> question about fuzzing. we use regtest chain params, but in corups for src/test/fuzz/descriptor_parse.cpp I see xprv keys. As a result fuzzing don't cover code paths with valid keys for bip32 decriptors. I tried to add initial seeds with tprv, but fuzzer doesn't detect any new edges covered. What do I miss?
21:31 -!- jonatack [~jon@88.124.242.136] has joined #bitcoin-core-dev
21:33 < sipa> S3RK: that's strange
21:34 < sipa> are you sure it's using regtest params?
21:35 < sipa> fuzzing should automatically find interesting inputs, so if the corpus onky have xprv ones... that probably means those are the ones that trigger coverage
21:46 < phantomcircuit> S3RK, it's also possible it just needs more time, if it's not something that's trivial to find or needs a specific magic value
21:52 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
21:54 -!- jukiki [5cd30a91@ipservice-092-211-010-145.092.211.pools.vodafone-ip.de] has joined #bitcoin-core-dev
22:00 -!- Snowstormer [~Snowstorm@195.206.169.184] has quit []
22:11 -!- IGHOR [~quassel@176.121.4.135] has quit [Quit: http://quassel-irc.org ? ??????????? ?????????. ????-??.]
22:16 -!- IGHOR [~quassel@176.121.4.135] has joined #bitcoin-core-dev
22:22 -!- ajbiz11 [~ajbiz11@84.39.117.57] has joined #bitcoin-core-dev
22:43 -!- jukiki [5cd30a91@ipservice-092-211-010-145.092.211.pools.vodafone-ip.de] has quit [Remote host closed the connection]
23:02 < shesek> I filed the getwalletinfo bug at https://github.com/bitcoin/bitcoin/issues/20297
23:23 -!- Kiminuo [~mix@141.98.103.76] has joined #bitcoin-core-dev
23:28 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
23:48 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
23:49 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Client Quit]
23:49 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
23:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:54 < bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/5d32009f1a3b...88776c292606
23:54 < bitcoin-git> bitcoin/master faf58ab MarcoFalke: ci: Add --with-libs=no to one ci config
23:54 < bitcoin-git> bitcoin/master fafc529 MarcoFalke: test: Run AssetTest even if built --with-libs=no
23:54 < bitcoin-git> bitcoin/master fa3967e MarcoFalke: test: Replace ARRAYLEN with C++11 ranged for loop
23:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:54 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #20245: test: Run script_assets_test even if built --with-libs=no (master...2010-testAssetTestlibconsensus) https://github.com/bitcoin/bitcoin/pull/20245
23:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
--- Log closed Wed Nov 04 00:00:06 2020