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
<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
<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
<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 :-)