AaronvanW has quit [Quit: Leaving...]
koolazer has joined #bitcoin-core-dev
drue has joined #bitcoin-core-dev
javi404 has quit [Ping timeout: 260 seconds]
mudsip has joined #bitcoin-core-dev
mudsip has quit []
sipsorcery has quit [Ping timeout: 264 seconds]
b_101_ has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 260 seconds]
franbopzle has quit [Ping timeout: 246 seconds]
bitdex has quit [Remote host closed the connection]
bitdex has joined #bitcoin-core-dev
dermoth has quit [Ping timeout: 260 seconds]
dermoth has joined #bitcoin-core-dev
lisper29 has quit [Quit: Leaving]
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
Guest67 has joined #bitcoin-core-dev
Guest67 has quit [Client Quit]
Guest91 has joined #bitcoin-core-dev
Guest91 has quit [Quit: Client closed]
as2333 has quit [Quit: as2333]
javi404 has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/360e047a7102...296e88225096
<bitcoin-git> bitcoin/master e6864fa fanquake: contrib: remove builder keys
<bitcoin-git> bitcoin/master 296e882 MarcoFalke: Merge bitcoin/bitcoin#26598: contrib: remove builder keys
<bitcoin-git> [bitcoin] zpv closed pull request #26815: builder-keys: remove luke-jr (master...patch-1) https://github.com/bitcoin/bitcoin/pull/26815
<bitcoin-git> [bitcoin] MarcoFalke closed pull request #26598: contrib: remove builder keys (master...drop_non_guix_keys) https://github.com/bitcoin/bitcoin/pull/26598
Guyver2 has joined #bitcoin-core-dev
jakwolf[m] has quit [Quit: You have been kicked for being idle]
jon_atack has quit [Ping timeout: 268 seconds]
jon_atack has joined #bitcoin-core-dev
gossie has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [Closing Window]
<p2plife> init message: messages are odd, in code they are _("foo_").translated - not sure why the final "_" nor why the .translated
<p2plife> the result is that these messaged (seen with grep "init message" ~/.bitcoin/debug.log) are all ending with bytes e2 80 a6, and then the newline 0a
<p2plife> I noticed since on screen these bytes looked like random characters. is that a known problem? I couldn't find it mentioned in Issues on github
<p2plife> ok nevermind. that's the ellipsis unicode. it looks weird on plain terminals,
<hebasto> p2plife: maybe open an issue to let others to reproduce the behaviour you mentioned?
<hebasto> oh, nm, you mentioned the "ellipsis" unicode
___nick___ has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] MarcoFalke opened pull request #26817: doc: Remove copyright years (master...2301-doc-copy-🍼) https://github.com/bitcoin/bitcoin/pull/26817
brunoerg has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
<bitcoin-git> [bitcoin] MarcoFalke opened pull request #26818: test: Fix feature_startupnotify intermittent issue (master...2301-test-fix-s-🐫) https://github.com/bitcoin/bitcoin/pull/26818
AaronvanW has joined #bitcoin-core-dev
vasild_ has joined #bitcoin-core-dev
vasild has quit [Ping timeout: 255 seconds]
jungly has joined #bitcoin-core-dev
BUSY has quit [Ping timeout: 260 seconds]
BUSY has joined #bitcoin-core-dev
Guest39 has joined #bitcoin-core-dev
vasild_ has quit [Quit: leaving]
AaronvanW has quit [Remote host closed the connection]
vasild has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
halosghost has joined #bitcoin-core-dev
sipsorcery has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 268 seconds]
jungly has quit [Ping timeout: 260 seconds]
<bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/296e88225096...61f35159ffad
<bitcoin-git> bitcoin/master fac810b MarcoFalke: test: Fix feature_startupnotify intermittent issue
<bitcoin-git> bitcoin/master 61f3515 MarcoFalke: Merge bitcoin/bitcoin#26818: test: Fix feature_startupnotify intermittent ...
<bitcoin-git> [bitcoin] MarcoFalke closed pull request #26818: test: Fix feature_startupnotify intermittent issue (master...2301-test-fix-s-🐫) https://github.com/bitcoin/bitcoin/pull/26818
<bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/61f35159ffad...3212d104f4ac
<bitcoin-git> bitcoin/master f2fc03e Pasta: refactor: use braced init for integer constants instead of c style casts
<bitcoin-git> bitcoin/master 3212d10 MarcoFalke: Merge bitcoin/bitcoin#23829: refactor: use braced init for integer literal...
<bitcoin-git> [bitcoin] MarcoFalke merged pull request #23829: refactor: use braced init for integer literals instead of c style casts (master...use-braced-init) https://github.com/bitcoin/bitcoin/pull/23829
kexkey has quit [Ping timeout: 272 seconds]
kexkey has joined #bitcoin-core-dev
___nick___ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
___nick___ has joined #bitcoin-core-dev
___nick___ has quit [Client Quit]
___nick___ has joined #bitcoin-core-dev
SpellChecker_ has joined #bitcoin-core-dev
SpellChecker has quit [Ping timeout: 255 seconds]
b_101 has joined #bitcoin-core-dev
as2333 has joined #bitcoin-core-dev
b_101_ has quit [Quit: Lost terminal]
<bitcoin-git> [bitcoin] achow101 pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/3212d104f4ac...b4fb0a3255d3
<bitcoin-git> bitcoin/master d5f4ae7 Sebastian Falbesoner: wallet: fully migrate address book entries for watchonly/solvable wallets
<bitcoin-git> bitcoin/master 730e14a Sebastian Falbesoner: test: wallet: check that labels are migrated to watchonly wallet
<bitcoin-git> bitcoin/master b4fb0a3 Andrew Chow: Merge bitcoin/bitcoin#26761: wallet: fully migrate address book entries fo...
<bitcoin-git> [bitcoin] achow101 merged pull request #26761: wallet: fully migrate address book entries for watchonly/solvable wallets (master...202212-migratewallet_persist_addressbook) https://github.com/bitcoin/bitcoin/pull/26761
bitdex has quit [Ping timeout: 255 seconds]
bitdex has joined #bitcoin-core-dev
<p2plife> will people be releasing statement regarding if commits and recent changes from luke-jr are "audited"? there are rumours or doubt arising that sources are "compromised" (yes I know there is a review process, but not everyone knows)
<achow101> p2plife: luke isn't a maintainer, he can't merge anything
<bitcoin-git> [bitcoin] hebasto opened pull request #26821: refactor: Make `ThreadHTTP` return void (master...220105-http) https://github.com/bitcoin/bitcoin/pull/26821
cotsuka has quit [Quit: Bye!]
<halosghost> though, might be a different question about knots
cotsuka has joined #bitcoin-core-dev
Guest39 has quit [Ping timeout: 260 seconds]
AaronvanW has joined #bitcoin-core-dev
<jamesob> Surprising that this is dead code in the functional test suite: https://github.com/bitcoin/bitcoin/blob/master/test/functional/test_framework/script.py#L817-L820
<jamesob> Where are all the taproot spends?
<jamesob> Looks like they only happen in feature_taproot.py, which is horrifying
<sipa> Why?
<jamesob> I just mean it's a beastly functional test when attempting to read through and find a simple taproot spend
<sipa> If you mean that feature_taproot.py is horrifying in terms of readability, I agree (though I'm still quite proud of it...).
<jamesob> Yeah just in terms of readability. I'm sure it delivers a lot of functionality and coverage
<sipa> I thought you meant it's horrifying that that's the only thing testing it.
<jamesob> I'm just surprised - I thought P2TR spends were more common in the functional tests
<sipa> Well most tests involve directing bitcoind to do the spending; there are few uses for doing the spending on the functional test side (except when testing verification of the relevant rules).
Talkless has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] brunoerg opened pull request #26822: p2p, rpc: don't allow past absolute timestamp in `setban` (master...2023-01-fix-ban-time) https://github.com/bitcoin/bitcoin/pull/26822
AaronvanW has quit [Ping timeout: 264 seconds]
<bitcoin-git> [bitcoin] MarcoFalke opened pull request #26823: refactor: Work around Werror=free-nonheap-object in AssumeCalculateMemPoolAncestors (master...2301-s390x-refactor-gcc-bug-📧) https://github.com/bitcoin/bitcoin/pull/26823
AaronvanW has joined #bitcoin-core-dev
<achow101> meeting?
<Murch1> Hi
<brunoerg> Hi
<achow101> #startmeeting
<core-meetingbot> Meeting started Thu Jan 5 19:02:41 2023 UTC. The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
<core-meetingbot> Available commands: action commands idea info link nick
<achow101> #bitcoin-core-dev Meeting: achow101 aj amiti ariard b10c BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj larryruane lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik petertodd
<achow101> phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
<sipa> Hi
<jamesob> hi
<instagibbs> hi
<furszy> hi
<kvaciral> hi
<achow101> Welcome to the weekly general IRC meeting.
<achow101> There are no preproposed meeting topics this week, does anyone have any last minute topics to discuss?
<larryruane> hi
<achow101> #topic high priority for review
<core-meetingbot> topic: high priority for review
<achow101> anything to add/remove/merge?
<jamesob> did the board get reset? I though I had an assumeutxo PR on there
<jamesob> can I add #25740?
<gribble> https://github.com/bitcoin/bitcoin/issues/25740 | assumeutxo: background validation completion by jamesob · Pull Request #25740 · bitcoin/bitcoin · GitHub
<achow101> jamesob: I don't think it's been changed
<jamesob> that's weird... I definitely remember my AU PR being on there
<lightlike> maybe it was the one that got merged recently?
<jamesob> hmm, dunno.
<achow101> jamesob: added
<jamesob> thanks
<larryruane> I may as well ask here, anyone have a PR they'd like to be covered in review club? (I'm hosting on Feb 15)
<achow101> all of them :)
<larryruane> Also we're always welcome to have people host, if you'd like to try that
<larryruane> :)
Guest96 has joined #bitcoin-core-dev
<achow101> LarryRuane: I think anything in the high prio board and the pr status board (https://github.com/orgs/bitcoin/projects/5/views/1)
<larryruane> achow101: +1 thanks
<achow101> anything else to discuss?
<achow101> #endmeeting
<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
<core-meetingbot> Meeting ended Thu Jan 5 19:17:29 2023 UTC.
<bitcoin-git> [bitcoin] fanquake opened pull request #26824: build: fix configuring with only bitcoin-util (master...fix_bitcoin_util_configure) https://github.com/bitcoin/bitcoin/pull/26824
<achow101> laanwj: I guess I should take over chairing the meetings permanently?
<jamesob> what's the policy on type hints in test_framework? are people amenable to those being added? I think generally it'd be a pretty big contributor to readability
<achow101> jamesob: we have type hints in some places, and the linter does run a type checker
<jamesob> e.g. in test_framework.key, test_framework.wallet, there are many places where the function has to be inspected to determine return type but just having that information accessible in the function signature would be convenient
<achow101> I would say add type hints as new stuff is added, kind of like how we do style stuff
<jamesob> I do think it would be beneficial if someone just started adding type information to signatures... because isn't it all trivially verifiable by the type checker? Like if someone adds incorrect annotations, that will be caught by CI, right?
<achow101> although test_framework is pretty low volume so blanket adding type annotations to all function signatures probably wouldn't cause too much rebasing?
<jamesob> yeah I wouldn't think so
<sipa> I think it may be helpful to do it for the few modules where it would actually have helped you in your work.
<jamesob> I think in individual tests would be too much churn, but for the framework I think adding annotations is reasonable; it's almost like scripted-diff in that it's CI enforced
<jamesob> sipa: yeah that's what I was thinking
<sipa> Given that we apparently already have annotations in some modules but not others, it doesn't seem like there is much of a need to do it over the entirety of the function test codebase at once.
<jamesob> (not to discourage adding type info in new tests...)
<bitcoin-git> [bitcoin] fanquake opened pull request #26825: build: remove already tested headers from AC_CHECK_HEADERS (master...remove_already_tested_headers) https://github.com/bitcoin/bitcoin/pull/26825
<jamesob> sipa: yeah and that'd be really tedious work anyway...
<sipa> And there isn't a strict separation between "having" and "not having" annotations; like you could go put "Any" on everything, and it wouldn't mean anything.
<sipa> (no pun intended)
SpellChecker_ has quit [Remote host closed the connection]
<jamesob> hah, right
SpellChecker has joined #bitcoin-core-dev
Guest96 has quit [Quit: Client closed]
<bitcoin-git> [bitcoin] fanquake opened pull request #26826: refactor: remove windows-only compat.h usage in randomenv (master...windows_randomenv_compat_usage) https://github.com/bitcoin/bitcoin/pull/26826
<bitcoin-git> [bitcoin] fanquake opened pull request #26827: doc: use "std lib clock" over "C++11 clock" (master...doc_std_lib_clocks) https://github.com/bitcoin/bitcoin/pull/26827
andrewtoth has quit [Remote host closed the connection]
andrewtoth has joined #bitcoin-core-dev
vasild has quit [Remote host closed the connection]
Talkless has quit [Quit: Konversation terminated!]
vasild has joined #bitcoin-core-dev
andrewtoth has quit [Remote host closed the connection]
andrewtoth has joined #bitcoin-core-dev
___nick___ has quit [Ping timeout: 268 seconds]
brunoerg has quit []
lisper29 has joined #bitcoin-core-dev
<lisper29> I'm learning to use BIP32 derived addresses in bitcoind. BIP32 4.3.2 (pub->pub) ends by specifying that when a derivation at index i is invalid "one should proceed with the next value for i". So if the deriveaddresses RPC returns an error, I'll try the next index. But I don't see the getnewaddress RPC or the Qt "create new receiving address" button's code trying the next index for this type of failed derivation. Do
<lisper29> they have a bug in that they'll never get past that invalid index? (pubkey.cpp CPubKey::Derive is what I assume performs the BIP32 4.3.2 validation.)
<sipa> It's not a bug in that it cannot occur. I should perhaps explain that in the BIP.
Guest57 has joined #bitcoin-core-dev
<lisper29> sipa: I think you've just ended many weeks of my misery. thank you!
Guest57 has quit [Client Quit]
<sipa> "cannot" as in the probability of it ever occurring in our lifetimes is negligible
<bitcoin-git> [bitcoin] andrewtoth opened pull request #26828: assumeutxo: catch and log fs::remove error instead of two exist checks (master...assumeutxo-remove-fix) https://github.com/bitcoin/bitcoin/pull/26828
<lisper29> Do I understand correctly then that deriveaddresses also will always produce a valid address at every index in [0,2^31-1]?
<sipa> yes
<lisper29> Ah I see, it's low probability, got it. I did see the 2^-126 probability for another section of BIP32. This section didn't mention it. And anyway its specified algorithm says that if invalid then try the next. So not being cryptographer or mathematician, I figured I must follow prescribed algorithm.
<lisper29> Hurray, thank you. That's a huge weight off a programmer's shoulders.
<lisper29> Last question: If that low probability index occurs, does deriveaddresses return an error? Then I can write code to try next index. Or does deriveaddresses return an address that I won't know is dangerous to advertise?
halosghost has quit [Quit: WeeChat 3.7.1]
<lisper29> If it's meaningless to reason at such low probabilities (e.g. because many other things can fail before then, such as hashes colliding), please ignore of course.
Guyver2 has left #bitcoin-core-dev [Closing Window]
<sipa> Yeah, it's just practically impossible to hit, even if someone were to intentionally try to make it happen with all computational power in the world.
<sipa> We can't even write a test for it, because of that.
AaronvanW has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-core-dev
<lisper29> Right, I guessed that it was low from no test vectors and the 2^-126 mentioned elsewhere. I know what to do. Assuming CPubKey::Derive does properly return a failure, there's 0 (not just negligible) probability of deriveaddresses returning an address when it shouldn't. So I'll write client code to loop to next index. Regardless, client code will never see a bad address from deriveaddresses, even if it runs until the
<lisper29> last table entry at: https://en.wikipedia.org/wiki/Timeline_of_the_far_future . And I'll tell all users of my program that in dealing with cryptography (which underlies bitcoin), there are these negligibly likely events. That's enough agonising for now :-)
AaronvanW has quit [Client Quit]
sipsorcery has quit [Ping timeout: 265 seconds]