bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
c_arc has joined #bitcoin-core-dev
prayank has quit [Quit: irc thread exit]
jawed has joined #bitcoin-core-dev
<jawed>
BIP meeting is happening nowish?
<michaelfolkson>
jawed: Happened on #bitcoin-dev channel. I'll send a summary and a conversation log to the mailing list
<jawed>
michaelfolkson thanks look like I had the wrong time
jawed has left #bitcoin-core-dev [#bitcoin-core-dev]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] meshcollider opened pull request #23142: Return false on corrupt tx rather than asserting (master...202109_no_assert_corruption) https://github.com/bitcoin/bitcoin/pull/23142
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
c_arc has joined #bitcoin-core-dev
jarthur has quit [Quit: jarthur]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
lukedashjr has joined #bitcoin-core-dev
luke-jr has quit [Ping timeout: 268 seconds]
lukedashjr is now known as luke-jr
luke-jr has quit [Client Quit]
luke-jr has joined #bitcoin-core-dev
___nick___ has joined #bitcoin-core-dev
hex17or has quit [Remote host closed the connection]
hex17or has joined #bitcoin-core-dev
commmon has joined #bitcoin-core-dev
common has quit [Ping timeout: 250 seconds]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
earnestly has quit [Ping timeout: 252 seconds]
c_arc has joined #bitcoin-core-dev
Henrik has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
vasild has quit [Remote host closed the connection]
vasild has joined #bitcoin-core-dev
saranshsharma has quit [Remote host closed the connection]
saranshsharma has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
dermoth has quit [Ping timeout: 252 seconds]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
jespada has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
saranshsharma has quit [Remote host closed the connection]
c_arc has joined #bitcoin-core-dev
saranshs_ has joined #bitcoin-core-dev
saranshs_ has quit [Remote host closed the connection]
saranshsharma has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<laanwj>
jarolrod: blocked them
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
Nebraskka has quit [Quit: Good day old chaps]
Nebraskka has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
commmon has quit [Remote host closed the connection]
commmon has joined #bitcoin-core-dev
smartin has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
saranshsharma has quit [Remote host closed the connection]
vysn has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
Nebraskka has quit [Quit: Good day old chaps]
Nebraskka has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
saranshsharma has joined #bitcoin-core-dev
saranshsharma has quit [Ping timeout: 245 seconds]
mikehu44 has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
adiabat has quit [Ping timeout: 252 seconds]
adiabat has joined #bitcoin-core-dev
<jonatack>
meshcollider: was looking into it too and updated that assertion helper in #23136 ⎦˚◡˚⎣
<gribble>
https://github.com/bitcoin/bitcoin/issues/23136 | test: update fee rate assertion helper in the functional test framework by jonatack · Pull Request #23136 · bitcoin/bitcoin · GitHub
c_arc has joined #bitcoin-core-dev
<S3RK>
#proposedwalletmeetingtopic two descriptors generating same scriptpubkey
c_arc has joined #bitcoin-core-dev
<vasild>
laanwj: right, a "node" victim.com:80 that never speaks bitcoin p2p would propagate less and fall out of addrmans. So a rate from a well propagated real bitcoin node with public ipv4 address and port 80 would give an upper bound. If that is not high enough to be considered as a dos attack, then a lower number will also not be.
<bitcoin-git>
bitcoin/master f529290 Hennadii Stepanov: Merge bitcoin-core/gui#439: Do not show unused widgets at startup
<bitcoin-git>
bitcoin/master 489060d Hennadii Stepanov: qt: Do not show unused widgets at startup
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<_aj_>
vasild: would it propogate less? i didn't think whether you'd tested a node influenced its propogation?
<vasild>
_aj_: I did not test whether it will propagate less, but the point is that it is an _upper bound_ (even if it propagates equally well). But anyway, I _guess_ it will propagate less because it will drop from some addrmans.
<vasild>
during gossip we don't test a peer (try to connect to it) and we gossip it regardless, but I think this "initial" propagation is not enough to get the peer in everybody's addrmans.
<_aj_>
vasild: no it's not, but all propogation is just repeats of this "initial" propogation
<vasild>
getaddr?
fedecuci has joined #bitcoin-core-dev
<_aj_>
vasild: hmm, does that count for a non-trivial number of addresses?
<laanwj>
oh crap, had to shut down the node to move around a few things, a disk is full
<jnewbery>
whether or not an address is actually a viable peer does not affect how well it propagates in addr gossip
<vasild>
_aj_: I don't know
<_aj_>
jnewbery: it does for getaddr; normal propogation you'll relay before you test it, but for getaddr there's a decent chance you'll have dropped a bad address before you get the getaddr request
<_aj_>
vasild: could be significant for nodes that aren't online all the time, but i wonder if that's a plausible set of nodes for creating a botnet in the first place
<vasild>
anyway, I do not insist that a junk address propagates worse than a real one. I insist that it propagates worse, or equally well (it does not propagate better for sure). So, a number from a real node will be an upper bound.
<_aj_>
vasild: the other thing is you could relay "secret-nuclear-facility.gov:22" and then wait for the cia to start going after node operators with "why are you trying to hack into our nuclear facilities" ? i don't know if anyone still overreacts to connection attempts in this day and age like that though
<vasild>
:)
* _aj_
remembers telnet'ing to the smtp port for some AusCERT computers and getting a stern talking to back in his uni days
<vasild>
my !=8333 port node is getting 5 incoming connections per minute
<laanwj>
i wonder if logic like "don't connect to ports under 1024" or such makes sense
<laanwj>
i mean if we're talking about old school sysadmins getting pissed about connections, that was usually the threshold below not to mess around with :)
<jnewbery>
_aj_: right, that's why I referred to addr gossip specifically, which I think is what matters more here. getaddr requests won't return bogus addresses that are IsTerrible()
<laanwj>
and on UNIX-like operating systems you'd need to run bitcoind as root to do that
<vasild>
in case anybody is curious how many incoming connections his node is getting (and lazy to type wretched bash commands), assuming debug=net is switched off on the node: bitcoin-cli logging '["net"]' && sleep 3600 && bitcoin-cli logging '[]' '["net"]'
<bitcoin-git>
bitcoin/master 7830cd0 Hennadii Stepanov: qt, refactor: Keep OptionsDialog in the main event loop
<bitcoin-git>
bitcoin/master 59f7ba4 Hennadii Stepanov: qt, refactor: Keep CoinControlDialog in the main event loop
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[gui] laanwj merged pull request #336: Do not exit and re-enter main event loop during shutdown (master...210516-loop) https://github.com/bitcoin-core/gui/pull/336
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
Henrik has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<fedecuci>
Hi guys, I am curious, how many people have a very strong understanding of the Bitcoin protocol and source code? I am talking about people that are comfortable with at least 80% of the codebase and would know almost immediately where to go to fix a bug in case it arises. Any estimate?
<fedecuci>
Also please let me know if this is not the place to ask such questions and I won't anymore of course.
c_arc has joined #bitcoin-core-dev
kpcyrd has left #bitcoin-core-dev [#bitcoin-core-dev]
mikehu44 has quit [Ping timeout: 245 seconds]
c_arc has joined #bitcoin-core-dev
mikehu44 has joined #bitcoin-core-dev
jespada has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
bitdex has quit [Quit: = ""]
c_arc has joined #bitcoin-core-dev
Henrik has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
c_arc has joined #bitcoin-core-dev
<TallTim>
I'd like to report using addnode to sync bitcoin core client with my personal full node has sped up my sync time. Thanks again to sipa for the advice.
<sipa>
:)
c_arc has joined #bitcoin-core-dev
<laanwj>
nice!
c_arc has joined #bitcoin-core-dev
<TallTim>
I appreciate the work you put in. Its obvious core has continually improved. Thank you.
<shiza>
+1
jtrag has quit [Quit: <----- is PODAK (Passed out drunk at keyboard), and he has somehow managed to quit/disconnect...]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<jamesob>
Are there people who're attesting to release binaries using opentimestamps?
<bitcoin-git>
bitcoin/master f9b633e Hennadii Stepanov: qt, wallet: Move activity progress dialog from data member to local
<bitcoin-git>
bitcoin/master 4a024fc Hennadii Stepanov: qt, wallet, refactor: Move connection to QObject::deleteLater to ctor
<bitcoin-git>
bitcoin/master f6991cb Hennadii Stepanov: qt, wallet: Add LoadWalletsActivity class
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[gui] hebasto merged pull request #342: wallet: Move wallets loading out from the main GUI thread (master...210521-wallet) https://github.com/bitcoin-core/gui/pull/342
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
c_arc has joined #bitcoin-core-dev
<sipa>
jamesob: i'm interested in knowing whether "-flto" and/or "-fdata-sections -ffunction-sections -Wl,--gc-sections" are possible/beneficial with our current compiler suite; what would be a good way to have your test infrastructure benchmark things?
saranshsharma has quit [Remote host closed the connection]
Henrik has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
c_arc has joined #bitcoin-core-dev
kexkey has joined #bitcoin-core-dev
<cfields>
sipa: +1, I'd like to know about lto as well. It seems mature enough across the board to switch to imo, as long as there are no obvious regressions.
<cfields>
(IIRC last time you tested it there were some weird slowdowns)
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
tralfaz has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] jonatack opened pull request #23146: Test transactions conflicted by double spend in listtransactions (master...test-txns-conflicted-by-double-spend-in-listtransactions) https://github.com/bitcoin/bitcoin/pull/23146
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<cfields>
sipa: blah, good point about mixed-use codebases. I guess https://github.com/sipa/minisketch/pull/51 is kinda a counterpoint to disabling the warning wholesale, as it pointed out something legal but logically broken.
<sipa>
cfields: FWIW, libsecp256k1 does assume that some signed integer behavior is actually well-defined (and it has compile-time assertions to check that), which means it's not fully C language neutral
<sipa>
(not UB though; only parts of signed integer behavior that are implementation defined)
Talkless has joined #bitcoin-core-dev
<sipa>
cfields: but i do think that we probably want to disable unsigned-integer sanitizers wholesale for minisketch
gleb7 has quit [Ping timeout: 252 seconds]
<laanwj>
disabling unsigned-integer sanitizers for cryptographic code makes a lot of sense
<cfields>
ACK, will just do it there. I'm still surprised that this happens rarely enough for our tests to pass with only a few exceptions. Guess it is pretty specific to crypto/mathy stuff.
<sipa>
we already pretty much do that
<sipa>
it's disputable whether minisketch is cryptographic, but it's pretty mathy :)
yanmaani has quit [Ping timeout: 276 seconds]
yanmaani has joined #bitcoin-core-dev
<laanwj>
right, it would have been nice if C had explicit wraparound and non-wraparound arithmetic, but this works
<sipa>
compilers actually do make use of this, FWIW; sometimes using signed integer as a loop variable is faster, because the compiler can assume it can't run forever
<sipa>
even if it never takes on a negative value
<cfields>
sipa: heh, I remember that as an ancient gcc bug. hope that's not still the case :)
AaronvanW has quit [Remote host closed the connection]
smartin has quit [Quit: smartin]
<laanwj>
not related to signed/unsigned or wraparound but i recently learned that on RISC-V 64-bit, explicitly using 64-bit loop counters can be much faster, as it doesn't have 32-bit arithmetic, so if the compiler can't reason that your value won't wrap, it will add AND (1<<32)-1 everywhere ... this is pretty annoying for code that needs to be fast on 32-bit hardware too
lightlike has joined #bitcoin-core-dev
<sipa>
cfields: not sure what you're referring too, but it may well not be a bug; a for (int x = 0;; x++) { ... } loop, which doesn't modify x in the body is guaranteed to not run forever for example (because that would require a signed int overflow, which is UB)
<laanwj>
of course, this only matters for really tiny loops, as in micro-benchmarks, normally the work actually done in the loop dominates
<cfields>
laanwj: I wonder if that's a case that int_fast32_t is suited for?
<sipa>
hmm, what is int_fast32_t on x86_64 and riscv64?
<laanwj>
lets see
emcy_ has joined #bitcoin-core-dev
promag_ has joined #bitcoin-core-dev
common has joined #bitcoin-core-dev
<cfields>
sipa: blah, I can't remember it now, but it was a relatively widely-known missed (safe) optimization. So maybe the loop count is known.
dodo__ has joined #bitcoin-core-dev
<laanwj>
both int_fast32_t and int_fast64_t are 64 bit on 64-bit RISC-V
adiabat_ has joined #bitcoin-core-dev
javi404_ has joined #bitcoin-core-dev
lukedashjr has joined #bitcoin-core-dev
Guest65 has joined #bitcoin-core-dev
sturles_ has joined #bitcoin-core-dev
diego has joined #bitcoin-core-dev
<cfields>
same on x86_64.
<sipa>
that makes sense
<sipa>
it's not universal though... iirc 64-bit multiplication and division are slower on x86_64 than 32-bit ones
mikehu44_ has joined #bitcoin-core-dev
Guest65 has quit [Quit: Connection closed]
lightlike has quit [*.net *.split]
Talkless has quit [*.net *.split]
luke-jr has quit [*.net *.split]
jespada has quit [*.net *.split]
emcy has quit [*.net *.split]
mikehu44 has quit [*.net *.split]
commmon has quit [*.net *.split]
adiabat has quit [*.net *.split]
jarthur has quit [*.net *.split]
dviola has quit [*.net *.split]
dodo has quit [*.net *.split]
upekkha has quit [*.net *.split]
promag has quit [*.net *.split]
sturles has quit [*.net *.split]
javi404 has quit [*.net *.split]
Lightsword has quit [*.net *.split]
cryptolightning has quit [*.net *.split]
lukedashjr is now known as luke-jr
dodo__ is now known as dodo
cryptolightning has joined #bitcoin-core-dev
cryptolightning has quit [Changing host]
cryptolightning has joined #bitcoin-core-dev
lightlike has joined #bitcoin-core-dev
promag has joined #bitcoin-core-dev
mekster66 has quit [Read error: Connection reset by peer]
mekster66 has joined #bitcoin-core-dev
rockhouse3 has joined #bitcoin-core-dev
jespada has joined #bitcoin-core-dev
jarthur has joined #bitcoin-core-dev
Lightsword has joined #bitcoin-core-dev
upekkha has joined #bitcoin-core-dev
promag_ has quit [Ping timeout: 265 seconds]
<shiza>
Functional tests runner defaults to as many jobs as virtual processors? And, shouldn't it default to one job for consistency with "make check"?
rockhouse has quit [Ping timeout: 265 seconds]
Victorsueca has quit [Ping timeout: 265 seconds]
rockhouse3 is now known as rockhouse
tripleslash has quit [Read error: Connection reset by peer]
jarthur has quit [Quit: jarthur]
jarthur has joined #bitcoin-core-dev
<laanwj>
that makes sense if they're different instructions; for RISC-V there's work on an extension that adds explicit 32-bit arithmetic (as part of more general bit manipulation extensions)
<laanwj>
shiza: have you tried that it runs faster in that case? the functional tests tend to peg 100% CPU already here so i don't think it'd make a difference
dongcarl has quit [Read error: Connection reset by peer]
<laanwj>
oh, sorry, read it wrong, thought you meant defaulting to number of cores + 1
dongcarl7 has joined #bitcoin-core-dev
<shiza>
If a random functional test tends to peg to 100% CPU already, why at all default to more than 1 or 2?
<shiza>
Alright, then I haven't written anything.
<shiza>
I should try it around more, before being sure it feels weird.
luke-jr has joined #bitcoin-core-dev
<shiza>
I suppose "make check" honors equivalence with "make -j 1 check". :thonking:
<shiza>
But I don't know.
<shiza>
Sometimes I've used "make -j TARGET" and it somehow exploded exponentially, but that's a topic for another day.
luke-jr has quit [Client Quit]
<shiza>
Well not exponentially, but exploded further than the number of virtual processors.
luke-jr has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<cfields>
shiza: -j launches every possible build job simultaneously. It's not intended to be bounded by cpu count.
<cfields>
If you use a bare -j, you probably want -l too.
glix_ has joined #bitcoin-core-dev
<shiza>
It looked like -j was being passed to nested makes, but I imagine how -l would help, didn't knew that, thanks.
jnewbery_ has joined #bitcoin-core-dev
_aj__ has joined #bitcoin-core-dev
_aj__ has quit [Changing host]
_aj__ has joined #bitcoin-core-dev
__nick__ has joined #bitcoin-core-dev
<cfields>
Yes, nested "$(MAKE)" invocations will share the same jobqueue, but manual "make"s will start over, potentially launching new parallel builds.
glix has quit [Ping timeout: 265 seconds]
_aj_ has quit [Ping timeout: 265 seconds]
gribble has quit [Ping timeout: 265 seconds]
jnewbery has quit [Ping timeout: 265 seconds]
___nick___ has quit [Ping timeout: 265 seconds]
Evel-Knievel has quit [Ping timeout: 265 seconds]
<cfields>
-l doesn't always help a ton though. Sometimes the jobs ramp up faster than the load can reflect.
Evel-Knievel has joined #bitcoin-core-dev
bijoo has joined #bitcoin-core-dev
<shiza>
Remembering now, every project demonstrates parallel make useless when matured enough.
<shiza>
"Useless". Not exactly.
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<laanwj>
i don't know about useless? bitcoin core's build should have plenty of potential parallelism, i once saw a screenshot of someone building on a 64-core machine, all cores 100%, though probably this won't be the case in the latter parts of the process during linking etc which have to merge a lot of build artifacts
<laanwj>
haven't personally tried with more than 8
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<shiza>
Naturally, multiple Make jobs will work OK most of the time.
<shiza>
But on the CI server it has to work OK all of the time, and it seems the only way to guarantee that is by running make without multiple nested jobs.
<shiza>
Again I mean the only way to guarantee that for every single project generically.
<sipa>
i build bitcoin core with -j48
<sipa>
without ccache it takes a minute or two
<shiza>
If it never fails, let's hope it stays that good forever. But there are a million different projects using or depending on Make.
<laanwj>
fwiw, some other build systems (such as meson/ninja) default to number_of_cores and always assume parallelism
<shiza>
Maybe what I once read was about naive projects getting lost at Make complexity.
<shiza>
Don't remember clearly.
<laanwj>
it's fairly easy with make to make a mistake with regard to ordering dependencies which causes issues (either errors or non-determinism) with high parallelism, if you find such a issue with bitcoin core please report it
<laanwj>
i think it's more likely nowadays for projects to get this correct because everyone has multicore PCs
<sipa>
ccache -C && git clean -dfx && ./autogen && ./configure --with-incompatible-bdb && time make -j48 check
<shiza>
Of course I would, and I doubt I'll find them, I won't be using master normally.
<sipa>
real 2m49.548s
<sipa>
user 53m18.218s
<sipa>
sys 4m41.772s
<sipa>
(which includes 30s of the single-threaded libsecp tests)
<laanwj>
that *is* fast
tripleslash has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
TheRec_ has joined #bitcoin-core-dev
tralfaz has quit [Remote host closed the connection]
TheRec has quit [Read error: Connection reset by peer]
<bitcoin-git>
bitcoin/master bccd1d9 Samuel Dobson: Remove -rescan startup parameter
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<cfields>
sipa: I'm stepping through the individual minisketch ubsan warnings and making sure they're all false-positives before marking them as such. ok if I pm you with a few of the less obvious ones?
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<laanwj>
yes, that one too
<jonatack>
can i add ##22932
<laanwj>
jonatack: added
<laanwj>
anything else?
<laanwj>
#topic Giving fanquake permissions in the repo to block users (meshcollider)
<core-meetingbot>
topic: Giving fanquake permissions in the repo to block users (meshcollider)
<laanwj>
so we have a pretty bad spam/troll problem lately so i think it makes sense, but there doesn't seem to be a fine-grained way to give this permission
<laanwj>
well maybe through the API i need to check
<meshcollider>
Indeed, fanquake seems a sensible choice of person to be given the extra permissions
<achow101>
I think the "maintain" permission can?
<laanwj>
yes
<achow101>
ack
<luke-jr>
NACK
<luke-jr>
fanquake merged the BIP9 consensus change without community consensus, he shouldn't have any access at this point
<meshcollider>
luke-jr: please provide reasoning for your nack
<hebasto>
agree to give additional permissions to fanquake
<meshcollider>
This could also be something which we leave for people to discuss throughout the week and make a decision at next week's meeting too, if that's more comfortable
<meshcollider>
So others that aren't online can weigh in if they have anything to say
<ariard>
meshcollider: yes i agree here
<laanwj>
ok...
<luke-jr>
developers are not supposed to be deciding consensus changes; someone who doesn't understand that isn't suited to having roles that can be abused for it
<laanwj>
i feel really uncomfortable with this behind his back, i'm ending this topic
<laanwj>
any other topics?
<meshcollider>
Sounds good, although he probably won't be up at 3am next week either :)
<gene>
is there a good time to reschedule, so that fanquake can attend?
<laanwj>
i'm sure things can be discussed outside the meeting
<gene>
+1
<jonatack>
laanwj: thanks for adding
<luke-jr>
(I agree he should be present for any such discussion, FWIW)
Guest92 has joined #bitcoin-core-dev
<Guest92>
luke-jr: Seeing how the pr you refer to hasn't been reverted since, doesn't that mean the other maintainers implicitly endorsed it (and thus, should als be fired in your logic)?
<meshcollider>
+1 on discussing when he's online, just thought the meeting was a good place to propose it formally
<meshcollider>
luke-jr: (Which PR is this specifically anyway?)
<luke-jr>
(can rebase if people say they want to review..)
<sipa>
yanmaani: -rescan in happy cases is _never_ necessary; the wallet stores itself up to where it is in sync (since 0.3.21; 2011) and will at startup rescan whatever part is necessary
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] meshcollider opened pull request #23147: trivial refactor: rename DBErrors::RESCAN_REQUIRED to NEED_RESCAN (master...202110_rename_rescan_enum) https://github.com/bitcoin/bitcoin/pull/23147
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<sipa>
and it's very annoying with the introduction of multiwallet, as now wallets can be loaded and unloaded on demand, rather than always being a single wallet at startup thing
<sipa>
so there is a rescan RPC instead now, if you really need it
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
lightlike has quit [Quit: Leaving]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
tralfaz is now known as davterra
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<yanmaani>
luke-jr: sorry, yeah, I mean reindex.
<yanmaani>
luke-jr: yeah, that would be very cool and clean up a lot of code. Does this fix the part where you have to specify the types separately for the docs and for the CLI too?
<yanmaani>
e.g. on lines 566-567 of your patch, it specifies bantime is RPCArg::Type::NUM and absolute is BOOL. But you also need to, in /src/rpc/client.cpp (lines 160-161), specify that bantime and absolute are non-string RPC arguments that need to be converted from JSON.
<yanmaani>
Likewise with the default values, which are (correct me if I'm wrong here) implemented by checking if(null) value = myDefault, but also specified (unchecked!) in the docs. Which is a violaiton of DRY and generally ungainly
c_arc has joined #bitcoin-core-dev
vnogueira has quit [Remote host closed the connection]
vnogueira has joined #bitcoin-core-dev
<meshcollider>
yanmaani: We don't need to typecheck optional parameters that use e.g. get_int, get_str, get_bool, etc. because those functions will typecheck when called
<meshcollider>
setban uses get_str and get_int64
c_arc has joined #bitcoin-core-dev
bomb-on has joined #bitcoin-core-dev
__nick__ has quit [Ping timeout: 252 seconds]
bijoo has quit [Quit: Client closed]
Guest64 has joined #bitcoin-core-dev
<Guest64>
Guys, hello. Tell me who's in the subject. I send a certain amount of money from Bitcoin Core to a Bitcoin address, the commission is generally acceptable. But the balance of the wallet itself is reduced by an amount that is 42 times more than the amount of funds sent. I canceled the operation. What can be wrong?
<yanmaani>
meshcollider: ohh, right
<yanmaani>
So the need for that would be a separate patch, yes?
<yanmaani>
(1) default values, (2) non-string arguments in RPC client, and (3) RPCTypeCheck
<meshcollider>
yanmaani: as I said, we don't need RPCTypeCheck? Not sure what you mean
<jonatack>
yanmaani: have a look in src/univalue/lib/univalue_get.cpp for the get_int, get_str, get_bool, etc. type checking, if you're curious
vysn has quit [Ping timeout: 250 seconds]
<yanmaani>
meshcollider: I'm asking if luke-jr's patch would obviate the need for RPCTypeCheck.
<yanmaani>
Or if that would be a separate thing.
<yanmaani>
(Or if it's not needed in new code)
<yanmaani>
jonatack: right, but that only works for primitive/normal types, right?
c_arc has joined #bitcoin-core-dev
<jonatack>
yanmaani: best to review it :) ...from looking at it quickly, the patch seems to add named args. so that for instance, instead of: