--- Log opened Tue May 04 00:00:00 2021
--- Day changed Tue May 04 2021
00:00 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev
00:16 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:16 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #21848: refactor: Make CFeeRate constructor arch-independent (master...2105-feerate) https://github.com/bitcoin/bitcoin/pull/21848
00:17 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:18 -!- duringo [2d57d6c5@45.87.214.197] has quit [Ping timeout: 240 seconds]
00:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:27 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #21849: fuzz: Limit toxic test globals to their respective scope (master...2105-fuzzToxic) https://github.com/bitcoin/bitcoin/pull/21849
00:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:40 -!- jespada [~jespada@87.74.37.248] has joined #bitcoin-core-dev
00:43 -!- Guyver2_ [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
00:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:45 < bitcoin-git> [bitcoin] laanwj pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/e2d4e67a8fcc...ab9a566ab333
00:45 < bitcoin-git> bitcoin/master ea269c7 Jon Atack: contrib: parse I2P addresses in generate-seeds.py
00:45 < bitcoin-git> bitcoin/master e01f173 Jon Atack: contrib: add a few I2P seed nodes
00:45 < bitcoin-git> bitcoin/master 142e2da Jon Atack: net: add I2P seeds to chainparamsseeds
00:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:45 < bitcoin-git> [bitcoin] laanwj merged pull request #21825: net: add I2P hardcoded seeds (master...i2p-hardcoded-seeds) https://github.com/bitcoin/bitcoin/pull/21825
00:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:45 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]
00:46 -!- prayank [~andr0irc@2402:8100:206c:68c8:30b0:af4b:7735:463b] has joined #bitcoin-core-dev
00:55 < wumpus> ryanofsky: done
00:57 -!- dnm21881[m] [dnm21881ma@gateway/shell/matrix.org/x-llapygmoibnbsrtg] has joined #bitcoin-core-dev
00:58 -!- dnm21881[m] [dnm21881ma@gateway/shell/matrix.org/x-llapygmoibnbsrtg] has left #bitcoin-core-dev []
01:00 -!- lkqwejhhgasdjhgn [~kljkljklk@p200300d46f06bf00ea203cd14cca75b0.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
01:04 < gmaxwell> Antpool taproot block, thats over 50% hashpower now.
01:06 < aj> \o/
01:07 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 240 seconds]
01:11 < hugohn> hi, I'm curious what else needs to be done before https://github.com/bitcoin/bips/pull/1097 can get a BIP number assigned?
01:11 < hugohn> I saw some chatter earlier about folks wanting to change the BIP process, but until that becomes more clear I assume the process stays the same.
01:11 < hugohn> (also yay on Taproot signaling progress)
01:12 -!- Guyver2_ [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
01:14 < wumpus> hugohn: nothing, it should just get a BIP number assigned
01:15 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 240 seconds]
01:15 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev
01:16 < wumpus> ping @luke-jr ^
01:16 < aj> hugohn: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018868.html suggests assigning a name in the meantime, i guess like hugohn-multisig-setup; otherwise what wumpus said
01:19 < hugohn> @wumpus @aj thanks !  
01:19 < wumpus> yes, moving to names might make sense too, in any case please don't let bitcoin innovation be stuck on having to centrally assign numbers, this shouldn't be an issue
01:20 < hugohn> I've already named the branch "bip-hugonguyen-bsms". Does it need to be included in the spec itself?
01:25 < hugohn> on a side note: I think using BIP numbers or acronyms like BSMS / PSBT as unique identifiers for a spec is still more ideal. Using personal names as identifiers for a standard seems... weird :) 
01:26 < hugohn> not to mention the long ID is a mouthful / harder to share
01:27 < hugohn> although the idea of of a more decentralized process does sound good
01:29 < hugohn> maybe the process could be decoupled, but the ID aspect could stay centralized (e.g. there could be a BIP on BIP number generation). just thinking out loud.
01:29 < wumpus> an idea we had early was to simply use the PR number as BIP number
01:29 < wumpus> some projects (rust, I think?) use this approach
01:30 < wumpus> but also there was some effort to make BIP numbers meaningful, certain ranges map to certain things, it is not simply a sequence generator
01:32 < wumpus> agree that having an author name in it is weird, on the other hand, namespacing is hard, many projects eventually settle on organization/pseudonym based namespacing to prevent name squatting etc
01:32 < hugohn> right. if it's not a simple sequence generator, a BIP on BIPs probably makes more sense.
01:33 < wumpus> this is mustly a problem if it would be managed by as scriptbot
01:33 < wumpus> you mean like BIP1 and 2?
01:34 < hugohn> yes
01:34 < wumpus> in any case, this discussion is kind of off-topic here, the bitcoin core project is one implementation, that the current BIPs repository is in the same orginazation is a historical artifact, it does not mean BIPs 'belong' to bitcoin core or something like that
01:39 < michaelfolkson> I think there will be future discussions on a revised BIP process once (hopefully) Taproot activation is completed hugohn if you'd like to engage with that https://github.com/bitcoin/bips/pull/1015
01:39 < michaelfolkson> A few things I think are probably in need of a revamp (or at least a discussion)
01:40 < hugohn> thanks @michaelfolkson . I'd take a look.
01:40 < wumpus> ideally it should be a fast and low-friction process
01:44 < michaelfolkson> Right, there are a few edge cases that need ironing out too eg what "Rejected" means and how you get out of "Rejected" status (if indeed you ever do)
01:51 < michaelfolkson> I'm assuming GUI translation issues should be in the GUI repo and not the main repo? https://github.com/bitcoin/bitcoin/issues/21847
01:52 < wumpus> correct, that is what the GUI repo is for
01:53 < wumpus> i think we should add an entry to the "https://github.com/bitcoin/bitcoin/issues/new/choose" list for GUI issues, redirecting people to the appropriate repository
01:54 < hugohn> @wumpus I understand. I think we should continue with this "historical artifact", as unfortunate as it is, until there's a better way. 
01:55 < hugohn> As the Bitcoin protocol slowly ossifies, the bulk of new specs will likely be in the Application layer. It does make less sense to bundle them with the Core project.
01:56 < michaelfolkson> hugohn: They aren't really bundled with the Core project. It is true the BIPs repo is under the Bitcoin Core GitHub org but no Bitcoin Core maintainers merge BIP PRs afaik so I think it is fine under the Core org
01:57 < michaelfolkson> hugohn: I personally think it would be overkill to give the BIPs repo its own org
01:59 < michaelfolkson> wumpus: There already is "An issue or feature request related to the GUI" option when you open an issue. Is that what you mean?
01:59 < michaelfolkson> wumpus: You click on that option and you get "Any report, issue or feature request related to the GUI should be reported at
01:59 < michaelfolkson> https://github.com/bitcoin-core/gui/issues/"
01:59 < wumpus> michaelfolkson: yes, except it should send you to the GUI repo
01:59 < wumpus> oh okay, that's a bit weird but i guess it works
01:59 < michaelfolkson> wumpus: Ah ok I see what you mean
02:01 < michaelfolkson> I agree that would be optimal but not sure if you can be redirected to a different repo when you click a new issue option
02:01 < wumpus> i guess the problem is that "gui" will have the same options, by definition, because it has the same underlying repository
02:01 < michaelfolkson> Right
02:02 < wumpus> i thought it could be like the "view policy" link for security reports, but apparently that one is a special edge cases by github
02:07 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 260 seconds]
02:16 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev
02:38 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 240 seconds]
02:39 -!- ogo [~ogo@gateway/tor-sasl/ogo] has joined #bitcoin-core-dev
02:39 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
03:03 -!- vincenzopalazzo [~vincenzop@host-79-37-17-61.retail.telecomitalia.it] has joined #bitcoin-core-dev
03:04 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 252 seconds]
03:08 -!- jespada [~jespada@87.74.37.248] has quit [Quit: Leaving]
03:21 -!- Sage56Koss [~Sage56Kos@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-dev
03:26 -!- Sage56Koss [~Sage56Kos@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 265 seconds]
03:37 -!- owowo [~ovovo@91.193.4.45] has joined #bitcoin-core-dev
03:37 -!- owowo [~ovovo@91.193.4.45] has quit [Changing host]
03:37 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
03:40 -!- d0minik [5f5afe59@ip5f5afe59.dynamic.kabel-deutschland.de] has joined #bitcoin-core-dev
03:41 -!- d0minik [5f5afe59@ip5f5afe59.dynamic.kabel-deutschland.de] has quit [Client Quit]
04:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:19 < bitcoin-git> [bitcoin] fanquake pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/ab9a566ab333...0ca8b7e7ecd5
04:19 < bitcoin-git> bitcoin/master faeabef MarcoFalke: ci: Enable D_GLIBCXX_DEBUG for multiprocess task
04:19 < bitcoin-git> bitcoin/master fad0f21 MarcoFalke: ci: Use clang in multiprocess task to avoid OOM
04:19 < bitcoin-git> bitcoin/master fa44f51 MarcoFalke: ci: Clarify that previous_releases task is using DEBUG
04:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:19 < bitcoin-git> [bitcoin] fanquake merged pull request #21812: ci: Enable D_GLIBCXX_DEBUG for multiprocess task (master...2104-ciDEBUG) https://github.com/bitcoin/bitcoin/pull/21812
04:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:26 -!- xxxyyyzzz111 [014084b8@1-64-132-184.static.netvigator.com] has joined #bitcoin-core-dev
04:27 -!- xxxyyyzzz111 [014084b8@1-64-132-184.static.netvigator.com] has left #bitcoin-core-dev []
04:42 < jonatack> MarcoFalke: question regarding fuzzed_data_provider.ConsumeBool(), which exists but isn't used yet...is it ok to add a line to an enum to use it? e.g. adding "kMaxValue = NET_MAX," at the end of netaddress.h::enum Network 
04:43 < fanquake> I see 169 uses of fuzzed_data_provider.ConsumeBool() ?
04:44 < jonatack> er, ConsumeEnum, mistyped...or do we prefer to avoid changing enums to use it
04:45 -!- prayank [~andr0irc@2402:8100:206c:68c8:30b0:af4b:7735:463b] has quit [Ping timeout: 250 seconds]
04:47 -!- prayank [~andr0irc@2402:8100:206c:68c8:2d54:9856:1ebd:884f] has joined #bitcoin-core-dev
04:52 -!- bithees [6e25f434@WGPON-37244-52.wateen.net] has joined #bitcoin-core-dev
04:53 -!- bithees [6e25f434@WGPON-37244-52.wateen.net] has quit [Client Quit]
04:55 < jonatack> will propose using ConsumeEnum() and see what reviewers say
05:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:06 < bitcoin-git> [bitcoin] kiminuo opened pull request #21850: Remove `GetDataDir(net_specific)` function (master...feature/2021-05-get-data-dir-step-2) https://github.com/bitcoin/bitcoin/pull/21850
05:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:16 -!- ShapeShifter499 [~ShapeShif@unaffiliated/shapeshifter499] has joined #bitcoin-core-dev
05:25 -!- Zao_ [~Zao_@185.163.110.100] has quit [Remote host closed the connection]
05:33 -!- OldMiner [~OldMiner@185.169.233.12] has joined #bitcoin-core-dev
05:33 -!- smartineng [~Icedove@88.135.18.171] has joined #bitcoin-core-dev
05:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:45 < bitcoin-git> [bitcoin] fanquake opened pull request #21851: [WIP] build: support cross-compiling for arm64-apple-darwin20 (Apple M1) in depends (master...m1_support_depends) https://github.com/bitcoin/bitcoin/pull/21851
05:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:46 -!- GarouDan [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has joined #bitcoin-core-dev
05:58 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 240 seconds]
05:59 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
06:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:07 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #21852: ci: Add msan fuzz config (master...2105-ci12Msan) https://github.com/bitcoin/bitcoin/pull/21852
06:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:08 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:08 < bitcoin-git> [bitcoin] fanquake closed pull request #21414: doc: add arm macOS depends platform triplet (master...macOS-platform-triplets) https://github.com/bitcoin/bitcoin/pull/21414
06:08 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:15 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
06:17 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
06:20 -!- jespada [~jespada@87.74.37.248] has joined #bitcoin-core-dev
06:24 -!- smctwo [~smctwo@87.200.180.239] has joined #bitcoin-core-dev
06:25 -!- prayank [~andr0irc@2402:8100:206c:68c8:2d54:9856:1ebd:884f] has quit [Quit: irc thread exit]
06:28 -!- smctwo [~smctwo@87.200.180.239] has quit [Ping timeout: 240 seconds]
06:33 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
06:33 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev
06:34 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Ping timeout: 240 seconds]
06:40 -!- undvrainbowvita8 [~egp_@128-71-13-3.broadband.corbina.ru] has quit [Ping timeout: 268 seconds]
06:55 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
07:07 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
07:12 -!- xenial-user [~puppy@host109-156-143-160.range109-156.btcentralplus.com] has joined #bitcoin-core-dev
07:14 -!- xenial-user [~puppy@host109-156-143-160.range109-156.btcentralplus.com] has left #bitcoin-core-dev []
07:39 -!- ShapeShifter499 [~ShapeShif@unaffiliated/shapeshifter499] has quit [Quit: ShapeShifter499]
07:43 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 240 seconds]
07:44 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
07:49 -!- cguida1 [~Adium@2806:2f0:51c1:5cee:e16e:b2eb:67a2:57d9] has joined #bitcoin-core-dev
07:53 -!- cguida [~Adium@2806:2f0:51c1:5cee:ec28:28d8:7d26:5683] has quit [Ping timeout: 260 seconds]
08:00 < vasild> sdaftuar: https://github.com/bitcoin/bitcoin/pull/20685#discussion_r625856311 -- maybe the i2p router was restarted or the connection to it was interrupted in some way and the i2p thread did RemoveLocal() (here: https://github.com/bitcoin/bitcoin/blob/0ca8b7e7ecd5bc537fbc1e372f6755a34a136f7f/src/net.cpp#L2232-L2234) which undid the initial AddLocal(MANUAL) due to externalip
08:01 < vasild> later when the connection was reestablished the i2p thread does AddLocal(BIND) which is not "strong" enough to overcome fDiscover==false
08:02 < vasild> sounds plausible?
08:03 -!- stortz [c8b9c69a@unaffiliated/stortz] has joined #bitcoin-core-dev
08:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:06 < bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/0ca8b7e7ecd5...a1c6434e19bc
08:06 < bitcoin-git> bitcoin/master fab3017 MarcoFalke: ci: Set BASE_SCRATCH_DIR early, so that it can be used in test configs
08:06 < bitcoin-git> bitcoin/master fa399a7 MarcoFalke: ci: Use clang-12 in msan task
08:06 < bitcoin-git> bitcoin/master fa0422c MarcoFalke: ci: Add msan fuzz config
08:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:06 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #21852: ci: Add msan fuzz config (master...2105-ci12Msan) https://github.com/bitcoin/bitcoin/pull/21852
08:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:07 < jonatack> update on FuzzedDataProvider::ConsumeEnum(), proposed to allow passing it a std::optional<T> max_value, so ConsumeEnum() may be used without needing to change existing enums.
08:08 < vasild> does it assume contigious values starting from 0?
08:08 < jonatack> yes, same as before
08:09 < jonatack> only avoids having to add an alias to the enum in the codebase
08:09 < vasild> yeah, can't be otherwise :/
08:11 < jonatack> otherwise, there's the existing ConsumeWeakEnum(values list...
08:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:23 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a1c6434e19bc...3f8f238deb5a
08:23 < bitcoin-git> bitcoin/master cf83b82 MarcoFalke: fuzz: Limit toxic test globals to their respective scope
08:23 < bitcoin-git> bitcoin/master 3f8f238 MarcoFalke: Merge bitcoin/bitcoin#21849: fuzz: Limit toxic test globals to their respe...
08:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:23 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #21849: fuzz: Limit toxic test globals to their respective scope (master...2105-fuzzToxic) https://github.com/bitcoin/bitcoin/pull/21849
08:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:50 < luke-jr> hugohn: I think what it is missing, is something like "This BIP is not compatible with existing multisig software/hardware at all."
08:50 < luke-jr> (unless it is)
08:51 -!- smctwo [~smctwo@37.245.210.234] has joined #bitcoin-core-dev
08:51 -!- smctwo [~smctwo@37.245.210.234] has quit [Remote host closed the connection]
08:52 -!- smctwo [~smctwo@37.245.210.234] has joined #bitcoin-core-dev
08:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:59 < bitcoin-git> [bitcoin] Relaxo143 opened pull request #21854: doc: make small corrections (v0.21.1 release notes) (master...patch-1) https://github.com/bitcoin/bitcoin/pull/21854
08:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:08 -!- smctwo_ [~smctwo@37.245.210.234] has joined #bitcoin-core-dev
09:08 -!- smctwo_ [~smctwo@37.245.210.234] has quit [Remote host closed the connection]
09:09 -!- smctwo_ [~smctwo@37.245.210.234] has joined #bitcoin-core-dev
09:09 -!- smctwo [~smctwo@37.245.210.234] has quit [Ping timeout: 260 seconds]
09:13 -!- GarouDan [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has quit [Remote host closed the connection]
09:15 -!- GarouDan_ [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has joined #bitcoin-core-dev
09:16 -!- smctwo [~smctwo@37.245.210.234] has joined #bitcoin-core-dev
09:17 -!- stortz [c8b9c69a@unaffiliated/stortz] has quit [Quit: Connection closed]
09:19 -!- smctwo_ [~smctwo@37.245.210.234] has quit [Ping timeout: 265 seconds]
09:20 -!- GarouDan_ [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has quit [Ping timeout: 265 seconds]
09:20 -!- smctwo [~smctwo@37.245.210.234] has quit [Ping timeout: 265 seconds]
09:21 -!- GarouDan [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has joined #bitcoin-core-dev
09:24 -!- smctwo [~smctwo@37.245.210.234] has joined #bitcoin-core-dev
09:26 -!- GarouDan [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has quit [Ping timeout: 268 seconds]
09:26 -!- smctwo [~smctwo@37.245.210.234] has quit [Remote host closed the connection]
09:28 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 240 seconds]
09:28 -!- smctwo [~smctwo@37.245.210.234] has joined #bitcoin-core-dev
09:28 -!- lkqwejhhgasdjhgn [~kljkljklk@p200300d46f06bf00ea203cd14cca75b0.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!]
09:29 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
09:33 -!- smctwo [~smctwo@37.245.210.234] has quit [Remote host closed the connection]
10:00 -!- proofofkeags [~proofofke@205.209.28.54] has joined #bitcoin-core-dev
10:05 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
10:08 < michaelfolkson> fanquake: Someone is building Core on Apple M1 here https://bitcoin.stackexchange.com/questions/105126/could-not-detect-boost-libraries-when-configuring-bitcoin-core-apple-m1-mac-mi
10:09 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
10:10 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:10 < bitcoin-git> [bitcoin] jonatack opened pull request #21855: fuzz: enable passing a max value to FuzzedDataProvider::ConsumeEnum() (master...ConsumeEnum-enable-passing-max-value) https://github.com/bitcoin/bitcoin/pull/21855
10:10 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:11 -!- lightlike [~lightlike@p200300c7ef197400945876005b846753.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
10:12 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 252 seconds]
10:18 -!- smctwo [~smctwo@91.75.111.136] has joined #bitcoin-core-dev
10:23 -!- smctwo [~smctwo@91.75.111.136] has quit [Ping timeout: 260 seconds]
10:23 -!- GarouDan [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has joined #bitcoin-core-dev
10:24 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
10:25 -!- cguida1 [~Adium@2806:2f0:51c1:5cee:e16e:b2eb:67a2:57d9] has quit [Quit: Leaving.]
10:36 -!- jungly [~jungly@host-82-49-146-18.retail.telecomitalia.it] has quit [Ping timeout: 252 seconds]
10:37 -!- GarouDan [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has quit [Remote host closed the connection]
10:42 < hugohn> @luke-jr the inclusion of things like NO_ENCRYPTION mode and BIP39-like PBKDF2 function parameters in the spec is to help with backward compatibility. IMO the main thing that might not be backward compatible with all vendors is the stateful nature of the Signers, which I have stated in the Compatibility section.
10:46 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 260 seconds]
10:48 -!- GarouDan [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has joined #bitcoin-core-dev
10:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:52 < bitcoin-git> [bitcoin] adamjonas opened pull request #21856: doc: add OSS-Fuzz section to fuzzing.md doc (master...add-oss-fuzz) https://github.com/bitcoin/bitcoin/pull/21856
10:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:53 -!- GarouDan [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has quit [Ping timeout: 265 seconds]
10:56 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 250 seconds]
10:56 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
10:58 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev
10:59 -!- jarolrod [sid475272@gateway/web/irccloud.com/x-uxltcdqeskugbhyk] has quit [Ping timeout: 245 seconds]
10:59 -!- dunk [sid16@gateway/web/irccloud.com/x-szdtiubjgycubtjv] has quit [Ping timeout: 260 seconds]
11:00 -!- endogenic [sid145991@gateway/web/irccloud.com/x-rpbwvsocatvzzacr] has quit [Read error: Connection reset by peer]
11:00 -!- digi_james [sid281632@gateway/web/irccloud.com/x-bnvrcpkdhkxgxzpl] has quit [Ping timeout: 250 seconds]
11:01 -!- digi_james [sid281632@gateway/web/irccloud.com/x-denjnhnlzrimsgue] has joined #bitcoin-core-dev
11:02 -!- endogenic [sid145991@gateway/web/irccloud.com/x-ygsbkwstspmhypgh] has joined #bitcoin-core-dev
11:02 -!- jarolrod [sid475272@gateway/web/irccloud.com/x-urbxualqfzlausno] has joined #bitcoin-core-dev
11:02 -!- dunk [sid16@gateway/web/irccloud.com/x-iomuwjcindcxowba] has joined #bitcoin-core-dev
11:02 -!- hebasto [sid449604@gateway/web/irccloud.com/x-gkvwysjshowrbwdf] has quit [Ping timeout: 258 seconds]
11:04 -!- hebasto [sid449604@gateway/web/irccloud.com/x-legvqghpryoffxkf] has joined #bitcoin-core-dev
11:07 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 260 seconds]
11:10 -!- owowo [~ovovo@2a02:29b8:dc01:1881::2e] has joined #bitcoin-core-dev
11:10 -!- owowo [~ovovo@2a02:29b8:dc01:1881::2e] has quit [Changing host]
11:10 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
11:19 -!- IcKingAlpha [~ident@62.182.99.225] has joined #bitcoin-core-dev
11:21 < robert_spigler> luke-jr: I agree with hugohn's analysis
11:22 -!- vincenzopalazzo [~vincenzop@host-79-37-17-61.retail.telecomitalia.it] has quit [Quit: Leaving]
12:02 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Remote host closed the connection]
12:04 -!- pox [~pox@gateway/tor-sasl/pox] has joined #bitcoin-core-dev
12:05 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:06 -!- p0x [~pox@gateway/tor-sasl/pox] has joined #bitcoin-core-dev
12:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:07 < bitcoin-git> [bitcoin] Rqcker opened pull request #21857: Pull request (master...master) https://github.com/bitcoin/bitcoin/pull/21857
12:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:07 < bitcoin-git> [bitcoin] Rqcker closed pull request #21857: Pull request (master...master) https://github.com/bitcoin/bitcoin/pull/21857
12:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:09 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 240 seconds]
12:16 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 250 seconds]
12:20 -!- sat [571594ac@host-87-21-148-172.retail.telecomitalia.it] has joined #bitcoin-core-dev
12:23 -!- duringo [2d57d6c5@45.87.214.197] has joined #bitcoin-core-dev
12:28 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 240 seconds]
12:29 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
12:30 -!- sat [571594ac@host-87-21-148-172.retail.telecomitalia.it] has quit [Quit: Connection closed]
12:38 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
12:45 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
12:46 -!- duringo [2d57d6c5@45.87.214.197] has quit [Quit: Connection closed]
12:53 -!- biteskola [~biteskola@170.76.76.188.dynamic.jazztel.es] has joined #bitcoin-core-dev
12:58 < luke-jr> robert_spigler: I'm not saying it should or shouldn't be a certain answer - but it needs to be in the BIP, whatever it is :p
12:58 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
13:10 -!- smartineng [~Icedove@88.135.18.171] has quit [Quit: smartineng]
13:16 -!- p0x [~pox@gateway/tor-sasl/pox] has quit [Remote host closed the connection]
13:18 -!- OldMiner [~OldMiner@185.169.233.12] has quit [Remote host closed the connection]
13:18 -!- pox [~pox@gateway/tor-sasl/pox] has joined #bitcoin-core-dev
13:22 -!- zpao [~zpao@185.163.110.100] has joined #bitcoin-core-dev
13:52 < jnewbery> Hi folks. We have a p2p meeting scheduled in 10 minutes. Currently there aren't any proposed topics at https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings.
13:55 < gmaxwell> Current bitcoin core causes really old nodes to be unable to sync and to dos attack you.  The issue is that prior to 0.7-ish the size of headers messages wasn't limited, and the node requests headers from everyone.  They blast you with a multimegabyte header and disconnect and go do it to someoen else.  These old nodes seem to have also formed a fork at an early height, nodes that have this 
13:55 < gmaxwell> fork will send it to you and get rejected for sending a fork before the highest checkpoing-- another product of requesting headers.
13:56 -!- duringo [c11b0cfd@193.27.12.253] has joined #bitcoin-core-dev
13:56 < gmaxwell> Fixing this appears to be trivial: Just don't ever request headers from peers that aren't NODE_WITNESS-- the node will never request blocks from them anyways.   But I changed this and it breaks like a dozen tests, some of which didn't seem trivial to fix.
13:56 < gmaxwell> Someone who cares about p2p might want to fix this.
13:58 < gmaxwell> (until I stopped sending headers reqests to non-node witness peers, this garbage was few percent of my (pruned) node's bandwidth usage)
13:59 -!- wumpus [~ircclient@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 258 seconds]
13:59 < gmaxwell> (my correct behavior might be slowly fixing the second forked-chain problem since I should be healing the partition)
14:00 -!- wumpus [~ircclient@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev
14:00 < jnewbery> #startmeeting
14:00 < core-meetingbot> Meeting started Tue May  4 21:00:29 2021 UTC.  The chair is jnewbery. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
14:00 < core-meetingbot> Available commands: action commands idea info link nick
14:00 < amiti> hi
14:00 < jnewbery> #bitcoin-core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik 
14:00 < gleb> hi
14:00 < glozow> hi
14:00 < jnewbery> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
14:00 < sipa> hi
14:00 < ajonas> hi
14:01 < jnewbery> There aren't any proposed topics in https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings
14:01 < jnewbery> Feel free to share your priorities in https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-Current-Priorities
14:01 < jnewbery> Does anyone have any topics to add?
14:02 < sipa> i'm working on PR'ing minisketch 
14:02 < sipa> i think it's in a good enough state now
14:02 < jnewbery> \o/
14:02 < gleb> sipa: thank you! I'm working on more or less finalizing erlay to invite people running nodes. Fully went through antoine's review, gonna make one protocol tweak it seems.
14:03 < gleb> *to invite people to run nodes.
14:03 < sipa> gleb: cool, will run
14:03 < glozow> \o/
14:03 < jnewbery> sipa: are you looking for any specific help?
14:04 < sipa> not in particular, but review is of course always welcome
14:04 < sipa> with this PR https://github.com/sipa/minisketch/pull/20 (making us able to just build field size 32 instead of everything) the binary size goes from 3 MB to 64 KiB
14:04 < sipa> also way faster compilation
14:05 < jnewbery> that seems good
14:06 < jnewbery> ok, any other topics?
14:07 < jnewbery> alright!
14:07 < jnewbery> #endmeeting
14:07 < core-meetingbot> topic: 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
14:07 < core-meetingbot> Meeting ended Tue May  4 21:07:03 2021 UTC.  
14:07 < core-meetingbot> Minutes:        https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2021/bitcoin-core-dev.2021-05-04-21.00.moin.txt
14:08 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 240 seconds]
14:09 < jnewbery> gmaxwell: I'm surprised there are a dozen tests with nodes that aren't signalling NODE_WITNESS. Do you have a branch?
14:09 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
14:10 < jnewbery> as far as I'm aware, the only functional test with a node that doesn't signal NODE_WITNESS is p2p_segwit.py (and that should be removed in #21090
14:10 < gribble> https://github.com/bitcoin/bitcoin/issues/21090 | Default to NODE_WITNESS in nLocalServices by dhruv · Pull Request #21090 · bitcoin/bitcoin · GitHub
14:12 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
14:14 < gmaxwell> Well dozen is probably an exaggeration, it was more than p2p_segwit.   This might implement the expected functionality: https://0bin.net/paste/1ugjq4jz#XcT5A29tp0YlpDnYDs9NRD92Z9myByRpsJOMzwButl4
14:15 < gmaxwell> (I say might because the patch I run locally is much larger, but it looks like I previously saved out that chunk while trying to run the tests.)
14:17 < gmaxwell> gleb: what protocol change?
14:17 -!- smctwo [~smctwo@bba597217.alshamil.net.ae] has joined #bitcoin-core-dev
14:17 < jnewbery> Did you try gating on fHaveWitness instead of fClient?
14:17 -!- GarouDan [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has joined #bitcoin-core-dev
14:20 < gmaxwell> No, though we shouldn't be sending headers requests to non-node-network peers either--. But ah, I see your point wrt implicated tests.
14:21 < gleb> gmaxwell: antoine found this inconsistency, let me explain here in short (full convo is here: https://github.com/bitcoin/bitcoin/pull/21515#discussion_r624952992)
14:21 < sipa> gleb: was it needed to include minisketch in bitcoin-tx?
14:22 < gmaxwell> (my sequence was that I just fixed it for myself to see that it fixed the behavior... then just tried running the tests to see if it looked like it would be easy to submit upstream,  it failed a number of tests, so I just dropped it into the patch I carry.
14:23 < gleb> gmaxwell: Ah hold on, maybe ignore that.
14:23 < gleb> I just realized maybe it's fine all the way.
14:24 < gleb> sipa: sorry, are you referring to the way I integrate minisketch in the erlay PR?
14:24 < sipa> gleb: yeah, cherry picking that
14:24 < sipa> just wonder if there was a reason for that
14:25 < gleb> gmaxwell: yeah indeed, I withdraw my comment, no protocol tweaks. Will finish last touches per antoine feedback tomorrow, and freeze the version to run nodes.
14:26 < gmaxwell> gleb: good because I was about to respond to you hear after reading that saying I didn't undrestand the issue there. :P
14:26 < gleb> gmaxwell: I'm glad you're following the work anyway.
14:27 < gmaxwell> gleb: I think in general when we talk about erlay (e.g. in the paper and elsewhere) we use this "non-reachable peer" terminology, but non-reachability doesn't exist explicitly anywhere in the implementation of bitcoin core or the bitcoin protocol... so although non-reachable peers were a good concept for modling, it can be a little confusing when it comes to the implementation.
14:29 < gleb> gmaxwell: Agree, I should think if I could gracefully disconnect the "general intuition" from protocol language.
14:29 < sipa> right, the protocol should only concern itself with "inbound" and "outbound" and "recon sender" and "recon receiver"
14:30 < gleb> Also, I should think about non-reachable nodes with a node from the same NAT or something, I just realized our current approach is prone in this case?
14:31 -!- GarouDan [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has quit [Remote host closed the connection]
14:31 -!- undvrainbowvita8 [~egp_@128-71-13-3.broadband.corbina.ru] has joined #bitcoin-core-dev
14:31 < gleb> Say my "non-reachable" node A (as the peers can easily tell by probing IP) has my own trusted inbound node B and that's the only connection for B, then the peers can easily tell that transactions flooded from B are either from B or from A.
14:32 < gleb> I should admit I never considered this corner case.
14:33 < sipa> hmm, do we just want to disable reconciliation on connections to/from non-public IPs?
14:33 < gmaxwell> that shouldn't be neceesary.
14:34 < sipa> i think the problem is: you have internal node A, only connected to bridge node B, which is connected to the public network
14:35 < sipa> if A relay a tx to B, B will treat this as being a reachable node, and use erlay to relay it further... which it would never do if B were just a non-reachable node without internal nodes behind it?
14:35 < gleb> sipa: right. Or maybe if there are N bridges, but A is still generally unavailable.
14:36 < sipa> sorry, i swapped notation; my A and B are the B and A in your explanation
14:37 < gmaxwell> I don't want to comment much because I've probably forgotten everything but this seems confused to me.  The privacy loss comes from flooding conditionally flooding, using the reconcillation itself is just additive and harmless. 
14:37 < sipa> gleb: is the logic "only use recon for transaction received from inbound connections" now?
14:37 < gleb> sipa: only use flood in that case.
14:37 < gleb> Ok, there are 2 relevant flags.
14:37 < sipa> gmaxwell: the choice whether to relay through recon or flood reveals information
14:38 < gmaxwell> sipa: It should always relay through recon (otherwise it's potentially just adding missed items to the sets), it might choose to additionally relay through flooding.
14:38 < sipa> gmaxwell: that's not what erlay proposes
14:38 < gmaxwell> I don't remember it being broken. :P
14:39 < gleb> sipa is correct, it was always either or
14:39 < sipa> come on
14:39 < gmaxwell> sipa: failing to add it to recon strictly wastes bandwidth, unless I'm confused.
14:39 < gmaxwell> Quite possible I'm confused.
14:39 < gmaxwell> If you don't add it to recon but your remote peer does, you just end up with a fake difference.
14:40 < gmaxwell> As your remote peer won't make the same flood/no-flood decision you do.
14:40 < gmaxwell> Am I confused?
14:40 < sipa> i'm trying to swap in the whole idea again :)
14:40 < gleb> Yeah same here, gimme a second.
14:41 < sipa> gleb: what happens with locally generated transactions?
14:41 < gmaxwell> I don't think this changes the fundimental issue gleb is looking at though.
14:41 < gmaxwell> But I'm trying to remember how any of this works so every piece of confusion is standing out for me.
14:41 < gleb> sipa: The idea was to always reconcile local transactions. It's done to preserve privacy of non-reachable, but you won't understand why unless you know the full protocol...
14:42 < sipa> gleb: so in which cases do you only flood a tx?
14:43 < gleb> sipa: if the transaction is received from inbound AND the peer is 1 of 8 outbound flooding peers.
14:44 < gleb> The idea is: non reachable has no inbounds, so they never flood (so local txs should also not be flooded)
14:44 < sipa> which for now is effectively all outbound peers?
14:45 < gleb> sipa: yes, now. ANd my confusion was the case after bump, but now I think that case is fine.
14:45 < gleb> The bridge case is not fine though. When this non-reachable is a bridge.
14:45 < gmaxwell> If a transaction that comes in from an inbound peers is only flooded out and not reconciled, how will those txn ever end up in reconcoillation? :P
14:45 < sipa> i believe the solution is just changing the criterion to "received from inbound *with public IP* AND ..."
14:46 < gmaxwell> ehhh
14:46 < sipa> but i still want to understand this again
14:46 < sipa> because i don't remember why this flooding is done in the first place
14:47 < gmaxwell> I still don't believe that it floods instead of reconcilling rather than in addition to, I think that is either transparently wrong or I'm badly corrupted. :)
14:47 < sipa> gleb: you say "received", is that both when received through flooding and through recon?
14:48 < gleb> sipa: currently there is no distinction, since we added an extra round for INV (just non-duplicate INV). It's possible to compare by short id, but currently I don't.
14:48 < gleb> It all looks like inbound inv.
14:48 < sipa> ok, just trying to reconcile my memory
14:49 < gleb> gmaxwell: I have to think why I didn't do additive
14:49 < lightlike> isn't recon/flooding a property of the connection instead of the transaction? So that a tx received from an inbound would be flooded to outbounds, but reconciled with other inbound peers?
14:49 < sipa> lightlike: no
14:49 < sipa> (well, both)
14:49 < gmaxwell> My stored approximation of early is that you reconcile with peers, and also flood each transaction you recieve, regardless of how you recieve them, with low fanout to outbound peers (obeying the normal rules about not sending a peer a txn you already know they have).  I know this isn't exact in the details.
14:49 < gleb> yeah, both.
14:50 < sipa> so the decision to flood and not reconcile should correspond to a prediction that you will have that tx while your peer won't
14:50 < sipa> how does "received from an inbound connection" lead to that prediction?
14:51 < gleb> gmaxwell: The problem with that is that non-reachable nodes will do too much useless flooding. They learn a transaction from 1 reconciliation, and then they flood to all the rest outbound peers?
14:51 < gmaxwell> gleb: If nodeA and nodeB  both recieve tx X,  and nodeA decides to recon it, and nodeB decides to flood it,  then the recon wastes bandwidth.  The process I understood you describing above wouldn't have peers making the same recon decision for the same txn... 
14:52 < gleb> gmaxwell: ok, my approach works, and let me explain.
14:52 < gmaxwell> gleb: that is why the flooded relay is low fanout. 
14:52 < gleb> Node A doesn't add tx to the set_B because it flooded the tx to B. Node B doesn't add it to the set_A because it was received from A.
14:52 < gleb> That's why both sets won't have the tx at the end
14:53 < gmaxwell> gleb: But node_b also could have recieved it from someone else first.
14:54 < sipa> yes, it's clear to me you don't want to both flood and add to recon set, because the peer won't relay the tx back from to, so adding it to the set would hurt reconciliation
14:54 < gmaxwell> sipa: Why wouldn't they add the flooded txn to it, if was new to them?  It's free if both sides have it.
14:54 < sipa> the question is why is there an assumption in this received-from-inbound-and-relay-to-outbound case that there won't be a relay in the other direction (as in: why can't the peer have learned the tx from elsewhere)
14:55 < sipa> gmaxwell: any tx you actually receive announced through flooding you can delete from that peer's recon set (not sure if the current implementation does that), but if it does, that seems strictly better than adding
14:55 < sipa> (in case you flood)
14:56 < gmaxwell> Consider, nodeb gets a txn from c,  nodea also gets a txn from c.  Nodea elects to flood it to a, nodeb elects to recon it to a.  Now there is an excess set difference.  If instead nodea flooded it and added it to recon, and B did as well (including for flooded txn recieved from a) the only time there would be a retcon difference is during a race with the flooding.
14:56 < sipa> delete if it was in that set in the first place, of course
14:56 < gmaxwell> okay I agree that would also work.
14:57 < gleb> Yeah, I see the point indeed. We should get rid of this extra assumption
14:57 < gmaxwell> I think they're ... the same?  in both cases you get a extra item in recon during a race between a flood and a recon.
14:57 < sipa> gleb: do you do this currently in the code? if i INV a tx to you for whatever reason, and that tx was in your recon set with me, do you delete it from that set?
14:58 < gleb> sipa: now, but I'm realizing now I should.
14:58 < sipa> gmaxwell: yeah, you either want to both add it, or both delete it when flooded- deleting seems slightly more efficient
14:58 < gmaxwell> In any case, the model where everything is recon and some flooding occurs at low order doesn't have the issue that outbound only nodes behave differently, other than they just happened to not recieve any txn via flooding so they'll get txn later.   I'm not arguing that it should work that way, just trying to remember the motivation for it not working that way.
14:59 < gmaxwell> sipa: Agreed. Though I'm not clear why deleting is slightly more effcicient? just that never adding it on one side takes less computation? 
14:59 < sipa> gmaxwell: yes, it ~ns scal different
15:00 < sipa> not adding on both sides
15:00 < gleb> gmaxwell: well, I chose to reconcile in a queue-manner every 2 seconds (16 seconds per peer). And the queue consists of outbounds.
15:01 < gleb> If we stick to these rules, we also want to flood some to make relay across the "backbone" faster. 
15:01 < gleb> gmaxwell: how would you suggest to flood?
15:02 < gleb> My suggestion is to flood to fixed 8 outbounds, and only what was received inbound. In that case, it just gets relayed though the network of reachable nodes super fast, without non-reachable doing useless stuff ever.
15:03 < gmaxwell> sipa: GOOD. I am glad to agree!
15:03 < gmaxwell> gleb: okay, I don't understand how I was ever okay with that. lol
15:04 < gmaxwell> The issue is that it imposes a strong assumption on the existance of a "non-reachable node" -- which as you are realizing now (and maybe did before?) -- no such clean distinction really exists.
15:04 < gmaxwell> (e.g. the NATed node with some lan peers)
15:05 < gleb> gmaxwell: not really, I never have "if non-reachable". It just makes this implicit categorization by looking at "txs received inbound"
15:05 < gleb> Which is, yeah, not true for NAT stuff.
15:07 < gmaxwell> I don't have any of our old discussions-- lost the server :( -- it might be useful to see how we changed from "flood each new txn to a few outbound peers" to "flood to 8 outbound peers (currently all) but only things learned from inbound peers"?
15:08 < sipa> gmaxwell: by new do you mean "locally created", or "any new tx learned through whatever means at all" ?
15:08 < gleb> gmaxwell: despite us not liking, non-reachable nodes is the majority of the network. If they flood, it's very likely to be useless, because their public peers likely already know the tx.
15:08 < sipa> (i assume the second, as the first is a pretty bad privacy leak)
15:08 < gmaxwell> newly learned, however we learned it.. flooding, local, retcon. 
15:08 < gmaxwell> Anything accept to mempool accepts.
15:09 < gmaxwell> gleb: yes, its often useless.   But it is still a constant amount of data per accepted transaction.
15:09 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Remote host closed the connection]
15:09 < gmaxwell> (and not an amount that grows with the number of peers it has)
15:10 -!- pox [~pox@gateway/tor-sasl/pox] has joined #bitcoin-core-dev
15:10 < gmaxwell> if fanout > 1 the vast majority of flooding will always be useless.
15:11 < gleb> A reconciliation happens every 16 seconds, flood trigger is every 1/2 seconds or something. If flood to only outbound, a non-reachable nodes will flood almost all transactions to their reachable peers. So recon set will be empty?
15:11 < gleb> You suggest to try fanout=2/3? If fanout=8, we end up getting 0 gain today (just better scaling)
15:11 < sipa> the fact that flooding is only outbound does imply that more well-reachable nodes will learn about transactions faster than less-reachable nodes
15:11 < gmaxwell> Right, at least at one point I know I was thinking in terms of fanout=2.
15:13 < gmaxwell> perhaps we should reconsider that asymmetry, and instead do something like flooding only happens in one direction on each link,  and whichever side knew more transactions in the last recon is the potentially-flodder.
15:14 < sipa> so in that sense i can see how deciding to not flood outbound-received transactions may be a useful optimization... the network structure implies that you're receiving generally from a group of peers who likely are better connected than you are
15:14 < gmaxwell> sipa: yes I am starting to see how things ended up here.
15:15 < sipa> i don't really see the problem with it
15:15 < gleb> And we can always switch to something different if at some point NAT landscape changes?
15:15 < gmaxwell> Basically nowhere else in the bitcoin protocol is there this in/out distinction -- just in tx relay privacy timers (which were 'recently' introduced relatively speaking) and in peer eviction.
15:16 < gmaxwell> for one thing it takes 80% or whatever of bitcoin nodes out of participation in rapidly forwarding transactions, which seems ... like a really big step to take without an obvious reason.
15:17 < gmaxwell> I'm not sure why we'd intentionally do that.
15:18 < gleb> gmaxwell: the timings were 1s for 95% reachable, 5s for 95% non-reachable. Something along those numbers.
15:18 < gleb> (the time it takes to spread a transaction). Saying "rapidly forwarding" is not so different
15:18 < gleb> Again, assuming the topology.
15:19 < gmaxwell> Like, have we made a series of single steps that were logcal but gives a weird outcome?  Step 1. relay faster to outbound peers because we control them, so they're less likely to be spies monitoring our txn.  Step 2. Introduce reconcillation, but make flooding only happen for reachable nodes because it has some moral similarity to step 1.   Conclusion, 80% of bitcoin nodes no longer participate 
15:19 < gmaxwell> in fast propagation?   But that wasn't the original goal, it seems like a side-effect though perhaps a benign one?
15:19 < gmaxwell> but not completely benign since now we have problems with txn originated 'near' these flooding non-participants.
15:20 -!- smctwo [~smctwo@bba597217.alshamil.net.ae] has quit [Remote host closed the connection]
15:20 < gleb> gmaxwell: I believe I made those steps, I even had 1-3 steps above. I always tried to keep you and pieter in sync, but you might have got lost at some point.
15:20 < sipa> but even without the assymetry in flood relay speed between outbound/inbound, it is the case that better connected nodes (which is correlated with connections to them) will learn about transactions fasters
15:22 < gmaxwell> sipa: indeed, that was why the strawman alternative I suggested above elected whatever direction that sourced more txn to be the flooding direction.
15:23 < sipa> figure 19 in the paper shows bandwidth/latency simulations for a number of configurations
15:23 < gmaxwell> gleb: I probably wasn't lost, I probably was right there with you at the time, following along with whatever reasoning got us there.
15:23 < gmaxwell> :P
15:23 < gmaxwell> but I don't really get the reasoning now. :(
15:24 < sipa> "flooding is not as useful to peers which are better connected than you are" is the summary i think
15:24 < gmaxwell> sipa: re: better connected,  esp if outbound connections are increased, it's not even unlikely that a NATed node could end up better connected than some arbitarily selected inbound only node.
15:24 < gleb> sipa: in those experiments, I never tried to pick the flood peers in a smart way. It was always N, M% random across inbound/outbound.
15:26 < sipa> gleb: it is surprising to me that in fig 19 in the paper, increasing the number of outbound flood peers improves both bandwidth and latency
15:26 < sipa> gmaxwell: that's fair
15:27 < gleb> sipa: I can't explain that now.
15:28 < sipa> gleb: is that graph using the same logic (only flood transactions receiving on incoming connections)?
15:28 < gleb> sipa: yes I think so.
15:29 < sipa> that suggests that that decision (relay tx received via inbound through flooding to outbounds) is (in your simulation model) a very good predictor of who won't have a tx already
15:30 < sipa> basically you want to use flooding when you have reasons to believe you had a tx earlier than the recipient, while recon is for when you and your peer are equals
15:30 < gmaxwell> maybe I should step back and also try to explain my general unease with the hard in/out split.  Essentially, it makes a strong assumption on the global structure of the network.    Recently in dogecoin there were network collapse issues related to a similar asymmetry during IBD... where almost the entire network was all in IBD because it had fallen behind, and as result wouldn't serve blocks 
15:30 < gmaxwell> and only requested them from peers they connected out to (which were more themselves in the same broken state)
15:30 < sipa> and i guess "receiving through inbound" is a very good predictor for that (again, in your model, which may not actually correspond to reality)
15:34 < gmaxwell> sipa:  If you flood txn recieved through flooding, then indeed, those are going to be the txn that are new.   I don't actually know that in/out really matters for that to be true, except when only flooding to outbound makes it true.
15:34 < gleb> sipa: yeah, and that achieved in the following ways. Flooding is mainly used across reachable. We cap at 8 outbounds, so even though "having earlier" is true in 50%, that's fine because it's capped. 
15:35 < gleb> sipa: For reconciliation it matters mainly for non-reachable, and efficiency is achieved by reconciling every 2 seconds via queue. When you hit 2*8=16 seconds interval per peer, you already reconciled with 7 other peers since last time, so you are almost equal to that 8th peer.
15:36 < gleb> Sorry for keeping the reachable terminology, I'm just explaining how sipa logic maps to my design.
15:36 < gleb> Yeah, if the topology changes, it would no longer be as efficient. We might see more bandwidth (unlikely more than currently)
15:36 < gmaxwell> thats fine. my comment about the term being confusing was because it looked like it was causing confusion in the review.
15:37 < gleb> well, i mean you also would prefer to avoid reasoning about it in the design i thought?
15:38 < gmaxwell> gleb: like I think with the currently proposed design, the bandwidth per node on reachable nodes may go up a lot... becuase previously non-reachable nodes participated actively in forwarding turn into passive participants and don't forward mcuh txn at all.
15:38 < gleb> gmaxwell: you mean sending tx bodies?
15:38 < gmaxwell> gleb: maybe, thats my impression now but it could just be that I forgot why I used to think it was okay.  But I'm not confused by its current existance in the design
15:38 < gmaxwell> yes
15:39 < sipa> perhaps it is the case that even today most relay done by non-reachable nodes doesn't actually contribute much to tx propagation?
15:39 < gmaxwell> nah, it's like a 2:1 asymmetry as seen on my nodes.
15:40 < sipa> by "contribute" in don't mean in terms of bandwidth, but in terms of how much propagation speed would suffer if they stopped
15:40 < gmaxwell> (if you go through your IRC logs with me you'll see maybe a year ago I saw that and thought something was wrong that it was so asymetric then realized it was finally that nodes updated to the most recent broadcast timing logic)
15:40 < gmaxwell> sipa: I actually mean bandwidth though both might be true.
15:41 < gleb> gmaxwell: yes, I think this is very true. Reachable will take more work on forwarding tx bodies, making it even more asymmetrical. I think that's fair to expect.
15:41 < sipa> i don't see why that would be the case
15:41 < gmaxwell> just thinking through the implications of taking the majority of nodes out of the general forwarding process.
15:42 < gmaxwell> sipa: for discussion, assume 80% of nodes are behind nat.  Right now, they probably carry the majority of the work transmititng txs  (yes, they're slower, but there are many more of them).  Post erlay, they won't realy tx bodies except fairly rarely.
15:43 < gleb> sipa: consider an average non-reachable node. The time between any reconciliations for it is 2 seconds. And the time of relaying across *all reachable* is 1 second. I think this implies most tx body work is done by reachable.
15:43 < gmaxwell> ^
15:44 < sipa> ok let me be more specific about what i'm not convinced of
15:44 < gmaxwell> that doesn't seem desirable to me, ... some asymetry is unavoidable because they have fewer connections each.
15:44 < gleb> I probably was like "but they will still save a lot of announcements, so it's fine to increase tx body work"
15:44 < gmaxwell> gleb: I don't think I ever considered that particular aspect before.
15:44 < gmaxwell> (lol well, I really don't know what I thought before, it's been too long)
15:45 < sipa> i believe it is possible (but don't know) that if we could today change the code so that non-reachable nodes drastically reduce how much they perform tx announcements and that when doing so (a) bandwidth usage of reachable nodes won't be affected much and (b) propagation delays won't suffer much
15:45 -!- GarouDan [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has joined #bitcoin-core-dev
15:46 < sipa> basically i'm saying that it could be the case that effectively a lot of tx propagation work performed today by non-reachable nodes is redundant
15:46 < gleb> I think greg's 2:1 can't agree with you.
15:47 < gleb> I assume, non-reachable sends 0.5x of reachable's tx body traffic?
15:47 < gmaxwell> sipa: sendign tx _bodies_ is never redundant.
15:47 < gmaxwell> lemme go get current figures one sec.
15:47 < sipa> gmaxwell: ah good point, every body only arrives at every node once
15:48 < sipa> whatever non-reachable nodes are doing in that regard must be compensated by others
15:48 < sipa> ok, that's convincing
15:49 -!- Squidicc [~squid@pool-72-74-34-120.bstnma.fios.verizon.net] has joined #bitcoin-core-dev
15:49 < gmaxwell> crap I lost my shell history on my node and now need to remember how to use JQ... I want to look at the ratio tx message sizes on inbound peers.
15:49 < gmaxwell> (it's just data in getpeerinfo)
15:50 < gleb> So potentially 2 problems with current design: 1) NAT privacy (could probably be fixed) 2) deepening the asymmetry
15:50 < gmaxwell> my very bad informal memory says that it was asymmetric, but except for bognon peers not THAT asymmetric.
15:50 < gmaxwell> bogon*
15:50 -!- GarouDan [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has quit [Ping timeout: 252 seconds]
15:50 -!- Squidicuz [~squid@pool-72-74-34-120.bstnma.fios.verizon.net] has quit [Read error: Connection reset by peer]
15:53 < gmaxwell> also: fwiw, we created most of this asymmetry 'recently' with the relay grouping stuff... and it wasn't an intended effect.  When I did notice it I was confused/surprised.  Though I don't think the current level is a problem.
15:53 < gmaxwell> I had automation that was identifyign spies to ban based on part of that ratio and I noticed when it started flagging lots more peers.
15:54 < gleb> gmaxwell: was it symmetrical before groups? Even when we just had 2s/5s independent timers?
15:55 < gmaxwell> gleb: SO, it wasn't asymmetrical enough for me to notice, but I think I was triggering on unusual as 2:1. It's a little hard to say for absolute sure because deployments happen over time.
15:55 < gmaxwell> It's not impossible that the independant 2/5sec change was the cause, and it just took a long time to be deployed enough for me to notice (or some other factor made it more visible).  But I think it's likely that making all inbounds share a group was the cause.
15:56 < gmaxwell> I didn't *really* realize something was going on that I didn't understand until I saw a big asymmetry on a connection between sipa's node and mine.
15:57 < gmaxwell> which I couldn't dismiss as being some weird peer.
15:57 < gmaxwell> well, sipa is weird but his bitcoin node isn't. :P
15:57 < gleb> gmaxwell: sad we haven't noticed that during the shared timer design, that's the stuff i like to model... but probably didn't know how to at a time
15:57 < gleb> I think that could have been my first PR to core in 2018.
15:58 < gmaxwell> Well you don't know what you don't know.
15:58 < gmaxwell> You could easily model the txdata burden, I just never thought of it.
16:00 < gmaxwell> The tx serving burden has come up before, but in a different context-- like if you get multiple INVs for the same tx at almost the same time, it's better to pick the source more randomly rather than always go to the first.
16:00 < gmaxwell> sorry.
16:00 < gleb> But that stuff we also changed in the context of invblock or tx overhaul or something recently? :)
16:01 < gleb> like, this exact suggestion, making it random and not first received
16:02 -!- smctwo [~smctwo@bba597217.alshamil.net.ae] has joined #bitcoin-core-dev
16:03 < gleb> So, if we want to make it more symmetrical, we indeed could direct some flooding into inbound, and independently from the tx source (maaaybe based on prev performance). I expect we loose some overall efficiency that way, but if that's desired.
16:03 < gleb> Yeah, that's exactly figure 19, except it chooses the flood peers randomly.
16:04 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
16:04 < bitcoin-git> [bitcoin] fanquake closed pull request #21854: doc: make small corrections (v0.21.1 release notes) (master...patch-1) https://github.com/bitcoin/bitcoin/pull/21854
16:04 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
16:07 < sipa> ./src/bitcoin-cli getpeerinfo | jq -r 'map("\(if .inbound then "I" else "O" end) \((.bytessent_per_msg.tx // 0) / ((.bytessent_per_msg.tx // 0) + (1 + .bytesrecv_per_msg.tx // 0)))") | .[]' | sort -g
16:08 < sipa> gmaxwell: something like that?
16:08 < gmaxwell> ./bitcoin-cli getpeerinfo | jq -c '.[] | select(."bytessent_per_msg"."tx">0) | select(."bytesrecv_per_msg"."tx">0) | select(."inbound"==false) | ."bytessent_per_msg"."tx"/."bytesrecv_per_msg"."tx"' 
16:08 < gmaxwell> is what I ended up with.
16:09 < gmaxwell> but yea your is better.
16:09 < gmaxwell> these need to be normalized though because naturally you'll only recieve once.
16:09 < gleb> sipa: I'm looking at my simulator, and I'm realizing I had no "received from inbound" policy at a time. Same in the paper. It was always just "flood to 8 outbounds" policy.
16:10 < sipa> gleb: that's surprising
16:10 < gmaxwell> that is anti-surprising to me! :P
16:11 -!- smctwo [~smctwo@bba597217.alshamil.net.ae] has quit [Ping timeout: 240 seconds]
16:11 < sipa> it conflicts with my intuition for why increasing flooding reducing bandwidth
16:12 < gleb> oh, hold on, sorry, the simulator is old code and hard to understand now :(
16:15 < gleb> It seems like at the time the idea was to only flood what's announced by reconciliation initiator to reconciliation responder (not backwards). Sorry again for this thought bouncing. Yeah, it seems i always had this idea in mind: try not to flood from non-reachable nodes.
16:16 < gleb> And since inbound always initiates, we effectively announce "what is learned inbound". The lattest simulator has that it seems.
16:17 < gleb> Anyway, so should we try other configurations again and see how much bandwidth gain we loose by not making topology assumptions?
16:17 < sipa> just trying "flood relay everything to 2-3-4-5-6-7-8 outbound peers" ?
16:19 < gmaxwell> sipa: so my node has 65 peers that I've exchanged txn with, and overall has sent 3.26x the tx data it has recieved. I think that ratio is pretty low, considering it only recieves once but sends up to 65 times.
16:20 < gmaxwell> gleb: also maybe add to the simulator something to get information on how much tx body data will be sent/recieved?  I'm pretty sure the current scheme will behave pretty poorly in that respect.
16:21 < gleb> gmaxwell: you mean poor in the sense of asymmetry?
16:21 < gmaxwell> gleb: yeah, poor in the sense that total traffic on reachable nodes would increase a lot, while traffic at each non-reachable node decreases a bit.
16:22 < gmaxwell> (because the latter outnumber the former)
16:22 < gleb> Okay, maybe it's time to re-implement the simulator so that other people can actually review and use it easier. I'll start looking into it tomorrow.
16:23 < gmaxwell> :( I feel bad.
16:23 < sipa> this is a fairly simple policy change, so i don't think this needs to hold up code review much
16:23 < sipa> (if we'd make it)
16:23 < gmaxwell> yea I don't think it really changes the implementation much except for a few lines here and there.
16:23 < sipa> oh, and don't forget the "remove from recon sets whatever is send/received through flooding" - i think that matters
16:23 < gleb> sipa: i agree, most of the module remains the same, this stuff is even outside the module.
16:24 < gleb> sipa: i noted it, don't worry
16:24 < sipa> gleb: thanks!
16:24 < gmaxwell> in the meantime, minisketch could get merged, and dropped from the erlay PR. That would be nice progress.
16:24 < gleb> okay, thank you, i'll come back once i have the results. I agree on the plan ^
16:25 -!- GarouDan [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has joined #bitcoin-core-dev
16:25 -!- smctwo [~smctwo@bba597217.alshamil.net.ae] has joined #bitcoin-core-dev
16:30 -!- smctwo [~smctwo@bba597217.alshamil.net.ae] has quit [Ping timeout: 240 seconds]
16:31 < gmaxwell> sipa: I have this vague idea that since my tx body ratio is 3.26x that my inv data ratio should be also 3.26x, ideally.  (of course it won't be, it'll be beteen 32 and 64x because I have 64 peers and invs are flooded)
16:31 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 260 seconds]
16:33 -!- mrostecki [mrostecki@nat/suse/x-qunzagdczmwaveyc] has quit [Ping timeout: 276 seconds]
16:34 < gmaxwell> oh, no it won't the invs ratio will be near 1 but both sides will be 64 times larger. duh.
16:34 -!- mrostecki [mrostecki@nat/suse/x-bdsgmfrittaifnzu] has joined #bitcoin-core-dev
16:49 -!- lightlike [~lightlike@p200300c7ef197400945876005b846753.dip0.t-ipconnect.de] has quit [Quit: Leaving]
16:55 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Remote host closed the connection]
16:56 -!- morcos [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev
17:02 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
17:04 -!- proofofkeags [~proofofke@205.209.28.54] has quit [Ping timeout: 268 seconds]
17:06 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 268 seconds]
17:07 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
17:09 -!- belcher_ is now known as belcher
17:17 < gmaxwell> sipa: it's not clear to me how it's possible to implement the policy to remove floods sent by the far side.  You can tell that you already have the txn when you recieve the flood,  so presumably you would have put it to be recon .. but it might have already been reconed and not part of your current recon set?
17:23 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 240 seconds]
17:24 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
17:28 < sipa> gmaxwell: in that case you don't remove it?
17:28 < sipa> i believe the set is kept explicitly, not just in sketch form
17:38 -!- mips [~mips@gateway/tor-sasl/mips] has joined #bitcoin-core-dev
17:47 -!- IckingAlpha1 [~ident@62.182.99.225] has joined #bitcoin-core-dev
17:47 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 265 seconds]
17:48 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev
17:50 -!- IcKingAlpha [~ident@62.182.99.225] has quit [Ping timeout: 260 seconds]
18:07 < gmaxwell> ah
18:07 < gmaxwell> that works then.
18:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
18:23 < bitcoin-git> [bitcoin] sipa opened pull request #21859: Add minisketch subtree and integrate in build/test (master...202105_minisketch) https://github.com/bitcoin/bitcoin/pull/21859
18:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
18:23 < sipa> ... 7712 lines
18:23 < sipa> really?
18:24 < fanquake> That's a lot of lines
18:26 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 246 seconds]
18:27 < sipa> it seems correct
18:39 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined #bitcoin-core-dev
18:52 -!- spinza [~spin@102.132.245.16] has quit [Quit: Coyote finally caught up with me...]
18:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
18:54 < bitcoin-git> [bitcoin] fanquake opened pull request #21860: [0.21] Backport update to Boost download URL (0.21...backport_boost_download) https://github.com/bitcoin/bitcoin/pull/21860
18:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
18:54 < sipa> jnewbery: feel like having a look at https://github.com/sipa/minisketch/pull/35 ?
18:57 -!- biteskola [~biteskola@170.76.76.188.dynamic.jazztel.es] has quit [Remote host closed the connection]
18:57 < gmaxwell> sipa: secret to programmer 'productivity' -- tables.
18:58 < sipa> gmaxwell: hmm?
19:00 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
19:00 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3f8f238deb5a...dc8da2a68554
19:00 < bitcoin-git> bitcoin/master fafb880 MarcoFalke: refactor: [index] Replace deprecated char with uint8_t in serialization
19:00 < bitcoin-git> bitcoin/master dc8da2a fanquake: Merge bitcoin/bitcoin#21824: refactor: [index] Replace deprecated char wit...
19:00 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
19:00 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
19:00 < bitcoin-git> [bitcoin] fanquake merged pull request #21824: refactor: [index] Replace deprecated char with uint8_t in serialization (master...2105-refactorUint8_t) https://github.com/bitcoin/bitcoin/pull/21824
19:00 < gmaxwell> sipa: the minisketch LOC is 95% tables.
19:00 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
19:01 < gmaxwell> Development Effort Estimate, Person-Years (Person-Months) = 1.84 (22.05)
19:01 < gmaxwell> strangly thats maybe not that far off. :P
19:01 < sipa> gmaxwell: more like 30%, actually
19:01 < sipa> or less
19:05 < gmaxwell> hm! I guess they just look huge when scrolling past them.
19:11 < sipa> there are 161 field implementations, and each have a few tables
19:11 < sipa> together that's 2000 lines or so
19:12 -!- IckingAlpha1 [~ident@62.182.99.225] has quit [Quit: —I-n-v-i-s-i-o-n— 3.5.2.1 (January '19)]
19:14 < gmaxwell> most of the loc are in build-aux. :P
19:15 < gmaxwell> src/ is:
19:15 < gmaxwell> SLOC	Directory	SLOC-by-Language (Sorted)
19:15 < gmaxwell> 1945    fields          cpp=1945
19:15 < gmaxwell> 1548    top_dir         cpp=1548
19:24 -!- spinza [~spin@102.132.245.16] has joined #bitcoin-core-dev
19:43 -!- dermoth_ [~dermoth@unaffiliated/dermoth] has joined #bitcoin-core-dev
19:43 -!- dermoth [~dermoth@unaffiliated/dermoth] has quit [Disconnected by services]
19:43 -!- dermoth_ is now known as dermoth
20:13 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
21:16 -!- GarouDan [~GarouDan@191.242.119.219.fibra.plimtelecom.com.br] has quit [Remote host closed the connection]
22:09 -!- awesome_doge [~Thunderbi@36-226-65-123.dynamic-ip.hinet.net] has joined #bitcoin-core-dev
22:18 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 240 seconds]
22:22 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Quit: pox]
22:28 -!- braydonf_ [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
22:39 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 260 seconds]
22:44 -!- pox [~pox@gateway/tor-sasl/pox] has joined #bitcoin-core-dev
22:52 -!- adiabat_ [~adiabat@63.209.32.102] has quit [Ping timeout: 265 seconds]
22:52 -!- adiabat_ [~adiabat@63.209.32.102] has joined #bitcoin-core-dev
22:55 -!- smctwo [~smctwo@bba597217.alshamil.net.ae] has joined #bitcoin-core-dev
22:59 -!- smctwo [~smctwo@bba597217.alshamil.net.ae] has quit [Ping timeout: 240 seconds]
23:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
23:17 -!- jungly [~jungly@host-79-35-187-51.retail.telecomitalia.it] has joined #bitcoin-core-dev
23:24 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
23:29 -!- jungly [~jungly@host-79-35-187-51.retail.telecomitalia.it] has quit [Ping timeout: 265 seconds]
23:31 -!- jungly [~jungly@host-79-35-187-51.retail.telecomitalia.it] has joined #bitcoin-core-dev
23:35 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
23:37 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
23:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:49 < bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/dc8da2a68554...779aaa7f03b2
23:49 < bitcoin-git> bitcoin/master fa5f938 MarcoFalke: test: Remove new_tx reference
23:49 < bitcoin-git> bitcoin/master fa5591d MarcoFalke: test: Hide tx rehash in helper
23:49 < bitcoin-git> bitcoin/master fa066f1 MarcoFalke: test: Run feature_cltv with MiniWallet
23:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:49 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #21754: test: Run feature_cltv with MiniWallet (master...2104-testCltvNoWallet) https://github.com/bitcoin/bitcoin/pull/21754
23:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:50 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Quit: pox]
23:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:54 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to 0.21: https://github.com/bitcoin/bitcoin/compare/194b9b8792d9...bbd89d23b3d0
23:54 < bitcoin-git> bitcoin/0.21 856de5b fdov: build,boost: update download url.
23:54 < bitcoin-git> bitcoin/0.21 bbd89d2 MarcoFalke: Merge bitcoin/bitcoin#21860: [0.21] Backport update to Boost download URL
23:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:55 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #21860: [0.21] Backport update to Boost download URL (0.21...backport_boost_download) https://github.com/bitcoin/bitcoin/pull/21860
23:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:59 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev
--- Log closed Wed May 05 00:00:46 2021